Boundary protection is the practice where scoping decisions become visible. Every other practice in your assessment is evaluated within the boundary you define here. Get the boundary wrong and you’re defending a bigger environment than you need to. Get it right and everything else gets simpler. The companion practice, SC.L2-3.13.2, evaluates whether the architecture behind that boundary reflects intentional security design.
What the assessor is actually evaluating
The NIST requirement says to monitor, control, and protect communications at external boundaries and key internal boundaries. In practice, the assessor is checking three things.
Do you know where your boundary is? This is the question that matters most and the one that trips people up first. Your CUI boundary is the line between systems that process, store, or transmit CUI and everything else. The assessor will ask you to show it. If you can’t point to a network diagram and say “CUI lives inside this boundary, and here’s what separates it from the rest of our network,” you have a problem before the assessment even gets going.
For a lot of small contractors, the CUI boundary is their entire network. That’s not wrong, but it means every system, every endpoint, every printer is in scope for all 110 practices. If you can segment, even if it’s a VLAN and some firewall rules, your scope shrinks and your assessment gets more focused.
Is the external boundary protected? This is the firewall question. Traffic coming in from the internet, traffic going out. Deny-by-default is not a suggestion here. It’s a requirement. Your firewall policy must have a deny-all inbound and a deny-all outbound rule at the bottom. Everything above those rules is an explicit allow for traffic you’ve decided your business needs. If you don’t have a dedicated firewall appliance, Windows Firewall or your EDR’s firewall component can satisfy the requirement, but either way the deny-by-default posture has to be there.
The allow rules above the deny-all can be permissive if you can explain why. Allowing all outbound traffic on ports 80 and 443 so the internet works is fine. The assessor cares that the default is deny and that each allow rule has a business reason behind it.
The assessor will also want to see monitoring at this boundary. Somebody should be watching what crosses it. Firewall logs feeding into a SIEM, IDS/IPS inspecting traffic (typically host-based IDS through your EDR, or built into the firewall itself), alerts when something unusual happens. This is where your MSSP earns a lot of their value. They’re typically the ones watching the perimeter 24/7.
Are there internal boundaries, and are they real? If your CUI environment is segmented from the rest of your network, the assessor wants to understand how. The good news is this doesn’t have to be complex. For most small contractors, a corporate network and a guest network is sufficient, assuming everything else makes sense on top of it. VLANs, firewall rules between segments, access control lists. Whatever the mechanism, it should be documented and it should match what’s actually configured. A network diagram that shows segmentation while the switch config has everything on the same VLAN is worse than having no diagram at all.
If your CUI boundary IS your entire network (no segmentation), be honest about it. The assessor would rather hear “our entire network is in scope and here’s how we protect the perimeter” than see a diagram that implies segmentation that doesn’t exist.
Scoping: the conversation that happens before everything else
This practice is where scoping lives. Before anyone evaluates your access controls, your audit logging, your incident response, they need to know what environment those controls apply to. SC.L2-3.13.1 defines that environment.
If you work with an MSSP that also handles compliance program management, scoping was probably one of the first conversations you had. Where does CUI enter your environment? Where does it live? Where does it go? Who touches it? The answers to those questions draw your boundary.
Common scoping patterns for small contractors:
Whole environment in scope. This is the most common and, honestly, the easiest approach for most small contractors. Your entire corporate network is the CUI boundary. Every endpoint, every server, every printer. It sounds like more work, but it means you’re not trying to maintain a separation boundary that’s one misconfiguration away from collapsing. You protect everything the same way and you don’t have to explain to the assessor why CUI definitely can’t reach that one machine that’s supposedly out of scope.
GCC High with managed endpoints. CUI lives in a GCC High tenant (Microsoft 365’s government cloud). Endpoints that access it are Azure AD and Intune joined, managed separately. Think of it like an entirely separate company on a different tenant. The boundary is the GCC High tenant and those specific managed endpoints. If you’re using Azure Virtual Desktops (AVDs) instead of physical endpoints, the boundary is the AVDs themselves, but you need to make sure CUI can’t leak out to however people are connecting to those AVDs.
Enclave approach. This is where contractors try to save money by scoping down to a small enclave. A pair of Azure Virtual Desktops, a PreVeil deployment, a locked-down subset of the network. The theory is sound: smaller boundary means fewer controls to implement. In practice, these get complicated fast. The enclave needs to be truly isolated, which means proving CUI never touches anything outside it. That proof is harder than most contractors expect, and the assessment gets more scrutiny, not less, because the assessor has to verify the enclave boundaries are airtight. For most small contractors, it’s easier and safer to put the whole environment in scope.
Whatever your model, document it. The assessor will ask how you determined your CUI boundary and what’s in scope. “We worked with our MSSP to identify everywhere CUI is processed, stored, or transmitted, and we drew the boundary around those systems” is a solid answer. “Everything is in scope” is also fine and is usually the simplest path.
What a realistic SSP definition looks like
[Organization Name] monitors, controls, and protects communications at the external boundary and key internal boundaries of the CUI environment. The CUI boundary is defined in the network architecture diagram (Appendix [X]) and encompasses [description of in-scope systems: e.g., "the GCC High tenant, managed endpoints, and the on-premise file server segment"].
External boundary protection is provided by [firewall/UTM appliance] configured with a deny-by-default posture. All inbound and outbound traffic is restricted to explicitly authorized ports, protocols, and destinations. Firewall rules are reviewed at least [quarterly/annually] and documented. [MSSP name] manages the firewall configuration, monitors traffic through [SIEM platform], and provides 24/7 alerting on anomalous boundary activity.
Internal boundary protection between the CUI segment and the general corporate network is enforced through [mechanism: VLAN segmentation, internal firewall rules, ACLs]. Traffic between segments is restricted to authorized services and monitored by [MSSP name] through the SIEM.
Network architecture diagrams are maintained and updated when significant changes occur to the environment. The CUI boundary definition and scoping decisions are reviewed at least annually as part of the security program review.
A few things to notice:
It defines the boundary explicitly. “The CUI boundary encompasses [these specific things].” The assessor shouldn’t have to guess what’s in scope.
It commits to deny-by-default. This isn’t optional. Deny-all inbound and deny-all outbound at the bottom of the firewall policy is required. Your allow rules above that can be permissive if they’re justified, but the default must be deny.
It names who manages what. If your MSSP manages the firewall and SIEM, say so. The assessor will want to talk to them about it.
It addresses both external and internal boundaries. Even if your internal boundary is simple (one VLAN separation), document it.
How to present your evidence
When the assessor gets to SC.L2-3.13.1, have these ready:
Your network diagram. This is the single most important piece of evidence for this practice. It should show every network segment, where CUI systems live, what separates them from everything else, and where traffic flows. Label the CUI boundary clearly. The tool doesn’t matter (Visio, Draw.io, Lucidchart, whatever makes sense), as long as the diagram is current and someone in the room can explain every part of it.
A word of warning: most contractors don’t have a usable network diagram when they start this process. What they have is something like a file called “network map.txt” with a few server IP addresses in it. That’s not a diagram. If you’re starting from scratch, this is one of the first things your MSSP or IT person should build, and it’s worth getting right because the assessor will reference it throughout the entire assessment, for this practice and many others.
Firewall rules. Not a 200-page dump, but the rule set with an explanation of the deny-by-default posture. Be ready to show the actual firewall interface. The assessor may ask about specific rules, particularly any allow rules. Know why each one exists.
SIEM or monitoring evidence. Dashboards, alert examples, log ingestion showing that boundary traffic is actually being monitored. If your MSSP runs the SIEM, they should be ready to pull this up and explain what they’re watching for.
Internal segmentation evidence. Switch configs showing VLANs, internal firewall rules between segments, ACLs. Whatever mechanism separates CUI systems from the rest of the network. If you claim segmentation on the diagram, be ready to prove it in the configuration.
Scoping documentation. How you determined your CUI boundary. This could be part of your SSP, a standalone scoping document, or meeting notes from when you and your MSSP worked through it. The assessor may ask how you decided what’s in scope and what’s not.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Common failures
No defined CUI boundary. The assessor asks where CUI lives and nobody can answer definitively. No diagram, no scoping documentation, no clear line between in-scope and out-of-scope systems. Without a defined boundary, the assessor can't evaluate whether it's protected, and every other practice becomes harder to assess.
A flat network with no segmentation. Every system on the same subnet, no VLANs, no internal firewall rules. This puts everything in scope for every practice. It's not automatically a failure for this practice, but it makes every other practice harder and it signals that boundary protection wasn't given much thought.
A network diagram that doesn't match reality. The diagram shows three segments. The switch config shows one VLAN. This is worse than having a flat network because it tells the assessor you drew a picture without implementing anything behind it.
No deny-all rules at the bottom of the firewall policy. Deny-by-default means there must be a deny-all inbound and a deny-all outbound rule at the bottom of your firewall policy. Everything above is explicitly allowed. If those deny-all rules don't exist, you don't have deny-by-default, and this is a specific control requirement. Allow rules can be permissive (allowing ports 80/443 outbound is fine) as long as there's a business reason, but the default at the bottom must be deny.
No monitoring at the boundary. A firewall exists, but nobody is watching what crosses it. No SIEM ingestion, no alerting, no regular review. The requirement says "monitor, control, and protect." Having a firewall covers "control." Without monitoring, you're missing a third of the requirement.
A clean network diagram with a clearly labeled CUI boundary. Firewall rules that make sense for the business with a deny-by-default posture. Evidence that traffic is actually being monitored, whether that's a SIEM dashboard, IDS alerts, or regular log review reports. Internal segmentation that matches the documentation. Someone in the room who can point to the diagram and explain every boundary decision. And when the diagram, the firewall config, the SIEM, and the verbal explanation all tell the same story, the assessor moves on.
If you use an MSP/MSSP
Boundary protection is typically one of the most MSSP-heavy practices. Your MSSP is probably the one who configured the firewall, manages the rules, monitors the traffic, and set up whatever segmentation exists. This is their wheelhouse.
Your MSSP should be in the room for this practice. They should be able to pull up the firewall interface, walk through the rule set, show the SIEM dashboards, and explain the monitoring and alerting posture. If the assessor asks “who manages your firewall?” the answer should be sitting right there.
Here’s how the split usually works:
What’s typically on you (the contractor):
- Knowing your CUI boundary (where CUI enters, lives, and moves)
- Approving firewall rule changes that affect business operations
- Understanding the network diagram well enough to explain it at a high level
- Reporting any new CUI workflows that might change the boundary
What’s typically on the MSSP:
- Firewall configuration and management
- SIEM deployment, monitoring, and alerting
- IDS/IPS management if deployed
- Network segmentation design and implementation
- Maintaining and updating network diagrams
- Reviewing firewall rules on a scheduled basis
- Being ready to demonstrate all of the above to the assessor
If your MSSP also handles compliance program management, the scoping conversation probably happened early. They helped you identify the CUI boundary, designed the segmentation around it, and built the monitoring to watch it. That’s the ideal scenario: the people who drew the boundary are the same people who defend it, and they’re in the room to explain it.
A good network diagram is the single most useful piece of evidence in a CMMC assessment, and it's useful far beyond this practice. AC, AU, SC, SI practices all reference the environment, and the diagram is what grounds everyone in the same picture. Invest time in getting it right. Label the CUI boundary. Show every segment. Mark what protects each boundary. Keep it current. The assessor will come back to this diagram throughout the entire assessment.
This page covers SC.L2-3.13.1 from NIST SP 800-171 Rev 2 (3.13.1). The guidance here is based on experience in real CMMC assessments and is intended to help you prepare. It is not legal or compliance advice. Your organization’s situation is unique, and you should work with qualified professionals for formal assessment preparation.