ISO 27001 Annex A 8.29
Untested code is unproven code - test the security as well as the function.
ISO 27001 Annex A 8.29 - Security Testing in Development and Acceptance
The control asks for security testing to be a defined part of the development cycle, not an afterthought. The point is that vulnerabilities are cheaper to fix during development than after release, and far cheaper to fix before they are exploited. Security testing at multiple stages - during build, before release, and at significant milestones - catches issues at the cheapest fix point.
Practical security testing combines automated and manual approaches. Static analysis catches known vulnerable patterns in source code. Dynamic testing exercises the running application for issues only visible at runtime. Dependency scanning identifies vulnerable libraries. Penetration testing finds the issues automation misses, particularly in business logic. Each technique has its place.
Acceptance criteria should include security. A release that fails functional acceptance does not ship; a release that fails security acceptance should be treated the same way. The acceptance gate should specify what security testing has to be passed and what to do when it is not.
The audit looks for evidence that security testing actually drove decisions - findings raised, prioritised, and either fixed or accepted with documented justification. Where the test reports exist but cannot be tied to action, the control is documenting test execution rather than driving security improvement. The connection from test to outcome is what makes the control effective.
Practical Compliance Guidance
Security testing is described in the IMS1 manual at section 8.5 alongside the Information Security Policy. Test reports and remediation records provide the operational evidence.
| alphaZ document | How to use it |
|---|---|
| ISO 27001 Toolkit | The full alphaZ ISO 27001 toolkit covering manual, policies, procedures, registers and audit checklists. |
| PP-8-100 Information Security Policy Procedure | Contains the Information Security Policy including the testing requirements at each development stage. Use as the source for security testing governance. |
Note - all the above files can be downloaded with an alphaZ subscription.
