The legal layer of the plan
A technical playbook explains how to detect, contain, and recover. A data breach response plan also needs a path for deciding whether personal information was affected, who makes the legal determination that notice is required, and how that determination is recorded. A matrix of the notice regimes that could realistically apply, organized by data type and by where affected people live, saves a great deal of research during an incident. Pre-approved templates for individual notices and regulator correspondence help, provided someone checks them against the actual facts before anything goes out. The plan should also say how and when the cyber insurer is told, since late notice can affect coverage.
Some regulators expect one to exist
For certain businesses a written plan is not optional. New York's financial regulator requires the companies it supervises to maintain a written incident response plan, federal health information security rules require covered health care organizations to have security incident procedures, and contracts with larger customers frequently require a plan as a condition of doing business. In those settings the plan is something a regulator or customer may ask to see, and its absence, or a plan that was plainly never used, can become part of the story after an incident. Even where nothing requires one, a company that had a plan and followed it is usually better placed to explain its decisions.
Keeping it current
Plans age quickly. Acquisitions bring in new systems and new data, vendors change, and the people named in the document move on. A short annual review confirming names, contact paths, insurer requirements, and the notice matrix catches most of the drift, and a change in the law is a reason to revisit sooner. We are often asked to review an existing plan rather than write a new one. When we do, we read it alongside the company's actual data map, contracts, and insurance policy, and we flag the places where the document assumes facts that are no longer true.
