- Write down the handful of engineering principles the organization actually applies — defense in depth, least functionality, fail secure — and require new systems and major changes to address them.
- Apply the principles at acquisition too: a product that cannot be configured to the organization's design principles is itself a design decision, and it deserves a recorded one.
3.13.2OFFICIAL STATEMENT BELOWBASIC REQUIREMENTPENDING NIST SME REVIEW
3.13.2 — Secure engineering principles
3.13 System and Communications Protection · NIST SP 800-171 Rev. 2 · The heading label is this site's navigational shorthand; the official language is the statement below.
Official requirement statement (verbatim)
Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.
NIST SP 800-171 Rev. 2 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A — Assessing Security Requirements for CUI ↗Independent interpretation
What this requirement is after
Security has to be designed in, not appended: architectural choices, development techniques, and engineering discipline that make systems defensible by construction. For most small organizations this is less about formal methods than about deliberate design — segmentation, least privilege, and fail-safe defaults chosen on purpose rather than inherited by accident.
Across revisions
Notable relocation: Rev. 3 moves secure engineering to the new System and Services Acquisition family as Security Engineering Principles (03.16.01) — it becomes an acquisition-and-development obligation rather than a communications-protection one.
Mapped practices
Brilliant at the Basics practices that support this requirement
No practice maps to this requirement — deliberately.
The campaign’s twenty practices are a priority list, not a control catalog, and none of them works this requirement’s substance directly. It still applies to you if it is in your contract’s scope: address it through your own implementation and the related artifacts below, and treat the absence of a mapping here as honesty, not permission to skip it.
Doing the work
Implementation considerations and evidence
- Design or architecture records for new systems showing security addressed before build
- A written statement of the engineering principles in use, referenced by project and change reviews
Artifacts
Templates and worksheets with a mapped relationship
No artifact in the library names this requirement yet. The library index groups everything by category and practice.
The other revision
Where this lands in Rev. 3
Provenance
Sources and review status
| Primary sources | NIST SP 800-171 Rev. 2 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A — Assessing Security Requirements for CUI |
|---|---|
| Review status | Pending NIST SME review |
| Content version | 1.0 |
| Updated |