Scope, assumptions and system boundaries: drawing the line around a system

A governance record is only as good as the line it draws. Scope and risk rest on a decision that is easy to leave implicit: what counts as this system. SP 800-18 Rev. 1 states the rule directly — “The process of uniquely assigning information resources to an information system defines the security boundary for that system” (lines 538–539) — and SP 800-37 Rev. 2 supplies the other half. The boundary says what is in; the assumptions say what that answer rests on, and assumptions do not last.

The line is assigned, not discovered

The assignment is the boundary. SP 800-18r1 adds that agencies “have great flexibility in determining what constitutes an information system”, and that resources grouped as one system should “generally be under the same direct management control” — budgetary, programmatic or operational authority and the responsibility that comes with it (lines 539–542, footnote 10 at line 562). SP 800-37r2 agrees from the authority side: “Authorization boundaries are determined by authorizing officials with input from the system owner based on mission, management, or budgetary responsibility” (lines 2864–2865). Two organisations can hold identical hardware and draw different lines — both defensible. What makes a line reviewable is that a named authority decided it against stated criteria — and that the record says so.

Inside, outside, and what is shared

The boundary is not “everything we own” or “everything on the network”. SP 800-37r2 separates three external classes. Enabling systems support the system across its life cycle and “are not contained within the authorization boundary of the system”; such a system “may provide common (i.e., inherited) controls” (lines 1567–1572). Other systems interact with it and are also outside the boundary (line 1575). The environment of operation is the ambiguous case: “Certain parts … may be included in the authorization boundary … while other parts may be excluded” (lines 1621–1622), a split that is “specific to the system and … context-driven” (lines 1634–1635). Outside does not mean irrelevant; it means governed elsewhere, inherited, or interfaced with.

            ┌────────────── SYSTEM — authorization boundary ──────────────┐
            │                                                             │
            │   system elements:  people · processes · technology ·       │
            │                     physical / environmental                │
            │   ──── subsystem A ────  ──── subsystem B ────  ──── ... ── │
            │                                                             │
            └────┬────────────────────┬─────────────────────┬─────────────┘
                 │                    │                     │
            enabling system      other system        environment of
            (may supply          (interaction,       operation: parts
             inherited            risk considered)   in scope or out —
             common controls)                         decided, not default

Drawing it too wide or too narrow

SP 800-37r2 prices both errors. Boundaries “too expansive” make “the risk management process unnecessarily complex”, while boundaries “too limited … may unnecessarily inflate the information security and privacy costs” (lines 1656–1661). The counter-pressure is accountability: “The system is included in a single authorization boundary to ensure accountability” (lines 2875–2876). SP 800-128 states the same constraint at component level: each component belongs to one system, and “the authority over and responsibility for each component is with only one system owner” (lines 1197–1199). A component that sits in two systems is owned by nobody.

Criteria for grouping elements

SP 800-18r1 gives the working criteria: resources that “Have the same function or mission objective and essentially the same operating characteristics and security needs”, and that “Reside in the same general operating environment” (lines 557, 572). SP 800-37r2 repeats the same tests for authorization boundaries (lines 1671–1679). Both add the same caveat — SP 800-37r2: the considerations are “not intended to limit the organization’s flexibility” (lines 1683–1686); SP 800-18r1: they “should not be viewed as limiting the agency’s flexibility” (lines 598–600).

Assumptions are the other half of the record

SP 800-39 defines risk framing as the set of “assumptions, constraints, risk tolerances, and priorities/trade-offs” that shape how an organisation manages risk, and requires all four to be identified (lines 693–700, 2243). The strategy then “makes explicit the specific assumptions, constraints, risk tolerances, and priorities/trade-offs used within organizations” (lines 1136–1137). SP 800-37r2 turns that into a task — P-2 takes “Organizational risk assumptions, constraints, priorities and trade-offs” as inputs (lines 2259–2263, 2279–2281) — and SP 800-39 says to write them down: “Organizations document any overarching assumptions” (line 2412). A line is drawn on the belief that a facility, a provider or an interconnection is, or is not, part of this system; when the belief changes, the line is stale.

What the boundary record has to state

SP 800-37r2 formats the work as a task: P-11, “Determine the authorization boundary of the system”, owned by the authorizing official, with design and architecture diagrams, stakeholder and asset information as inputs and one output — “Documented authorization boundary” (lines 2838–2846). Read with the assumption requirement, the record has four parts: what is inside and under whose management; what is outside, and whether it is inherited or interfaced with; the criteria and assumptions the line rests on; and when the decision will be examined again. That list is this sheet’s synthesis, not a quotation.

Revisiting the line

Boundaries are meant to move. “The scope of the authorization boundary is revisited periodically as part of the continuous monitoring process carried out by the organization” (lines 1681–1682), and SP 800-39 feeds results back: assessment “may influence the original assumptions, change the constraints … or shift priorities” (lines 2260–2261). A new provider, a withdrawn shared service, a facility that moves from inherited to in scope — each is a changed assumption, and a reason to re-open the decision rather than let it age.

Level and prerequisites

L2 — operational: draw a boundary, state the assumptions it rests on, keep the record reviewable. Prerequisites: the L1 vocabulary for what is in scope and why, and the L1 account of who answers for an asset. The security plan, baselines and assessment belong to the assurance sheets.

Where to go next

Cybersecurity Governance — the area this sheet belongs to.
Security governance foundations — this sheet’s node.

References

NIST — SP 800-18 Rev. 1, Guide for Developing Security Plans for Federal Information Systems (February 2006) — https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-18r1.pdf — §2 “System Boundary Analysis and Security Controls” and §2.1 “System Boundaries”: the assignment that defines the security boundary, direct management control, the grouping criteria and the flexibility caveat.
NIST — SP 800-128, Guide for Security-Focused Configuration Management of Information Systems (August 2011) — https://doi.org/10.6028/NIST.SP.800-128 — §2.3.4: one component, one system, one system owner, one authorization boundary.
NIST — SP 800-39, Managing Information Security Risk: Organization, Mission, and Information System View (March 2011) — https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-39.pdf — §2.1 the risk framing component (assumptions, constraints, risk tolerance, priorities/trade-offs), §2.3.3 the risk management strategy that makes them explicit, and the Step 1 risk-framing tasks that document them.
NIST — SP 800-37 Rev. 2, Risk Management Framework for Information Systems and Organizations (December 2018) — https://doi.org/10.6028/NIST.SP.800-37r2 — §2.4 system and system elements, §2.5 authorization boundaries, Task P-2 risk management strategy and Task P-11 authorization boundary.