CMMC Level 2 Practice 3.13.2: Employ architectural designs, software development techniques, and systems engineering

CMMC Level 2 Practice 3.13.2 requires you to build and operate your CUI environment using secure architecture and secure engineering practices that reduce and contain vulnerabilities before they become exploitable. To operationalize it quickly, define an approved reference architecture for the CUI boundary, enforce secure SDLC and configuration standards, and retain evidence that these requirements are applied in real projects. ¹

Key takeaways:

• Treat 3.13.2 as an engineering control: secure-by-design architecture plus repeatable build and change practices. ²
• Assessors look for proof in real work artifacts: diagrams, standards, tickets, review records, and build/pipeline controls. ³
• Scope matters: focus on the CUI boundary and all systems that store, process, or transmit CUI, including third-party components that touch it. ⁴

Security engineering controls fail most often because they are described as policies instead of being embedded into how systems are designed, built, and changed. CMMC Level 2 Practice 3.13.2 (mapped to NIST SP 800-171 Rev. 2 3.13.2) pushes you toward “prevention by design”: architecture that limits blast radius, and development/engineering techniques that avoid introducing predictable weaknesses. ²

For a CCO, GRC lead, or compliance officer, the fastest path is to translate this requirement into a small set of enforceable guardrails: (1) an approved architecture pattern for the CUI environment, (2) secure configuration and build standards that teams must follow, (3) defined review gates (architecture review, change review, code review where applicable), and (4) an evidence capture routine that makes assessments straightforward. ³

This page focuses on requirement-level implementation guidance you can put into operation without boiling the ocean. It assumes you already have a defined CUI scope/boundary or are finalizing it in parallel. Where software development is not performed internally, this requirement still applies through configuration, integration, infrastructure-as-code, and how you select and govern third-party products inside the CUI boundary. ²

Regulatory text

Excerpt (as provided): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.13.2 (Employ architectural designs, software development techniques, and systems engineering).” ¹

Operator meaning: you must use secure architecture and secure engineering practices to reduce opportunities for attack. That includes: designing segmentation and trust boundaries, choosing patterns that limit privilege and exposure, and using development/engineering techniques that prevent common weaknesses from entering production. Keep proof that these practices are defined, required, and actually followed for in-scope systems. ²

Plain-English interpretation (what the assessor expects)

3.13.2 is about how you build and change systems, not just how you run them. An assessor typically expects to see:

• A documented target architecture for the CUI environment (network and identity boundaries, segmentation, admin pathways, external connections).
• Engineering standards that translate security objectives into concrete rules (secure configuration baselines, hardening standards, approved services, encryption patterns, secrets handling, logging patterns).
• Repeatable gates that prevent unsafe designs/changes from shipping (architecture review, change approval, code review where applicable, infrastructure-as-code review where applicable).
• Evidence in real artifacts from real projects, not a clean policy written last week. ⁵

Who it applies to

Entities: Defense Industrial Base organizations and federal contractors that handle CUI and need CMMC Level 2 alignment. ⁶

Operational context (where it bites):

• The CUI boundary and all systems that store, process, or transmit CUI.
• “Software development” includes traditional application development, but also scripts, automation, configuration, and infrastructure-as-code used to provision or manage the CUI environment.
• Third parties matter if their software, managed services, or platforms are part of the CUI environment or directly administer it. You still need architecture controls and engineering standards for how those services are integrated and governed. ⁷

What you actually need to do (step-by-step)

Use this sequence to operationalize 3.13.2 with minimal ambiguity.

Step 1: Define the “secure-by-design” reference architecture for the CUI boundary

Produce (and approve) a baseline architecture that becomes the default pattern for in-scope systems:

• Trust boundaries: where CUI lives, how it flows, what connects to it.
• Segmentation: separate user, server, admin, and external zones; document permitted paths.
• Identity and privileged access: how admins authenticate, where admin actions occur, and how you isolate admin endpoints.
• Remote access and third-party access: approved methods and control points.
• Central security services: logging, vulnerability scanning, patching, time sync, key management (as applicable). ²

