Skip to content
arrow_back
Annex A 8.25verifiedISO/IEC 27001:2022

Secure Development Lifecycle

Set rules for secure software and system development to avoid costly production issues.

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.

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

18 June 2026

Official control statement

Rules for the secure development of software and systems shall be established and applied.
verifiedISO/IEC 27001:2022Annex 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.

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.
fact_check

Audit / evidence tips

  • AskDocumentation on secure development guidelines
  • AskTo see evidence of security checkpoints in past development projectsGoodWill 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
link

Cross-framework mappings

How Annex A 8.25 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.

ASD ISM

ControlNotesDetails
layersPartially meets(30)expand_less
ISM-0246ISM-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-0402ISM-0402 requires comprehensive vulnerability testing (including SAST, DAST and SCA) prior to release and periodically thereafter
ISM-0938ISM-0938 requires selecting vendors whose development practices demonstrate Secure by Design/Secure by Default
ISM-1239ISM-1239 requires robust web application frameworks to be used for web application development
ISM-1240ISM-1240 requires validation and sanitisation of all input received over the internet by software to prevent exploitation via untrusted data
ISM-1241ISM-1241 addresses a specific secure development requirement: encoding all web application output to prevent unsafe interpretation in bro...
ISM-1275ISM-1275 requires validation/filtering of database queries generated by software to ensure only legitimate, correctly formed queries are ...
ISM-1276ISM-1276 requires a specific secure implementation pattern for database access: parameterised queries or stored procedures instead of dyn...
ISM-1278ISM-1278 requires software to be designed or configured to minimise database error information disclosed to users
ISM-1419ISM-1419 requires that development and modification of software only occurs in development environments to avoid uncontrolled changes in ...
ISM-1730ISM-1730 requires that a software bill of materials (SBOM) is produced and made available to consumers of software
ISM-1796ISM-1796 requires organisations to digitally sign files containing executable content with certificates that have a verifiable chain of t...
ISM-1798ISM-1798 requires that secure configuration guidance (hardening/loosening guides) is produced and made available to software consumers as...
ISM-1850ISM-1850 requires developers to mitigate the OWASP Top 10 security risks when developing web applications
ISM-1851ISM-1851 requires that OWASP API Security Top 10 risks are addressed during web API development
ISM-1917ISM-1917 requires cryptographic components to support nominated PQC and strong algorithms by 2030, tying into procurement and development
ISM-1922ISM-1922 requires the OWASP Mobile Application Security Verification Standard (MASVS) to be used when developing mobile applications
ISM-2016ISM-2016 requires software to validate and sanitise all inputs received over a local network
ISM-2028ISM-2028 requires organisations to test software artefacts for known weaknesses using SAST/DAST/SCA before they are imported into the aut...
ISM-2030ISM-2030 requires commit-time scanning to identify and block secrets and keys from being stored in the authoritative software repository
ISM-2033ISM-2033 requires software security requirements to be documented, stored securely, and maintained throughout the SDLC
ISM-2039ISM-2039 requires the software threat model to be reviewed throughout the SDLC to ensure it reflects the as-built software and changes to...
ISM-2041ISM-2041 requires memory-safe languages or memory-safe programming practices as a concrete security requirement for software development
ISM-2043ISM-2043 requires software to be architected and structured for readability and maintainability
ISM-2055ISM-2055 requires that where build provenance exists for imported third-party software components, it is used during development to confi...
ISM-2056ISM-2056 requires that software build provenance is produced and made available to software consumers so they can verify how a build was ...
ISM-2057ISM-2057 mandates comprehensive input validation rules are documented, correctly implemented, and tested with both positive and negative ...
ISM-2060ISM-2060 requires code reviews to be utilised to confirm Secure by Design and secure programming practices are being followed
ISM-2064ISM-2064 addresses a specific secure session design: preventing cookie tampering by using digitally signed opaque bearer tokens
ISM-2122ISM-2122 requires organisations to use suitable AI models to strengthen their software security testing
sync_altPartially overlaps(4)expand_less
ISM-0401Annex A 8.25 requires rules for secure development of software and systems to be established and applied
ISM-1780Annex A 8.25 requires organisations to establish and apply rules for secure development across the software/system lifecycle
ISM-2042Annex A 8.25 requires organisations to establish and apply secure development lifecycle rules
ISM-2083ISM-2083 requires software producers to provide software users with a CBOM of cryptographic components
handshakeSupports(5)expand_less
ISM-0481ISM-0481 requires that cryptographic software and libraries only use approved high assurance cryptographic protocols
ISM-1616ISM-1616 requires a formal vulnerability disclosure program to help securely develop and maintain products and services by receiving and ...
ISM-1797ISM-1797 requires software development outputs (installers, patches and updates) to be digitally signed or distributed with cryptographic...
ISM-1826ISM-1826 requires selecting vendors who build server applications using Secure by Design/Secure by Default principles and secure programm...
ISM-2025ISM-2025 requires an issue tracking solution to link software development tasks to security issues/decisions and to change, feature and d...
extensionDepends on(1)expand_less
ISM-2121ISM-2121 requires that only developers with sufficient cyber security skills are used on relevant projects or tasks
linkRelated(8)expand_less
ISM-0971Annex A 8.25 requires defined and consistently applied secure development rules across the lifecycle
ISM-1238Annex A 8.25 requires organisations to establish and apply rules for secure development of software and systems
ISM-1849Annex A 8.25 requires secure development lifecycle rules to be established and applied
ISM-2031Annex A 8.25 requires organisations to establish and apply rules across a secure development lifecycle for software and systems
ISM-2034Annex A 8.25 requires organisations to define and apply rules for secure development over the SDLC
ISM-2036Annex A 8.25 requires secure development lifecycle rules to be established and applied
ISM-2040Annex A 8.25 requires organisations to define and apply secure development rules across the SDLC
ISM-2061Annex 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.

See all Technological controls controls, or browse the full ISO 27001 library.

school

Want to implement this control?

Mindset Cyber runs PECB-accredited ISO/IEC 27001 training that maps directly to the controls in this library.

Mapping detail

Mapping

Direction

Controls