CMMC Level 2 System Boundary Diagram Template (Microsoft 365, endpoints, and any on-prem), with an example you can copy

If you’re preparing for CMMC Level 2, your CMMC system boundary diagram is one of the fastest ways to show assessors you control where CUI lives, how it moves, and what’s in scope.

I like to think of the boundary diagram as the fence line on a property map. If the fence line is unclear, everything becomes an argument. If it’s clear, the conversation shifts to controls, evidence, and accountability.

Below is a reusable template you can copy, plus a worked example for a typical SMB using Microsoft 365, managed Windows endpoints, and a small on-prem network. This isn’t legal advice, and you should align everything with official CMMC and NIST guidance.

What a CMMC Level 2 boundary diagram must communicate (and what gets missed)

At Level 2, I treat the boundary diagram as a scoping artifact first, and a network picture second. Assessors want to see in-scope components that store, process, or transmit CUI, plus anything that protects them (identity, logging, management). They also want to see out-of-scope systems that must stay separated.

The best baseline for scoping language is the DoD’s own guidance, so I keep it nearby while I draw: CMMC Level 2 Scoping Guide (PDF). When I’m mapping controls back to requirements, I also cross-check against NIST 800-171 references (a plain-English starting point helps): NIST SP 800-171 compliance guide.

Here’s what I make explicit on every diagram:

• Where CUI is allowed (Microsoft 365 services, approved endpoints, on-prem servers).
• Trust boundaries (Internet edge, VPN boundary, cloud tenant boundary, admin boundary).
• External dependencies (Microsoft 365, any MSSP/SIEM, backup provider, ticketing tools).
• Shared responsibility (what Microsoft does, what my client does, what my MSP does).
• Data flows (solid arrows for CUI flow, dashed arrows for management/telemetry).

If your diagram doesn’t show how CUI moves, it’s a picture. If it shows flows and boundaries, it becomes audit evidence.

Reusable CMMC Level 2 system boundary diagram template (Microsoft 365 + endpoints + on-prem)

When I build a template diagram for a client, I keep the shape library simple (boxes, arrows, a legend). You can do this in Visio, draw.io, Lucidchart, or even PowerPoint. The tool matters less than consistency.

Template sections (copy these headings into your diagram)

1) Title and boundary statement

• Boundary box title: “CMMC Level 2 System Boundary (CUI Environment)”
• Short note: “Only authorized users and managed devices may access CUI.”

2) In-scope (inside boundary)

• Microsoft 365 tenant: Exchange Online, SharePoint/OneDrive, Teams (only if CUI is permitted there)
• Entra ID (Azure AD): MFA, Conditional Access, admin roles
• Endpoint management: Intune/MDM
• Endpoint protection: EDR (for example, Microsoft Defender for Endpoint)
• Windows endpoints: laptops/desktops used to access CUI
• On-prem segment (if any): firewall, VPN gateway, AD (optional), file server or line-of-business app
• Logging/SIEM: central log collection and alerting (cloud or on-prem)
• Backup system: backup target and restore path

3) Out-of-scope (outside boundary)

• Personal BYOD devices (blocked)
• Non-CUI SaaS tools (marketing, scheduling, design tools)
• Public Internet
• Vendor systems that never touch CUI

4) Flows and legend

• Solid arrow: “CUI flow”
• Dashed arrow: “Management/telemetry”
• Label common paths: HTTPS to M365, VPN tunnel to on-prem, auth to Entra ID, logs to SIEM, backups to repository

To keep labeling consistent, I use a simple naming convention:

Diagram label	Type	Scope	Example	Notes to add
ID-1	Identity	In-scope	Entra ID	MFA, Conditional Access, admin boundary
CLD-1	Cloud service	In-scope	M365 SharePoint	CUI allowed sites only
EP-1..n	Endpoint	In-scope	Win11 Laptop (Managed)	Intune, EDR, Device Hardening
OP-1	On-prem	In-scope	File Server	CUI share, backups, patching
EXT-1	External dependency	Out-of-scope	Non-CUI SaaS	Document separation controls

When Microsoft 365 is in scope, I document it as an external dependency with shared responsibility. If you’re evaluating government cloud options, this can influence design choices; here’s useful context: Microsoft 365 GCC High and CMMC.

Worked example you can copy (SMB using Microsoft 365 + managed endpoints + small on-prem)

I’ll use a common scenario I see when I’m acting as a Business Technology Partner for growing teams: Microsoft 365 for collaboration, Windows devices for work, plus a small on-prem network for a legacy app. Sometimes that “app” supports Restaurant POS Support or Kitchen Technology Solutions, so I’m careful about what touches CUI and what doesn’t.

Copyable example labels (paste into your diagram as-is)

Boundary box title: Example: SMB CMMC L2 Boundary (CUI Environment)

In-scope boxes (inside boundary):

• CLD-1 Microsoft 365 Tenant (CUI): Exchange Online, SharePoint/OneDrive (CUI sites), Teams (CUI team/channel policy)
• ID-1 Entra ID: MFA, Conditional Access, admin roles (separate admin accounts)
• MGMT-1 Intune/MDM: compliance policy, app control, device baselines
• SEC-1 EDR: endpoint telemetry, isolation, investigation workflow
• EP-1 to EP-6 Windows 11 Endpoints (Managed): company-owned, encrypted, Device Hardening applied
• OP-1 Firewall + VPN Gateway: remote access boundary, restrict to managed endpoints
• OP-2 On-Prem AD (optional): if used, document trust with Entra ID
• OP-3 File Server or LOB App: CUI storage or processing (if applicable)
• LOG-1 SIEM/Log Platform: receives M365 audit logs, endpoint logs, firewall/VPN logs
• BKP-1 Backup Repository: immutable or protected backups, tested restores

Out-of-scope boxes (outside boundary):

• EXT-1 Public Internet
• EXT-2 Personal Devices (BYOD): blocked from CUI access
• EXT-3 Third-party SaaS (Non-CUI): HR/payroll, marketing, scheduling
• EXT-4 Vendor/Managed Service Provider: shared responsibility statement, support channels

Arrows (label them):

• EPs → CLD-1: “HTTPS CUI flow”
• EPs → ID-1: “Auth (MFA/CA)”
• EPs → OP-1: “VPN tunnel (CUI flow when accessing on-prem CUI)”
• All components → LOG-1: “Telemetry/logging”
• OP-3 → BKP-1: “Backups (encrypted, monitored)”

In practice, this diagram becomes the anchor for my Cybersecurity Services, Endpoint Security, and Cloud Management deliverables. It also supports Business Continuity & Security planning because it shows restore points, identity dependence, and remote access paths.

Conclusion

A clear CMMC system boundary diagram saves time, prevents scope fights, and tightens your SSP story. I recommend keeping it versioned, tied to your asset inventory, and updated after every Office 365 Migration, Cloud Infrastructure change, or Infrastructure Optimization project.

This post isn’t legal advice. For assessments, I align the diagram with official CMMC and NIST guidance, then document external dependencies and shared responsibility in plain language. If you want a second set of eyes as part of Technology Consulting, Managed IT for Small Business, or an IT Strategy for SMBs, I’m happy to help you build a Secure Cloud Architecture that stands up to scrutiny.