Annex A 8.25 verified ISO/IEC 27001:2022
Secure Development Lifecycle
Set rules for secure software and system development to avoid costly production issues.
Technological controls Preventative ISO/IEC 27001:2022secure sdlcsecure codingoutsourced development
record_voice_over
Plain language
This control is about making sure that the software and systems you develop are secure from the start. If you don't establish clear rules for secure development, you risk creating products that are vulnerable to cyber attacks, which can cause financial loss and damage to your reputation.
01 — Overview
Framework
ISO/IEC 27001:2022
Control effect
Preventative
ISO 27001 domain
Technological controls
Classifications
N/A
Official last update
24 Oct 2022
Control Stack last updated
12 Apr 2026
Maturity levels
N/A
Official control statement
Rules for the secure development of software and systems shall be established and applied.
verified ISO/IEC 27001:2022 Annex A 8.25
priority_high
Why it matters
Insecure development practices embed vulnerabilities, leading to costly breaches or system failures that damage trust and incur financial losses.
settings
Operational notes
Maintain secure coding standards and bake security into the SDLC (threat modelling, SAST/DAST, code review, dependency scanning) to find flaws early.
02 — Implement
build
Implementation tips
- The IT manager should establish clear rules for secure development. This involves setting guidelines for how software and systems are built to prevent vulnerabilities. Using standards from ISO 27002:2022, they can ensure that developers separate testing and production environments and follow secure coding practices.
- The software development lead should integrate security checkpoints into the development cycle. This means including specific points in the project timeline where security is assessed, such as during design and before release. This ensures that any security issues are identified and fixed early.
- Security trainers should provide training for developers on secure development practices. They can organise sessions to teach developers about secure coding, the importance of testing for vulnerabilities, and keeping abreast of the latest security threats.
- The procurement team should ensure that any outsourced development follows your organisation's secure development rules. They need to verify this by obtaining documented assurances or certifications from suppliers.
- The IT security team should regularly perform security tests, such as code scans and penetration tests, to identify and rectify vulnerabilities. These tests should be scheduled after key development milestones as part of the software lifecycle management process.
03 — Audit
fact_check
Audit / evidence tips
-
Askdocumentation on secure development guidelines
-
Askto see evidence of security checkpoints in past development projects
Goodwill show proactive identification and mitigation of security risks
-
Asktraining records and materials for developers on secure development
-
Askagreements or compliance documents from third-party developers
04 — Mappings
link
Cross-framework mappings
How Annex A 8.25 relates to controls across ISO/IEC 27001, Essential Eight, and ASD ISM.
ASD ISM
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (29) expand_less | ||
| ISM-0246 | ISM-0246 requires that, when an emanation security threat assessment is required, it is sought as early as possible in a system’s life cycle | |
| ISM-0402 | ISM-0402 requires comprehensive vulnerability testing (including SAST, DAST and SCA) prior to release and periodically thereafter | |
| ISM-0938 | ISM-0938 requires selecting vendors whose development practices demonstrate Secure by Design/Secure by Default | |
| ISM-1239 | ISM-1239 requires robust web application frameworks to be used for web application development | |
| ISM-1240 | ISM-1240 requires validation and sanitisation of all input received over the internet by software to prevent exploitation via untrusted data | |
| ISM-1241 | ISM-1241 addresses a specific secure development requirement: encoding all web application output to prevent unsafe interpretation in bro... | |
| ISM-1275 | ISM-1275 requires validation/filtering of database queries generated by software to ensure only legitimate, correctly formed queries are ... | |
| ISM-1276 | ISM-1276 requires a specific secure implementation pattern for database access: parameterised queries or stored procedures instead of dyn... | |
| ISM-1278 | ISM-1278 requires software to be designed or configured to minimise database error information disclosed to users | |
| ISM-1419 | ISM-1419 requires that development and modification of software only occurs in development environments to avoid uncontrolled changes in ... | |
| ISM-1730 | ISM-1730 requires that a software bill of materials (SBOM) is produced and made available to consumers of software | |
| ISM-1796 | ISM-1796 requires organisations to digitally sign files containing executable content with certificates that have a verifiable chain of t... | |
| ISM-1798 | ISM-1798 requires that secure configuration guidance (hardening/loosening guides) is produced and made available to software consumers as... | |
| ISM-1850 | ISM-1850 requires developers to mitigate the OWASP Top 10 security risks when developing web applications | |
| ISM-1851 | ISM-1851 requires that OWASP API Security Top 10 risks are addressed during web API development | |
| ISM-1917 | ISM-1917 requires cryptographic components to support nominated PQC and strong algorithms by 2030, tying into procurement and development | |
| ISM-1922 | ISM-1922 requires the OWASP Mobile Application Security Verification Standard (MASVS) to be used when developing mobile applications | |
| ISM-2016 | ISM-2016 requires software to validate and sanitise all inputs received over a local network | |
| ISM-2028 | ISM-2028 requires that software artefacts undergo SAST/DAST/SCA-based testing for known weaknesses before being admitted into the organis... | |
| ISM-2030 | ISM-2030 requires commit-time scanning to identify and block secrets and keys from being stored in the authoritative software repository | |
| ISM-2033 | ISM-2033 requires software security requirements to be documented, stored securely, and maintained throughout the SDLC | |
| ISM-2039 | ISM-2039 requires the software threat model to be reviewed throughout the SDLC to ensure it reflects the as-built software and changes to... | |
| ISM-2041 | ISM-2041 requires memory-safe languages or memory-safe programming practices as a concrete security requirement for software development | |
| ISM-2043 | ISM-2043 requires software to be architected and structured for readability and maintainability | |
| ISM-2055 | ISM-2055 requires that where build provenance exists for imported third-party software components, it is used during development to confi... | |
| ISM-2056 | ISM-2056 requires that software build provenance is produced and made available to software consumers so they can verify how a build was ... | |
| ISM-2057 | ISM-2057 mandates comprehensive input validation rules are documented, correctly implemented, and tested with both positive and negative ... | |
| ISM-2060 | ISM-2060 requires code reviews to be utilised to confirm Secure by Design and secure programming practices are being followed | |
| ISM-2064 | ISM-2064 addresses a specific secure session design: preventing cookie tampering by using digitally signed opaque bearer tokens | |
| sync_alt Partially overlaps (4) expand_less | ||
| ISM-0401 | Annex A 8.25 requires rules for secure development of software and systems to be established and applied | |
| ISM-1780 | Annex A 8.25 requires organisations to establish and apply rules for secure development across the software/system lifecycle | |
| ISM-2042 | Annex A 8.25 requires organisations to establish and apply secure development lifecycle rules | |
| ISM-2083 | ISM-2083 requires software producers to provide software users with a CBOM of cryptographic components | |
| handshake Supports (5) expand_less | ||
| ISM-0481 | ISM-0481 requires that cryptographic software and libraries only use approved high assurance cryptographic protocols | |
| ISM-1616 | ISM-1616 requires a formal vulnerability disclosure program to help securely develop and maintain products and services by receiving and ... | |
| ISM-1797 | ISM-1797 requires software development outputs (installers, patches and updates) to be digitally signed or distributed with cryptographic... | |
| ISM-1826 | ISM-1826 requires selecting vendors who build server applications using Secure by Design/Secure by Default principles and secure programm... | |
| ISM-2025 | ISM-2025 requires an issue tracking solution to link software development tasks to security issues/decisions and to change, feature and d... | |
| link Related (8) expand_less | ||
| ISM-0971 | Annex A 8.25 requires defined and consistently applied secure development rules across the lifecycle | |
| ISM-1238 | Annex A 8.25 requires organisations to establish and apply rules for secure development of software and systems | |
| ISM-1849 | Annex A 8.25 requires secure development lifecycle rules to be established and applied | |
| ISM-2031 | Annex A 8.25 requires organisations to establish and apply rules across a secure development lifecycle for software and systems | |
| ISM-2034 | Annex A 8.25 requires organisations to define and apply rules for secure development over the SDLC | |
| ISM-2036 | Annex A 8.25 requires secure development lifecycle rules to be established and applied | |
| ISM-2040 | Annex A 8.25 requires organisations to define and apply secure development rules across the SDLC | |
| ISM-2061 | Annex A 8.25 requires secure development rules to be established and applied across the lifecycle | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.