Develop and Maintain Secure Software Policy
A secure software development policy is developed, formally implemented across the software development life cycle, and maintained so that software is designed, built and released securely.
Plain language
This control requires a written rule book that sets out how your organisation designs, codes, tests and releases software securely, and then actually enforces it in day-to-day development work. It is not enough to write the policy and file it away; secure coding standards, code review and security testing have to be built into how developers and the build pipeline operate. The policy must also be kept current and re-approved when threats, tools or development practices change.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
June 2026
Control Stack last updated
19 June 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentOfficial control statement
A secure software development policy is developed, implemented and maintained.
Why it matters
If no secure software development policy is documented, implemented and maintained, developers work without a consistent, authoritative standard, so secure coding requirements, mandatory code review and security testing are applied inconsistently or skipped under delivery pressure. Common defects such as injection flaws, insecure dependencies, hard-coded secrets and missing input validation reach production because there is no enforced gate that catches them, and the organisation cannot demonstrate a defensible, repeatable basis for how its software is secured.
Operational notes
Treat the policy as a living standard that binds every codebase and development team, not a one-off document. Re-approve and update it at least annually and whenever a triggering change occurs, such as adopting a new language, framework, source control or CI/CD platform, a significant change to the threat environment, or a security incident traced to a development practice. Keep the policy's enforcement mechanisms (secure coding standards, mandatory code review, SAST/DAST integration and branch protections) aligned with the tooling actually in use, and record each version, approval and change so the implemented and maintained dimensions are evidenced over time.
Implementation tips
- Author a secure software development policy that mandates specific, named requirements: a secure design step, language- and framework-specific secure coding standards, mandatory peer code review, and automated security testing before release; have it formally approved and assign a named owner.
- Implement the policy in source control by enabling branch protection on protected branches: require pull-request review with at least one independent reviewer, require security status checks to pass, and block direct pushes and force-pushes.
- Integrate SAST and software composition analysis into the CI pipeline so every build scans application code and third-party dependencies, and configure the pipeline to fail the build when findings exceed the severity threshold set in the policy.
- Add DAST or equivalent dynamic security testing against pre-production builds in the pipeline so running-application flaws are caught before release, and route results back to the development team.
- Publish the secure coding standards as a referenceable artefact (for example linters, pre-commit hooks and IDE rule sets) so the standard is applied at the point of coding, not retrofitted later.
- Maintain the policy by re-approving it at least annually and on triggering changes (new language, framework or CI/CD platform, threat-environment shifts, or a development-related incident), and record each version and approval so the maintained requirement is evidenced.
Audit / evidence tips
- Obtain the secure software development policy and confirm it is formally approved, version-controlled and assigned an owner, and that it covers secure design, secure coding standards, code review and security testing rather than only high-level intent.
- Inspect the policy's review history to confirm it has been reviewed and re-approved within the last 12 months and after relevant changes such as a new framework, CI/CD platform or a development-related security incident.
- Examine CI/CD pipeline definitions for one or more production codebases to confirm SAST and DAST stages run automatically and that builds fail when findings exceed the threshold defined in the policy.
- Inspect branch-protection settings on protected branches to confirm mandatory pull-request review and required security status checks are enforced and direct pushes are blocked, matching the policy.
- Sample recent merged changes and confirm each passed the mandatory code review gate and security scans before release, evidencing that the policy is implemented and not just documented.
Cross-framework mappings
How ISM-2120 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (1) expand_less | ||
| Annex A 5.1 | ISM-2120 requires the organisation to develop, implement, and maintain a secure software development policy | |
| handshake Supports (1) expand_less | ||
| Annex A 5.36 | ISM-2120 requires a secure software development policy | |
ISO 42001
| Control | Notes | Details |
|---|---|---|
| handshake Supports (1) expand_less | ||
| Annex A 5.4 | ISM-2120 necessitates a secure software development policy to define secure design and development practices | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.