The Incident Tabletop That Found a Real Gap
You run a tabletop exercise for a 300-person healthcare-adjacent company that handles appointment scheduling and insurance eligibility checks. The scenario: a laptop with a spreadsheet of 4,200 patient names, dates of birth, and insurance member IDs is stolen from an employee's car. During the exercise, three facts emerge. First, the spreadsheet was exported from the scheduling system for a board report and never deleted. Second, the laptop had full-disk encryption, but the employee cannot confirm it was enabled on that machine. Third, the company's incident response plan says 'notify the privacy officer' but does not name who decides whether notification is required, does not set a timeline, and was last tested in 2021. The legal team says the state breach law 'probably doesn't apply because it was encrypted.' The insurer contract requires notice within 72 hours of discovery.
1. The legal team's 'probably encrypted' position is doing a lot of work. How do you evaluate it?
Read the worked answer
The position rests on an unverified premise, and the burden is on the company to establish the encryption exception - not to assume it.
What must be verified:
- Whether full-disk encryption was actually enabled and active on that specific device at the time of theft. 'The laptop had encryption' describes capability, not state.
- Whether the device was powered off, in sleep, or logged in. Encryption protects data at rest; a device in a logged-in or suspended state may be accessible.
- Whether the exported spreadsheet sat on an encrypted volume or a separate/removable location.
- Whether device management records (MDM, endpoint logs) can confirm state. If they cannot, you cannot claim the exception with confidence.
Why 'probably' is not a defensible standard:
- Breach statutes typically require notification unless the data is rendered unusable, and the company bears the burden of demonstrating that. An unverified encryption claim is a guess.
- The insurer contract's 72-hour notice is independent of the state-law analysis. Contractual notice may be required even where statutory notice is not.
- If the claim later proves wrong, you have both a notification failure and a credibility problem with regulators and the insurer.
Practical path: treat as notifiable until device records prove encryption was active. Run the state-law and contract analyses in parallel, not sequentially, because the 72-hour clock does not wait for the state analysis.
2. The IR plan has no decision owner and no timeline. What do you build, and what is the minimum viable version given a 300-person company?
Read the worked answer
Build a decision structure, not a longer document. The gap is accountability and time, not prose.
Minimum viable elements:
- A named decision owner for notification determinations - typically the privacy officer with a documented backup. Not a committee; committees do not decide at 6 p.m. on a Friday.
- A decision framework the owner applies: what data, how many people, what identifiers, is it rendered unusable, which jurisdictions, which contracts. This turns a judgment call into a repeatable one.
- Clock rules: start the clock at discovery, define who can constitute discovery, and set internal deadlines ahead of external ones - e.g., facts gathered within 24 hours, decision within 48, insurer notice by hour 60 to meet the 72-hour contract term.
- A contact tree including outside counsel, the insurer, and a regulator-notification channel.
- A one-page incident log template capturing decisions and their basis - essential if you are later asked why you did or did not notify.
Why not a full rewrite: a 300-person company will not maintain a 60-page plan. A two-page decision-and-clock annex to the existing plan, tested annually, is more likely to be used and more likely to be current. The 2021 test date is itself the finding - schedule the next test and report results.
3. The spreadsheet was exported for a board report and never deleted. What does this incident tell you about your controls, and what do you fix?
Read the worked answer
The theft is the trigger; the export is the root cause. Fixing the laptop does not fix the export.
What it reveals:
- No purpose limitation in practice. A board report needed aggregate figures; someone exported 4,200 rows of identifiable data. The control should make the minimum-data path the easy path.
- No export governance. There is no approval, logging, or expiry on data exports from the scheduling system.
- No lifecycle for ad hoc files. Once exported, the file left the governed system and entered an ungoverned one (a laptop, a car).
- No device-state assurance. You cannot confirm encryption on a device holding patient data.
Fixes, in order of leverage:
- Change the export default: provide pre-aggregated board reporting views so identifiable exports are unnecessary. This removes the reason the file existed.
- Gate and expire exports: require approval for identifiable exports, log them, and set automatic deletion or access expiry.
- Enforce device posture: verify encryption via MDM and block access to sensitive systems from unverified devices.
- Prohibit storage of identifiable exports on endpoints - direct to a governed repository.
Report it: the tabletop found a real gap; that is a success of the exercise and belongs in the audit committee update with the remediation dates, not buried.