SC.L2-3.13.2: Security Engineering & Architectural Design

What this means

This control mandates that your organization adopt and apply security engineering principles across system design, development, and deployment. You must use architectural patterns, secure coding practices, and systems engineering methodologies that reduce security risks inherent in your IT infrastructure. This means security considerations drive design decisions—not reactive compliance checks.

How to comply

1. 1.Document your security architecture and design standards, including threat modeling and design patterns that reduce attack surfaces
2. 2.Implement secure software development lifecycle (SDLC) practices with security checkpoints at each phase
3. 3.Apply systems engineering principles like defense-in-depth, least privilege, and fail-safe defaults in all new systems
4. 4.Conduct security design reviews before deployment of critical systems and applications
5. 5.Train developers and architects on secure coding standards and security-first design methodologies
6. 6.Maintain records of security design decisions and how architectural choices mitigate identified threats

Evidence auditors look for

• Security architecture documentation with threat models and design justifications
• Secure SDLC process documentation with security gates and review checklists
• Code review policies emphasizing security patterns and vulnerability prevention
• System design specifications showing application of defense-in-depth principles
• Training records for development and architecture teams on security engineering
• Design review meeting minutes and security approval sign-offs for major systems

Frequently asked questions

GRCWatch automates documentation of your security engineering decisions and design reviews, creating audit-ready evidence that SC.L2-3.13.2 is embedded in your SDLC—without slowing development velocity.

See how GRCWatch handles this control automatically

Related controls