A widely shared plan with the appropriate stakeholders describing what they should do and expect to see in the event of a security incident — for instance a cyber attack or stolen laptop.
What is it?
Incidents are common things that cause upset and degrees of chaos in the business, a system outage, a data breach, or some other event. Given a scenario, what should people do, who calls who, what data should they collect, what should be left well alone?
An incident response plan is a set of directives, job role requirements, playbooks, and checklists employed whenever an event occurs.
Historically it’s been positive to see a coherent response plan well thought out and communicated to participants. These days we can expect to see parts of the response automated in terms of root cause analysis support data, temporary automated shutdowns, re-routing of data automating as much as possible as per a pre-agreed execution plan.
What’s in for you?
In the event of a security incident, it pays to have a well defined plan. This helps you reach a satisfactory conclusion quickly. Without an incident response plan, you run the risk of a suboptimal outcome: perhaps an important stakeholder won’t get timely notification or maybe important evidence will be compromised, hampering investigations.
What are the trade offs?
Most businesses should have some semblance of an incident response plan. But have those plans been tested? Testing for these plans often means rehearsals, with staff responding to an intentionally created incident. If you wait until you have an incident before testing your plans, you could be in for a nasty surprise.
How is it being used?
Some regulators now make incident response plans part of their compliance requirements: organizations are expected to know — in detail — how to deal with security incidents.