Output: “CUI Reference Architecture” with diagrams and written standards, version-controlled, with an owner and approval record. ³

Step 2: Translate architecture into enforceable engineering standards

Write a short set of standards teams can follow without interpretation:

• Secure configuration baseline for OS, endpoints, and network devices in-scope.
• Secure build/config rules (e.g., no default credentials, hardened images, approved ports/protocols, secure TLS configuration).
• Secrets handling standard (where secrets can be stored, rotation expectations, build pipeline handling).
• Logging and audit standard (minimum events, centralization, retention approach).
• Secure dependency/product intake for third-party components used in the CUI boundary (approved list or risk-based exception process). ²

Keep it tight: if engineers need a meeting to understand the rule, the standard is too vague.

Step 3: Put review gates into the way work gets done

Add mandatory checkpoints that create durable evidence:

• Architecture review gate: required for new systems and material changes that affect trust boundaries, external connectivity, identity, or data flows.
• Change management gate: require security review/approval for changes to firewall rules, IAM policies, admin tooling, logging, and encryption.
• Code/config review gate: require peer review for code, scripts, and infrastructure-as-code that touches in-scope components.
• Exception gate: define how teams request deviations from the reference architecture and standards, with compensating controls and time-bounded approvals. ⁸

Step 4: Implement technical mechanisms that backstop the standards

Policies do not prevent drift. Add controls that make the secure path the easy path:

• Standard hardened images/templates for servers and endpoints used in the CUI boundary.
• Configuration management to enforce baselines and detect drift.
• CI/CD or deployment controls that block releases without required reviews (where applicable).
• Network controls that enforce segmentation (not just diagrams). ²

Step 5: Prove it with recurring evidence capture

Decide what you will capture, where it is stored, and who reviews it:

• Each architecture review produces a record (ticket, meeting minutes, decision log).
• Each significant change has an approval trail and testing/validation evidence.
• Baseline compliance reports (configuration drift reports, template versioning, approved image attestations). ³

Practical tip: store evidence in the same systems engineers already use (ticketing and version control), then export to your GRC repository on a cadence.

Step 6: Map the requirement to control operation (assessment-ready)

Create a simple control statement: “Engineering teams must implement the CUI reference architecture and follow secure engineering standards; security reviews and technical enforcement prevent or detect deviations; evidence is retained for assessment.” Then map each sub-activity to the artifacts you can show an assessor. ⁵

If you use Daydream, this is where it fits naturally: tracking the control narrative, owners, systems, and an evidence collection schedule so you can demonstrate ongoing operation without rebuilding the story every assessment cycle. ³

Required evidence and artifacts to retain

Retain artifacts that show both design and execution:

Architecture & engineering

• CUI boundary definition and data flow diagrams for in-scope systems.
• CUI reference architecture document with version history and approvals.
• Secure configuration standards (OS, endpoint, network, cloud services as applicable).
• Secure SDLC / engineering standard (code review rules, IaC rules, secrets rules). ²

Operational proof

• Architecture review records (tickets, minutes, sign-offs, decision logs).
• Change management records for security-significant changes (who approved, what changed, validation evidence).
• Baseline compliance/drift reports and remediation tickets.
• Exception register for deviations, with compensating controls and expiration/renewal approvals.
• Samples of pull requests / peer reviews for in-scope code, scripts, or IaC. ³

Third-party integration

• Approved product/service list for in-scope environments or documented intake process.
• Contracts/SOW language or security requirements for third parties administering in-scope systems (access paths, logging, authentication). ⁴

Common exam/audit questions and hangups

Expect assessors to probe these areas:

