From prevention to resilience
Cybersecurity has long focused on preventing incidents. But the reality is that incidents will occur — the question is how well you can handle them.
Operational resilience is about building your organisation’s ability to absorb disruptions, adapt and continue delivering. It’s a paradigm shift from “it won’t happen to us” to “when it happens, we’re ready”.
The fundamental question: If your most important system goes down tomorrow — how quickly can you recover? And do you know for certain, or do you just think you do?
The four pillars of resilience
1. Business Continuity (BCP) Plans to maintain critical business processes during disruptions. What is critical? How do we continue if X doesn’t work?
2. Disaster Recovery (DR) Technical plans to restore IT systems and data. Backup, redundancy, recovery procedures.
3. Incident Management Processes to detect, handle and learn from security incidents. Roles, escalation, communication.
4. Crisis Communication How do we communicate internally and externally during a crisis? Who says what to whom?
NIS2 requirements for resilience
NIS2 Article 21.2c requires business continuity and crisis management, including backup and disaster recovery.
Article 21.2b requires handling of security incidents, including 24-hour reporting.
Implicit requirement that plans must work in practice. Processes that haven't been tested are unreliable.
Measures must be proportionate to the risk. Critical systems require more robust resilience.
Build resilience step-by-step
- Identify critical processes and systems What must function for the business to survive? Map dependencies. Prioritise based on business impact if unavailable.
- Define RTO and RPO How quickly must each critical process/system be restored (RTO)? How much data loss is acceptable (RPO)? These drive solution design.
- Implement technical capability Backup, replication, redundancy, failover. Ensure technology can deliver against RTO/RPO. Document recovery procedures.
- Create plans and procedures Business continuity plan, DR plan, incident plan, crisis communication plan. Clear roles, responsibilities and escalation paths.
- Test and exercise Plans that aren't tested rarely work. Conduct exercises: tabletop, technical tests, full-scale simulations. Learn from the results.
- Continuous improvement Update plans based on lessons learned, business changes and new threats. Resilience is a process, not a project.
Exercise types
| Type | Description | Frequency |
|---|---|---|
| Tabletop | Discussion exercise without technical activation. “What do we do if X happens?” | Quarterly |
| Walkthrough | Step-by-step review of procedures. Identify gaps. | Half-yearly |
| Functional | Test specific capability, e.g. backup recovery | Monthly |
| Full-scale | Simulate real incident. Activate all processes. | Annually |
Common shortcomings
The document exists, but nobody knows if it works. 73% who test find gaps.
The plan references systems that no longer exist, or lacks new critical systems.
DR plan exists, but no business continuity plan. IT can restore, but the business doesn't know what to do.
Technology works, but nobody knows how to communicate with customers, media, authorities.
Critical dependencies on key personnel, individual systems or suppliers.
Backups are taken, but nobody has tested restoration. "Schrödinger's backup."
Resilience checklist
Identification:
- Critical business processes identified
- Critical systems mapped
- Dependencies documented
- RTO and RPO defined
Technical capability:
- Backup strategy implemented
- Recovery tested and verified
- Redundancy for critical systems
- Failover mechanisms in place
Plans and processes:
- Business continuity plan documented
- DR plan documented
- Incident management plan documented
- Crisis communication plan documented
Testing and exercises:
- Tabletop exercise conducted in last quarter
- Technical DR test conducted in last six months
- Full-scale exercise conducted in last year
- Lessons learned documented and plans updated
How Securapilot can help
Securapilot supports your organisation’s resilience efforts:
- Business continuity — Document and manage BCP
- Incident management — Structured handling and reporting
- Risk management — Identify threats to resilience
- Documentation — Plans and procedures in one place
- Follow-up — Track exercises and improvement measures
Book a demo and see how we can support your resilience capability.
Frequently asked questions
What is the difference between resilience and backup?
Backup is a technical measure to restore data. Resilience is the organisation's ability to continue functioning despite disruptions. Backup is part of resilience, but far from everything.
How does resilience relate to NIS2?
NIS2 Article 21 explicitly requires business continuity and crisis management. Organisations must be able to maintain or restore critical services during disruptions.
How often should we test our resilience?
At least annually for overall business continuity. Backup recovery and technical DR more frequently. Incident exercises 1-2 times per year. Tabletop exercises can be done quarterly.
What are RTO and RPO?
RTO (Recovery Time Objective) is the maximum acceptable time to restore a service. RPO (Recovery Point Objective) is the maximum acceptable data loss, measured in time. Example: RTO 4 hours, RPO 1 hour.
