How to define an audit scope: a practical guide

A scope statement can look complete until someone asks where the customer file went.

MicroApz Security · Updated 2 November 2026

A team preparing for an assessment often starts with a familiar sentence: “The scope is our customer support platform.” It sounds clear until someone asks what happens when an agent downloads an attachment, signs in through the company identity service, or calls a remote-support supplier.

Those questions do not automatically mean every laptop and supplier belongs inside every assessment boundary. They do mean the decision needs a reason. An effective scope describes the service being assessed, the dependencies that matter, and the decisions behind what is included or excluded.

Open the phone-size infographic for larger text ↗

At each step, ask who can access the data, what can change, and who owns the dependency.

What should an audit scope include?

Start with the service, the activities it performs, the locations and people involved, the information it handles and the technology and suppliers it relies on. The exact boundary depends on the assessment and its applicable requirements. A SOC 2 system description, for example, serves a different purpose from an ISO management-system scope.

Map the control plane, not only the data plane

The customer’s request may travel through the web application and database, but a privileged identity provider, deployment pipeline or cloud administrator can change the service without appearing in that transaction. Trace both the path taken by data and the administrative paths that can change access, configuration or recovery. Record shared services and their control owners even when the eventual examination treatment is a separate decision.

Resolve discrepancies between the diagram and observed configuration before signing off. An inventory export is a starting population, not proof that its discovery coverage is complete.

Do not decide the boundary by copying an asset list. Trace a real activity first. The asset list then helps you check whether you missed a dependency.

A practical five-step scoping workshop

1. Choose a representative activity. Pick a normal customer journey and an exception, such as a support escalation.
2. Trace data and decisions. Sketch where information enters, moves, is stored, exported and deleted. Use synthetic data in the workshop.
3. Find dependencies. Include identity, endpoints, backups, administration and suppliers in the conversation—even when their final treatment is undecided.
4. Assign an owner and evidence. Ask who can explain each dependency and what record could substantiate the answer.
5. Challenge and document the boundary. Record inclusions, exclusions, assumptions and open decisions. Check the result against the assessment requirements with the appropriate assessor or adviser.

Worked example: three questions behind one service

Consider the support scenario above. The following rows are illustrative; your evidence and assessment treatment will depend on your environment.

A scope record you can copy

What a useful decision looks like

Illustrative record: “Agents may download attachments to managed laptops. The endpoint team owns device configuration; support owns the handling process. Include the endpoint dependency in the assessment discussion because a local copy can contain customer data. Verify download settings and retention before the boundary is approved. Open: confirm whether deletion is enforced; endpoint owner to report by [date].”

Notice the difference between a dependency to investigate and a final assessment decision. If the supplier cannot access customer data during an approved support session, record how that was established and who accepted the exclusion. If evidence is missing, leave the decision open rather than treating an assumption as a fact.

Questions readers often ask

Does a shared identity service automatically need a full separate assessment? Not necessarily. Its role, control responsibilities and treatment depend on the assessment. Document the dependency and discuss the boundary with the relevant assessor.

When should the scope be revisited? When the service, data flows, locations, access model or important suppliers change—and at the review points required by your programme.

Three mistakes that create rework

• Writing only a product name. The service may rely on shared systems that need explicit treatment.
• Treating “outsourced” as an answer. The supplier may operate the control, but responsibilities and evidence still need to be understood.
• Hiding unknowns. An unresolved dependency is more useful as an assigned decision than an undocumented exclusion.

What should you do next?

Take one important service into a 45-minute workshop with its business owner, application owner, identity or infrastructure representative and supplier manager. Leave with a one-page flow and an open-decision list. Validate the boundary against the relevant assessment before approving it.

A 45-minute workshop agenda

Minutes 0–10: agree the customer-facing service and one representative transaction. 10–25: draw the data and access paths. 25–35: challenge shared services and supplier dependencies. 35–45: assign unresolved decisions and agree who will confirm the assessment boundary. The output is a decision record, not a promise that every listed dependency is automatically in scope.

This is a practical working method, not a complete standard-specific scoping assessment.

Source and scope: The AICPA SOC resources describe the SOC service and criteria landscape; the ISO/IEC 27001 catalogue describes the information-security management-system standard. The workshop and examples above are MicroApz implementation guidance; determine the actual assessment boundary with the applicable criteria and assessor.