This practice asks: Does your current architecture reflect intentional security design decisions? The assessor doesn’t care whether security was baked in from day one or whether you cleaned up a mess and rebuilt it with security in mind. What matters is that the architecture as it stands today reflects deliberate choices. If your MSSP retrofitted your environment after you started pursuing CMMC, that’s fine. But the old slop needs to be cleaned up and the current state needs to show clear security engineering principles.
What the assessor is actually evaluating
The assessor wants to see that your systems reflect deliberate security architecture. They’ll ask questions about why your environment is configured the way it is. They’re listening for answers that connect your design to security principles.
They’re not looking for theoretical frameworks or lengthy documentation of philosophy. They want to hear: “We segmented our network so compromised assets can’t move laterally.” “Admin accounts are separate from user accounts to limit blast radius.” “MFA is required for all remote access because that’s where the risk is.” Clear thinking about threat and mitigation, expressed through your actual setup.
If you work with an MSP or MSSP, they designed your security architecture. Document that design and have them ready to explain it. The network design, the group policy structure, the conditional access rules. That’s the evidence.
Building blocks of security architecture
For small contractors, focus on three things:
Defense in depth. You have layers. Network segmentation, endpoint protection, email filtering, access controls. Not one magic fix.
Least privilege in the design. Admin accounts are separate. Service accounts have limited permissions. Users don’t run with elevated rights. This isn’t something you patch in later. This ties directly to AC.L2-3.1.2 (separation of user and privileged accounts).
Fail secure. Your defaults are locked down. You whitelist what’s allowed, not blacklist what’s forbidden. When something breaks, it fails safely. Your network boundary design (see SC.L2-3.13.1) embodies this principle.
SSP language that works
Our systems are designed with security embedded from initial architecture. We segment the network into three zones: untrusted perimeter, internal operations, and restricted data handling. Each zone has defined access controls enforced at the boundary. Administrative access is isolated to dedicated admin workstations with separate credentials. Least privilege is the baseline: users receive only the permissions required for their role. MFA is required for all remote access and all administrative actions. Service accounts run with minimal necessary permissions. Email filtering applies multiple checks at least at intake, attachment scanning, and URL inspection. Endpoint protection includes antivirus, firewall, and behavioral detection. This architecture reflects intentional design choices tied to threat modeling and access control principles, not reactive additions.
How to present your evidence
- Network diagram with documented security segmentation rationale
- Access control policy showing least privilege enforcement
- Evidence of separate admin accounts and role-based access
- MFA implementation documentation and configuration
- Defense-in-depth architecture showing layered security controls
Walk the assessor through your environment as built. “Here’s our network diagram. You can see the segments. Here’s why we did it that way.” Pull up your access policy. “This is our least privilege policy. Admins use a separate account. Here’s the evidence of it in action.” Show your MFA implementation. Explain the layers in your email security.
If an MSP built your environment, have them available or provide documentation they created. They can explain the architectural decisions better than anyone. Their design notes, network diagrams, security design documents. That’s your evidence.
The goal is to demonstrate that security was a design principle, not a feature you added later.
Common failures
No articulated rationale. Your network is segmented, but when asked why, you say "that's just how it was set up." Assessors hear "we don't understand our own architecture."
No design documentation. You can't point to any artifact showing that security principles were considered upfront. Everything is just "it's configured this way."
Single layer of defense. You have a firewall. That's it. Everything else is hope.
You explain your architecture. You can articulate why your systems are designed the way they are, with security reasoning behind each decision. You know your own setup.
You have documentation or a resource who does. Design notes, network diagrams, MSP agreements, group policy documentation. Anything that shows security was intentional.
Multiple layers, intentionally placed. You can walk through defense in depth. Network boundaries. Access controls. Endpoint protection. Email filtering. Each layer has a purpose.
If you use an MSP or MSSP
Get them involved in your SSP and evidence package. Have them document the architectural decisions they made. Ask them to explain:
- Why your network is segmented the way it is.
- How least privilege is built into your access model.
- What layers of defense they implemented and why.
- What security principles informed their design.
Their design is your evidence. Their explanation is your credibility.
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
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.
Q&A: What the assessor asks and what good answers sound like
Disclaimer: This page reflects CMMC Level 2 practices as of March 2026. NIST SP 800-171 Rev 2 defines the underlying requirement. Always align your actual SSP and security decisions with your current compliance obligations and your organization’s real threat environment.