ISO 27001 control 8.29 expects you to test software against its security requirements before accepting it, using a defined process with test methods and acceptance criteria. Evidence is a test plan, dated results, and a recorded decision to accept or reject. Automated pipeline reports count.
What the control says
The control calls for a testing process that verifies security requirements are implemented in the software as specified. It applies in development and at acceptance. A policy or procedure is recommended, not mandatory.
For small teams the testing rules fit in the secure development policy. Larger companies may write a secure testing and acceptance procedure.
Define four things first
The guidance lists the pieces of the process:
- Test methods, such as code analysis, dependency checks, dynamic testing
- A plan, including who runs what and when
- Expected inputs and outputs for each test
- Acceptance criteria used to approve a system
Acceptance criteria are the part teams skip. Write them as a rule: for example, no open critical findings without a recorded exception.
Match method to question
| Question | Test type |
|---|---|
| Does our own code have flaws? | Static code analysis |
| Are the libraries we ship vulnerable? | Dependency scanning |
| Does the running app misbehave? | Dynamic testing |
| Does a security feature work as specified? | Functional test of that feature |
Evidence to keep
Auditors may look for evidence that software is tested against security requirements. A tidy set:
- The test methods and acceptance criteria
- Dated reports from the last few releases
- A record of who approved each release
- Exceptions with owner and expiry
Tools that automate scripts and generate reports make this cheap. Small teams can run them on developer machines. Larger ones often centralise them.
Try it yourself
Open the demo and run a code scan. Look at the dated findings list and imagine it attached to a release record as your testing evidence.
Click through it at your own pace, or open it full screen.
Where tooling helps
Safeguard offers SBOM and dependency scanning, reachability analysis and policy gates that record pass or fail on pull requests. You define the acceptance criteria. Try the free scan at gold.safeguard.sh/scan.
Quick check
Do automated scan reports count as evidence?
Yes, if they are dated, tied to a release and kept. The control mentions tools that automate tests and generate reports.
What are acceptance criteria?
They are the rules used to decide whether tested software may go live, such as which severities block a release.
Sources
Last reviewed: 19 October 2026.
