A.8.29 Security testing in development and acceptance
Define and run security testing across the development life cycle.
8
artefacts
1
held by a system
2
at each review
hard
to go live
Policy repository / GRC workspace
where the evidence lives
teal = a system already holds it · olive = produced at each review
system holds itEvidence a system already holds
- Remediation ticket 12345 · Vulnerability scanner / patch tooling
periodic reviewEvidence produced at each review
- Penetration test report · Vulnerability scanner / patch tooling
- Security signoff minutes · Policy repository / GRC workspace
governing documentDocuments that govern the control
- Development security test plan v1.2 · Policy repository / GRC workspace
- Test scope matrix · Policy repository / GRC workspace
- Static code analysis summary.html · Document repository
- Vulnerability tracker to · Policy repository / GRC workspace
- Release acceptance checklist · Policy repository / GRC workspace
First move
Mostly documents and reviews. Pull the 1 system-held artefact from your Vulnerability scanner / patch tooling on a schedule; put the documents under version control with an owner and review date, and log each review as a dated record with a named reviewer.
Common gaps auditors find
- testing only after release
- inconsistent test coverage across modules
- lack of documented remediation evidence
- no formal acceptance signoff
Do this for your whole sheet
Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.
Build my evidence sheet