Beat the ICO 72 hour clock: Disaster Recovery Planning IT Leaders Can Use

A disaster recovery plan secures operational continuity and recoverable data when systems fail or are attacked, and the first practical step is to assemble incident leadership and identify which services the business cannot survive without. Reputable guidance from the NCSC, the ICO and experienced providers such as Abersecure all point the same way: prepare before the incident, not during it.

What a disaster recovery plan is, and how it fits with business continuity

A disaster recovery plan (DRP) sets out how we restore IT systems, applications and data after an outage, cyber attack or physical disruption. Its purpose is narrow but critical: get the technology that the business depends on back into a working state within a defined timeframe, with data intact and verified.

This differs from business continuity planning (BCP), which covers the whole organisation, including people, premises, suppliers and communications, and not just the technology stack. Incident response sits alongside both: it covers the immediate detection, containment and investigation of a security event, before recovery activities begin in earnest. In practice the three overlap constantly. A ransomware attack triggers incident response first, disaster recovery to rebuild systems, and business continuity to keep the organisation trading while that rebuild happens.

BS EN ISO 22301 gives organisations a recognised framework for structuring this work. It helps identify threats, define recovery priorities and build a management system that can be audited and improved over time, rather than a document that sits untouched until something goes wrong.

Regulatory obligations add another layer that a DRP must account for. Under UK GDPR, a notifiable personal data breach must be reported to the Information Commissioner’s Office without undue delay and no later than 72-hour after becoming aware of it, unless the breach is unlikely to put individuals’ rights and freedoms at risk. A DRP that does not account for this clock, including who makes the call and what evidence must be gathered, leaves the organisation exposed at the worst possible moment. Building these hooks into the plan from the outset, rather than treating them as a separate compliance exercise, is what turns a document into something the board can rely on.

Why disaster recovery planning matters for continuity, compliance and reputation

Downtime is rarely just an IT problem. Every hour that order systems, email or customer-facing platforms stay down translates into lost revenue, missed deadlines and staff unable to work. Data loss compounds this: rebuilding lost records, re-keying transactions or explaining gaps to customers and regulators takes far longer than the outage itself, and the damage to trust often outlasts the technical fix.

Compliance adds a second layer of urgency. If personal data is involved in an incident, the 72 hour reporting clock from the ICO’s breach guidance starts as soon as the organisation becomes aware, regardless of whether recovery is complete. Boards and IT leaders need evidence that a breach was contained promptly, that data handling followed a documented process, and that the organisation acted reasonably throughout. Without a DRP that specifies who gathers this evidence and when, that case becomes much harder to make under pressure.

Standards and national guidance exist precisely to close this gap between good intentions and demonstrable readiness. BS EN ISO 22301 gives a structure that auditors, insurers and boards recognise, which matters when a recovery has to be justified after the fact. NCSC guidance on what to do when cyber attacks disrupt your organisation frames recovery as a formal programme with named workstreams and a clear path to minimum viable operations, rather than an improvised scramble. That framing gives boards something concrete to assure themselves against: not “did IT fix it”, but “did we follow a tested, documented process that a regulator or insurer would recognise as reasonable”.

The reputational dimension is harder to quantify but no less real. Customers and partners judge an organisation on how it handles a crisis, not just whether one occurred. A business that can show a structured, rehearsed recovery process tends to retain more trust than one that visibly improvises, even when the underlying incident is similar in scale.

Step-by-step process to create a practical, auditable DRP

Building a DRP that will actually work under pressure means working through governance, priorities and documentation in a deliberate order, rather than starting with a backup tool and working backwards.

1. Appoint a senior responsible owner (SRO) and define incident command. Someone at board or senior leadership level needs clear authority to make recovery decisions, including the authority to spend money, pause normal operations or accept temporary risk. Without this, recovery stalls on approvals during the hours that matter most.
2. Identify critical services and set recovery targets. List every system and process the organisation depends on, then rank them by how quickly the business fails without them. For each, define a Recovery Time Objective (RTO), how long the organisation can tolerate the outage, and a Recovery Point Objective (RPO), how much data loss is acceptably measured in time since the last good backup.
3. Map dependencies between systems. Few applications stand alone. Identity services, network infrastructure and core databases often sit underneath several business functions, and recovery sequencing has to reflect that: a finance system cannot come back online before the identity platform that authenticates its users.
4. Build the documentation that recovery depends on. This includes asset inventories, network diagrams, and runbooks for each critical system that spell out exact restore steps, who performs them and in what order. Store this documentation somewhere it remains accessible even if production systems are offline, since the NCSC specifically advises keeping network and asset information separate from production systems for exactly this reason.
5. Define recovery options for each critical system. Decide in advance whether a given system will be restored from backup, failed over to a standby environment, rebuilt from scratch, or supported by a manual workaround while the technical fix is completed. Each option has different time and cost implications, and deciding in the moment wastes hours an organisation rarely has to spare.
6. Build regulatory and communication steps into every runbook. Each runbook should specify who checks whether personal data is affected, who owns the ICO notification decision and clock, and who drafts internal and external messaging. Treating this as part of the technical recovery process, not a separate afterthought, is what keeps the 72 hour window from being missed.
7. Test, review and revise. A DRP that has never been exercised is a theory, not a plan. Testing (covered in detail later in this guide) is what turns documentation into a capability the organisation can actually rely on.

