A.8.25 Secure development life cycle
Establish and apply rules for secure development of software and systems.
13
artefacts
3
held by a system
3
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
- Static analysis tool output logs · SIEM / log platform
- Approved code change tickets · SIEM / log platform
- Fuzz testing logs · SIEM / log platform
periodic reviewEvidence produced at each review
- Risk assessment worksheets · Policy repository / GRC workspace
- Peer review meeting minutes · SIEM / log platform
- Penetration test report · Vulnerability scanner / patch tooling
governing documentDocuments that govern the control
- Secure Development Policy document · Policy repository / GRC workspace
- Secure Coding Standards manual · Policy repository / GRC workspace
- Developer onboarding checklist · HR system / LMS
- Threat Model diagrams · Document repository
- Mitigation decision register · Policy repository / GRC workspace
- Dynamic application security testing results · Document repository
- Vulnerability remediation tracker · Policy repository / GRC workspace
First move
Mostly documents and reviews. Pull the 3 system-held artefacts from your SIEM / log platform 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
- Policy exists but not enforced
- Threat models not updated for new features
- Code reviews performed inconsistently
- Security testing limited to final release
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 sheetA.8.24 Use of cryptography · A.8.26 Application security requirements