ISO/IEC 27001:2022 Annex A · Control 8.29

Security Testing in Development and Acceptance: A Practical Implementation Guide

Test security requirements and realistic attack paths before systems enter or change production.

This control concerns defining and implementing security testing throughout development and acceptance.

Practical interpretation: Testing should be risk based, independent enough for the context and traceable to requirements. A one-time scan does not establish secure acceptance.

What should the control achieve?

Security test strategy follows application risk.
Automated and manual methods complement each other.
Findings affect release decisions.
Production fixes are verified and regression-tested.

Step-by-step implementation

Plan testing by risk

Select SAST, DAST, dependency, configuration, abuse-case and penetration testing.

Define acceptance criteria

Link severity, required evidence and exception authority to release.

Prepare safe environments

Use controlled data, accounts, tooling and test boundaries.

Execute throughout delivery

Test components early and integrated behavior before release.

Triage findings

Validate, assign owner, prioritize and distinguish root cause.

Retest and close

Verify fixes and add regression coverage.

What this could look like in practice

A high-risk customer portal runs automated scans on every build and manual authorization testing before release. Critical findings block deployment; accepted medium findings need risk-owner approval and expiry.

Activity	Practical implementation	Evidence
Pipeline test	Automated checks give rapid developer feedback.	Build report
Acceptance test	Security requirements map to test cases.	Traceability
Penetration test	Independent testers assess realistic attack paths.	Test report
Retest	Fix is verified before closure.	Retest evidence

Implementation evidence

Security test strategy
Risk classification
Test plans
Acceptance criteria
Tool reports
Manual test reports
Finding tracker
Retest records

Useful metrics

Critical findings at release
Security tests completed
Fixes passing retest
Production defects missed

Common mistakes

Testing only immediately before launch.
Using scanners without validation.
Letting developers close their own critical findings without retest.
No acceptance criteria.
Testing with uncontrolled production data.

Questions an auditor may ask

How is test depth determined?
Which requirements have tests?
Who can accept findings?
Show a retest.

Implementation test: Select a released feature and trace its security requirements, planned tests, findings, decisions and regression coverage.

Continue through Annex A

Explore the growing library of practical guides for all 93 Annex A controls.

Open the ISO 27001 Annex A Control Library

This independent educational guide paraphrases the practical intent of the control and does not replace the official ISO standards, professional advice or an organization-specific risk assessment. It is not affiliated with or endorsed by ISO.

ISO 27001 Annex A 8.29: Security Testing in Development and Acceptance – Practical Implementation Guide