Scope of the System
The scope domain tests whether you can draw a defensible line around a system and categorize it correctly, because everything downstream - baseline selection, assessment, authorization - depends on that line.
Defining the authorization boundary
NIST SP 800-37 treats a system as a discrete set of information resources with a defined boundary. The authorization boundary includes every component that processes, stores, or transmits the system's data, plus the people, processes, and connections needed to operate it, including interconnections to other systems and external providers. Anything inside the boundary must be assessed or covered by an inherited common control. Elements the agency cannot directly control, such as the underlying hypervisor of an IaaS provider, sit outside the boundary - but the risk does not vanish. It is carried through the provider's authorization and documented as an interconnection or supply chain consideration.
Categorization under FIPS 199
- Identify information types using NIST SP 800-60 and assign provisional impact values (low, moderate, high) for confidentiality, integrity, and availability.
- Apply the high-water mark: overall categorization is the highest value across the three objectives.
- Special factors, such as law enforcement data or a national security link, can raise the provisional value; the AO may adjust with justification.
- Record the result in the SSP and the agency system inventory.
Worked example
A grants-tracking application runs on agency servers but authenticates through an enterprise identity provider (IdP) and writes backups to a shared service. The IdP is a common control: it lives inside the enterprise boundary, its evidence is inherited, and the application team does not re-assess it. The backups, however, contain application data, so backup storage falls inside the application boundary and must be assessed. The IdP relationship is documented as an interconnection with the inherited control noted in the SSP.
Traps that cost marks
- Categorizing from one objective and ignoring the others.
- Assuming shared infrastructure is automatically out of scope; data location drives scope.
- Omitting development or test environments that use production data or share production credentials.
- Leaving boundary and interconnection detail out of the SSP, so assessment and authorization have no baseline.