Practical software guides
A cyber policy sets expectations. Recovery requires a tested way to restore a particular service and decisions about who can pause work, notify people and approve re-entry.
| Question | Evidence |
|---|---|
| Critical service | Task and approved recovery objectives |
| Authority | Incident lead, backup and decision scope |
| Independent access | Protected emergency contacts and administrator recovery |
| Restore | Isolated clean environment and verified backup |
| Customer work | Minimum authorised fallback; no insecure payment capture |
| Re-entry | Reconciliation, access checks and approved release |
A board tabletop
Use a fictional unavailable booking system and synthetic records. Ask the incident lead to reach the backup contact without the normal inbox, locate the restore procedure and decide what can continue. Board participants review authority and communication, not technical instructions improvised during the exercise.
Restore a test backup, reconcile a temporary booking and try a revoked account. Record actual duration, missing steps and unresolved conflicts. No successful drill or recovery-time result is claimed here. A copy on the same failed account is not an independent backup.
Use CISA’s ransomware guidance for incident-planning context and qualified responders for actual incidents. This is not a claim of legal notification compliance. The ordinary outage playbook covers customer-facing continuity; the security incident needs its own containment and approval decisions.