ISO 27001 Annex A 8.25 Secure development lifecycle
What it says
Rules for the secure development of software and systems shall be established and applied.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishSet rules for secure software and system development to avoid costly production issues.
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.
Free. Save your status, tasks and notes.
Why it matters
Insecure development practices embed vulnerabilities, leading to costly breaches or system failures that damage trust and incur financial losses.
How to implement
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.
Keep it running
Maintain secure coding standards and bake security into the SDLC (threat modelling, SAST/DAST, code review, dependency scanning) to find flaws early.
Evidence and audit
- Check 1 of 4What an auditor asks for
Ask for
Documentation on secure development guidelines.
Look at
Whether these guidelines cover all phases of software development. Good documentation will be comprehensive and aligned with ISO 27002:2022 standards.
- Check 2 of 4What an auditor asks for
Ask for
To see evidence of security checkpoints in past development projects.
Look at
Whether these checkpoints actually resulted in security improvements or changes to the project.
Good evidence
Will show proactive identification and mitigation of security risks.
- Check 3 of 4What an auditor asks for
Ask for
Training records and materials for developers on secure development.
Look at
A regular training schedule and content that covers the latest secure coding practices. Good evidence will show that training is up-to-date and comprehensive.
- Check 4 of 4What an auditor asks for
Ask for
Agreements or compliance documents from third-party developers.
Look at
Whether these documents prove alignment with your organisation's secure development policies. Good documents will clearly outline that third parties are contractually bound to follow these policies.
Mappings
Closest match in ASD Information Security Manual: ISM-0402, Software vulnerability testing using SAST, DAST and SCA, which this control covers in full and more.
ASD Information Security Manual: 47 mappings
This control is broader than ISM-0402.
ISM-0402 requires comprehensive vulnerability testing (including SAST, DAST and SCA) prior to release and periodically thereafter. Annex A 8.25 requires the organisation to establish and apply rules for secure development across the software and system lifecycle, under which security testing is one possible rule set. ISM-0402 is a specific secure-SDLC requirement focused on vulnerability testing, while Annex A 8.25 covers many additional secure development practices beyond testing.
This control is broader than ISM-0938.
ISM-0938 requires selecting vendors whose development practices demonstrate Secure by Design/Secure by Default. ISO/IEC 27001:2022 Annex A 8.25 speaks to rules for a secure development lifecycle, supporting the assurance ISM-0938 seeks from vendors. Annex A 8.25 covers development governance, while ISM-0938 focuses on vendor selection based on their adherence to these principles.
This control is broader than ISM-0971.
Annex A 8.25 requires defined and consistently applied secure development rules across the lifecycle. ISM-0971 mandates using the OWASP Application Security Verification Standard when developing web applications, which is one way to operationalise secure development requirements. Annex A 8.25 is broader as it applies to all software/systems and does not prescribe a specific standard or only web scope.
This control is broader than ISM-1238.
Annex A 8.25 requires organisations to establish and apply rules for secure development of software and systems. ISM-1238 is one specific rule/practice within that lifecycle, requiring threat modelling to support secure development activities. Annex A 8.25 is broader because it covers the full set of SDL rules (e.g., requirements, coding, testing, release) beyond threat modelling alone.
This control is broader than ISM-1239.
ISM-1239 requires robust web application frameworks to be used for web application development. Annex A 8.25 establishes and applies rules for a secure development lifecycle, within which selecting approved/robust frameworks is a common mandated rule. Annex A 8.25 is broader, covering governance and practices across the SDLC beyond the specific design choice of a web framework.
This control is broader than ISM-1240.
ISM-1240 requires validation and sanitisation of all input received over the internet by software to prevent exploitation via untrusted data. Annex A 8.25 requires an organisation to establish and apply secure development lifecycle rules, within which input validation is a common secure coding requirement. ISM-1240 is a specific technical control expectation, while Annex A 8.25 is broader and covers the full lifecycle beyond input handling.
This control is broader than ISM-1241.
ISM-1241 addresses a specific secure development requirement: encoding all web application output to prevent unsafe interpretation in browsers. Annex A 8.25 requires rules for secure development of software and systems to be established and applied, which would normally include standards for output encoding/escaping for web applications. ISM-1241 is one concrete rule within a secure development lifecycle, while Annex A 8.25 is broader and covers the full set of secure development rules and practices.
This control is broader than ISM-1275.
ISM-1275 requires validation/filtering of database queries generated by software to ensure only legitimate, correctly formed queries are issued. Annex A 8.25 requires an organisation to establish and apply rules for a secure development lifecycle, within which secure database query handling would be defined and enforced. ISM-1275 represents one concrete SDL rule, while Annex A 8.25 covers governance and application of many secure development rules beyond database queries.
This control is broader than ISM-1276.
ISM-1276 requires a specific secure implementation pattern for database access: parameterised queries or stored procedures instead of dynamic query generation. Annex A 8.25 requires an organisation to establish and apply rules for secure development of software and systems, under which standards and patterns like safe database query methods would be defined and enforced. ISM-1276 represents one concrete rule that would sit inside the broader secure development rule-set required by Annex A 8.25.
This control is broader than ISM-1278.
ISM-1278 requires software to be designed or configured to minimise database error information disclosed to users. This relates to Annex A 8.25 because a secure development lifecycle typically includes requirements for safe error handling and information leakage prevention in application/database interactions. Annex A 8.25 is broader across the full SDLC, while ISM-1278 is a specific secure design/configuration outcome focused on database error message content.
This control is broader than ISM-1419.
ISM-1419 requires that development and modification of software only occurs in development environments to avoid uncontrolled changes in production. Annex A 8.25 requires rules for a secure development lifecycle to be established and applied, which typically includes environment separation and controlled promotion of changes. ISM-1419 is a specific SDLC control (environment constraint), whereas Annex A 8.25 is broader across the full lifecycle and governance of secure development.
This control is broader than ISM-1730.
ISM-1730 requires that a software bill of materials (SBOM) is produced and made available to consumers of software. This is a specific secure-development and supply-chain transparency practice that fits within ISO/IEC 27001:2022 Annex A 8.25, because publishing an SBOM operationalises "rules for secure development" around component governance, third‑party dependency management, and enabling downstream vulnerability response by customers. Annex A 8.25 is broader and includes secure coding, design, testing, build/release controls and toolchain practices, whereas ISM-1730 focuses narrowly on the SBOM artefact and its availability to consumers.
This control is broader than ISM-1796.
ISM-1796 requires organisations to digitally sign files containing executable content with certificates that have a verifiable chain of trust as part of software development. ISO/IEC 27001:2022 Annex A 8.25 requires secure development rules to be established and applied across the software and systems lifecycle. ISM-1796 is a specific secure development rule focused on code signing and trust chains, making it a subset of the broader secure SDLC requirements in Annex A 8.25.
This control is broader than ISM-1797.
ISM-1797 requires software development outputs (installers, patches and updates) to be digitally signed or distributed with cryptographic checksums to assure integrity. ISO/IEC 27001:2022 Annex A 8.25 requires a secure development lifecycle, within which release integrity controls (code signing, checksum publication, release validation) are commonly mandated practices. Annex A 8.25 is broader, covering many SDLC security requirements beyond release artefact signing.
This control is broader than ISM-1798.
ISM-1798 requires that secure configuration guidance (hardening/loosening guides) is produced and made available to software consumers as part of software development. Annex A 8.25 requires an organisation to establish and apply rules for a secure development lifecycle across software and systems. Producing consumer hardening guidance is one concrete SDL activity, but Annex A 8.25 is broader and includes many other lifecycle practices beyond configuration guidance publication.
This control is broader than ISM-1849.
Annex A 8.25 requires secure development lifecycle rules to be established and applied. ISM-1849 requires using the OWASP Top 10 Proactive Controls in web application development, providing a concrete set of secure coding/development controls. Annex A 8.25 is broader because it applies to all software and lifecycle phases and does not limit itself to web proactive controls.
This control is broader than ISM-1850.
ISM-1850 requires developers to mitigate the OWASP Top 10 security risks when developing web applications. ISO/IEC 27001:2022 Annex A 8.25 mandates establishing and applying a secure development lifecycle, within which OWASP Top 10 mitigations are a common, practical set of security rules and activities. Annex A 8.25 is broader because it covers secure development generally (not only web applications and not only OWASP Top 10).
This control is broader than ISM-1851.
ISM-1851 requires that OWASP API Security Top 10 risks are addressed during web API development. Annex A 8.25 requires an organisation-wide secure development lifecycle with rules applied across software and systems, which would typically include security requirements, design, build, test and release practices that help meet OWASP API Top 10. ISM-1851 is an API-focused security outcome, while Annex A 8.25 is a broader governance and process control for all development work.
This control is broader than ISM-1922.
ISM-1922 requires the OWASP Mobile Application Security Verification Standard (MASVS) to be used when developing mobile applications. ISO/IEC 27001:2022 Annex A 8.25 requires a secure development lifecycle to be established and applied across software and systems development. Using OWASP MASVS is a specific secure-SDLC standard/practice for the mobile application context, while Annex A 8.25 is broader and technology-agnostic.
This control is broader than ISM-2016.
ISM-2016 requires software to validate and sanitise all inputs received over a local network. ISO/IEC 27001:2022 Annex A 8.25 requires an organisation to establish and apply secure development lifecycle rules, within which input validation requirements are commonly defined, implemented, and verified. Annex A 8.25 is broader as it covers governance and end-to-end SDLC practices (e.g. design, testing, release) whereas ISM-2016 is a specific technical requirement for input handling.
This control is broader than ISM-2025.
ISM-2025 requires an issue tracking solution to link software development tasks to security issues/decisions and to change, feature and defect work. This supports ISO/IEC 27001:2022 Annex A 8.25 by providing a practical mechanism to evidence and enforce secure development lifecycle rules through traceable tickets, workflows and approvals. Annex A 8.25 is broader (covering the full set of SDL rules), while ISM-2025 is focused specifically on traceability via issue tracking.
This control is broader than ISM-2028.
ISM-2028 requires organisations to test software artefacts for known weaknesses using SAST/DAST/SCA before they are imported into the authoritative source for software. Annex A 8.25 requires secure development lifecycle rules to be established and applied, which typically includes security testing activities and quality gates. ISM-2028 is a specific SDL rule focused on vulnerability detection prior to import, whereas Annex A 8.25 also covers many other secure engineering practices beyond testing.
This control is broader than ISM-2029.
ISM-2029 requires the authoritative source for software to restrict the use and import of third-party libraries and components to trustworthy sources. This is a specific secure development rule that would sit within the rules for secure development of software and systems required by Annex A 8.25. Annex A 8.25 covers the whole secure development life cycle, while ISM-2029 addresses only the sourcing of third-party components.
This control is broader than ISM-2030.
ISM-2030 requires scanning at commit-time to detect plaintext or encoded credentials, keys and secrets and to block them from being stored in the authoritative source repository. Annex A 8.25 requires the organisation to establish and apply secure development lifecycle (SDLC) rules across software and systems development. ISM-2030 is a specific SDLC control implementation focused on secret detection and prevention, whereas Annex A 8.25 is broader and covers many other secure development practices beyond source repository secret scanning.
This control is broader than ISM-2031.
Annex A 8.25 requires organisations to establish and apply rules across a secure development lifecycle for software and systems. ISM-2031 is a specific secure-SDLC rule requiring compilers/interpreters/build tools and pipelines to use security features that harden produced executables. Annex A 8.25 is broader because it covers many SDLC practices beyond build-tool hardening (e.g. requirements, design, review, testing, release).
This control is broader than ISM-2034.
Annex A 8.25 requires organisations to define and apply rules for secure development over the SDLC. ISM-2034 requires documenting and reviewing security design decisions throughout development, which is a specific lifecycle rule supporting secure architecture and traceability. Annex A 8.25 is broader because it encompasses security requirements, implementation, verification, release and maintenance rules in addition to design decision management.
This control is broader than ISM-2036.
Annex A 8.25 requires secure development lifecycle rules to be established and applied. ISM-2036 requires identifying and documenting security responsibilities for software developers, which underpins accountability and consistent application of secure development practices. Annex A 8.25 is broader because roles and responsibilities are only one aspect of secure SDLC rules alongside technical and process controls.
This control is broader than 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 the threat environment. ISO/IEC 27001:2022 Annex A 8.25 requires organisations to establish and apply rules for a secure development lifecycle, within which ongoing threat modelling review is a common required practice. The ISO control is broader because it covers the whole set of secure-SDLC rules (e.g., governance, roles, practices), while ISM-2039 focuses specifically on continuous threat model review.
This control is broader than ISM-2040.
Annex A 8.25 requires organisations to define and apply secure development rules across the SDLC. ISM-2040 focuses specifically on using secure programming practices for the chosen programming language during software development. Annex A 8.25 is broader because secure programming is only one component of an SDLC rule set (alongside requirements, design, review, testing and release controls).
This control is broader than ISM-2041.
ISM-2041 requires memory-safe languages or memory-safe programming practices as a concrete security requirement for software development. Annex A 8.25 requires establishing and applying rules for a secure development lifecycle across the full SDLC, which would typically incorporate secure coding standards such as memory safety. ISM-2041 is a specific technical rule within the broader governance and process scope of Annex A 8.25.
This control is broader than ISM-2043.
ISM-2043 requires software to be architected and structured for readability and maintainability. ISO/IEC 27001:2022 Annex A 8.25 requires an organisation to define and apply rules for a secure development lifecycle, where maintainable structure and clear design are common enforceable rules (e.g. coding standards, architecture reviews). Annex A 8.25 is broader as it spans the full SDLC and multiple security practices, while ISM-2043 is limited to architecture/structure quality attributes that make software easier to safely change.
This control is broader than ISM-2055.
ISM-2055 requires that where build provenance exists for imported third-party software components, it is used during development to confirm those components were built to an appropriate standard. ISO/IEC 27001:2022 Annex A 8.25 requires an organisation to establish and apply secure development rules across the software/system development lifecycle, which can include third-party component assurance practices such as provenance verification. ISM-2055 is a specific supply-chain assurance practice within the broader secure SDLC governance expected by Annex A 8.25.
This control is broader than 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 created. Annex A 8.25 establishes and applies rules for a secure development lifecycle, within which generating and publishing build provenance is a common supply-chain assurance practice. Annex A 8.25 is broader (covers many SDLC activities such as design, testing, change control), while ISM-2056 focuses specifically on producing and distributing provenance artefacts.
This control is broader than ISM-2057.
ISM-2057 mandates comprehensive input validation rules are documented, correctly implemented, and tested with both positive and negative cases. Annex A 8.25 establishes and applies secure development lifecycle (SDL) rules, which typically include requirements for input validation standards and verification activities. ISM-2057 is a specific SDL requirement, whereas Annex A 8.25 covers the full lifecycle and many other secure development rules beyond validation.
This control is broader than ISM-2060.
ISM-2060 requires code reviews to be utilised to confirm Secure by Design and secure programming practices are being followed. ISO/IEC 27001:2022 Annex A 8.25 requires an established and applied secure development lifecycle, within which peer review and secure design verification activities commonly sit. Annex A 8.25 covers many lifecycle rules beyond code review, whereas ISM-2060 focuses specifically on the code review assurance activity.
This control is broader than ISM-2061.
Annex A 8.25 requires secure development rules to be established and applied across the lifecycle. ISM-2061 is a specific SDLC practice requiring developer-supported security-focused peer reviews for critical/security-relevant components. Annex A 8.25 is broader because it includes code review as one possible rule among many other SDLC activities and governance requirements.
This control is broader than ISM-2064.
ISM-2064 addresses a specific secure session design: preventing cookie tampering by using digitally signed opaque bearer tokens. Annex A 8.25 requires establishing and applying secure development rules (secure SDLC), under which secure authentication/session management patterns such as signed session tokens would normally be mandated and verified. ISM-2064 is one specific SDLC control outcome, while Annex A 8.25 spans the full lifecycle and many other secure engineering rules.
This control is broader than ISM-2122.
ISM-2122 requires organisations to use suitable AI models to strengthen their software security testing. ISO/IEC 27001:2022 Annex A 8.25 mandates rules for secure software and system development, where ISM-2122 acts as one tactical approach among broader secure development practices.
This control is broader than ISM-2154.
ISM-2154 requires pinning third-party dependencies to approved versions in source code to reduce build-time supply chain risk and unapproved component drift. Annex A 8.25 requires an organisation-defined secure development lifecycle, within which rules for dependency management (including lockfiles, approved registries and version pinning) are typically established and enforced. Annex A 8.25 is broader lifecycle governance, while ISM-2154 is a concrete implementation requirement within that lifecycle.
This control is broader than ISM-2155.
ISM-2155 requires reproducible builds to enable independent verification that release artefacts were produced from the stated source code. Annex A 8.25 requires an organisation to establish and apply rules for a secure development lifecycle, which commonly includes rules for build pipeline integrity, traceability and release governance. ISM-2155 is a specific secure-SDLC rule focused on deterministic, verifiable builds, whereas Annex A 8.25 extends to many other SDLC practices such as design reviews, dependency management and secure release procedures.
This control partially meets ISM-2033.
ISM-2033 requires software security requirements to be documented, stored securely, and maintained throughout the SDLC. This is a specific element of Annex A 8.25, which requires the organisation to establish and apply rules for secure development more broadly (e.g. roles, processes, secure design, build, review and release practices). In other words, ISM-2033 is one concrete SDLC rule about requirements artefact management, whereas Annex A 8.25 covers the full secure SDLC governance set.
This control partially overlaps ISM-0401.
Annex A 8.25 requires rules for secure development of software and systems to be established and applied. ISM-0401 requires Secure by Design principles and practices throughout the SDLC, addressing design-time security outcomes and practices. They overlap strongly because Secure by Design is a major class of secure development rules, but Annex A 8.25 is broader (covers more than design) and ISM-0401 is more prescriptive about a specific philosophy and its application throughout the lifecycle.
This control partially overlaps ISM-1780.
Annex A 8.25 requires organisations to establish and apply rules for secure development across the software/system lifecycle. ISM-1780 requires SecDevOps practices to be used, which is a delivery/operating model that embeds security into CI/CD and operational feedback loops. They overlap on embedding security activities into development, but ISM-1780 is specifically about a DevOps operating approach while Annex A 8.25 can be met via non-DevOps SDLC methods and broader lifecycle governance rules.
This control partially overlaps ISM-2042.
Annex A 8.25 requires organisations to establish and apply secure development lifecycle rules. ISM-2042 mandates Secure by Default practices throughout the SDLC, including enabling built-in security measures in the base product. They overlap on embedding security rules into development, but ISM-2042 is specifically about default configurations/product posture, while Annex A 8.25 covers a wider set of SDLC controls beyond defaults.
This control partially overlaps ISM-2083.
ISM-2083 requires software producers to provide software users with a CBOM of cryptographic components. Annex A 8.25 requires secure development lifecycle rules to be established and applied, which commonly includes maintaining component inventories and producing security artefacts for consumers. Annex A 8.25 is broader across the whole SDLC, while ISM-2083 is a specific deliverable focused only on cryptographic components and their disclosure to users.
This control supports ISM-1616.
ISM-1616 requires a formal vulnerability disclosure program to help securely develop and maintain products and services by receiving and actioning reported vulnerabilities. This supports Annex A 8.25 by providing a feedback mechanism from real-world use into the secure development rules and practices. Annex A 8.25 focuses on establishing and applying secure development rules, while ISM-1616 focuses on structured intake, coordination, and response to disclosed vulnerabilities.
This control depends on ISM-2121.
ISM-2121 requires that only developers with sufficient cyber security skills are used on relevant projects or tasks. ISO/IEC 27001:2022 Annex A 8.25 is a prerequisite in practice because establishing and applying secure development rules defines the security competencies developers must understand and apply to be considered 'sufficiently skilled'. Annex A 8.25 focuses on organisational SDLC rules and practices, while ISM-2121 focuses on staffing decisions based on developer capability against those rules.
ASD Essentials for enterprise IT: 2 mappings
- IT.PRO-01.1Design systems with telemetry, least privilege, data protection and minimal attack surfaceBroader than
This control is broader than IT.PRO-01.1.
IT.PRO-01.1 requires systems to be designed securely to provide visibility, enforce authorised access, protect data, minimise privileges, limit exposed services and remove unnecessary functionality. Secure design is one part of the secure development of software and systems for which ISO/IEC 27001 Annex A 8.25 requires rules to be established and applied. Annex A 8.25 spans the whole development life cycle, while IT.PRO-01.1 concentrates on secure design outcomes.
- IT.PRO-01.2Use secure build and deployment processes to enforce security controls consistentlyPartially overlaps
This control partially overlaps IT.PRO-01.2.
IT.PRO-01.2 requires secure build and deployment processes that enforce security controls consistently across systems. Securing build and deployment pipelines forms part of the secure development of software and systems for which ISO/IEC 27001 Annex A 8.25 requires rules to be established and applied. Annex A 8.25 covers the wider development life cycle, including design, coding and testing, while IT.PRO-01.2 also extends to consistent control enforcement when deploying any system.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.
Get help with this control
ISO 27001 training
Mindset Cyber runs PECB-accredited ISO/IEC 27001 training that maps directly to the controls in this library.