Annex A 8.29 verified ISO/IEC 27001:2022
Security testing in development and acceptance
Ensure security tests are part of the development process to find issues early.
record_voice_over
Plain language
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.
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
19 Mar 2026
Maturity levels
N/A
Official control statement
Security testing processes shall be defined and implemented in the development life cycle.
verified ISO/IEC 27001:2022 Annex A 8.29
priority_high
Why it matters
Without security testing during development and acceptance, vulnerabilities can reach production undetected, increasing breach likelihood, rework cost and stakeholder trust loss.
settings
Operational notes
Incorporate security tests into every sprint; ensure all findings feed directly into the bug-tracking system for prompt action.
02 — Implement
build
Implementation tips
- 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.
03 — Audit
fact_check
Audit / evidence tips
-
Askthe security testing plan for recent software projects
Goodplan will show structured testing at each development stage with specific goals and security checks
-
Askevidence of security training given to developers
-
Asksupplier 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 cybersecurity standards
04 — Mappings
link
Cross-framework mappings
How Annex A 8.29 relates to controls across ISO/IEC 27001, Essential Eight, and ASD ISM.
ASD ISM
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (12) expand_less | ||
| ISM-0401 | Annex A 8.29 requires organisations to define and implement security testing processes within the development and acceptance life cycle | |
| ISM-0402 | ISM-0402 requires comprehensive software vulnerability testing using SAST, DAST and SCA before initial release, subsequent releases, and ... | |
| ISM-0971 | ISM-0971 requires web applications to be developed against OWASP ASVS, which defines verification requirements and associated testing exp... | |
| ISM-1240 | ISM-1240 requires software to validate and sanitise all internet-sourced input to reduce the likelihood of vulnerabilities such as inject... | |
| ISM-1524 | ISM-1524 requires that content filters used by Cross Domain Solutions (CDSs) are subjected to rigorous security testing to confirm they w... | |
| ISM-1780 | Annex A 8.29 requires security testing processes to be embedded in development and acceptance | |
| ISM-1851 | ISM-1851 requires that OWASP API Security Top 10 issues are mitigated as part of building web APIs | |
| ISM-2032 | ISM-2032 requires the build solution to gate software artefact creation until all automated tests complete with no warnings, alerts or er... | |
| ISM-2042 | Annex A 8.29 mandates defining and implementing security testing processes throughout development and acceptance | |
| ISM-2057 | ISM-2057 focuses on ensuring input validation is specified, implemented, and tested using positive and negative unit or integration tests | |
| ISM-2062 | ISM-2062 requires unit and integration testing (including positive and negative use cases) to assure code quality and security | |
| ISM-2102 | ISM-2102 requires organisations to periodically test existing software artefacts in the authoritative source to detect known weaknesses u... | |
| sync_alt Partially overlaps (8) expand_less | ||
| ISM-1791 | ISM-1791 requires assessing the integrity of delivered IT and OT products and services as part of acceptance | |
| ISM-1922 | ISM-1922 requires development teams to use OWASP MASVS as a security standard for mobile application development | |
| ISM-2026 | ISM-2026 requires scanning software artefacts for malicious code before they are imported into the authoritative software source | |
| ISM-2028 | Annex A 8.29 requires implementing security testing processes in development and acceptance | |
| ISM-2031 | ISM-2031 requires organisations to use security features in compilers, interpreters and build pipelines to improve executable file security | |
| ISM-2055 | ISM-2055 requires using third-party build provenance (when available) during development to validate that imported components meet approp... | |
| ISM-2060 | ISM-2060 requires code reviews to validate Secure by Design and secure programming practices in software | |
| ISM-2061 | ISM-2061 requires developer-supported security-focused peer reviews on critical and security-focused software components to identify secu... | |
| handshake Supports (12) expand_less | ||
| ISM-0400 | Annex A 8.29 requirements for embedding security testing in development life cycles are supported by ISM-0400, which prescribes environme... | |
| ISM-1238 | ISM-1238 requires threat modelling during the SDLC to identify potential risks and likely attack paths | |
| ISM-1239 | ISM-1239 requires the use of robust web application frameworks to reduce common web application security weaknesses by design | |
| ISM-1419 | ISM-1419 requires software changes to be performed only in development environments rather than directly in production | |
| ISM-1597 | ISM-1597 requires credentials to be obscured as they are entered into systems, implying the organisation must implement and validate secu... | |
| ISM-1850 | ISM-1850 requires the OWASP Top 10 to be mitigated in web application development | |
| ISM-2029 | ISM-2029 requires that third-party libraries and components are only imported from trustworthy sources to reduce the likelihood of malici... | |
| ISM-2033 | Annex A 8.29 stipulates defining and executing security testing processes within the SDLC | |
| ISM-2039 | ISM-2039 requires reviewing the threat model throughout development so identified threats and assumptions remain accurate as the software... | |
| ISM-2040 | ISM-2040 requires the use of secure programming practices to reduce the introduction of vulnerabilities during implementation | |
| ISM-2054 | ISM-2054 requires using an available SBOM for third-party components to identify and avoid known vulnerabilities during software development | |
| ISM-2059 | ISM-2059 requires organisations to restrict uploaded/input file types and scan for malicious content before files are accessed, executed ... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.