Writing · Compliance scoping

The Certificate Arrived. Then the Controls Fell Apart.

For many years, I've worked across IT operations, data centers, infrastructure, security, and compliance. Over that time, I've watched the job change. We used to measure success by the systems we ran, the controls we deployed, and the tools we bought.

Today, successful leaders start elsewhere: they learn how the business operates and how it makes money.

That shift matters most at the very first step of any compliance program, the step many companies rush past: scoping.

The pressure to check the box

The request usually sounds familiar:

• A customer asks for a SOC 2 report.
• A prospect wants ISO 27001 or HITRUST certification.
• A contract requires NIST 800-171.
• The board says we need a formal compliance program.

Leadership wants the report or certificate, and the fastest path seems to be applying the framework to everything. It feels thorough, but it usually backfires.

Frameworks matter. They give a program structure and build customer trust. But a framework only tells you which controls to consider. It doesn't tell you where they belong. That answer comes from the business.

What happens when you skip scoping

It's a common pattern across every framework. A company applies every control to every department to pass its first assessment. It's a checkbox exercise, and it works, until the auditors leave.

Within a year or two, the most basic controls stop working:

• Changes go live without review.
• Incidents go undocumented.
• Disaster recovery only exists on paper.
• Nobody tracks control performance or collects evidence.

The problem usually isn't the people or the framework. It's scope. Marketing, finance, and HR face the same control burden as the teams that build and deliver the product. People outside core delivery teams can't see why the controls matter to their work, so they quietly stop following them.

Poor documentation makes it worse. A checkbox program is built to pass an audit, not to run a compliance program. Evidence is gathered once a year for the auditor instead of being produced in daily work. It ends up scattered: tickets in one system, spreadsheets on a shared drive, and screenshots in someone's inbox.

When a process owner leaves, that part of the program goes with them. Every audit becomes a fire drill to rebuild proof that should have been collected all along.

Understand the business first

You can't scope what you don't understand.

Before touching a framework, I learn how the business operates, how it generates revenue, and what data it needs to protect. That understanding clarifies where real risks lie, so the program focuses on what matters most. In practice, it comes down to five areas:

1. Follow the revenue. Start with what customers pay for. Know which products generate revenue, how they're delivered, and which systems keep them running. A company selling a single SaaS platform is scoped very differently from one selling hosted infrastructure, managed services, and consulting.
2. Follow the data. Scope must track data. Know what data you collect, where it lives, how it moves, and who can access it. Customer records, health data, controlled unclassified information (CUI), and payment details each require different systems to be in scope. A sales tool that exports customer lists or a support platform that handles sensitive tickets belongs in scope, even if it sits outside the core product.
3. Know what you've promised. Customer contracts, security commitments, and regulations often define scope more precisely than framework guidelines. If a contract commits to protecting data in a specific environment, that environment is in scope. If an internal system has no regulatory or customer footprint, it may not need to be within the audited boundary.
4. Map the dependencies. No product runs in isolation. Identity providers, cloud platforms, and key vendors support what customers buy. Some processes are always in scope, no matter what the company sells. HR onboarding and offboarding is one: background checks, policy sign off, and security training at hire, and prompt access removal when someone leaves, decide who can reach the systems inside the boundary, and auditors test them every year. Good scoping draws the boundary, then maps where the business crosses it.
5. Let risk set priorities. Once revenue and data locations are clear, true risks emerge. An outage in a core delivery system or a breach of customer data hurts the business far more than a gap in a back office tool. Risk should dictate control rigor, not a framework checklist.

Building lasting ownership

Building business understanding takes more than a kickoff questionnaire. It requires business acumen and time spent with the teams who design, build, and operate the product.

Engineers and developers know how the product is built and modified, which systems handle real customer data, and where documentation falls short. Operations teams know how systems run every day: how they're monitored, who responds when something breaks, and which third party dependencies matter.

A compliance leader who speaks both languages can ask the right questions and recognize when an answer doesn't add up. One candid conversation with a lead engineer or an operations manager will reveal more about scope than a hundred generic surveys.

When controls fit existing workflows, they last. Change management mirrors how teams already roll out changes. Incident response follows established escalation paths. Engineers and operators follow controls that make sense and quietly route around those that don't.

Rebuilding the program around the business

Fixing an overscoped program starts with executive alignment. With leadership support, you can narrow the scope to the systems, services, people, and data directly involved in product delivery, reinforcing the program from the top down.

GRC leadership must also ensure the program runs between audits:

• Clear documentation. Every control clearly described with a single owner, defined evidence output, and storage location.
• Scheduled collection. A defined artifact collection schedule (monthly, quarterly, or annually, automated where possible) so evidence builds naturally between audits.
• Assessor alignment. Document the finalized scope boundary, such as a SOC 2 system description or an ISO 27001 scope statement, and review it with your auditor before fieldwork begins.

Once the new scope is formalized, the payoff is real. Audit effort drops, costs come down, and remaining controls have owners who understand why they matter.

What this means for technology leaders

Leaders in security, compliance, and IT rarely fail on technical grounds. They fail when they don't connect with the business. We aren't just system owners and tool buyers anymore. We translate how the business works into a program that protects it.

So when executive leadership asks to launch a compliance program, don't start with the auditor's checklist. Start with the business:

"Show me how we make money and where our data lives."

← More writing