When scoping a security compliance audit, which boundaries must be fixed first, and what goes wrong when one is left vague?

## Why scope comes first Every audit conclusion is bounded. A certificate, an attestation opinion or an authorization covers a defined set of systems, places, time and requirements - and nothing else. Most painful audits are painful because scope was argued about after fieldwork started. Fixing it first is the difference between a planned engagement and a year of surprises. ## The four boundaries | Boundary | Question to settle | Example from the primary texts | |---|---|---| | **Systems** | Which components are inside, and which connected systems are outside? | NIST SP 800-37 defines the authorization boundary as all components to be authorized, excluding separately authorized connected systems | | **Locations** | Which offices, data centres, cloud regions and remote sites? | Physical safeguards and facility controls only apply where the scope says | | **Period** | Point in time, or a period over which controls must operate? | PCI DSS asks assessors to sample across the entire period the assessment covers | | **Criteria / controls** | Which requirements or criteria are tested? | The AICPA criteria allow a practitioner to report on one or more Trust Services categories, with all criteria for each category usually addressed | ## Systems: the boundary pulls The hardest boundary is the system one, because connectivity drags systems in: - The **CMMC rule** applies its assessments to contractor systems that process, store or transmit FCI or CUI, that provide security protections for such systems, or that are **not logically or physically isolated** from them. A flat network turns the whole estate into scope. - **PCI DSS** says it is not acceptable for an entity to apply requirements to only a sample of its environment, and not acceptable for an assessor to review only a sample of requirements. Sampling happens within scope; it never shrinks it. Scoping is therefore often an engineering exercise first: isolate the in-scope systems so the boundary can be drawn credibly. ## Inherited controls Many controls are operated by someone else - a cloud provider, a managed service, a parent organization. Scoping must say how each is evidenced: 1. **List the inherited controls** and the provider operating each. 2. **Obtain the provider's own assurance** (an authorization package, an attestation report or a certificate) and check its scope and date cover what you rely on. NIST SP 800-37 describes a customer reviewing the provider's authorization package, including the time elapsed since the results were produced. 3. **Record the split of responsibility.** For Level 3, the CMMC rule requires a customer responsibility matrix and body of evidence showing which requirements the contractor meets and which it inherits from a cloud provider. 4. **Test your side**: the controls you must operate for the inherited one to work. ## What goes wrong with vague scope - **Scope creep in fieldwork**: the auditor finds an unlisted system connected to an in-scope one and must either add it or qualify the conclusion. - **Period mismatch**: a period starting before a control existed guarantees exceptions for the early months. - **Criteria mismatch**: the report covers security only, but the sales team promises availability; the report cannot support the claim. - **Location gaps**: a data centre left out means its physical controls are untested, even though customer data lives there. - **Inherited-control gaps**: a provider's report covers a different period or service than the one used. ## Changing scope mid-engagement Scope does change - a new product launches, a data centre migrates, an acquisition closes. The safe pattern is to agree the change with the auditor in writing, decide whether the new element is tested for the full period or only from its start date, and make sure the final report or certificate states the change. Silent additions and removals are what create disputes at the end. ## A scoping checklist - Written system description with a diagram of the boundary and connections. - List of locations and cloud regions in scope. - Period start and end, and whether it is point-in-time or period-based. - Criteria or requirements in scope, and any excluded with the reason. - Inherited controls, providers and their assurance documents. - Owners for each control area, so evidence requests have a destination. A strong answer names the four boundaries, shows how connectivity and inheritance complicate the system boundary, and gives concrete failure modes of vague scope.