1. “Show me the architecture.” They will ask for diagrams that match reality, plus how you keep them current.
2. “Where is this enforced?” They will ask how standards are enforced technically (templates, drift detection, controls), not just documented. ²
3. “Prove you follow it.” They will request multiple examples across systems: a new build, a change, and an exception. ³
4. “What about cloud/SaaS/third parties?” They will ask how you ensure architecture boundaries and admin controls still apply when an external provider runs part of the stack. ⁴

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating 3.13.2 as a policy-only control.
  Fix: require architecture reviews and show records tied to system changes. ³

• Mistake: No defined “reference architecture,” only one-off diagrams.
  Fix: publish a standard pattern for the CUI boundary and force deviations through an exception process. ²

• Mistake: Assuming “we don’t develop software” means “not applicable.”
  Fix: include scripts, integrations, configuration, and infrastructure-as-code in scope where they affect CUI systems. ²

• Mistake: Evidence is scattered and rebuilt for audits.
  Fix: define an evidence register and recurring capture. Daydream (or your GRC system) should mirror the control steps and required artifacts so owners know what to produce and when. ³

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific practice. The practical risk is assessment failure or delayed contract eligibility if you cannot demonstrate secure engineering practices with objective evidence aligned to CMMC Level 2 and NIST SP 800-171 Rev. 2. ⁹

Practical 30/60/90-day execution plan

Use phases (not calendar promises) to drive execution.

First 30 days (stabilize scope and standards)

• Confirm the in-scope CUI boundary and list of in-scope systems. ⁴
• Draft and approve the CUI reference architecture (minimum: network zones, admin pathways, external connections, key security services).
• Publish “minimum engineering standards” for in-scope changes: architecture review triggers, change approval triggers, and baseline configuration sources of truth.
• Stand up an evidence register: what artifacts, where stored, who owns, and review cadence. ³

By 60 days (embed gates into workflow)

• Implement architecture review workflow in ticketing (required fields: system, change type, data flow impact, approval).
• Add change management requirements for security-significant changes; require security sign-off for defined categories.
• Start collecting proof: select a few representative systems and ensure each has a diagram, a baseline, and at least one documented review event. ²

By 90 days (show operating maturity)

• Expand reference architecture adoption to all in-scope systems; document exceptions with approvals and expirations.
• Implement technical enforcement where feasible (templates, drift detection, pipeline checks) and retain outputs as evidence. ²
• Run an internal assessment dry-run: pull an evidence packet for multiple systems and validate that artifacts align to the control narrative. ³

Frequently Asked Questions

Does 3.13.2 require a formal “secure SDLC” program even if we only configure commercial products?

You still need secure engineering techniques for how you configure, integrate, and change in-scope systems. Document standards and review gates for configuration changes and automation that affect the CUI boundary. ²

What’s the minimum architecture documentation an assessor will accept?

Provide current network/data flow diagrams for the CUI boundary plus a reference architecture that defines your standard pattern and security services. Pair it with review records that show the diagrams drive real decisions. ³

How do we handle deviations from the reference architecture?

Use a formal exception process with documented risk, compensating controls, an approver, and an expiration or re-approval trigger. Keep an exception register and show examples. ²

Are infrastructure-as-code templates and scripts in scope for 3.13.2?

If they provision or manage systems that store, process, or transmit CUI, treat them as engineering artifacts subject to peer review and change control. Retain repository history and review evidence. ²

What evidence is strongest for 3.13.2 during a CMMC assessment?

Real project artifacts: architecture review tickets, approved diagrams tied to system IDs, change approvals for security-significant changes, and proof that baselines are enforced or monitored for drift. ³

How do third-party managed services fit this requirement?

If a third party administers or hosts in-scope systems, your architecture must define their access paths and control points. Keep contractual/security requirements plus operational evidence like access approvals and logging/monitoring integration. ⁴

Footnotes

1. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170

2. NIST SP 800-171 Rev. 2

3. DoD CMMC Program Guidance

4. 32 CFR Part 170

5. DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2

6. 32 CFR Part 170; DoD CMMC Program Guidance

7. NIST SP 800-171 Rev. 2; 32 CFR Part 170

8. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance

9. DoD CMMC Program Guidance; 32 CFR Part 170