Following this sequence produces a plan that is both usable in a real incident and defensible to a board, an auditor or a regulator afterwards. The governance step matters more than it might seem: plans that skip straight to technical detail tend to collapse the moment a decision needs sign-off from someone who was never named.

Technical controls that make recovery reliable

Governance and process only work if the underlying technical recovery is sound, and that starts with how backups are designed and protected.

A resilient backup strategy keeps copies in more than one place and in more than one form. Offline or offsite copies that are not permanently connected to the network protect against attacks that deliberately target backup systems, a common feature of modern ransomware. Versioning preserves earlier states of data so a restore is not limited to the most recently infected copy, and immutability, where backup data cannot be altered or deleted even by an administrator account, closes off one of the most common ways ransomware operators try to destroy recovery options. The NCSC’s guidance on ransomware-resistant backups sets out these principles directly: separate storage, immutability where possible, and regular restore testing so the backup is proven to work rather than assumed to.

Protecting the backup infrastructure itself matters just as much as the backups it holds:

• Restrict privileged access to back up systems to a small, named group rather than general IT administrator accounts.
• Require multi-factor authentication on every account that can configure, delete or restore backup data.
• Use separate, hardened administrative paths (sometimes called privileged access workstations) for backup and recovery tasks, kept apart from everyday user devices.
• Rebuild identity systems early in any sequence, since most other recovery steps depend on trusted authentication being available first.

Identity is worth singling out because it is so often the dependency that gets missed. If the platform that authenticates users and grants access is itself compromised or unavailable, nothing else can be safely restored on top of it. NCSC guidance on recovering from disruptive cyber attacks treats identity rebuilding as a step that should be planned and sequenced in advance, not worked out on the day.

Cloud and on-premises environments bring different assurance requirements before reconnecting anything to the network. Cloud platforms often offer faster failover and simpler scaling, but require clear understanding of what the provider backs up by default and what remains the customer’s responsibility. On-premises recovery gives more direct control but usually takes longer to rebuild from scratch. Whichever environment is in use, the same discipline applies: validate that a backup is clean and complete before restoring it, and avoid reconnecting a recovered system to the wider network until it has been checked for the same compromise that caused the original incident.

Pro Tip: Test a full restore from your backup system at least quarterly, not just the backup job itself: a successful backup that cannot be restored within your RTO is not a working safety net.

Governance and running a recovery programme to reach minimum viable operations

Once an incident moves from detection into recovery, the organisation needs a structure, not just a plan on paper. NCSC guidance on what to do when cyber attacks disrupt your organisation frames this as a formal recovery programme with named workstream leads, each responsible for a defined slice of the rebuild, reporting into a single coordination point.

A workable structure typically includes:

• A named lead for each major workstream, such as infrastructure rebuild, application recovery and data validation.
• A cross-cutting legal and communications function that tracks regulatory deadlines, including the ICO’s 72 hour clock, alongside internal and external messaging.
• A single decision authority who resolves conflicts between workstreams, for example when a security check and a business pressure to restore service pull in different directions.
• A liaison role for coordinating with insurers, external CIR providers and any regulators that need to be kept informed.

The organising concept here is minimum viable operations, or MVO: the smallest set of systems and processes the business needs to function, even in a reduced or manual form, while full recovery continues in the background. Early recovery may mean operating without some corporate systems altogether, and the NCSC is explicit that any workarounds adopted in this phase need a security review and a plan for reconciling data once full systems return.

Escalation thresholds should be agreed before an incident, not during one: at what point does a workstream lead escalate a blocked decision, and to whom. Clear thresholds stop recovery stalling while people wait for permission that was never clearly assigned.

External support decisions also belong in this governance layer. The NCSC advises arranging or retaining a Cyber Incident Response (CIR) provider in advance and exercising with them where possible, since mobilisation during a live incident takes far longer if the relationship and ways of working have never been tested together.

Testing and exercising your DRP

A DRP that has not been tested is an assumption, and assumptions tend to fail at the worst possible time. Different exercise types reveal different weaknesses, so a mature testing programme uses several.

1. Tabletop exercises walk the leadership team through a simulated scenario verbally, testing decision-making, communication and escalation without touching live systems. These are quick to run and good at surfacing governance gaps.
2. Technical restore tests actually recover a system or dataset from backup to confirm the process works and measure how long it takes against the stated RTO.
3. Full rebuild exercises simulate recovering a complete environment from nothing, which is the only way to find gaps that smaller tests miss, since realistic rebuilds expose problems that tabletop exercises alone cannot reveal.
4. Supplier-involved drills bring external partners, such as a CIR provider or cloud vendor, into the exercise to test real coordination rather than assumed cooperation.

