1Overview
SC.L2-3.13.2 requires that security be built into how systems are designed and developed. It requires that the organization employ architectural designs, software development techniques, and systems engineering principles that promote effective information security, so that security is a property of the system's construction rather than something added afterward. It is a five-point requirement that cannot be deferred on a plan of action.
Security bolted onto a finished system is weaker and costlier than security designed in from the start. This control requires that the organization identify architectural designs, software development techniques, and systems engineering principles that promote effective information security, and then actually employ them. It applies to how systems are architected, how software is developed, and how engineering decisions are made, so that security considerations shape the system as it is built. Its five-point weight reflects that a system engineered without security in mind carries weaknesses that are hard to remedy later.
Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.
The requirement names three categories, architectural designs, software development techniques, and systems engineering principles, and the six assessment objectives pair identification and employment for each. The organization first identifies, within each category, the practices that promote effective information security, then employs those identified practices. The result is that security-promoting approaches are chosen deliberately and applied in how systems are built and maintained.
2The Assessment Objectives
NIST SP 800-171A decomposes 3.13.2 into six objectives: identify and employ security-promoting practices across three categories.
Architectural designs that promote effective information security are identified. Security-promoting designs are chosen.
Software development techniques that promote effective information security are identified. Security-promoting techniques are chosen.
Systems engineering principles that promote effective information security are identified. Security-promoting principles are chosen.
Identified architectural designs are employed. The chosen designs are used.
Identified software development techniques are employed. The chosen techniques are used.
Identified systems engineering principles are employed. The chosen principles are used.
The six objectives pair identify and employ across the three categories. The common gap is between identification and employment: practices are named in policy but not actually applied in how systems are built. The assessor looks for both identification and employment in all three categories.
3Failure Patterns
The failures are about security-promoting practices named but not applied.
Identified but not employed
Naming security-promoting designs, techniques, or principles without actually using them satisfies identification but not employment. The practices have to shape how systems are built.
Security added after the fact
Building systems without security-promoting engineering and bolting on protection later produces weaker results. Employing these practices during design and development builds security in.
One category only
Addressing architecture while ignoring development techniques or engineering principles, or the reverse, leaves categories unmet. All three have to be identified and employed.
4Ownership
This is an architecture and engineering-owned control.
| Role | Responsibility for this control |
|---|---|
| System architects and engineers | Identify and employ security-promoting designs, techniques, and principles. Own the engineering evidence. |
| Developers | Apply the identified security-promoting development techniques. |
| Security or compliance lead | Confirms identification and employment across all three categories. |
5Tooling
The control is largely procedural, delivered by adopted security-promoting engineering practices.
| Objectives | Tooling | What it provides |
|---|---|---|
| [a], [d] | Secure architecture standards | Identified and employed security-promoting designs. |
| [b], [e] | Secure development practices | Identified and employed development techniques. |
| [c], [f] | Systems engineering principles | Identified and employed engineering principles. |
The caveat is that the practices have to be employed, not just documented. A catalog of security-promoting approaches that no project applies satisfies identification but leaves employment unmet. The assessor examines identification and employment across all three categories, so all six objectives have to hold.
6Evidence
The satisfied version of 3.13.2 shows security-promoting practices identified and applied.
| Evidence | What it demonstrates |
|---|---|
| Architecture and engineering standards | Objectives [a], [b], [c]. Security-promoting practices identified. |
| System designs and development records | Objectives [d], [e], [f]. The practices employed. |
The evidence should show security-promoting designs, techniques, and principles identified and then employed in how systems are built. The standards together with the design and development records are the clearest demonstration, and because this control cannot sit on a plan of action, the practices have to be real at the time of assessment.
Security built in beats security bolted on
A system engineered without security-promoting practices carries weaknesses later controls can only patch, so this five-point control asks that such practices be identified and employed across architecture, development, and engineering. Building security into how systems are designed is part of the onsite readiness work this practice does, and it is one of the controls that must be met rather than deferred.
Start CMMC Readiness or call 802-335-26627Sources
- NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.13.2. csrc.nist.gov
- NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.13.2[a] through 3.13.2[f]. csrc.nist.gov
- 32 CFR 170.24, CMMC Scoring Methodology, listing SC.L2-3.13.2 among the five-point basic security requirements. ecfr.gov