CMMC 3.13.2 (Security Architecture & Engineering): Evidence & What Assessors Actually Check

Control: NIST SP 800-171 Rev. 2 §3.13.2 · CMMC Practice: SC.L2-3.13.2 · Updated June 2026

Plain-English answer

3.13.2 requires you to employ architectural designs, software development techniques, and systems engineering principles that promote effective information security. Two halves to each: identify the security-promoting designs/techniques/principles you use (defense-in-depth, least functionality, segmentation, secure SDLC), and employ them in practice. If you don't develop software, the development objectives apply only as far as you build anything.

Who this applies to

Every organization seeking CMMC Level 2 for a CUI environment. It's where your architecture and configuration choices get tied back to security intent.

Why it matters

3.13.2 is the "did you design for security on purpose?" control. It ties your boundary protection, segmentation, and baseline configuration together into a coherent, documented rationale. It carries a weighted SPRS deduction if unmet (verify the exact value against the DoD Assessment Methodology).

Control lineage

• CMMC Practice: SC.L2-3.13.2
• NIST 800-171 Rev. 2: §3.13.2 — employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.
• NIST 800-171A objectives: [a] architectural designs that promote effective information security are identified; [b] software development techniques that promote effective information security are identified; [c] systems engineering principles that promote effective information security are identified; [d] identified architectural designs are employed; [e] identified software development techniques are employed; [f] identified systems engineering principles are employed.

What the assessor will EXAMINE

• A documented security architecture (defense-in-depth, segmentation, least functionality) showing the designs you rely on.
• Systems-engineering / secure-configuration standards that reflect security principles.
• Secure software development practices where you build software (secure coding, code review, testing) — or documentation that you don't develop in-scope software.
• SSP narrative for 3.13.2 connecting the designs/principles to how the environment is actually built.

What the assessor will INTERVIEW & TEST

• Interview: "What security architecture and engineering principles do you apply, and where do I see them in the build?" — name them and point to the architecture doc + live configuration.
• Test: Trace a named principle (e.g., least functionality, segmentation) to where it's actually implemented.
• Test: If you develop software, review secure-development practice evidence (reviews, testing).

Evidence examples (produce these)

• Security architecture document naming the designs/principles (defense-in-depth, least functionality, segmentation, fail-secure).
• Systems-engineering / hardening standards that operationalize those principles.
• Secure SDLC evidence where applicable (secure-coding standard, code review, security testing) — or a documented non-applicability rationale.
• SSP section 3.13.2 mapping identified principles to where they're employed.

Common failure patterns

• Security exists in pieces but is never documented as an architecture — objectives [a]/[d] can't be shown.
• Principles named in a policy but not actually employed in the build — identify without employ.
• Software developed in scope with no secure-development practices — objectives [b]/[e] fail.
• The architecture document doesn't match the real environment.

SPRS impact & POA&M

SPRS: 3.13.2 carries a weighted deduction (verify the exact value). POA&M: confirm 3.13.2's POA&M eligibility against current CMMC rules before assuming it can be deferred.

Assessor-ready summary

You're good on 3.13.2 when the security-promoting architectural designs, development techniques (where you build software), and engineering principles are identified in writing and demonstrably employed in the live environment, and the SSP ties the two together.

Can you show security was designed in — not bolted on? Get a security-architecture evidence map →

Related: 3.13.1 Boundary Protection · 3.4.1 Baseline Configuration · All control pages

Athena prepares organizations for CMMC Level 2; certification rests with C3PAOs/DIBCAC. Verify all control facts against NIST SP 800-171 Rev. 2, NIST SP 800-171A, and current CMMC rules.