Prioritise testing around the systems identified as most critical in the earlier dependency mapping, starting with identity, backups and any cloud services the business cannot operate without. Record the findings from every exercise formally, assign an owner to each gap identified, and set a deadline for closing it. Auditors and insurers increasingly expect to see this evidence trail, and it is far easier to produce it as a routine output of testing than to reconstruct it after the fact.

A sensible baseline is to run a tabletop exercise at least annually and a technical restore test more frequently, with additional testing triggered by major changes such as a new core system, a cloud migration or a significant change in staff responsible for recovery.

Authoritative recovery checklist for the first days after an incident

The first few days after a major incident set the tone for everything that follows, and the NCSC’s guidance on what to do when cyber attacks disrupt your organisation offers a practical structure for this period.

• Establish a single, central log of decisions and actions from the outset, so the organisation can reconstruct what happened and why.
• Maintain situational awareness across all workstreams, with regular short briefings rather than ad hoc updates.
• Communicate early and honestly with staff, customers and other stakeholders, even when full details are not yet known.
• Preserve evidence before making changes, since a hasty fix can destroy the information needed later for investigation or regulatory reporting.
• Stand up the recovery programme with named workstreams and prioritise restoration to minimum viable operations rather than full recovery in one step.
• Validate backups before restoring them, and plan how any temporary manual workarounds will be reconciled with systems once they return.

Our Security by Default approach embeds security considerations into support engagements from the outset rather than adding them afterwards. Our Backup & Disaster Recovery service is designed to support exactly this kind of readiness, from backup design through to restore testing, so that when recovery is needed, the groundwork has already been done.

Resources and a short checklist to start drafting your DRP this week

A usable first draft does not need to be perfect, it needs to exist and be testable. Start with these elements:

• A one-page list of critical services, each with an owner, an RTO and an RPO.
• A named senior responsible owner with clear authority to make recovery decisions.
• At least one documented runbook for your single most critical system, including restore steps and who performs them.
• A note on where backups are stored, how often they are tested, and whether any copy is offline or immutable.
• A one-paragraph communication plan covering staff, customers and the ICO’s 72 hour reporting clock where personal data is involved.

For authoritative reference material, the NCSC’s guidance on preparing for a highly disruptive cyber incident sets out four preparation areas worth structuring a plan around: business continuity, people, technical recovery and decision-making authority. BS EN ISO 22301 offers a fuller framework for organisations ready to formalise their approach, and the ICO’s breach guidance is the primary reference for reporting obligations.

A practical next step is a short internal readiness review: have your IT lead and a senior decision-maker spend an afternoon working through the checklist above and noting the gaps, since that exercise alone tends to surface the priorities for the weeks ahead.

How we support disaster recovery planning and execution

Drafting a DRP is one thing, keeping it current, tested and ready to execute under pressure is another, and that ongoing work is where many internal teams run out of time. Our Backup & Disaster Recovery service covers backup design, immutable storage and restore testing, so recovery targets are backed by infrastructure that has actually been proven to work rather than assumed to.

Where a DRP needs to connect into wider security monitoring and incident handling, our managed cyber security services provide the detection and response capability that sits alongside recovery, and our managed IT support keeps day-to-day operations stable so your team can focus on recovery planning rather than routine firefighting at the same time.

If you want a second pair of eyes on an existing plan, a readiness review, a restore test or help to deploy backup and disaster recovery infrastructure, The Backup & Disaster Recovery page is a recommended starting point for scoping such work.

FAQ

What is the difference between a disaster recovery plan and a business continuity plan?

A disaster recovery plan focuses specifically on restoring IT systems, applications and data after disruption, while a business continuity plan covers the whole organisation, including people, premises and suppliers. They work together: continuity planning keeps the business functioning while disaster recovery rebuilds the technology underneath it.

How quickly must a data breach be reported under UK GDPR?

A notifiable personal data breach must be reported to the ICO without undue delay and no later than 72 hours after the organisation becomes aware of it, unless the breach is unlikely to risk individuals’ rights and freedoms. Your disaster recovery runbooks should name who owns this decision and this clock in advance.

What makes a backup resistant to ransomware?

The NCSC recommends keeping backups separate from primary systems, making them immutable where possible so they cannot be altered or deleted, and testing restores regularly to confirm they actually work. A backup that has never been restored in a test is not a proven safety net.

How often should we test our disaster recovery plan?

A reasonable baseline is a tabletop exercise at least annually and more frequent technical restore tests, with additional exercises triggered by major system changes, cloud migrations or staff changes affecting recovery responsibilities. Full rebuild exercises, run less often, tend to expose gaps that smaller tests miss.

What is minimum viable operations (MVO) in a recovery context?

Minimum viable operations is the smallest set of systems and processes a business needs to keep functioning, even in a reduced or manual form, while full technical recovery continues. NCSC guidance treats prioritising restoration to MVO, rather than attempting full recovery in one step, as central to running an effective recovery programme.