Boundary Diagrams That Satisfy a NIST 800-171 Assessment

A boundary diagram that reflects how your environment handles CUI earns immediate credibility in a NIST SP 800-171 assessment. Assessors look for an external system boundary, key internal boundaries, and the control points that monitor, control, and protect communications.

Assessor expectations

NIST SP 800-171 Rev. 2 sets the baseline with SC.L2-3.13.1. NIST states that you monitor, control, and protect communications at external boundaries and key internal boundaries. The CMMC Level 2 Assessment Guide builds on that and calls for evidence that those boundaries exist in your design, not in a slide deck. The guide treats the system of interest as the set of assets that process, store, or transmit CUI, plus the assets that provide security protection for those assets.

NIST SP 800-171A names the assessment objects for boundary protection. The assessor reviews your list of key internal boundaries, system design documentation, boundary protection hardware and software, configuration settings, and audit records. A diagram that aligns to those objects saves time and reduces follow-up.

Two simple signals tell an assessor that your diagram will stand up:

The diagram matches the SSP narrative for the same system.
The diagram shows where CUI flows, and where controls enforce policy.

For background on how DoD defines scope, see our overview of CMMC scoping and the CUI boundary.

Boundary drawing method

Start with the system of interest. Draw the outer boundary that encloses every asset that processes, stores, or transmits CUI. Name the tenant, data centers, facilities, and network segments that anchor that edge.

Mark key internal boundaries next. Separate control zones where you enforce policy. Common examples include identity planes, administrative networks, virtual network segments, and enclave-to-enterprise gateways. Show which systems enforce those boundaries.

Trace CUI data flows. Draw arrows for ingress and egress at the external boundary, and between internal zones. Label the protocols or services that carry CUI. Call out encryption, filtering, or inspection at each crossing.

Place boundary protection components at the crossings. Name the firewalls, proxies, gateways, conditional access policies, and mail hygiene that monitor and control traffic. For each component, show a configuration anchor the assessor can verify, such as a device name or policy object.

Tie logging and monitoring to the same points. Identify the SIEM, mailbox auditing, and network telemetry that record boundary events. Point to the system that stores those audit records.

End with a legend and scope statement that repeats asset inclusions and exclusions. The legend locks your notation. The scope statement links the diagram to the SSP section and the asset inventory.

Scope contents

The CMMC Scoping Guide Level 2 directs contractors to map assets into five categories. The diagram should make those categories visible at a glance, or in a companion callout:

CUI Assets that process, store, or transmit CUI.
Security Protection Assets that provide security protection for CUI Assets.
Contractor Risk Managed Assets that connect to CUI Assets.
Specialized Assets such as OT, IoT, or government furnished equipment with constrained control application.
Out-of-Scope Assets that do not connect to CUI Assets under the assessment.

The CMMC Level 2 Assessment Guide treats the set of CUI Assets and Security Protection Assets as the heart of scope. Draw the edge that encircles them, then show how Contractor Risk Managed Assets and Specialized Assets connect through controlled interfaces. Keep Out-of-Scope Assets off the diagram, or park them in a pale zone with a single labeled connection to avoid confusion.

Map the diagram one-to-one with the asset inventory. Use the same names, or add a lookup table. If the assessor can walk from a symbol to a line item and then to a device or policy, you remove debate over scope during evidence collection.

Common diagram mistakes

Avoid problems that trigger rework and extra interviews:

Org charts drawn as networks. Assessors need the system design, not the reporting chain. Draw systems, interfaces, and control points.
Flat drawings that skip internal boundaries. If you encrypt at rest and in transit but never show where trust breaks change, the diagram fails SC.L2-3.13.1 intent.
Generic product icons without configuration anchors. Name the device, tenant, subscription, or policy so the assessor can verify settings.
Cloud edges drawn as a single cloud. Name the tenant, the region, and the boundary service that enforces policy at each crossing.

Microsoft cloud boundary considerations

Microsoft publishes GCC High and DoD service descriptions for organizations that handle DoD CUI or ITAR-related data. Microsoft validates eligibility before it provisions those environments. Microsoft 365 Government GCC High and DoD run as separate sovereign offerings with unique boundaries and endpoints. Microsoft 365 GCC runs as a data enclave of Commercial, with a different boundary model. Microsoft also states on the public sector blog that Microsoft 365 Commercial does not support FedRAMP. That distinction affects how you draw trust boundaries for DFARS 252.204-7012 flows.

Draw the tenant edge with care:

Label the tenant, the sovereign cloud, and the region. Add the public endpoints or service tags that define entry points you allow.
Show Microsoft-operated boundary services you use, such as Exchange Online Protection, SharePoint external sharing controls, or Azure AD Conditional Access. Draw them as control planes with policy names the assessor can confirm.

Do not collapse provider responsibilities into your boundary. Microsoft’s service accreditation boundary, and Microsoft’s support operations, sit outside your system boundary for assessment evidence. Your diagram should show where your control ends and where the provider’s managed service begins.

The Microsoft Product Placemat for CMMC 2.0 can help you plan features, but Microsoft labels it a Preview. Treat it as a planning aid, not as evidence in an assessment package.

If you plan, build, or migrate a GCC High tenant, align this diagram work with the system description and scope decisions you document in the SSP. Our SSP guide explains how to keep those documents consistent over time.

Evidence alignment

Assessors test SC.L2-3.13.1 by walking the diagram and pulling proof at each boundary. Prepare two evidence threads in advance:

Design evidence. Provide the diagram, the SSP boundary narrative, and a list of key internal boundaries. Attach device inventories for boundary hardware and software.
Operational evidence. Provide configuration exports, policy screenshots, and audit records from boundary control points. Include samples that show communications monitored, controlled, and protected at the crossings you drew.

NIST SP 800-171A names these artifacts as assessment objects. The CMMC Level 2 Assessment Guide, and the CMMC Assessment Process, direct assessors to confirm that the external boundary and key internal boundaries exist in design, and in operation. If your diagram anchors both threads, you shorten test time.

Two practical tips improve traceability without clutter:

Put short evidence IDs on the diagram near each control point. Use the same IDs in your evidence index.
Add a page that lists each boundary crossing, the control that enforces it, and the exact file or dashboard that shows current state.

Notation that works

You do not need a tool-specific format. You need a drawing that a third party can read in a few minutes. Use a simple legend, stick to two line styles, and label every interface.

Two notations help in cloud-heavy environments:

Identity boundary. Draw a distinct lane for the identity plane, and show where Conditional Access, MFA, and privileged admin roles sit. Link those to the policies that gate access to CUI data paths.
Egress control. Draw outbound paths from the enclave through mail gateways, DLP controls, and web proxies. Show the point that filters or blocks exfiltration from CUI repositories to public endpoints.

Keep the latest version in source control with the SSP, the asset inventory, and the scoping workbook. That keeps names synchronized across the package.

For broader context on how assessment evidence maps across the requirement set, review our overview of NIST 800-171 to CMMC Level 2 mapping.