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.
Fail secure. Your defaults are locked down. You whitelist what’s allowed, not blacklist what’s forbidden. When something breaks, it fails safely.
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
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.