Incident response and recovery planning: decided in advance, not under pressure

A cyber incident response plan is the written answer to questions nobody answers well under pressure: who decides, who gets called, what gets isolated first, which systems come back in what order, and who gets told by when. It is the coordination layer of our managed cybersecurity and compliance stack: the part that turns a dozen controls into one response.

• The people. Named personnel, the chain of command, and who decides when the first name on the list is unreachable.
• The roles. What your staff, our team, your insurer, your counsel and your vendors each own, agreed while everyone is calm.
• The systems. Which applications and data the business cannot run without, ranked, so recovery order follows the ranking.
• The thresholds and the tools. How an event gets classified, what each severity triggers, and what is available to contain, investigate and restore.

The first hour, on paper

Most of the cost of an incident accumulates in the gap between noticing and acting. The plan's job is to make that gap short and boring.

Hour one has a fixed shape: confirm, contain, preserve, notify. Confirmation comes first because a compromised mailbox and a failed storage controller need opposite responses. Containment is where pre-agreed authority earns its keep: if disabling an account needs a call to somebody on a plane, containment does not happen. Preserving evidence is the step teams skip and regret, because reimaging a machine erases the record of how it was reached, and that record is what insurers and forensic examiners ask for. Notification comes last in the sequence and it runs on a clock: breach notification deadlines in policies and regulations start at the moment of discovery, so the plan carries the contact list and the deadlines together.

Recovery: how long, from what, in what order

Response stops the bleeding. Recovery is the other half, and it starts with two numbers. How much data you can afford to lose sets how often backups run. How long a system can be down before the loss starts to hurt sets what kind of recovery you pay for. We call them the recovery point objective and the recovery time objective, or RPO and RTO. Answer both per system and the recovery order writes itself.

A restore that has never been performed is a hypothesis. Planning means proving the restore works, knowing how long the full sequence takes against real data volumes, and deciding what the business runs on while it runs. That last decision is business continuity. Backup is its own capability with its own page, managed backup and recovery; this page is about the plan that decides when to invoke it and in what order.

A plan you have not tested is a document

Plans fail in predictable places. The phone list is a year old. The person who knew the restore process left in March. Or the plan lives on the file server that is currently encrypted. A one-hour tabletop walkthrough finds all three: pick a realistic scenario, put the people who would be involved in a room, and step through it out loud. The test is whether people can find the document, whether the names in it still work, and whether two readers of the same step take the same action.

A plan is accurate the day it is written and drifts from there, so it gets reviewed when the environment changes: a new critical application, a new office, a vendor swap, new people on call.

Nobody should have to start this from a blank page. Documenting the systems, the dependencies and the accounts is work we already do for the clients we manage, so a plan written on top of it starts from what is true about your environment rather than from a template.

On the Compliance plan we run that tabletop with you rather than leaving it on your list.

How we deliver it today

When a plan is invoked, response runs through Blackpoint Cyber SNAP, a staffed security operations center, on Advanced plans and up, and recovery runs on Axcient for backup and disaster recovery, on those same plans.

Incident Response Planning and Disaster Recovery Planning are their own rows on the uConnect plan chart, and both sit on the Compliance plan, where the runbook is built with your team, walked through in a tabletop exercise, and kept current. It lives with your documentation, so the people who need it during an incident are the ones who wrote it.

Not sure what would happen at your company on a bad morning? Start small: list the systems the business cannot run without for a day, in order. That list is the spine of both the response order and the recovery order, and it is where the conversation with us starts.

Planning sits next to three layers that do the detecting and the remembering. Managed detection and response is the layer that executes containment, SIEM and security monitoring is where log-based timelines live, and compliance logging is the retained record that answers an auditor's or an insurer's questions months later.

What is backed up, how often, and what a restore looks like from your side is documented for clients in our managed backup stack guide.