In-scope systems

Scope starts from the service commitment: whatever stores, processes, or transmits customer data in delivering the audited service belongs inside — the production environment, the deployment pipeline that changes it, the identity provider gating access, the monitoring stack, and the corporate processes that hire and equip the people running it all. Vendors performing controls on your behalf enter the boundary as subservice organizations. The result is written down in the system description, which is where a reader goes to learn what “in scope” meant for your audit.

Because the boundary is management’s to draw, it is also management’s to gerrymander — and reviewers know the moves. The classics: scoping to a single product while selling three, attesting a hardened enclave that customer data never actually lives in, excluding the analytics pipeline where production data gets copied, or leaning on the corporate network audit while the SaaS runs somewhere else entirely. A reviewer’s first test is blunt: does the described system match what we are buying? Reports that fail it get filed under marketing.

Honest scoping runs the opposite direction — draw the boundary around reality, then narrow the criteria categories if cost needs managing. A tight, truthful scope beats a broad, decorative one in every serious review.