ISO 27001 Annex A 8.29 Security testing in development and acceptance
What it says
Security testing processes shall be defined and implemented in the development life cycle.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEnsure security tests are part of the development process to find issues early.
This control is about making sure computer systems and software are tested for security problems before they're used in real life. If this isn't done, a company could end up with systems that hackers can easily attack, leading to data breaches and loss of customer trust.
Free. Save your status, tasks and notes.
Why it matters
Without security testing during development and acceptance, vulnerabilities can reach production undetected, increasing breach likelihood, rework cost and stakeholder trust loss.
How to implement
The IT manager should integrate security testing as a core part of the software development process.
This means planning security checks right from the start and ensuring these tests meet specific safety standards laid out in ISO 27002:2022. The checks should not only cover how the software is supposed to work but also consider any ways it could be attacked or misused.
Developers should perform secure coding and code reviews to catch security issues early.
They need to follow secure coding practices and undergo training to spot common vulnerabilities. Peer reviews should be conducted regularly where developers check each other's work for potential security weaknesses before it's sent for further testing.
Security officers should ensure that any changes or updates to systems are tested in an environment that mimics the real setup as closely as possible.
This involves setting up test environments that use the same configurations as production systems, based on guidelines from the ASD Essential Eight.
The procurement team should include security requirements in contracts with software suppliers.
They need to clarify that the supplier must perform and document thorough security testing on their products, which should be evaluated against the Australian Cyber Security Centre guidelines before any purchase or implementation.
IT staff should employ automated security testing tools to identify vulnerabilities efficiently.
These tools, like vulnerability scanners, should be used alongside manual tests to provide a comprehensive overview of potential security issues, ensuring compliance with the Privacy Act 1988 and APRA CPS 234.
Keep it running
Incorporate security tests into every sprint; ensure all findings feed directly into the bug-tracking system for prompt action.
Evidence and audit
- Check 1 of 4What an auditor asks for
Ask for
The security testing plan for recent software projects.
Look at
Whether the plan covers all phases of development and includes both automated and manual testing methods.
Good evidence
Plan will show structured testing at each development stage with specific goals and security checks.
- Check 2 of 4What an auditor asks for
Ask for
Evidence of security training given to developers.
Look at
Attendance records and training materials that focus on secure coding and vulnerability awareness. Good evidence shows regular, comprehensive training sessions that cover current security threats and best practices.
- Check 3 of 4What an auditor asks for
Look at
Configurations and setup scripts to ensure they match the production environment. Proper documentation will verify that test environments are accurate models of actual systems, as per ISO 27002:2022.
- Check 4 of 4What an auditor asks for
Ask for
Supplier contracts for outsourced software. Review whether contracts specify security requirements and testing obligations. Good contracts include specific clauses for security testing and compliance with applicable Australian cyber security standards.
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.
ISO/IEC 42001: 1 mapping
This control partially overlaps A.6.2.4.
Annex A 6.2.4 requires defining and documenting verification and validation measures for an AI system, with criteria for when they are applied. ISO/IEC 27001 Annex A 8.29 requires defined and implemented security testing processes in the development life cycle, which is a key subset of verification activities for AI system software and infrastructure. The overlap is partial because Annex A 8.29 is limited to security testing in development/acceptance, while Annex A 6.2.4 also covers AI-specific validation of intended purpose, model behaviour, and non-security quality attributes.
ASD Information Security Manual: 23 mappings
This control is broader than ISM-0402.
ISM-0402 requires comprehensive software vulnerability testing using SAST, DAST and SCA before initial release, subsequent releases, and periodically to uncover previously unidentified vulnerabilities. Annex A 8.29 requires that security testing processes are defined and implemented within the development and acceptance lifecycle, which can include vulnerability testing activities such as SAST/DAST/SCA. ISM-0402 is more prescriptive and specific about the testing types and timing, whereas Annex A 8.29 is broader and leaves the specific testing methods to the organisation.
This control is broader than ISM-0971.
ISM-0971 requires web applications to be developed against OWASP ASVS, which defines verification requirements and associated testing expectations. Annex A 8.29 requires security testing processes to be defined and implemented in the development life cycle. Implementing OWASP ASVS under ISM-0971 directly strengthens Annex A 8.29 by providing concrete testable controls and acceptance criteria, though Annex A 8.29 also covers broader testing processes beyond web applications.
This control is broader than ISM-1524.
ISM-1524 requires that content filters used by Cross Domain Solutions (CDSs) are subjected to rigorous security testing to confirm they work as intended and cannot be bypassed. Annex A 8.29 requires defined and implemented security testing within the development and acceptance lifecycle, which would include testing of security-relevant components such as content filters. ISM-1524 is a specific, high-rigour testing requirement for a particular security control (CDS content filters), whereas Annex A 8.29 is broader and applies to security testing across the SDLC generally.
This control is broader than ISM-2032.
ISM-2032 requires the build solution to gate software artefact creation until all automated tests complete with no warnings, alerts or errors. Annex A 8.29 requires security testing processes to be defined and implemented across development and acceptance, which commonly includes automated security/unit/integration tests as part of CI/CD. ISM-2032 is a specific pipeline enforcement mechanism, while Annex A 8.29 is broader and covers defining the testing regime (including acceptance testing), not just enforcing clean test outcomes before build.
This control is broader than ISM-2054.
ISM-2054 requires using an available SBOM for third-party components to identify and avoid known vulnerabilities during software development. This supports Annex A 8.29 by providing a concrete input to security testing (component inventory plus versioning) that can be used to drive SCA checks and vulnerability-focused test activities within the development life cycle. Annex A 8.29 is broader in testing scope (e.g. dynamic testing, acceptance testing) whereas ISM-2054 is specifically about SBOM-informed vulnerability checking of third-party components.
This control is broader than ISM-2102.
ISM-2102 necessitates the periodic testing of software artefacts using SAST, DAST, or SCA throughout the SDLC. Annex A 8.29 requires defining security testing processes within the development lifecycle, which includes activities like SAST/DAST/SCA. ISM-2102 is more specific about periodicity and methodology compared to the broader Annex A 8.29.
This control is broader than ISM-2122.
ISM-2122 requires the use of suitable AI models to augment security testing for organisational software. ISO/IEC 27001:2022 Annex A 8.29 requires defining and implementing security testing processes across the development lifecycle, allowing for AI-assisted testing approaches, making ISM-2122 a specific technique within this broader requirement.
This control partially meets ISM-0401.
Annex A 8.29 requires organisations to define and implement security testing processes within the development and acceptance life cycle. ISM-0401 incorporates Secure by Design principles, which generally includes security testing as part of these processes. While ISM-0401 is broader (encompassing architecture and governance), Annex A 8.29 focuses specifically on testing processes.
This control partially meets ISM-1780.
Annex A 8.29 requires security testing processes to be embedded in development and acceptance. ISM-1780 covers wider DevOps practices that integrate automated security testing, among other measures, throughout the SDLC. It encompasses broader cultural and operational practices beyond just testing.
This control partially meets ISM-2042.
Annex A 8.29 mandates defining and implementing security testing processes throughout development and acceptance. ISM-2042 enforces Secure by Default principles across the SDLC, often verified by testing. This widens its scope beyond testing to include default security settings, while Annex A 8.29 narrows down to the procedural aspects of security testing.
This control partially meets ISM-2057.
ISM-2057 focuses on ensuring input validation is specified, implemented, and tested using positive and negative unit or integration tests. Annex A 8.29 requires security testing processes to be defined and implemented throughout development and acceptance, which can include validation-focused test cases. ISM-2057 is narrower because it prescribes a particular class of security testing (input validation) and traceability, while Annex A 8.29 spans broader security testing methods and coverage.
This control partially meets ISM-2062.
ISM-2062 requires unit and integration testing (including positive and negative use cases) to assure code quality and security. This directly fits within ISO/IEC 27001:2022 Annex A 8.29, which requires defined and implemented security testing processes across the development life cycle and acceptance activities. Annex A 8.29 is broader in that it can include additional security testing types (e.g. dynamic testing, penetration testing, acceptance criteria) beyond unit and integration testing that ISM-2062 explicitly calls out.
This control partially overlaps ISM-1791.
ISM-1791 requires assessing the integrity of delivered IT and OT products and services as part of acceptance. Annex A 8.29 requires security testing in development and acceptance, which can include validation that delivered software/components are genuine and unmodified before go-live. Annex A 8.29 is oriented to SDLC security testing (often for internally developed or integrated solutions), while ISM-1791 applies broadly to delivered operating systems, applications, and physical IT/OT equipment regardless of development origin.
This control partially overlaps ISM-1922.
ISM-1922 requires development teams to use OWASP MASVS as a security standard for mobile application development. ISO/IEC 27001:2022 Annex A 8.29 requires defined and implemented security testing processes within the development lifecycle. MASVS includes verification requirements and testing/validation expectations that can inform mobile app security testing, but Annex A 8.29 applies to security testing more generally and is not limited to OWASP or mobile.
This control partially overlaps ISM-2026.
ISM-2026 requires scanning software artefacts for malicious code before they are imported into the authoritative software source. Annex A 8.29 relates by requiring security testing to be defined and implemented within the development and acceptance lifecycle, which can include malware and integrity checks on build outputs and dependencies. Annex A 8.29 is broader (covers multiple kinds of security testing and SDLC stages), while ISM-2026 is specifically focused on malicious code scanning at the import/gating point.
This control partially overlaps ISM-2028.
Annex A 8.29 requires implementing security testing processes in development and acceptance. ISM-2028 specifies security testing (SAST, DAST, SCA) for third-party components, representing a subset of activities. ISM-2028 is more focused on third-party testing, while Annex A 8.29 oversees a broader testing strategy inclusive of acceptance testing.
This control partially overlaps ISM-2060.
ISM-2060 requires code reviews to validate Secure by Design and secure programming practices in software. ISO/IEC 27001:2022 Annex A 8.29 requires security testing processes to be defined and implemented in the development lifecycle, which can include static analysis, manual review, and other verification activities that may overlap with code review. Annex A 8.29 is broader across multiple testing approaches, while ISM-2060 is specifically about the review of code/design conformance rather than testing outcomes.
This control partially overlaps ISM-2061.
ISM-2061 requires developer-supported security-focused peer reviews on critical and security-focused software components to identify security issues early. Annex A 8.29 requires security testing processes to be defined and implemented in the development and acceptance lifecycle, and peer reviews are one form of security verification that can complement technical testing. Annex A 8.29 extends beyond review into defined testing activities (e.g. SAST/DAST/penetration testing), while ISM-2061 is specifically about human review of code/design changes.
This control supports ISM-1238.
ISM-1238 requires threat modelling during the SDLC to identify potential risks and likely attack paths. Annex A 8.29 requires security testing processes to be defined and implemented in the development life cycle, and threat models are commonly used to derive and prioritise security test cases (e.g., abuse-case testing) and acceptance criteria. The key difference is that ISM-1238 is about analytical risk identification, while Annex A 8.29 is about executing and governing testing activities.
This control supports ISM-1850.
ISM-1850 requires the OWASP Top 10 to be mitigated in web application development. ISO/IEC 27001:2022 Annex A 8.29 requires defined and implemented security testing across development and acceptance, which is a key mechanism to detect OWASP Top 10 issues (e.g. injection, broken access control, security misconfiguration) before release. Annex A 8.29 focuses on testing processes, whereas ISM-1850 is about ensuring the specific OWASP Top 10 risks are addressed (through design, coding, configuration and testing).
This control supports ISM-2039.
ISM-2039 requires reviewing the threat model throughout development so identified threats and assumptions remain accurate as the software is built and changed. ISO/IEC 27001:2022 Annex A 8.29 requires security testing processes to be defined and implemented in the development life cycle, and an up-to-date threat model directly informs what to test, when to retest, and which abuse cases to prioritise. Annex A 8.29 is about executing testing activities, whereas ISM-2039 is about maintaining the threat model that guides and justifies those tests.
This control depends on ISM-2033.
Annex A 8.29 stipulates defining and executing security testing processes within the SDLC. ISM-2033 focuses on maintaining detailed software security requirements that inform testing criteria. While Annex A 8.29 handles the practical testing execution, ISM-2033 reinforces it via robust requirements management.
This control depends on ISM-2119.
ISM-2119 requires suitable AI models to be used to augment vulnerability assessments and penetration tests. This supports ISO/IEC 27001 Annex A 8.29 by strengthening the organisation's security testing processes (e.g., using AI to improve test coverage, triage findings, and identify exploitable paths) within the development and acceptance lifecycle. Annex A 8.29 is broader in that it requires defined and implemented security testing processes regardless of tooling, whereas ISM-2119 is a specific augmentation technique focused on AI-enabled testing.
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.