Cyber resilience: planning to keep running when attacks succeed

What cyber resilience means

Traditional security asks "how do we keep attackers out?". Cyber resilience adds a second question: "when something gets through, how do we keep the important things running and recover fast?". It brings together security, business continuity and disaster recovery, and it is increasingly expected by regulators, insurers and customers.

The four stages in Figure 1 are a common way of describing it. You anticipate by planning and rehearsing, withstand by keeping core services going in a reduced form, recover by restoring normal service, and adapt by fixing the causes so the next attack does less harm.

Security and resilience compared

Both are needed. Strong prevention means fewer incidents to recover from; strong resilience means the incidents that do happen are survivable. An organisation with excellent firewalls but no tested backups is secure until the day it is not, and then it may be out of action for weeks.

Resilience is also a business conversation rather than only a technical one. Leaders decide which services matter most and how much downtime is acceptable; IT then designs backups, failover and plans to meet those targets. Getting that agreement in writing before an incident avoids arguments about priorities in the middle of one.

The building blocks

• Know your critical services. List what the organisation must keep running, such as payroll, patient records or online orders, and which systems and suppliers each depends on.
• Set recovery objectives. The recovery time objective (RTO) is how long a service can be down. The recovery point objective (RPO) is how much data you can afford to lose, measured in time.
• Protect backups. Keep copies that ransomware cannot reach or change, such as offline or immutable backups, and protect backup consoles with MFA.
• Plan for manual working. Decide how staff carry on with paper forms or phones if systems are down.
• Exercise. Test restores and run tabletop exercises so people know their roles.
• Learn. After every incident or exercise, fix the gaps and update the plans.

Tip: a backup you have never restored is only a hope. Schedule a real restore test at least once a quarter and time it against your RTO.

Suppliers and resilience

Many critical services now depend on cloud platforms and managed service providers. Your resilience is only as good as theirs, so ask suppliers about their own recovery times, backup arrangements and incident notification. Keep contact details for them outside your own systems, because email may be down when you need them most. Where a single supplier failure would stop the business, consider a fallback, such as a second internet connection or an export of key data you can work from.

Real-world example: a private hospital

A fictional private hospital maps its critical services and finds that the pharmacy system has an RTO of four hours, but its backups had never been restored and would take two days. The IT team moves the pharmacy database to more frequent, immutable backups and practises a restore, cutting recovery to three hours. Nurses also get printed medicine charts for use during outages. Months later, ransomware hits the admin network. The pharmacy system is isolated and restored the same afternoon, while wards use paper charts in the meantime. Patients are not turned away.