ASD ISM 2120Develop 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
05 Sept 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentTopic
Secure software development
Official 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
- AskRequest the current secure software development policy, including its approval record, version history and named owner.Look atCheck that the policy 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.GoodAn approved, versioned policy with a named owner that sets out concrete requirements for secure design, coding standards, code review and security testing.
- AskRequest the policy's review history and change log.Look atConfirm the policy 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.GoodReview records show re-approval within the last 12 months and evidence that the policy was revisited after relevant technology changes or incidents.
- AskRequest the CI/CD pipeline definitions for one or more production codebases.Look atCheck that SAST and DAST stages run automatically and that builds fail when findings exceed the threshold defined in the policy.GoodPipelines run SAST and DAST on every build without manual intervention and fail builds that breach the policy's finding threshold.
- AskRequest a demonstration of branch-protection settings on protected branches in the source control system.Look atConfirm mandatory pull-request review and required security status checks are enforced and direct pushes are blocked, matching the policy.GoodProtected branches require pull-request review and passing security checks, direct pushes are blocked, and these settings match what the policy requires.
- AskRequest a sample of recently merged changes with their review and scan records.Look atConfirm each change passed the mandatory code review gate and security scans before release.GoodEvery sampled change shows a completed code review and passing security scans before release, evidencing 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 |
|---|---|---|
layersPartially meets(1)expand_less | ||
| Annex A 5.1 | ISM-2120 requires the organisation to develop, implement, and maintain a secure software development policy | |
handshakeSupports(1)expand_less | ||
| Annex A 5.36 | ISM-2120 requires a secure software development policy | |
ISO 42001
| Control | Notes | Details |
|---|---|---|
sync_altPartially overlaps(1)expand_less | ||
| Annex A 6.1.2 | Annex A 6.1.2 requires the organisation to document responsible-development objectives for AI systems and integrate measures to achieve t... | |
handshakeSupports(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.
Related ASD ISM controls in Software development
See all Guidelines for software development controls, or browse the full ASD ISM library.