Incident Readiness
Incident Readiness & Business Continuity
Don't wait for an incident to find out who acts.
We prepare the plans, roles, and recovery steps, then test them with your team before a real situation does.
An untested plan is still an assumption
A plan may exist, yet during an incident it is unclear who decides, who is informed, and what is restored first.
Without readiness
- No one knows who decides
- Communication is late
- Recovery has no order
With readiness
- Clear roles and escalation
- Prepared communications
- Set recovery priorities
Illustrative examples
When do you need this service?
After an incident or a significant system change
When continuity and recovery priorities need setting
This service focuses on readiness in advance; it does not mean emergency response to an ongoing incident.
What we offer, by scope
Incident response readiness
assessing capabilities and plans, scenario playbooks, escalation and communication, and tabletop exercises.
Business continuity readiness
identifying critical operations, business impact analysis (BIA), and continuity priorities.
Disaster recovery readiness
reviewing recovery objectives (RTO and RPO) and recovery plans when included.
ISO 22301 guides the continuity scope where it applies.
Not included by default
- A continuous monitoring centre
- Digital forensic investigation
- Live restore testing without a separate agreement
Illustrative examples; actual roles are set in your plan
Ransomware
Roles: incident lead, technical team, management, communications lead
- Isolate affected systems
- Preserve evidence
- Activate the communication plan
- Verify backups are clean before restoring
Data leak
Roles: incident lead, legal lead, technical team, communications lead
- Identify the affected data
- Stop the source of the leak
- Assess legal notification obligations
- Inform stakeholders according to the plan
Major outage
Roles: incident lead, operations team, technical team, management
- Activate the continuity plan
- Switch to the approved alternative
- Restore systems by priority
- Review the cause after recovery
How we work
Assess
The current state.
Write
The plans and playbooks.
Exercise
A tabletop exercise with the people involved.
Improve
Fix what the exercise revealed.
Deliverables
A plan where everyone knows their role, tried before it is needed.
- Response plans and playbooks ready for approval by the responsible authority
- An escalation and communication matrix
- The tabletop exercise report, with improvement recommendations and proposed follow-up owners
- Continuity or recovery outputs when included in the agreement
Every deliverable is reviewed by someone who did not prepare it before it is delivered.
Illustrative sample — not real data
Sample runbook
The first hour of a ransomware incident
- 0–15 min — isolate affected devices and inform the incident lead.
- 15–30 min — estimate the scope and preserve evidence.
- 30–60 min — management decision and the first communication.
Prerequisites
- A mutual NDA
- The list of critical systems
- Existing plans if any
- Management participation in the exercise
FAQ
Does the service include response during an incident?
It does not assume emergency response is available; support for an ongoing incident needs a separate, confirmed arrangement.
What is a tabletop exercise?
A step-by-step discussion of an incident scenario with the team, with no activity on the systems.
Is one exercise enough?
We recommend periodic review and exercises, and after every significant change.
Does it include backup testing?
We review recovery requirements within scope; a live restore test needs an explicit agreement.
Related services
Prepare the response before you need it
A 30-minute scoping call, followed by a written proposal setting out the scope and deliverables.
Request a scoping call