RMFInsider

Building an authorization boundary diagram that survives an AO’s review is one of those tasks that looks simple until you’re staring at a system with a dozen interconnections and no idea where the line actually goes. Get the boundary wrong and everything downstream — your control selection, your POA&M scope, your eMASS package — inherits the mistake. This is the how-to I wish someone had handed me the first time I built one for a real DoD system.

What an Authorization Boundary Diagram Actually Defines

NIST SP 800-37 Rev. 2 addresses this directly in Preparation task P-11, which defines the authorization boundary scope: it includes all system elements that are authorized together, and excludes anything that’s separately authorized. That second half is the part people skip past, and it’s the source of most boundary disputes. A shared service, a connected system, or an interconnected platform that has its own separate ATO is not automatically part of your boundary just because your system talks to it.

So before you draw a single box, answer one question: what set of components is this specific authorization decision covering? Everything inside that set is in scope. Everything with its own independent authorization — even if it’s directly connected — sits outside your boundary and gets represented as an interconnection, not an internal component.

What Goes Inside the Boundary

• Hardware and virtual assets under this system’s direct authorization — servers, workstations, network devices, VMs.
• Software and applications running on those assets that are part of this authorization decision.
• Data flows and internal network segments that stay entirely within the system as you’ve scoped it.
• Any component you’re accepting responsibility for the security posture of, as part of this specific ATO.

What Stays Outside the Boundary

• Systems with their own separate ATO — represent these as external interconnections with a labeled connection, not as internal components.
• Shared infrastructure or enterprise services managed and authorized by a different program or organization.
• Anything you don’t have authority to implement or modify controls on directly — if you can’t control it, you generally shouldn’t be claiming it inside your boundary.

The interconnection itself — the data flow crossing that boundary line — is very much your concern and needs to be documented, even though the system on the other end isn’t. That distinction trips people up constantly: excluding a connected system from your boundary doesn’t mean ignoring the connection.

What AOs Actually Look For

When an AO or their staff reviews a boundary diagram, they’re checking whether the diagram matches the reality of the system — not whether it looks polished. Specifically, they’re looking for:

• Consistency between the diagram, the hardware/software inventory, and the control implementation narrative — if the diagram shows a component the inventory doesn’t list, that’s an immediate red flag.
• Clear labeling of every external interconnection, including the system name, the direction of data flow, and the type of connection.
• A boundary that isn’t drawn suspiciously narrow to avoid claiming components that should reasonably be included — AOs have seen this before and will ask pointed questions.
• Legible, current diagrams — not a screenshot of a whiteboard sketch from eighteen months ago that nobody’s updated since.

Is a Boundary Diagram the Same as a Network Diagram?

Not quite, and conflating the two is another common source of confusion. A network diagram typically shows the technical topology — how devices connect, what subnets exist, where firewalls and routers sit. A boundary diagram answers a narrower, more specific question: what is inside this authorization decision, and where exactly does the authorized responsibility stop. In practice, most ISSOs build them as companion artifacts, with the boundary diagram often overlaid on or derived from the network diagram, but they’re answering different questions for different audiences. An assessor reading your network diagram wants to understand how traffic moves. An AO reading your boundary diagram wants to understand what they’re being asked to accept risk for.

If your program only maintains one combined diagram, make sure it clearly distinguishes the authorization boundary line from the general network topology — a diagram that shows connectivity without a clearly marked boundary line leaves the AO’s staff to guess at exactly what’s being authorized, which is precisely the ambiguity that gets packages sent back.

Common Rejection Reasons

I covered eMASS package rejections broadly in my pre-submission checklist, but boundary diagrams specifically account for a disproportionate share of the kickbacks I’ve seen. The recurring patterns:

Rejection Reason	What’s Really Happening
Diagram doesn’t match the hardware/software list	Someone updated one artifact and not the other after a system change
Interconnections missing or unlabeled	A data flow to an external system exists in practice but was never documented
Boundary drawn too broadly	Components with their own separate authorization got pulled inside the diagram incorrectly
Boundary drawn too narrowly	Components the ISSO doesn’t want to claim responsibility for got quietly left off
Diagram is outdated	System has changed since the diagram was built and nobody updated the artifact

Every single one of these is avoidable with a basic discipline: treat the boundary diagram as a living artifact tied to your hardware/software baseline, not a one-time deliverable you build once and file away.

Where the Diagram Lives in eMASS

Your boundary diagram belongs alongside your other core artifacts in the eMASS package — typically referenced in or attached near your system description and network diagram materials. If you’re still getting comfortable with how eMASS organizes package artifacts generally, eMASS for Beginners walks through the structure before you get into boundary-specific details.

A habit that’s saved me repeated rework: whenever a system change goes through a security impact analysis, check whether that change affects the boundary before closing out the change ticket. It’s a lot easier to update the diagram in the moment than to reconstruct six months of drift right before a reassessment.

This is also where a lot of the friction from earlier in an authorization’s life comes back to bite people. A boundary diagram that was accurate at initial ATO but never revisited through a year or two of ConMon activity is, by the time reauthorization rolls around, describing a system that no longer exists. Treating the diagram as part of your recurring ConMon evidence — not a one-time artifact you check off during the original assessment — is the difference between a smooth reauthorization and a scramble to reconstruct what actually changed.

A Practical Build Process

• Start from your current hardware and software baseline — not from memory, not from an old diagram.
• Identify every component with a separate ATO and mark it explicitly as external, connected via a labeled interconnection.
• Draw the boundary line around everything that remains — the components this specific authorization actually covers.
• Label every data flow crossing the line, in both directions if traffic moves both ways.
• Cross-check the finished diagram against your hardware/software inventory line by line before submission.
• Set a recurring reminder — tied to your ConMon cadence — to revisit the diagram whenever the system changes.

Frequently Asked Questions

Does a connected system need to be inside my boundary?

Not if it has its own separate authorization. Per NIST SP 800-37 Rev. 2’s boundary scope guidance, systems that are separately authorized stay outside your boundary — but the connection between your system and theirs still needs to be documented as an interconnection.

How often should I update the boundary diagram?

Any time the system changes in a way that adds, removes, or reconfigures a component or an interconnection. Tying this review to your existing security impact analysis process for every change is the most reliable way to keep it current instead of rediscovering drift right before a reassessment.

What’s the single most common reason boundary diagrams get kicked back?

Inconsistency with the hardware/software inventory. A diagram that shows components the inventory doesn’t list, or vice versa, is one of the fastest ways to get a package sent back for correction before an assessor even gets to the control narratives.

Should I draw my boundary broad or narrow?

Neither — draw it accurate. Drawing it artificially broad pulls in components you don’t actually control and can’t meaningfully attest to. Drawing it artificially narrow to dodge responsibility for a component that’s genuinely part of the system reads as evasive to an AO’s staff and invites exactly the kind of scrutiny that delays authorization. The right size is whatever set of components this specific authorization decision is actually covering — nothing more, nothing less.

Who should be involved in building the boundary diagram?

In my experience it works best as a collaborative artifact rather than something the ISSO builds alone in isolation. System administrators and network engineers know the actual technical topology; the ISSO owns translating that into an authorization-scoped view and reconciling it against the hardware/software baseline. Building it solo from documentation alone, without validating against the people who maintain the system day to day, is a common way inaccuracies creep in.

If you want a structured way to track boundary changes alongside the rest of your ATO evidence instead of managing it as a one-off file, my RMF Checklist is built to keep this kind of artifact current as your system evolves.