What this policy is
The secure-SDLC policy — requirements for threat modelling, secure-coding training, SAST/DAST coverage, dependency-scanning, secrets-management, and pre-production security testing.
Why every organization needs one
Most exploitable application vulnerabilities are introduced during development. Shifting security left through SDLC controls is far cheaper than fixing in production.
What a competent Software Development Security Policy typically contains
- Purpose and scope
- Roles and responsibilities
- Definitions
- Threat-modelling trigger and template
- SAST/DAST coverage requirements
- Dependency-scanning cadence
- Secret-management standards
- Review cadence (typically annual) and version control
- Approval, sign-off and effective date
How iCompaas tracks this policy
The icompaas policy-doc producer manages this document through an 8-state lifecycle: draft → generated → internal_qa → customer_review → in_review → approved → signed (with rejected as a terminal side-state). The producer publishes a policy_doc_software_development_security_policy_signed compliance finding once at least one document of this kind reaches the signed state for the account being assessed; the finding then rolls up into every compliance framework that references this policy (see the table below).
Compliance frameworks that reference this policy
The icompaas compliance controls library links every policy document to the controls in each framework that require, evidence, or otherwise rely on it. Below: every control across every framework in the iCompaas catalogue that names this policy as part of its evidence base. Each control links to its own dedicated page with auditor-view content + implementation guidance.
| Framework | Control | Title | Component |
|---|---|---|---|
| ISO/IEC 27001:2022 | A.5.8 | Information security in project management | Organizational controls |
| ISO/IEC 27001:2022 | A.8.4 | Access to source code | Technological controls |
| ISO/IEC 27001:2022 | A.8.25 | Secure development life cycle | Technological controls |
| ISO/IEC 27001:2022 | A.8.26 | Application security requirements | Technological controls |
| ISO/IEC 27001:2022 | A.8.29 | Security testing in development and acceptance | Technological controls |
| ISO/IEC 27001:2022 | A.8.31 | Separation of development, test and production environments | Technological controls |
| ISO/IEC 27701:2025 | A.3.27 | Secure development life cycle | Security considerations |
| ISO/IEC 27701:2025 | A.3.28 | Application security requirements | Security considerations |
8 controls across 2 frameworks reference this policy.
About this page
This article is part of the iCompaas Policy Documents library — one page per signed-document type the icompaas policy-doc producer tracks for customer accounts. The article is intentionally framework-agnostic: a customer signing a policy of this kind gets the same regulatory benefit across every framework that references it.