Compliance: Scope

Compliance scope defines the precise boundary of what a compliance program covers — which entities, systems, processes, data types, and jurisdictions fall inside the obligation. Misidentifying scope is one of the most consequential errors in compliance management: an overly narrow scope creates unaddressed legal exposure, while an inflated scope wastes resources on activities that carry no regulatory obligation. This page explains how scope is defined, how frameworks use it operationally, and how organizations distinguish in-scope from out-of-scope assets and activities.

Definition and scope

In compliance practice, "scope" refers to the defined universe of applicability for a given regulatory requirement, certification standard, or internal policy. Scope answers four foundational questions: who is subject to the obligation, what systems or processes are covered, where the obligation applies geographically or jurisdictionally, and when it takes effect or lapses.

The Payment Card Industry Data Security Standard (PCI DSS), published by the PCI Security Standards Council, defines scope as all system components that store, process, or transmit cardholder data, plus any component that could affect the security of those systems. This definition is significant because it explicitly extends scope beyond the primary data-handling systems to include adjacent infrastructure. Under PCI DSS version 4.0, organizations must formally confirm their cardholder data environment (CDE) scope at least once every 12 months and upon significant changes.

NIST SP 800-37, the Risk Management Framework, uses a comparable construct: the "authorization boundary," which delineates the information system and its components that fall under a single authorization decision. NIST defines the authorization boundary at the system level (NIST SP 800-37, Rev. 2, §2.3), and the boundary determination directly controls which controls apply, which assessments are required, and which inherited controls can be leveraged from shared infrastructure.

For a structured understanding of how scope integrates with broader frameworks, see Compliance Standards Overview.

How it works

Scope determination follows a structured process across most major frameworks. The steps below reflect the general methodology described in ISO/IEC 27001:2022 (clause 4.3) and corroborated by NIST guidance:

  1. Identify the triggering obligation — Determine which regulation, standard, or contractual requirement initiates the scoping exercise (e.g., HIPAA, SOC 2, GDPR, PCI DSS).
  2. Map data flows and asset inventory — Catalog all systems, processes, personnel, and third parties that interact with regulated data or activities.
  3. Apply the framework's inclusion criteria — Use the specific standard's definitions to classify each asset as in-scope, out-of-scope, or conditionally in-scope.
  4. Identify scope reduction mechanisms — Assess whether segmentation, tokenization, or exemptions can legitimately reduce scope without creating control gaps.
  5. Document and approve the scope statement — Formalize the scope boundary with sign-off from accountable leadership, as required by ISO/IEC 27001:2022 clause 4.3 and implied by SOC 2 attestation requirements.
  6. Validate scope continuously — Monitor for changes (new systems, vendors, data types, geographies) that would require scope revision.

The Process Framework for Compliance provides a detailed breakdown of how these steps integrate into a full compliance lifecycle.

Common scenarios

Healthcare organizations under HIPAA — The U.S. Department of Health and Human Services Office for Civil Rights enforces HIPAA's scope through the definitions of "covered entity" and "business associate." A hospital's electronic health record system is unambiguously in scope. A cafeteria management system that never touches protected health information (PHI) is typically out of scope, unless it shares network segments with PHI systems in a way that creates indirect exposure.

Retailers processing payment cards — PCI DSS scope routinely creates disputes around point-of-sale terminals, e-commerce platforms, and third-party payment processors. Using a fully outsourced payment processor that handles all card data can reduce a merchant's scope to SAQ A (the simplest self-assessment questionnaire), provided no cardholder data touches the merchant's own systems.

Cloud environments — The shared responsibility model used by AWS, Microsoft Azure, and Google Cloud partitions compliance obligations between the cloud provider and the customer. FedRAMP, administered by the General Services Administration, requires agencies and their cloud service providers to define an explicit system boundary in the System Security Plan, distinguishing provider-controlled components from customer-controlled components.

Multi-jurisdictional privacy obligations — An organization subject to both California's CCPA (enforced by the California Privacy Protection Agency) and the EU's GDPR faces overlapping but non-identical scopes. GDPR scope is triggered by offering goods or services to EU data subjects or monitoring their behavior, regardless of where the organization is established. CCPA scope is triggered by revenue thresholds, data volume thresholds, or revenue from data sales, as defined under California Civil Code §1798.140.

Decision boundaries

Scope decisions produce binary classifications — in-scope or out-of-scope — but the boundary conditions require careful analysis. Three contrasts define the most consequential decision points:

Connected vs. isolated systems — A system physically or logically separated from regulated data by a validated network segment (firewall, VLAN, air gap) may qualify as out of scope. A system on the same flat network as regulated data is in scope even if it never directly accesses that data, because it could affect the security of in-scope systems (the PCI DSS "connected to" standard).

Data at rest vs. data in transit — Some frameworks apply different control sets depending on whether data is stored or transmitted. HIPAA's Security Rule applies to electronic PHI in all forms; PCI DSS applies to cardholder data regardless of transmission or storage state.

Direct obligation vs. inherited obligation — A business associate under HIPAA carries direct obligations under the Security Rule but may inherit certain controls from a covered entity's program where documented in a Business Associate Agreement. Inherited controls do not eliminate the associate's independent obligation — they define which party is accountable for which control.

For source materials and regulatory citations supporting scope analysis, see Compliance Public Resources and References.

References

Read Next

Compliance: Standards Overview This page covers the definition and scope of compliance standards, how they operate in practice, the scenarios where they... Process Framework for Compliance This page covers the core architecture of such frameworks — how they are built, where enforcement obligations attach, how they... Compliance Public Resources and References This page catalogs the major categories of public-domain compliance resources available to US-based organizations, explains...