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. The principle is defense in depth — multiple overlapping layers so that if any single control fails, others compensate.

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 security design principles applied in the system architecture?	Architecture documentation shows deliberate security design decisions
2	Is defense in depth implemented?	Multiple overlapping layers of controls — not a single point of failure
3	Are systems engineering principles applied?	Security considered at design time, 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

---

Implementation

🔒

Step-by-step guides for Microsoft 365, AWS, Azure, and GCP are available to Ancitus clients.

Start a conversation →

---

CMMC Practice ID: SC.L2-3.13.2 | SPRS Weight: 5 points | POA&M Eligible: No