03 / Incident response planning

Can your response plan work without your normal systems?

A usable incident response plan must remain accessible when normal communications, identity services or shared files are unavailable. Scope the engagement around decisions and dependencies, then exercise them with the people who would actually take responsibility.

This is planning guidance, not an emergency response service.

01 / Starting point

What is included in a response planning engagement?

A planning engagement usually defines escalation, roles, communications and response procedures; it does not automatically include live incident support or technical recovery. Separate those services in the scope. An incident retainer, forensic investigation, penetration test and disaster recovery implementation require different access, expertise and commercial arrangements.

Start with the business services whose disruption would matter most. Identify identity providers, cloud administration, telecommunications, payroll and other dependencies relevant to those services. Consider events such as compromised accounts, ransomware and supplier outages without assuming every event needs the same response. Define how an operational fault becomes a suspected security incident and who can declare a major incident when the cause remains uncertain.

02 / Decisions

Who should be allowed to disconnect a critical service?

A named decision-maker with a documented deputy should hold that authority, supported by clear escalation criteria and an understanding of the business consequences. Technical responders need to know when they can act immediately and when they must consult operational leadership. Delayed authority can be as disruptive as a missing technical procedure.

Include IT, business operations, communications, HR, legal advisers and privacy responsibilities where relevant. Specify an out-of-band communication route that does not depend on potentially compromised accounts. Protect contact lists, but make an authorised offline copy accessible. Define how supplier support and insurance contacts are reached, and check contractual conditions before assuming a preferred responder can be appointed. A contact list needs an owner and a practical maintenance process.

03 / Records and duties

When does a cyber incident require notification to the ICO?

A personal data breach requires notification to the ICO unless it is unlikely to result in a risk to people's rights and freedoms. Under the UK GDPR, a notifiable breach must be reported without undue delay and, where feasible, within 72 hours of becoming aware of it. Not every security incident is a personal data breach.

Scope a decision process that records awareness, known facts, uncertainty and notification reasoning. High risk to individuals can also trigger a duty to inform them without undue delay, subject to the legal conditions. Do not wait for a complete forensic narrative before seeking qualified privacy advice. Preserve relevant logs and decision records with controlled access; collection and handling should be directed by competent responders, rather than improvised changes that might destroy evidence.

04 / Rehearsal

Is a tabletop exercise enough to demonstrate readiness?

A tabletop exercise demonstrates how people reason through a scenario; it does not prove that backups restore or technical controls operate as intended. Use it to test escalation, authority, communications and competing priorities. Technical recovery testing needs its own safeguards, permissions and acceptance criteria.

Agree exercise objectives and boundaries in advance. A facilitator can introduce loss of email, an unavailable decision-maker or conflicting supplier information to test specific assumptions. Record decisions and unresolved dependencies without turning the session into a performance ranking of participants. For a mid-sized organisation, include deputies: the plan should not require every key person to be present. Findings should identify an owner, an action and a way to demonstrate the problem has been addressed.

05 / Return to service

Who decides that recovery is complete?

The responsible business owner should accept the restored service, informed by technical and security evidence. Restoring servers is not enough if transactions cannot be reconciled, staff cannot authenticate or the original compromise remains unresolved. Separate technical restoration from business acceptance and ongoing monitoring.

The handover pack should include an accessible plan, role-specific procedures, communication templates, exercise findings and a maintained improvement register. Recovery objectives must reflect business requirements and tested capabilities, not a consultant's preferred default. Link lessons to NIST CSF priorities and staff reporting practice. Agree when plans will be reviewed after significant service changes or incidents, and make unresolved recovery dependencies visible to leadership.

Further guidance: NCSC incident management, NCSC Exercise in a Box and ICO personal data breach reporting. Obtain qualified advice on the duties applying to your incident.