System and Communications Protection 3.13.2 (3.13.2)
Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.
Get Full GuidanceWhat Is This CMMC Control?
This control requires organizations to build security into their systems from the ground up by using proven design principles, secure coding practices, and engineering methods that make systems inherently more secure. Rather than bolting security on after the fact, organizations must integrate security considerations throughout the entire system lifecycle—from initial design through development, deployment, and ongoing modifications. This applies to new systems, major upgrades, and to the extent possible, updates to existing legacy systems.
Control Intent
To ensure that information systems are designed, developed, and maintained using established security engineering principles that create inherently secure and resilient systems, rather than relying solely on add-on security controls after systems are built.
Who This Control Applies To
- •Organizations developing new information systems that will process, store, or transmit CUI
- •Organizations performing major upgrades or significant modifications to existing systems
- •System architects and designers responsible for system architecture and design decisions
- •Software development teams building custom applications or system components
- •System integrators combining multiple components into organizational systems
- •Organizations procuring systems where they can influence design and development requirements
- •IT departments managing system lifecycle activities including upgrades and modifications
Not Applicable When
- •The organization exclusively uses unmodified commercial off-the-shelf (COTS) products with no custom development or significant configuration
- •The organization has no systems undergoing new development, major upgrades, or significant modifications during the assessment period
- •The organization operates only legacy systems with no planned or ongoing changes where applying security engineering principles is technically infeasible
- •The system is scheduled for decommissioning within the assessment period with no development or modification activities
Key Objectives
- 1Integrate security engineering principles into the design and architecture of organizational systems to establish foundational security from inception.
- 2Apply secure software development techniques and practices throughout the system development lifecycle to reduce vulnerabilities and security weaknesses.
- 3Implement systems engineering principles that promote defense-in-depth, least privilege, and other security concepts to create resilient systems resistant to threats.
- 4Ensure security considerations are incorporated into system upgrades and modifications, including legacy systems to the extent technically feasible.
Sample Self-Assessment Questions (Partial)
Are you currently developing any new systems or applications that will handle CUI?
Are you planning or performing any major upgrades to existing systems that process CUI?
Implementation Approaches (High-Level)
Secure System Development Lifecycle (SDLC) with Security Gates
Formal SDLC process that incorporates security requirements, design reviews, and verification at each phase from requirements through deployment
Security Architecture Framework with Design Patterns
Established security architecture framework defining approved design patterns, security principles, and technical standards that must be applied to all systems
Secure Coding Standards and Developer Training Program
Documented secure coding standards combined with mandatory developer training on security engineering principles and secure development practices
Threat Modeling and Risk-Based Design Process
Formal threat modeling process applied during system design to identify threats, attack vectors, and required security controls before implementation
Security Engineering for Legacy Systems with Documented Limitations
Documented approach for applying security engineering principles to legacy systems to the extent technically feasible, with clear documentation of limitations and compensating controls
Procurement Security Requirements for Acquired Systems
Security engineering requirements incorporated into procurement processes to ensure acquired systems are designed and developed with security principles
Evidence & Assessment Notes
Expected Evidence
Organizations should maintain documentation and evidence demonstrating compliance with this control. This may include policy documentation, configuration records, audit logs, access reviews, and other relevant artifacts that show how the control is implemented and maintained.
Plan of Action & Milestones (POA&M)
If no SDLC with security requirements exists, POA&M should include timeline to develop and implement secure SDLC with security gates at each phase If developers lack security training, POA&M should include plan to provide security engineering and secure coding training to all developers working on CUI systems If no threat modeling or security design review process exists, POA&M should include timeline to establish process and apply to systems in scope If security architecture framework does not exist, POA&M should include plan to develop security architecture standards and design patterns If legacy systems cannot meet requirements, POA&M should document specific technical limitations, compensating controls, and system replacement or upgrade timeline If procurement processes lack security requirements, POA&M should include plan to update procurement templates and processes to include security engineering requirements If security engineering principles are documented but not implemented, POA&M should include verification and enforcement mechanisms POA&M should be specific about which systems or projects are affected and what security engineering practices will be implemented POA&M should include measurable milestones such as 'SDLC policy approved,' 'developers trained,' 'threat model completed for System X,' 'architecture review process established' For legacy systems, POA&M should include both near-term compensating controls and long-term system replacement or upgrade plans POA&M should address both process establishment (policies, procedures, standards) and implementation evidence (actual threat models, architecture reviews, trained developers)
Frequently Asked Questions
Does this control require us to develop all systems in-house, or does it apply to systems we purchase?
This control applies to both internally developed systems and systems you procure or acquire. For systems you develop, you must apply security engineering principles throughout development. For systems you purchase, you should include security engineering requirements in procurement processes and verify that vendors followed secure development practices. The key is ensuring security is built into systems from the beginning, regardless of who develops them.
We only use commercial off-the-shelf software with no custom development. Does this control apply to us?
If you use only unmodified COTS products with no custom development, configuration, or integration work, this control may have limited applicability. However, if you perform significant configuration, customization, or integration of COTS products, you should apply security engineering principles to those activities. Additionally, your procurement process should include security requirements to ensure vendors applied security engineering principles when developing the COTS products.
What is the difference between this control and just implementing security controls?
This control focuses on building security into the design and architecture of systems from the beginning, rather than adding security controls after systems are built. It requires using proven engineering principles like defense-in-depth, least privilege, and secure design patterns during the design phase. The goal is to create inherently secure systems that are resistant to threats by design, not just protected by add-on security tools.
Our systems are all legacy and cannot be modified to meet modern security engineering principles. How do we comply?
For legacy systems, you must apply security engineering principles to the extent technically feasible given current hardware, software, and firmware limitations. Document the specific technical limitations that prevent full application of security engineering principles, implement compensating controls where possible, and formally accept residual risks. You should also have a plan to replace or upgrade legacy systems that cannot meet security requirements.
What kind of training do developers need to satisfy this control?
Developers should receive training on security engineering concepts and principles such as defense-in-depth, least privilege, secure design patterns, common vulnerabilities, and secure coding practices. Training should be specific enough to enable developers to apply security principles in their daily work. Generic security awareness training is not sufficient—developers need technical training on how to build secure systems and write secure code.
Is threat modeling required for every system change, or only for major changes?
The control requires applying security engineering principles to new development and major upgrades. For routine maintenance or minor changes, full threat modeling may not be necessary. However, you should have criteria defining what constitutes a 'major upgrade' and ensure that significant changes undergo security design review or threat modeling. Even for minor changes, security implications should be considered as part of your change management process.
How ConformatIQ Helps With CMMC Readiness
ConformatIQ is an AI-assisted CMMC readiness platform designed to help organizations prepare for assessments more efficiently. The platform supports document generation such as SSPs and POA&Ms, guided readiness workflows, centralized evidence tracking, and interview preparation for assessments.
Ready to Get Full Guidance?
Access complete implementation details, detailed assessment questions, evidence requirements, and expert guidance for this control.
Request Full GuidanceInformation sourced from NIST SP 800-171 Rev. 2. See full disclaimer.