How to Write an Incident Response Plan Your Team Will Actually Use

Most incident plans fail for a simple reason: they are long documents written for auditors, and nobody can find or follow them at two in the morning. A useful plan answers a few urgent questions quickly. Who is in charge? Who do we call? What can we shut down? What must we tell people, and by when?

What the plan should include

• Severity levels

  Three or four levels with plain examples, so people know when to escalate.

• Roles

  Incident lead, technical lead, communications, legal and an executive sponsor, each with a named backup.

• Contact sheet

  Staff, legal counsel, cyber insurer, forensic provider, key vendors and law enforcement contacts.

• Decision authority

  Who may disconnect systems, disable accounts, or engage outside help without waiting for approval.

• Communication rules

  Who speaks to staff, customers, regulators and the press, and which alternate channel to use if email or chat is compromised.

• Notification duties

  Your legal, contract and insurance deadlines, reviewed by counsel before an incident happens.

Follow the six phases

• Prepare

  Set up logging, backups, access and contacts before anything goes wrong.

• Identify

  Confirm what happened, what is affected and how severe it is.

• Contain

  Stop the spread, while preserving evidence. Avoid wiping systems too soon.

• Eradicate

  Remove the attacker's access and fix how they got in.

• Recover

  Restore from clean backups and watch closely for signs of return.

• Learn

  Hold a blameless review within a couple of weeks, and update the plan.

Add short playbooks

Keep step-by-step guidance for likely scenarios in separate one-page playbooks: ransomware, business email compromise, a lost device, stolen credentials, a vendor breach and accidental data exposure. Store an offline copy of everything, along with contact details, in case your systems are unavailable.

Assign clear roles

During an incident, confusion over who decides often causes more delay than the technical work does. Small companies may have one person filling several roles, but the responsibilities still need names attached.

• Incident lead

  Runs the response, keeps the timeline and makes sure decisions happen. This person coordinates rather than doing all the technical work.

• Technical lead

  Directs investigation and containment, and advises on the effect of each action.

• Communications lead

  Prepares updates for staff, customers and other outside parties, working from facts that have been confirmed.

• Legal counsel

  Advises on privilege, contracts and notification duties. Bring counsel in early, since the wording used in the first hours can matter later.

• Executive sponsor

  Makes business decisions, such as shutting down a service or approving outside spending.

• Scribe

  Records what was learned, what was decided and when. That record supports insurers, auditors, regulators and your own review.

Plan your notification deadlines

Deadlines can start running sooner than most teams expect, and they depend on where you operate, what data is involved and what your contracts say. Your counsel should map these in advance. Examples include GDPR, which generally requires notifying the supervisory authority within 72 hours of becoming aware of a reportable personal data breach, and HIPAA, which requires business associates to notify covered entities without unreasonable delay and no later than 60 days after discovery. US public companies have a Form 8-K disclosure duty within four business days of determining that a cybersecurity incident is material.

Also check customer contracts, which may have much shorter timelines, and your cyber insurance policy, which may set conditions on when you give notice and which vendors you can use. Put the results in one simple table in your plan, with the owner for each notification.

Example: the first hour of a ransomware incident

A short playbook gives people something concrete to do while under pressure. Here is a simplified example. Yours should reflect your own systems and be reviewed by your advisers.

• Confirm and declare

  Validate the alert, open an incident channel on a system you trust, and assign an incident lead.

• Contain

  Isolate affected devices from the network, but do not power them off unless instructed, as memory can hold useful evidence.

• Protect identity and backups

  Check for compromised administrator accounts, reset privileged credentials as advised, and disconnect or lock down backups to protect them.

• Call for help

  Contact legal counsel, your insurer and your incident response provider using the offline contact list.

• Preserve evidence

  Keep logs and ransom notes, and note what you changed and when. Do not contact the attacker without legal guidance.

• Tell people what to do

  Give staff a simple instruction through a trusted channel, including what not to use and who to contact.

Example: business email compromise

Not every incident involves malware. If an attacker takes over a mailbox and sends a fake payment request, act quickly. Contact your bank at once to try to stop or recall any transfer. In the US, also consider reporting the event to the FBI's Internet Crime Complaint Center. Reset the account password, revoke active sessions and check mailbox rules, as attackers often add rules that hide replies. Then review which other messages or documents the attacker could have reached, and warn any partners who may have received fraudulent emails.

How to run a useful tabletop

Pick a scenario that could really happen to your company, and bring together technical staff, leadership, legal, communications and anyone who owns an affected service. Reveal the scenario in stages, with new facts every few minutes, and ask people what they would do and who they would call. The aim is to find gaps rather than to test individuals, so keep it blameless.

Try adding complications such as the incident lead being on vacation, the chat system being unavailable, or a journalist calling before you have the facts. Close by listing actions, owners and dates. Published frameworks, including NIST SP 800-61, can help you shape your process, but your plan should fit your company's size and systems instead of copying a template word for word.

Test it

A tabletop exercise is a guided discussion of a realistic scenario with technical staff and leaders in the room. It takes a few hours, and it usually reveals missing contacts, unclear authority and backups no one has recently tested. Fix what you find, then run another exercise the following year.

NPLUS Global writes plans and playbooks with your team, runs tabletop exercises, and helps coordinate with your insurer and legal counsel, so you are ready before a real incident occurs.