Security Engineering

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

Quoted verbatim from NIST SP 800-171 Rev. 2 §3.13.2.Source

An assessor determines each objective separately. “Mostly implemented” is not a result — every objective below has to stand on its own.

1. [a]

   architectural designs that promote effective information security are identified;

   1 example covers this

2. [b]

   software development techniques that promote effective information security are identified;

   No example covers this objective yet. Submit your own example.

3. [c]

   systems engineering principles that promote effective information security are identified;

   1 example covers this

4. [d]

   identified architectural designs that promote effective information security are employed;

   1 example covers this

5. [e]

   identified software development techniques that promote effective information security are employed; and

   No example covers this objective yet. Submit your own example.

6. [f]

   identified systems engineering principles that promote effective information security are employed.

   1 example covers this

Objective text quoted verbatim from NIST SP 800-171A via the CMMC Level 2 assessment guide.

• addresses[a][c][d][f]

  SC.L2-3.13.2 · Security Engineering

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

  • [a]

    architectural designs that promote effective information security are identified;

  • [c]

    systems engineering principles that promote effective information security are identified;

  • [d]

    identified architectural designs that promote effective information security are employed;

  • [f]

    identified systems engineering principles that promote effective information security are employed.

  Reference architecture and landing-zone guardrails for an OSC that buys rather than builds

  CCControlVerdict Corpus@cv-corpusOSCJul 31, 2026

  Community is just starting — add yours. No verdicts yet.

  Implementation

  AO coverage. Claims objectives [a], [c], [d], and [f] — identifying and employing architectural designs and systems engineering principles. Objectives [b] and [e] (software development techniques) are not claimed here: this organization develops no software that runs in or touches the enclave. Vendor software assurance is handled through purchasing requirements and the risk-assessment process, not through internal development practice, and the SSP records that determination rather than asserting a secure-SDLC.

  Architectural designs identified [a]. A short written reference architecture fixes five patterns: the enclave is its own spoke with no shared admin plane; identity is the primary perimeter (SSO plus device compliance); CUI has one authoritative labeled store; management interfaces live on a separate network with their own credentials; and no enclave resource carries a public IP.

  Systems engineering principles identified [c]. Least functionality (deploy the smallest service tier that meets the need), defense in depth (no single control is the only thing between the internet and CUI), fail-closed defaults, minimize trust relationships between systems, and design-before-deploy review for anything that touches CUI.

  Employing the designs [d]. Terraform modules encode the patterns, so the default path produces a compliant resource. Landing-zone policy denies public IPs, unencrypted storage, and storage accounts without private endpoints. A deployment that needs to deviate fails policy and must carry an approved architecture review record.

  Employing the principles [f]. The architecture review checklist is a required section of the change ticket for any new enclave system: what data class, what boundary it lands behind, what identity it uses, what happens when its dependency fails, and what is being removed rather than added. Reviews are signed by someone other than the requester.

  Maintenance. Reference architecture reviewed annually and after any platform migration. Guardrail policy exemptions expire in 90 days. Rejected or deviated designs are kept so the reasoning is auditable.

  Accepted gap. A legacy on-prem MRP system predates the reference architecture and cannot be re-platformed into the spoke pattern. It is documented as a standing deviation on an isolated VLAN with its own review date and a migration line item in the roadmap.

  What the evidence looks like

  • Enclave reference architecture document with version history
  • Landing-zone policy definitions (deny public IP, require encryption, require private endpoint)
  • Terraform module repository with peer-review history for enclave modules
  • Two completed architecture review checklists, including one that forced a design change
  • Standing deviation record for the legacy MRP system

  Environment

  ~140-person electronics supplier. No in-house product software; the enclave is SaaS plus a small cloud landing zone managed as code.

  Tools

  • Terraform
  • Cloud landing zone

  Edit history

  · No edits yet