How I work
Scope before framework
A framework tells you which controls to consider. It does not tell you where they belong. That answer comes from the business. Before I touch a control set, I ask one question: show me how we make money and where our data lives.
Five questions
How I draw the boundary
Follow the revenue
Start with what customers pay for, and the systems that deliver it.
Follow the data
Know what sensitive data you hold, where it lives, and who can reach it.
Know what you promised
Contracts and regulations often define scope more precisely than a framework.
Map the dependencies
Draw the boundary, then map every place the business crosses it.
Let risk set priorities
Control rigor should follow business impact, not a checklist.
Between audits
Programs that keep running after the auditors leave
Checkbox programs pass the first assessment, then fall apart: changes go live without review, incidents go undocumented, and disaster recovery only exists on paper. Three habits prevent that.
One owner per control
Every control is clearly described, with a single owner, a defined evidence output, and a storage location. When someone leaves, the control doesn't leave with them.
Evidence on a schedule
Monthly, quarterly, or annual collection, automated in a GRC platform where possible, so proof builds up in daily work instead of in a fire drill before fieldwork.
Scope agreed with the auditor
The boundary is written down, in a SOC 2 system description or an ISO 27001 scope statement, and reviewed with the auditor before fieldwork begins.
Controls that fit how people work
Change management mirrors how teams already ship. Incident response follows existing escalation paths. One candid conversation with a lead engineer or operations manager reveals more about scope than a hundred generic surveys.
Precision, not shortcuts
Good scoping is about precision. Every framework has a baseline that cannot be excluded. Overscoping causes control fatigue; arbitrary underscoping creates blind spots and audit friction.