Trigger and severity
Confirm what actually counts as an incident, who can declare one, and whether severity levels change who gets involved.
Independent IT security review
Check whether your incident plan would actually work-before you need it.
This is not incident response. It is an independent check of the runbooks, roles, contact trees, and evidence sources an incident would actually depend on, done while nothing is on fire.
- Before any access
- Written question and scope
- Agreed evidence method
- No automatic tenant changes
Read the runbook the way an incident would use it.
A document titled “Incident Response Plan” is not the same as a plan someone could follow under pressure. The review reads it for gaps, not just existence.
Step-by-step usability
Check whether the runbook can be followed by whoever is on shift at 2 a.m., not only by the person who wrote it.
Currency
Identify systems, vendors, or contacts the runbook still names that no longer match how the organization actually operates.
Confirm the roles exist outside the document.
A response plan without accountable people and a communication path is a stack of good intentions.
Decision authority
Identify who can approve isolating a system, notifying customers, or engaging outside help, and whether that person is reachable off-hours.
Contact tree
Verify internal and vendor contacts-including cyber insurance and legal-are current and reachable through more than one channel.
Backup coverage
Confirm a named backup exists for every critical role, since an incident will not wait for the primary contact’s vacation to end.
Verify the evidence sources the plan assumes will be there.
A runbook that says “check the logs” is only useful if the logs exist, are retained long enough, and someone knows how to reach them under pressure.
Log retention and access
Confirm sign-in, mail flow, and admin activity logs are retained long enough to matter and that someone can actually pull them quickly.
Backup and recovery evidence
Connect this plan to the organization’s actual backup and recovery posture instead of assuming restoration will simply work.
External dependencies
Identify what evidence sits with a cloud provider, IT provider, or vendor, and whether access to it is agreed in advance rather than negotiated mid-incident.
Turn a tabletop exercise into evidence, not a checkbox.
The value of a readiness review is a realistic exercise against the actual plan, with the gaps written down and assigned.
Tabletop against a real scenario
Walk the plan through a specific, plausible scenario instead of a generic checklist, and note where it breaks down.
Owned gap list
Attach every gap found to a named owner and a decision-fix, accept, or investigate-rather than a long unowned list.
Review cadence
Set a realistic interval to repeat the exercise, since staff, vendors, and systems change faster than most plans get revisited.
Next step
Define the review before sharing evidence.
Start with the trigger, decision, and known boundaries. Do not send passwords, recovery codes, or tenant exports.