ISO 27001 A.8.29 - Security Testing in Development and Acceptance

Requirement

“Security testing processes shall be defined and implemented in the development life cycle.”

Plain-language meaning

Security testing should be planned, performed, recorded, and used as part of development and acceptance. It should not be left until the final days before go-live.

Testing can apply to new systems, changed systems, subsystems, devices, applications, infrastructure, and integrations.

Why this matters

If security testing happens only at the end, vulnerabilities and inappropriate functionality can remain embedded in the system and become expensive to fix. Early and repeated testing finds problems while they are still manageable.

Acceptance criteria should define what security evidence is required before a system is approved for operational use.

Implementation guidance

1. Define security testing process

Define when security testing occurs, which methods apply, who performs testing, what evidence is retained, and who approves acceptance.

2. Select testing methods by risk

Testing may include security requirements testing, vulnerability scanning, penetration testing, automated source code testing, dependency testing, manual code review, formal analysis, configuration testing, and abuse-case testing.

3. Test during development

Use ongoing testing to remove vulnerabilities early. Do not rely only on final acceptance testing.

4. Define acceptance criteria

Security acceptance criteria should cover access control, defective input handling, regression tests, security controls, secure configuration, user training, operational readiness, and unresolved vulnerabilities.

5. Involve relevant stakeholders

Operations, users, product owners, security, and other stakeholders should be involved where their role affects secure operation or acceptance.

Audit guidance

Auditors should verify:

• security testing process is defined;
• testing frequency and depth are risk-based;
• security acceptance criteria are defined;
• testing occurs during development and before operational use;
• regression, defective input, access control, and security control tests are considered;
• findings are recorded, remediated, retested, or risk-accepted;
• operations and users are consulted where secure operation depends on them;
• required training is considered before acceptance;
• final acceptance is authorized and recorded.

Evidence examples

Strong evidence

• Test scope and frequency trace to risk.
• Testing occurs throughout development.
• Acceptance criteria are documented before acceptance.
• Defective input and access control tests are included.
• Findings are closed or risk-accepted before go-live.
• Users and operations are involved where needed.

Weak evidence

• Security testing happens only after development is complete.
• No written acceptance criteria exist.
• Functional testing is treated as security testing.
• Findings are accepted informally.
• Regression or abuse-case testing is missing.
• Users are not trained to operate security controls.

Common failures

Exam traps

Related controls and concepts

• A.8 Technological Controls MOC
• A.8.25 Secure Development Life Cycle
• A.8.26 Application Security Requirements
• A.8.28 Secure Coding
• A.8.8 Management of Technical Vulnerabilities
• A.8.9 Configuration Management
• A.8.19 Installation of Software on Operational Systems
• Security Test Plan
• Security Acceptance Criteria Checklist
• Security Test Results and Remediation Tracker
• Security Acceptance Sign-Off Record
• A.8.29 Audit Evidence Pack
• A.8.29 Audit Checklist

KB-ready summary

• Define security testing process.
• Set acceptance criteria.
• Test throughout development.
• Track and retest findings.
• Include users and operations where secure use matters.
• Record final security acceptance.

Templates and checklists

• Security Test Plan
• Security Acceptance Criteria Checklist
• Security Test Results and Remediation Tracker
• Security Acceptance Sign-Off Record
• A.8.29 Audit Checklist