10.7.3 Failure response timeline
Failures of critical security control systems are responded to promptly, including restoring functions, identifying causes, addressing issues, and modifying procedures to prevent recurrence.
5
artefacts
2
held by a system
0
at each review
moderate
to go live
Ticketing / ITSM
where the evidence lives
teal = a system already holds it · olive = produced at each review
system holds itEvidence a system already holds
- Incident tickets with response timelines · Ticketing / ITSM
- Metrics on MTTR · Policy repository / GRC workspace
periodic reviewEvidence produced at each review
none for this control
governing documentDocuments that govern the control
- Root cause analysis documents · Document repository
- Procedure update records post-incident · Policy repository / GRC workspace
- Trend analysis of control failures · Document repository
First move
Start with the 2 of 5 artefacts that already live in a system (Ticketing / ITSM); keep the periodic reviews but log each one as a dated record with a named reviewer.
Common gaps auditors find
- No RCA performed
- Procedures not updated
- MTTR not measured
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 sheet10.7.2 Critical security control failure detection (all entities) · 11.1.1 Testing policy documented