Cyber incident response planning: preparing for the first 72 hours

The difficult decisions concern what the business can safely do while recovery is still under way.

A business can restore its systems and still be unable to fulfil orders, release products or authorise payments. Applications may be running while the information and controls needed to use them remain incomplete. For leadership, that creates a difficult interval between technical progress and a dependable return to work.

A cyber incident response plan needs to account for that interval. The first 72 hours provide a useful planning window, although some decisions will be urgent within minutes and disruption may continue far longer. The commercial question is how much activity can be sustained without creating losses, liabilities or errors that compound the original incident.

Recovery priorities carry a commercial cost

The sequence in which systems return determines which commitments the business can meet. Restoring finance may enable urgent supplier payments while dispatch remains suspended. Recovering production records may allow goods to be released even while less consequential applications remain unavailable.

Those choices require more precision than a list of “critical systems”. An order platform might support several activities with different tolerances for interruption. Accepting new orders, checking stock and confirming delivery commitments do not necessarily deserve the same priority.

Consider a manufacturer whose machinery remains operational but whose quality system is inaccessible. Staff can make the product, yet cannot verify the current specification or demonstrate that the required checks have been completed. Continuing production could turn an IT interruption into defective stock, disputed deliveries or a traceability problem.

The financial assessment therefore extends beyond the hourly cost of downtime. It includes the cost of work that may have to be repeated, transactions that cannot be verified and promises made on incomplete information. These consequences give the recovery sequence its business rationale.

Temporary working has a capacity limit

Manual processes can preserve selected activities, but their limits become more significant as an interruption continues. A payment arrangement that handles a few urgent transactions may be unsuitable for normal volumes. Paper production records may sustain one shift while creating a substantial reconciliation task for the next.

This is where a three-day scenario becomes useful. An arrangement that works on the first morning may depend on a particular individual, a small volume of exceptions or information that is becoming outdated. Its viability changes as those conditions change.

Temporary working also creates a second workload. Orders, payments and records generated outside the usual applications eventually have to be reconciled with them. If that work is overlooked, the return of the system can expose duplicate transactions, missing records and uncertainty about what has already been completed.

The relevant decision is how much activity to permit within those limits. In regulated settings, there may be a point at which pausing a service is preferable to continuing without the information or controls required to deliver it safely. That judgement needs operational input as well as technical advice.

Reopening requires a basis for accepting risk

Containment and continuity can pull in opposite directions. Restricting access may limit an attack while preventing legitimate work; reconnecting a service may relieve commercial pressure while introducing uncertainty about whether the threat has been removed.

Technical responders need agreed authority to act urgently, while leadership needs a clear view of the decisions that remain with the business. An IT provider’s responsibility for restoration does not automatically extend to accepting the commercial consequences of reopening.

The evidence supporting that decision matters. A backup protected against alteration or deletion may still contain compromised data. A restored application may depend on an unavailable identity service or supplier connection. Recovery therefore involves establishing which copies and systems can be trusted, then checking whether they support the intended activity.

A useful test follows a transaction through to completion. Can an authorised employee confirm an order, approve its release and retain a reliable record? Where that sequence breaks, the business can identify what remains restricted and what additional checks are needed.

The same evidence should inform customer commitments. A technical restoration estimate may leave out validation, reconciliation and accumulated work. Treating it as a delivery promise risks creating a further gap between what customers expect and what the business can provide.

Reporting obligations proceed alongside this work. The response plan needs to accommodate applicable data protection, sector, contractual and insurance requirements while the investigation is still developing.

The separate 72-hour reporting requirement

Under UK GDPR, controllers must notify the ICO of a reportable personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it. This is separate from an operational planning window and is not a deadline for restoring systems.

Information can be provided in phases where necessary. Personal data breaches must be recorded even when notification is not required; affected individuals must also be informed without undue delay where a breach is likely to create a high risk to their rights and freedoms. The ICO’s guidance explains the reporting thresholds.

Test the assumptions behind the recovery target

A recovery exercise can expose a gap that a successful restoration test leaves untouched. The order system may return within its agreed target while dispatch remains dependent on an unavailable third party. Finance may regain access while the backlog exceeds the team’s capacity to process it.

These findings have implications for investment. Faster restoration may be valuable, but a missing supplier alternative, an impractical workaround or a bottleneck in approvals may determine the actual interruption. Testing across operations, finance and IT helps establish which constraint deserves attention.

The NCSC’s Exercise in a Box offers free material for practising incident response. Its scenarios can support discussions alongside technical recovery tests, with particular attention to what the organisation could deliver under restricted conditions.

For leadership, the value is a more credible account of the disruption the business could absorb. A recovery target becomes commercially meaningful when it includes the checks, capacity and supporting services needed to meet commitments again. Until then, it remains an incomplete measure of the exposure.

Kanj Technologies brings together cyber security, business continuity and the infrastructure work that supports recovery. Speak to Kanj about reviewing whether your technical recovery arrangements reflect the way your business needs to operate.

Related reading: Business continuity and operational dependency and IT and OT continuity planning for UK manufacturing.