# ISO/IEC 27001:2022 A.8.29 — Security testing in development and acceptance - Source: https://support.icompaas.com/compliance/iso-27001-2022/a-8-29-security-testing-in-development-and-acceptance - Section: [Compliance](https://support.icompaas.com/compliance) › [ISO/IEC 27001:2022 Annex A Controls](https://support.icompaas.com/compliance/iso-27001-2022) › Technological controls - Last updated: 2026-06-05 - Publisher: iCompaas, Inc. (https://www.icompaas.com) **ISO/IEC 27001:2022**·Annex A `A.8.29`·high·Component: **Technological controls** ## What this control requires > Security testing processes shall be defined and implemented in the development life cycle. > > — ISO/IEC 27001:2022, Annex A A.8.29 ### In plain English Security testing processes shall be defined and implemented in the development life cycle. In practice, this means you can prove you policy management-level controls on a defined cadence. ## Why it matters ISO 27001 certification depends on showing each Annex A control is either implemented or explicitly justified for exclusion in the Statement of Applicability (SoA). Certification bodies sample controls during surveillance audits, and a missing SoA entry — or implementation that doesn't match the SoA wording — is a finding. This control is rated **high**. Auditors expect a named owner, a remediation SLA, and a tooling artefact that evidences continuous operation. ## What an auditor looks for An ISO 27001 lead auditor looks for: (1) an SoA entry covering the control with justification, (2) a documented procedure or policy implementing it, (3) records that prove the procedure runs (logs, tickets, training records) and (4) management-review evidence that effectiveness is monitored. Within **Technological controls**, the assessor will trace your implementation back to the catalogue reference (Annex A A.8.29) and look for objective evidence on the latest two assessment cycles. ## How to implement #### Code Review Testing **Pipeline.** Require at least one human reviewer plus passing CI (lint, type, unit, security scan) before merge — protected branches enforce this. #### Policy Management **Docs.** Keep each policy in version-controlled Markdown alongside the code that implements it; ship a signed PDF snapshot at each annual review and link the SHA into the SoA. #### Secure Development **Pipeline.** Require code review, SAST (Semgrep / Snyk Code), SCA (Dependabot / Renovate), secret-scanning and IaC scanning in the merge pipeline. **Branch protection.** Protected branches enforce reviews, signed commits and passing CI before merge; document the protection rules as the control evidence. ### Operational checklist - **Policy.** Document the trigger, the owner and the cadence. - **Management.** Document the trigger, the owner and the cadence. - **Secure.** Document the trigger, the owner and the cadence. - **Security.** Document the trigger, the owner and the cadence. - **Scope:** management, security, development life cycle. ## Evidence to collect - **Code Repo Scan.** Source-control evidence — branch protection, required reviewers, CI status, SCA / SAST reports. - **Ticketing Workflow.** `ticketing_workflow` evidence Pipeline security tests and release approvals show defects are addressed before acceptance. ## Common pitfalls - Policies that no engineer has read; the version in Confluence drifts from the version that's actually being enforced. - CI security checks set to warn-only; the merge button is faster than the security feedback. ## How it maps to other frameworks Computed from shared tags, control component and key-operation subjects — handy when you are reconciling controls across an audit. - [**NIST SP 800-171 Rev. 3 3.13.2** — Recategorized as NCO](https://support.icompaas.com/compliance/nist-sp-800-171-rev-3/3-13-2-recategorized-as-nco) - [**BSI C5:2020 DEV-01** — Policies for the development/procurement of information systems](https://support.icompaas.com/compliance/bsi-c5-2020/dev-01-policies-for-the-development-procurement-of-information-systems) - [**SOC 2 (2017 TSC) CC1.2** — Board Independence and Oversight](https://support.icompaas.com/compliance/soc-2-trust-services-criteria/cc1-2-board-independence-and-oversight) - [**HIPAA (45 CFR Part 164) 164.308(a)(5)(i)** — Security Awareness and Training](https://support.icompaas.com/compliance/hipaa/164-308-a-5-i-security-awareness-and-training) - [**NIST SP 800-53 Rev. 5 SA-15(3)** — Criticality Analysis](https://support.icompaas.com/compliance/nist-sp-800-53-rev-5/sa-15-3-criticality-analysis) ## Related controls in ISO/IEC 27001:2022 - [**Annex A A.8.25** — Secure development life cycle](https://support.icompaas.com/compliance/iso-27001-2022/a-8-25-secure-development-life-cycle) - [**Annex A A.8.31** — Separation of development, test and production environments](https://support.icompaas.com/compliance/iso-27001-2022/a-8-31-separation-of-development-test-and-production-environments) - [**Annex A A.8.27** — Secure system architecture and engineering principles](https://support.icompaas.com/compliance/iso-27001-2022/a-8-27-secure-system-architecture-and-engineering-principles) - [**Annex A A.8.28** — Secure coding](https://support.icompaas.com/compliance/iso-27001-2022/a-8-28-secure-coding) - [**Annex A A.8.33** — Test information](https://support.icompaas.com/compliance/iso-27001-2022/a-8-33-test-information) - [**Annex A A.8.26** — Application security requirements](https://support.icompaas.com/compliance/iso-27001-2022/a-8-26-application-security-requirements) ## References - [ISO/IEC JTC 1/SC 27 — ISO/IEC 27001:2022](https://www.iso.org/standard/27001) - Catalogue identifier: `Annex A A.8.29` Topics: governance riskcode review testingpolicy managementsecure development ## Related compliance guidance - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): Start with the full ISO 27001 implementation guide — scope, roadmap, evidence and how the assessment runs. - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Most companies that hold ISO 27001 also need a SOC 2 report for North American customers, and the two share most of their technical controls.