Annex A.8.29 Security Testing in Development and Acceptance

Annex A.8.29 requires security testing to be defined and performed across the development lifecycle, including before release. The control is about proving that security checks are built into acceptance and delivery processes, so issues are found before they reach production and become harder to fix.

Expanded Definition

Annex A.8.29 Security Testing in Development and Acceptance is a lifecycle control that requires security testing to be planned, executed, and evidenced before software is accepted for release. It treats security assurance as part of delivery, not as a separate review after deployment. In practice, this means security requirements, test cases, and acceptance criteria are aligned so that vulnerabilities, misconfigurations, and unsafe behaviours are identified while change is still inexpensive to correct.

This control is closely related to secure development governance in ISO/IEC 27001:2022 Information Security Management and the control family model in NIST SP 800-53 Rev 5 Security and Privacy Controls, though organisations apply it through different development methods. Some teams interpret it narrowly as penetration testing before go-live, but that is too limited. The better reading is broader: code analysis, dynamic testing, dependency checks, configuration validation, and acceptance sign-off all contribute to whether the control is met. ISO guidance in ISO/IEC 27002:2022 Information Security Controls also reinforces that security controls should be embedded into change and release activity.

The most common misapplication is treating security testing as a one-time pre-launch checkbox, which occurs when teams run a final scan without defined acceptance criteria or repeatable evidence.

Examples and Use Cases

Implementing security testing rigorously often introduces release-gate friction, requiring organisations to weigh delivery speed against the cost of shipping defects that should have been caught earlier.

• Automated static analysis runs in the build pipeline, and a release is blocked if critical findings remain unresolved.
• dynamic application security testing is performed in a staging environment that mirrors production closely enough to validate authentication, session handling, and input controls.
• Infrastructure-as-code templates are reviewed and tested before acceptance so insecure defaults, exposed services, or weak network paths are caught before deployment.
• Security acceptance criteria are written into user stories, making security a formal condition of done rather than an informal recommendation.
• For applications that use agents, APIs, or non-human identities, test cases verify that secrets, tokens, and privileged workflows cannot be abused during deployment or handoff.

In mature environments, this control is also applied to third-party components and updates, because dependency risk can enter the delivery chain even when source code itself is unchanged. That is why many teams map testing requirements to established governance patterns in ISO/IEC 27001:2022 Information Security Management and use control baselines from NIST SP 800-53 Rev 5 Security and Privacy Controls to define acceptable evidence.

Why It Matters for Security Teams

Security Testing in Development and Acceptance matters because it shifts security assurance left without removing accountability at release. If teams do not define what must be tested, when it must be tested, and what evidence is required for acceptance, insecure code can pass through delivery workflows simply because delivery was successful. That creates a false sense of control, especially in fast-moving environments where build automation can make weak governance look efficient.

This is also where identity security and NHI governance intersect naturally. Build pipelines, deployment tools, service accounts, and agents often rely on non-human identities and secrets, so testing must cover privilege boundaries, token handling, and misuse of automation paths. A release may look functionally correct while still exposing credentials, over-permissioned roles, or unsafe API trust relationships. Controls such as ISO/IEC 27002:2022 Information Security Controls and NIST SP 800-53 Rev 5 Security and Privacy Controls become operationally relevant when evidence is needed to prove that security gates actually existed.

Organisations typically encounter the consequences only after a vulnerable release, a failed audit, or a production incident, at which point security testing in development and acceptance becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams use AI-driven testing in the development lifecycle?
• How can security and development teams improve API security testing for SPAs?
• How should security teams build mobile app testing into development pipelines?
• When does static testing create a false sense of security?