In partnership with
When was the last time you read your incident response plan (IRP)? Does your plan say something like… “Escalate incident to incident response stakeholders.”
Great. Love that for you. But for this to work, you need to know who counts as an incident response stakeholder? Who calls those people? In what order are they called? What facts are they given? Who approves the holding message if the incident hits at 10:47 p.m. and your GC is on a plane with spotty Wi-Fi.
The point I’m trying to make is that when there isn’t detail in your IRP, what happens in a real incident becomes unfortunately predicable. You end up scrambling. Someone pings a dozen channels. Security starts containment before escalation happens. Legal is asking for facts, but there hasn’t been a full intake yet. Communications want an approved holding statement, but there is nowhere near enough information to make any statements yet. And all this happens while your plan sits there like a well-meaning motivational poster.
This is the gap between 'we have an IRP' and 'we can execute.' The plan has the ‘what,’ but it assumes that you’ve separately created process for ‘how’. Your job is to build that missing ‘how’ into artifacts, owners, and muscle memory.
Smart starts here.
You don't have to read everything — just the right thing. 1440's daily newsletter distills the day's biggest stories from 100+ sources into one quick, 5-minute read. It's the fastest way to stay sharp, sound informed, and actually understand what's happening in the world. Join 4.5 million readers who start their day the smart way.
What an IRP is
An IRP is a map. Execution readiness is the ability to drive the route when you are tired, stressed, and missing half the information.
Most IRPs describe phases (identify, contain, eradicate, recover) and list broad responsibilities. That is necessary, but it is not always sufficient to actually take action. Even though “plan” is in the name, a lot of IRPs end up not having execution-level detail in them. Partly, because that level of detail would make the plan tough to follow and navigate, and partly because sometimes that level of detail isn’t established when the plan is first put into place.
Privacy incidents are especially unforgiving because the hard parts are not only technical but focus on decision-making, communications, contracts, timelines, and evidence. The sooner you accept that, the faster you will build an IRP that actually works.
Note here that you may not WANT or NEED to make your IRP a 200-page tome. With clients, I often suggest targeted playbooks, SOPs, and annexes to the IRP that go into sufficient detail to help the various functions and teams execute on the plan.
The missing execution layer: what your plan may assume exists
If your IRP contains phrases like 'notify,' 'escalate,' 'coordinate,' or 'engage stakeholders,' it is silently assuming that someone already built the operational layer underneath those verbs.
Here are the artifacts that usually sit in the missing middle:
A roles and escalation matrix (who owns which decisions, and when issues jump tiers)
Assembly and escalation triggers (what facts trigger Legal, Comms, HR, Procurement, Exec involvement)
Vendor and subprocessor contacts (and the contract clauses that control notice and cooperation)
An insurer notification path (who calls, what is shared, and how privilege is preserved)
A decision log template (what you decided, why, and what evidence supported it)
An evidence capture routine (screenshots, exports, meeting notes, and timestamps, stored consistently)
A communications approval path (who can approve internal updates, external notices, and regulator responses)
A post-incident learning loop (what gets updated, who owns it, and by what date)
The point of a tabletop is not the scenario. It is the handoffs.
A tabletop exercise is a pressure test of handoffs, so it can be extremely helpful in identifying the missing pieces of your plan’s execution lawyer. The scenario your team runs is just the backdrop. The real product is getting clarity on plan remediation actions, such as bottlenecks you can fix, missing owners you can assign, and evidence gaps you can close. The goal of every tabletop exercise is to leave with a short list of operational improvements and assigned owners.
This is also where privacy gets practical. Privacy asks: what data was involved, which jurisdictions matter, what contractual promises apply, what choices did users make, and what do we need to say (and not say) while facts are still moving.
How to retrofit your existing IRP without rewriting it
If you do this quarterly, your IRP stops being a static plan and becomes a training program. That is how you respond fast when an incident hits.
Identify your top 5 incident types (vendor breach, misconfigured cloud storage, phishing, internal mishandling, ransomware). Pick what is realistic for your org.
Map the critical handoffs for those incidents: Security to Legal, Legal to Comms, Procurement to Vendor, HR to leadership, etc.
Create the missing middle artifacts (escalation criteria, vendor contact register, decision log, evidence routine). Keep them short and usable.
Run a mini tabletop (60 minutes plus debrief) focused on one incident type and one set of handoffs. Capture what broke.
Update the artifacts and assign owners with dates. The assignment is the work. The document is the wrapper.
Where privacy makes incident response harder
Training on privacy response adds layers that security-only exercises often miss. Contracts may impose notice timelines. Consumer rights workflows may intersect. HR may need to manage employee communications. Data minimization and retention practices shape what was even exposed. Vendor relationships determine what facts you can obtain quickly.
Privacy incidents take an incident from ‘bad things happened’ to 'bad things happened and now we have to make defensible decisions under uncertainty.'
The organizations that respond best are not the ones with the longest plan. They are the ones with the clearest owners, simplest artifacts, and a repeated practice loop.
Become a paid subscriber to get access to all of the mini tools that we publish with each post. For instance, this post includes an IRP Reality Check!
Finally, reminder that the opinions expressed in this article are the opinion of The Privacy Design Lab. They are not legal advice, and no attorney-client relationship is formed by reading this article or downloading the M&A Privacy Integration Map. If you need to consult legal counsel, you can book a consult with ARLA Strategies or other legal counsel you trust!
If you’re tired of privacy advice that only works in theory, you’re in the right place.
The Privacy Design Lab exists for people who want to practice privacy, not just talk about it. It focuses on practical, repeatable ways teams actually learn. We offer hands-on workshops, downloadable systems, and the Design Studio community where teams and practitioners can go deeper. Paid Fieldnotes subscribers get access to our full archive, plus supporting materials you can actually use.
If that sounds like your kind of work, we’d love to have you.