3.13.2 — Security by Design

The One-Liner

If your security is an afterthought layered on top of an insecure architecture, you’re building a castle on sand.

What It Says

Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.

What It Actually Means

Security must be a deliberate design decision, not something added after the architecture is built. That decision is realized as defense in depth — layered protections so that no single control is your last line of defense and, if one fails, the others still stand. The CMMC standard names developing layered protections as a systems security engineering principle, so it works alongside good architecture, not against it. Those engineering principles trace back to NIST SP 800-160, the source the requirement draws on, and they apply across the whole lifecycle: as legacy components age past the point where they can still meet them, that judgment feeds the decision to replace, upgrade, or re-platform. Engineering Trustworthy Secure Systems frames defense in depth, least privilege, and least functionality as architectural choices made at design time — properties you build into the structure, not operational habits bolted on afterward.

Five layers of defense in a well-designed CUI environment:

1. Network — segmentation, firewalls, boundary controls
2. Identity — MFA, least privilege, conditional access
3. Endpoint — hardened configs, EDR, encryption
4. Data — DLP, sensitivity labels, encryption at rest
5. Monitoring — SIEM, alerts, incident response

The assessor isn’t looking for perfect security. They’re looking for evidence that you thought about security architecture and made deliberate decisions — not that things grew organically with security patched in later.

Document your architecture decisions and the rationale behind them.

---

Pass or Fail

Your assessor needs a “yes” to every row:

#	Question	What “yes” looks like
1	Are architectural designs that promote security identified and employed?	Architecture documentation names the security design choices (e.g., network segmentation and trust zones) and they’re actually implemented
2	Are secure software development techniques identified and employed?	Secure coding standards, peer code review, and SAST/DAST in the pipeline — chosen and in active use
3	Are systems engineering principles that promote security identified and employed?	Security built in at design time and carried through the build — not retrofitted

---

What to Have Ready on Assessment Day

Documents they’ll review: System and communications protection policy; system security plan; system design documentation; security architecture documentation; system configuration settings

People they’ll talk to: System or network administrators; personnel with information security responsibilities; system developers; enterprise architects

Live demos they’ll ask for: Mechanisms implementing security design principles in the system architecture

---

The Assessor’s Playbook

These are the actual questions. Have answers ready.

• “Walk me through your security architecture. What layers of defense do you have?”
• “If your firewall fails, what other controls protect CUI?”
• “Was security designed into the architecture or added later?”
• “Show me your architecture documentation — where are the security decisions documented?”
• “How do you evaluate security when making architectural changes?”

Real-World Example

A contractor documented their security architecture as part of their SSP: network segmentation (CUI zone, corporate zone, DMZ), identity layer (Entra Conditional Access with MFA), endpoint layer (Intune-managed devices with Defender), data layer (Purview sensitivity labels with DLP), monitoring layer (Sentinel SIEM). Each layer is documented with what it protects against and what compensates if it fails. The assessor asks ‘what happens if your firewall goes down?’ — the answer: endpoint protection still blocks malware, Conditional Access still enforces MFA, DLP still prevents unauthorized data transfer, and the SIEM alerts on the firewall outage.

---

Where Companies Trip Up

No architecture documentation. Systems grew organically with no deliberate design. Document your current architecture and the security rationale.

Single point of failure. All security depends on one firewall or one control. If it fails, CUI is exposed.

Security retrofitted. Systems built first, security added later — creating gaps where security doesn’t fit naturally.

No compensating controls. Each control stands alone. If one fails, there’s no backup.

---

How to Talk About This

To a CEO or Board

Security is built into our architecture from the ground up. Five layers of defense mean no single failure exposes our CUI.

To an Engineering Team

Defense in depth: network segmentation + Conditional Access/MFA + Intune/Defender + Purview DLP + Sentinel SIEM. Architecture documented with security rationale. Annual architecture review for gaps.

---

Connected Requirements

Requirement	Why it matters here
3.13.1 — Guard the Boundaries	Boundary protection is one layer of the defense-in-depth architecture
3.13.5 — DMZ for Public Systems	DMZ separation is an architectural decision
3.4.2 — Harden Everything	Hardened configs are the endpoint layer of defense in depth