Skip to main content
← All controls
SA-15 / A.8.25 / CIS-16.3 NIST SP 800-53 Rev 5

Documented secure SDLC policy

Demonstrate that the organization has formally documented, approved, and communicated a secure SDLC policy that defines security requirements, controls, and responsibilities across all software development phases.

Description

What this control does

A documented secure Software Development Lifecycle (SDLC) policy establishes the organization's formal requirements, processes, and controls for integrating security throughout all phases of software development—from requirements gathering and design through coding, testing, deployment, and maintenance. This policy defines roles and responsibilities, mandates secure coding standards, specifies security testing gates (e.g., static analysis, dynamic scanning, penetration testing), and outlines change management and vulnerability remediation procedures. The policy ensures development teams follow a consistent, auditable approach to building secure software and reducing the attack surface introduced by custom code and third-party components.

Control objective

What auditing this proves

Demonstrate that the organization has formally documented, approved, and communicated a secure SDLC policy that defines security requirements, controls, and responsibilities across all software development phases.

Associated risks

Risks this control addresses

  • Injection flaws, buffer overflows, and other code-level vulnerabilities introduced due to lack of secure coding standards
  • Unauthorized or malicious code changes merged into production without security review or approval
  • Unpatched or outdated third-party libraries and dependencies incorporated into applications without vulnerability scanning
  • Insufficient security testing resulting in exploitable vulnerabilities reaching production environments
  • Inadequate separation of duties allowing developers to bypass security gates and deploy untested code
  • Lack of accountability and traceability for security decisions during design and implementation phases
  • Non-compliance with regulatory or contractual secure development requirements due to absence of formal policy

Testing procedure

How an auditor verifies this control

  1. Request the current secure SDLC policy document, including version number, approval signatures, and publication date.
  2. Review the policy to verify it explicitly covers all SDLC phases: requirements analysis, design, implementation, testing, deployment, and maintenance.
  3. Confirm the policy defines secure coding standards, references industry frameworks (e.g., OWASP, CERT), and specifies mandatory security testing tools and activities.
  4. Verify the policy assigns clear roles and responsibilities for security oversight, including security champions, code reviewers, and approvers.
  5. Check that the policy mandates vulnerability management procedures, including remediation timelines and escalation paths for critical findings.
  6. Confirm the policy addresses third-party and open-source component management, including inventory, vulnerability scanning, and license compliance.
  7. Validate the policy was formally approved by executive or senior management within the past 12-24 months.
  8. Interview a sample of developers, security engineers, and project managers to confirm awareness and understanding of policy requirements.
Evidence required The auditor collects the signed secure SDLC policy document with version control history and approval records, screenshots or exports from policy management systems showing distribution and acknowledgment tracking, and interview notes or attestations from development and security personnel confirming receipt and understanding. Supporting evidence includes references to related standards documents (coding guidelines, testing procedures) cited within the policy.
Pass criteria The control passes if a current, formally approved secure SDLC policy exists that comprehensively addresses all development phases, defines security requirements and testing gates, assigns clear accountability, and has been communicated to relevant personnel within the defined review cycle.

Where this control is tested

Audit programs including this control