Skip to content

Managed vCISO

Incident response preparedness

What this is

Incident response preparedness is the work done before an incident: defining who decides, writing playbooks for the scenarios most likely to occur, establishing regulatory notification timelines, and rehearsing through tabletop exercises. Preparation determines the outcome of an incident far more than the tooling available during one.

The problem

The first thirty minutes decide the next thirty days, and nobody has rehearsed them.

Most organisations have an incident response policy. Very few have rehearsed one. The policy says the incident response team will convene and assess severity. It does not say who has authority to take production offline at 2am, who tells the customers, who decides whether this is notifiable, or what happens if the person named in the policy is the one whose account was compromised.

Those questions get answered in the first half hour of a real incident, under pressure, by whoever is awake. The answers determine whether you contain it, whether you preserve evidence, and whether you meet the 72-hour notification window that starts running from awareness rather than from understanding.

A tabletop exercise finds the gaps cheaply. It reliably surfaces the same things: nobody knows who can authorise downtime, the contact list is out of date, the backup restore has never been tested end to end, and the legal and communications people have never been in the room with the engineers.

Who this is for

  • Organisations with an incident response policy that has never been tested.
  • Companies whose customer contracts commit to notification timelines nobody has mapped.
  • Teams in scope of GDPR breach notification, DORA incident reporting, or NIS-style duties.
  • Firms whose cyber insurance requires a tested response capability.
  • Anyone who has had a near miss and discovered the process did not work.

Delivery

How the engagement actually runs

Sprints inside your engineering cycle, with findings arriving continuously rather than a report arriving at the end. Durations are elapsed time for a typical scope, and get re-scoped against your estate before anything is committed.

  1. 011 week

    Assess readiness

    What exists, what obligations you carry, and who currently believes they are responsible for what - which rarely agrees between people.

  2. 022 weeks

    Write the playbooks

    Scenario-specific and decision-led, built around your actual architecture and your actual people.

  3. 031 day, plus prep

    Rehearse

    A facilitated tabletop with the real decision-makers, run with injects and a hard clock. Pressure is the point.

  4. 042-4 weeks

    Fix what broke

    Remediate what the exercise exposed, then rehearse again at a lighter weight in six months.

Deliverables

What you actually receive

Artefacts your team owns and can maintain after the engagement, not a report that ages the moment it lands.

Deliverables for Incident response preparedness, with what each one contains and when it lands
DeliverableWhat it containsWhen
Scenario-specific playbooksRansomware, business email compromise, cloud misconfiguration exposure, supplier compromise and insider data loss. Each with decisions, owners and thresholds rather than generic phases.Week 3
Decision and authority matrixWho can declare an incident, who authorises downtime, who approves customer communication, and who deputises when they are unavailable.Week 2
Regulatory notification mapEvery notification obligation you carry, its clock, its trigger and its recipient - GDPR's 72 hours, contractual commitments, sector duties - in one place.Week 3
Communications templatesHolding statements and customer notifications drafted in advance, because they are written badly under pressure and read forever afterwards.Week 4
Tabletop exerciseA facilitated exercise with the real decision-makers - engineering, legal, comms, executive - run against a realistic scenario with injects.Week 5
Findings and remediation planWhat the exercise broke, prioritised, with owners. This is the actual output; the playbook is the input.Week 6

Frameworks this touches

FAQ

Questions people actually ask

What is a tabletop exercise?

A facilitated discussion-based exercise where the people who would actually run an incident are presented with a realistic scenario and work through their response in real time, with new information injected as it progresses. Nothing is done to live systems. The value is in surfacing the decisions nobody had made, the contacts nobody had checked and the assumptions that do not hold - which it does reliably and cheaply.

How long do we have to report a personal data breach?

Under UK GDPR, a controller must notify the ICO within 72 hours of becoming aware of a personal data breach unless it is unlikely to result in a risk to individuals. Where the risk to individuals is high, they must also be informed without undue delay. The clock starts at awareness, not at full understanding, so a partial notification followed by an update is both expected and preferable to a late complete one.

How often should incident response be rehearsed?

A full tabletop annually, and a lighter walkthrough after any material change - a new critical system, a significant architecture change, or turnover among the named decision-makers. Rehearsal decays fastest through people leaving: a playbook naming three individuals who have all changed roles is not a tested capability regardless of when it was last exercised.

Do we need a retainer with an incident response firm?

For most organisations without an internal forensics capability, yes. A pre-agreed retainer means the contract, the scope and the rates are settled before you need them, and an established relationship means responders arrive with context. Negotiating a statement of work during an active incident wastes the hours that matter most, and it is done badly under pressure.

More in Managed vCISO

Start

Three ways in, depending on how close the deadline is.

Or just email a human: hello@cloudgap.ai

We reply within24 hours