ISO/IEC 27001:2022 · derived mapping target
A.8.29Security testing in development and acceptance
Test software for security during development and before it is accepted into production, so weaknesses are caught before release.
Mapping at a glance
A.8.29Security testing in development and acceptanceISO/IEC 27001:2022
A.8.29 is covered by 14 Sekit CSF controls. +9 more in the table below. Open in the full graph →
Mapped from the Sekit CSF
The Sekit controls that cover this requirement, lens by lens.
RCF-0031Control testing program · PolicysupportsThis Sekit policy defines which controls get tested, how often and by whom, giving security testing before release the planned structure this ISO control requires.RCF-0033Control testing program · TechnicalsupportsThe Sekit technical control runs automated tooling such as scheduled scans continuously, extending the testing rigor this ISO control requires beyond a one-time check before release.RCF-0117Secure SDLC policy · TechnicalsupportsThis Sekit technical control gates the pipeline so automated security checks must pass before production, the enforcement mechanism this ISO control requires for testing before acceptance.RCF-0121Secure code review · PolicysupportsThe Sekit policy requires a security-focused review before release, one of the testing activities this ISO control requires during development and before acceptance.RCF-0122Secure code review · ProcesssupportsThis Sekit process control runs a security-aware peer review on every change, the human testing layer this ISO control requires alongside automated scans.RCF-0123Secure code review · TechnicalsupportsThe Sekit technical control wires an automated scanner into the workflow to catch flaws on every change, one of the automated testing methods this ISO control requires.RCF-0124SAST/DAST · PolicysupportsThis Sekit policy documents the requirement for automated static and dynamic testing before release, one of the testing methods this ISO control requires alongside review and acceptance checks.RCF-0125SAST/DAST · ProcesssupportsThe Sekit process control executes static and dynamic tests as a routine part of every build, applying the testing this ISO control requires to each release rather than occasionally.RCF-0126SAST/DAST · TechnicalsupportsThis Sekit technical control integrates the test tools into the pipeline so a critical finding stops the release, the enforced gate this ISO control expects.RCF-0129Dependency/SBOM management · TechnicalsupportsThe Sekit technical control runs automated dependency scanning that flags or blocks builds with known-vulnerable components, a specific test this ISO control requires before acceptance.RCF-0135IaC scanning · TechnicalsupportsThis Sekit technical control blocks infrastructure templates that fail automated scanning from ever deploying, closing off a path to production that bypasses the application-level tests entirely.RCF-0137API security · ProcesssupportsThe Sekit process control folds security into API design, pre-release testing and live monitoring, giving endpoints ongoing scrutiny that a one-time pre-release scan alone would miss.RCF-0141Container security · TechnicalsupportsThis Sekit technical control scans container images before they deploy and keeps enforcing restrictions once containers are running, catching drift that a pre-release scan alone would not see.RCF-0404Release management · ProcesssupportsThis Sekit process control puts every release through testing and approval before deployment with records kept, the acceptance discipline this ISO control requires before software reaches production.
NIST CSF 2.0 counterparts
Reached through the Sekit CSF controls both map to — a mapping, not a formal equivalence.
ISO/IEC 42001:2023 — Annex A counterparts
Cyber Essentials counterparts
Evidence that proves this control
What an auditor, or Sekit's evidence engine, asks for.
Application security testing evidence
The proof that code and applications are automatically scanned for flaws (SAST/DAST), including dependencies and APIs.
CI/CD pipeline security
The security controls in the automated build-and-deploy process, including containers and infrastructure-as-code.
From the Sekit evidence catalog
In practice
Security testing before release combines automated and human checks: static and dynamic scans run on every build, dependency scanning flags known-vulnerable components, and a security-aware peer review catches what the tools miss. Auditors expect the pipeline configuration to show these as hard gates, a critical finding blocking the release rather than only logging a warning, and want findings tracked to closure rather than dismissed. The gap that shows up most often is dependency scanning that runs and reports correctly, but nobody owns triaging the alerts, so a known-vulnerable library ships release after release while the scan report technically proves the control exists.
Common gaps
Dependency scanning correctly flags a critical vulnerability in a shared library, but nobody has triaged the alert or assigned it an owner.
Static analysis runs in CI but its results are advisory only, so builds with high-severity findings still deploy to production.
Container images are scanned before deployment, but runtime enforcement is missing, so a container with a known vulnerability can still be started manually.
Questions your auditor will ask
Does a critical finding from your security tests block a release, or only get logged?
The security test tools are integrated into the pipeline so a critical finding stops the release automatically before it reaches production.
How do you catch vulnerable third-party dependencies before they ship?
Automated dependency scanning flags or blocks builds containing components with known vulnerabilities, shown in the application security testing evidence.
Is every code change reviewed by a person as well as scanned by tools?
Yes, every change gets a security-aware peer review from a trained developer in addition to the automated static and dynamic tests.
How are releases approved before deployment?
Every release goes through testing and approval before deployment, in practice and with records, rather than being deployed straight from a developer machine.
Where regulation demands it
NIS2 art. 6.5 requires security testing before systems go live, and ENS mp.sw.2 requires formal acceptance and putting systems into service only after that testing is complete.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.
Ask Sekura: “What evidence proves A.8.29?”
Also via MCP, free with account