Case Studies

Background

A professional-services accounting firm with approximately 30 staff (IT outsourced; ≤25 IT band) processed client wire transfers as a routine part of its work — tax payments, closings, vendor remittances. The firm had a written wire authorization policy. The managing partner believed dual approval was required for all material transfers. That belief was correct for transfers above the formal threshold. It was not correct for the transfer that cleared.

What happened

A senior accountant received an email appearing to be from the managing partner — one character transposed in the display name, not the domain — requesting an urgent same-day wire ahead of a client closing. The managing partner was unreachable by phone. The email felt urgent and contextually correct. The transfer was $47,000. It cleared. The fraud surfaced the following morning when the managing partner saw a receipt notification he had not generated. By that point the wire had moved through an intermediate account.

The firm’s bank recommended running the BEC Pack as a condition of opening the fraud recovery process.

What the firm found when it ran the BEC Pack

The pack was run ten days after the loss, post-incident, at the bank’s recommendation.

1. A two-person rule with a threshold gap. The firm had a documented wire authorization policy requiring dual approval above $50,000. The policy existed and had been reviewed at the prior year’s partners meeting. What had never been formally set was the lower boundary — different partners recalled the threshold as $50,000 or $75,000. The $47,000 transfer required only one approval under either version. The attacker did not defeat the two-person rule. The wire fell below it. The policy had a seam that had never been named.
2. No out-of-band verification requirement for single-approval transfers. The policy defined dual-approval procedures in detail. For transfers below the threshold — the majority of routine wires — there was no documented verification requirement. The informal practice was to call the requestor if something felt off. On an urgent same-day request from the managing partner, nothing felt off enough to make the call.
3. No incident timeline for the bank. The bank’s fraud recovery process required a written timeline: when the email arrived, when the transfer was initiated, when the fraud was discovered, and what recovery steps were taken and when. The firm reconstructed this from memory across three employees two days after the event. The bank’s response noted timeline inconsistencies in the initial submission.
4. No IC3 complaint record. The FBI’s Internet Crime Complaint Center requires organized facts — dollar amount, method, recipient account details, timeline — to process a BEC complaint. The firm’s first attempt was returned for missing fields.

What the pack produced

The BEC Pack restructured payment authorization and produced the evidence record needed for bank and regulatory processes.

• A wire authorization matrix — one page — defining who can initiate, who must approve, what the dollar thresholds are at each tier, and what out-of-band verification is required regardless of transfer size. The lower threshold gap is now explicitly set.
• A verification procedure for urgent transfer requests, including a pre-established contact list for each authorized requestor — phone numbers maintained separately from email and message threads.
• A reconstructed incident timeline organized against the BEC Pack’s Decision Log format, resubmitted to the bank and IC3. The bank’s fraud team noted it as “substantially more organized” than the initial submission.
• An Evidence Register capturing fraudulent email headers, transfer confirmation, bank correspondence, and recovery status — structured so the firm’s insurance carrier, outside counsel, and bank fraud unit each received the same organized packet.

In their words

“We thought we had a two-person rule. We did — above $50,000. The wire was $47,000. IR 2.0 didn’t find a missing control. It found the seam in a control we thought was complete. That’s a harder thing to see on your own.”

— Operations lead, professional-services firm (anonymized)

Background

A dental practice with approximately 30 staff (IT outsourced; ≤25 IT band) came to its annual cyber-insurance renewal having never failed to renew. The office manager and the practice’s IT vendor sat down to fill out the application together. The practice had controls. It could not prove them.

What happened

Fifteen minutes into the renewal application, they stopped. The application asked for documented MFA enforcement across all remote access points. MFA was on — but no document showed which users were enrolled, whether exceptions existed, or when enrollment had last been verified. The IT vendor believed it was fully deployed. The office manager did not know. Backup testing, employee training records, and incident response procedures raised the same problem: the practice had performed the work but had not produced evidence of it. The broker extended the deadline. The practice ran the Insurance Readiness Pack.

What the practice found

The pack ran as a pre-renewal preparation exercise, no prior incident involved.

1. MFA deployment was partial, with no exception record. One clinical workstation used by a part-time employee had been excluded from MFA enrollment at setup due to a compatibility issue. The exclusion was never logged. The IT vendor had forgotten it. The practice had no exception register showing the decision, the risk accepted, or a planned remediation date.
2. Backup testing was assumed, not verified. Nightly backups ran without issue. No one had tested a restore from the dental records management system since the vendor provisioned it eighteen months earlier. The renewal application asked for the date of the last successful restore test. There was no documented answer.
3. Training records did not exist in the form the carrier required. Staff had completed annual security awareness training tracked in the LMS. The carrier’s application required a signed acknowledgment that employees had received and understood the firm’s security policies. No such acknowledgment had been collected.
4. No incident response document. Not a gap in the procedure — the document did not exist. The broker noted this would affect the premium tier if unresolved.

What the pack produced

The Insurance Readiness Pack is structured around three outputs: the attestation worksheet, a control evidence summary, and a gap register with remediation owners and timelines.

• The completed attestation worksheet answered all broker questions with citations to specific evidence. Where evidence did not yet exist, the gap register showed what was being created, by whom, and by what date. The broker accepted this as a basis for underwriting.
• A backup restore test was conducted and documented within ten days of starting the pack. The test surfaced a configuration issue with the dental records management system that the nightly backup had not caught. The issue was corrected before the policy renewed.
• A one-page security acknowledgment form was created and signed by all staff. Combined with the LMS training record, it satisfied the carrier’s training documentation requirement.
• An MFA exception register was created. The compatibility issue was resolved, full enrollment verified, and the register now tracks any future exclusions with a required review date.

In their words

“The renewal application was not asking hard questions. It was asking basic questions we should have been able to answer for years. The pack did not create new work. It organized work we thought we had already done and showed us where the gap between ‘we do this’ and ‘we can prove this’ was wider than we realized.”

— Office manager, healthcare practice (anonymized)

Background

A CPA firm with approximately 20 staff (IT outsourced; ≤25 IT band) offboarded a senior associate after five years. She had been the de facto administrator for most of the firm’s SaaS subscriptions. IT offboarded her Active Directory account within the day. The firm believed the offboarding was complete. It was not.

What happened

Two weeks after the departure, a client reported they could still access a shared folder on the document management platform using a link the associate had sent months earlier. IT confirmed the account was disabled. The shared link had not expired. That was the visible problem. The Foundations Pack was run to find what was underneath it.

What the firm found

The pack was run as a post-offboarding baseline exercise, no prior security incident.

1. No SaaS system inventory. The IT vendor managed primary infrastructure. SaaS subscriptions had been acquired by whoever needed them — partners, the office manager, the departed associate — with no central list. The Foundations Pack intake identified eleven active SaaS platforms. The IT vendor had documentation for four.
2. No offboarding checklist tied to actual systems. The firm’s offboarding procedure covered Active Directory, email, and building access. It did not cover SaaS platforms, shared links, client portal configurations, or the API integrations the associate had configured between platforms. Those integrations continued running under her credentials after her AD account was disabled.
3. No vendor access record. Two of the eleven platforms discovered had active credentials belonging to a vendor whose engagement had ended eighteen months earlier. No process connected contract end dates to access termination.
4. No data-classification baseline. The document management system held client tax files, engagement letters, and signed returns going back seven years. The firm had no record of what data categories each platform held, who could reach them, or what the exposure surface looked like on any single account compromise.

What the pack produced

• A complete SaaS platform register listing all eleven systems — data categories held, access model, designated owner, and quarterly review cadence.
• An offboarding checklist rebuilt from the register — not a generic IT checklist, but a system-by-system sequence showing what access to revoke in each platform, in what order, and who verifies completion.
• A vendor access record showing all third-party integrations, the credentials each uses, permission scope, and last verified date. The two stale vendor accounts were revoked as part of creating the record.
• A shared-link audit covering the document management system and client portal. Active links were inventoried, reviewed by the managing partner, and either confirmed as intentional or revoked. A quarterly review was added as a standing task.

In their words

“We offboarded her correctly by the process we had. The process just didn’t cover half the systems she touched. The Foundations Pack didn’t find a security incident. It found the gap between what we thought offboarding covered and what it actually covered. That’s a harder thing to see on your own.”

— Managing partner, professional-services firm (anonymized)

Background

A federally insured community credit union with four branches and roughly $60 million in assets (≤25 IT band) processed member wire transfers through a manual workflow that had operated without incident for eleven years. Staff verified member identity; a supervisor approved; the wire was submitted. The process was familiar. It was not documented at the point where it failed.

What happened

A staff member received an email appearing to come from a longtime commercial member — correct name, correct account number, plausible travel context — asking to change the destination account on a pending wire. The staff member checked with her supervisor. Neither called the member. The change was processed. The wire — $31,000 — cleared to an account the member had never seen. The member called two days later to ask why the transfer hadn’t arrived. The credit union’s bond insurance carrier recommended running the BEC Pack and Insurance Readiness Pack as part of evaluating the claim.

What the credit union found when it ran the packs

Both packs were run together post-incident, at the carrier’s recommendation.

1. No documented callback requirement for payment-instruction changes. Staff knew they were supposed to call members to verify unusual requests. That knowledge lived in training sessions. It was not written into the wire transfer procedure. When the carrier asked to see the documented verification requirement, there was nothing to produce.
2. No account-change authentication standard. The email used the member’s name and account number — both of which appear on statements and are not secrets. There was no requirement to authenticate a channel-change request through a second factor or pre-registered contact method.
3. No NCUA incident notification pathway. Under Part 748 of NCUA regulations, federally insured credit unions must report a reportable cyber incident within 72 hours of forming a reasonable belief one has occurred. The credit union had no documented threshold for when a fraud event crossed into NCUA-reportable territory, no named responsible party, and no submission path. The event was not reported to the NCUA. When the examiner followed up six weeks later, this became an additional compliance finding separate from the bond claim.
4. No evidence packet structure for bond claims. The carrier’s claim form required a timeline of events, verification steps performed, identities of all staff involved in the authorization, and documentation of controls in place at the time. The credit union reconstructed this from memory across three employees over four days. The claim was delayed pending supplemental documentation.

What the packs produced

• A wire verification procedure requiring out-of-band callback to a pre-registered member phone number — not the number in any email, not the number on the account statement — for all payment instruction changes regardless of channel.
• An NCUA reportable incident decision tree calibrated to the three-prong definition under Part 748. The tree names the responsible party and the submission path to cyberreports.ncua.gov.
• A Suspicious Activity Report preparation checklist covering FinCEN filing requirements for BEC wire fraud incidents — separate from the NCUA notification.
• A bond claim evidence register capturing incident timeline, staff actions, verification steps taken and not taken, and control status at time of event — structured for the carrier’s form fields, not internal narrative.
• A completed Insurance Readiness attestation worksheet for the renewal cycle, with documentation citations for each claimed control. The wire verification procedure and SAR checklist are cited as new controls implemented post-incident.

In their words

“We had a process. The process depended on staff judgment about when to call and when the email was enough. IR 2.0 showed us the process was informal where it needed to be explicit — specifically at the moment when a member requests a change through a channel we can’t authenticate. That’s where the loss happened. That’s where the procedure now lives.”

— Operations supervisor, financial institution (anonymized)

Background

A regional electric cooperative serving a rural service territory (26+ IT band — dedicated operations and IT staff with separate procurement lines) ran its first third-party vulnerability scan as part of a NERC CIP compliance self-assessment. The scan was scoped to IT systems. It also found fourteen devices that were not in any inventory the cooperative maintained — including a substation automation device installed by a contractor three years earlier and never formally accepted into the asset register. Nobody had told the scan to look for those devices. Nobody knew they were there.

What happened

The scan results triggered the Foundations Pack. There was no prior security incident. The trigger was asset discovery: the cooperative could not explain what was on its own network.

What the cooperative found when it ran the Foundations Pack

The pack was run as a compliance-preparedness baseline exercise following the vulnerability scan.

1. No unified asset inventory. The IT team maintained a list of managed endpoints. The operations team maintained work orders and contractor invoices for field equipment. Neither list had ever been reconciled. The fourteen unregistered devices were not anomalies — they represented how equipment had been added over five years without a central intake process.
2. No network boundary documentation. The billing platform and the SCADA historian shared a network segment originally designed as separate. A firewall rule modified during a maintenance window two years earlier had created a temporary connection. The rule was never reversed. No one knew the segment was shared.
3. No vendor access register. Three contractors had active remote access credentials. One had concluded its engagement fourteen months earlier. Its credentials had not been revoked. No process connected contract end dates to access termination.
4. No patch exception record. Several OT devices ran firmware the manufacturer had flagged as end-of-life. The risk was known operationally — updating required taking equipment offline. That decision had never been documented: no record of who accepted the risk, when, or what the planned remediation window was.
5. No isolation authority matrix. If a security event required taking a network segment offline, it was unclear who held authority to authorize the disconnection or whether operations staff had any say in a decision that could affect delivery reliability. The Foundations Pack forced the question. It had never been asked.

What the pack produced

• A unified asset register combining IT endpoints, OT devices, and field automation equipment — network location, management status, firmware version, vendor contact, and designated owner per asset. The fourteen unregistered devices were reviewed; twelve accepted into the register with documented owners, one determined to be decommissioned hardware never physically removed, one a contractor-managed device with active connectivity flagged for vendor resolution.
• A network boundary diagram documenting actual current-state segmentation, including the shared segment. The firewall rule was reviewed jointly by IT and operations and reverted after confirming the maintenance need had concluded.
• A vendor access register with all active remote credentials, associated contractor, contract status, and last verified date. The fourteen-month-stale credentials were revoked.
• A patch exception log for all end-of-life OT firmware — known risk, accepted-by name and date, planned remediation window.
• An isolation authority matrix defining who can authorize network segment isolation, the notification chain to operations leadership, and minimum-service criteria before connectivity can be restored.

In their words

“We knew we had IT and OT running separately. We thought that was a network architecture question. The pack showed us it was also a visibility question — we had assets on our network we couldn’t account for, access credentials active for vendors we hadn’t worked with in over a year, and a firewall boundary that had quietly dissolved. None of that was visible until we built the register.”

— IT manager, energy cooperative (anonymized)

Background

A US-based specialty retail company (≤25 IT band; IT outsourced) with approximately $2 million in annual revenue sells online to customers in the United States and seven EU member states. Customer data — including IP address and device identifiers for EU customers — is stored in a US-hosted database. The company had a privacy policy referencing GDPR. It had no operational procedure for a GDPR notification scenario.

What happened

A misconfigured access control on a third-party marketing integration exposed the customer database to unauthorized read access for an estimated nine days. The integration vendor notified the company on a Friday afternoon. The company’s IT consultant contained the exposure by end of day. On Monday morning, the CEO asked the general counsel whether anyone needed to be notified. The general counsel said she would check. She was primarily familiar with US state breach notification law. By the time the correct answer was established — notification to the German Supervisory Authority was required within 72 hours of awareness — the window had already passed. The company filed late. The LfD opened a formal inquiry.

What the company found when it ran the packs

Both packs were run after the LfD inquiry opened, as part of the company’s regulatory response and insurance renewal preparation.

1. No GDPR incident decision tree. The company had GDPR obligations it knew about in the abstract. It had no procedure for determining — at the moment of discovery — whether an event triggered the Article 33 supervisory authority notification, the Article 34 individual notification, or both. The 72-hour clock runs from the moment the controller becomes aware, not from the completion of legal analysis. Without a pre-built decision tree, the analysis took two business days.
2. No EU representative designation on file. As a controller without an EU establishment, the company was required under Article 27 to designate an EU representative. It had not done so. The LfD inquiry noted this as a secondary compliance finding.
3. No data subject inventory by jurisdiction. EU and US customer records were commingled in the database with no jurisdiction field. Determining which customers were EU data subjects — and therefore potentially subject to Article 34 individual notification — required a custom database query that took six hours to build and validate.
4. No vendor breach notification SLA in the integration contract. The marketing vendor had discovered the misconfiguration two days before notifying the company. Under Article 33(2), a processor must notify the controller without undue delay. The company had no SLA requiring prompt notification and no record of when the vendor actually became aware — meaning the 72-hour clock may have started running before the company was told.

What the packs produced

• A GDPR incident decision tree mapping four questions — EU data subjects involved? Personal data breach under Article 4(12)? Article 33 notification threshold met? Article 34 individual notification threshold met? — to the LfD online notification form fields. Can be completed in under thirty minutes by staff without legal training.
• An Article 27 EU representative designation, documented. The company engaged a representative service in Germany.
• A data subject jurisdiction flag added to the customer database schema, with a retroactive classification run completed and documented. EU customers are now identifiable in under two minutes.
• A vendor breach notification SLA addendum drafted and sent to the marketing integration vendor and two other third-party processors. Requires notification within 24 hours of the vendor becoming aware of unauthorized access to company data.
• A completed Insurance Readiness attestation worksheet documenting GDPR controls — data mapping, DPA contact, notification procedure, vendor SLA — for the cyber-insurance renewal. The carrier had added GDPR notification coverage as a question on the renewal application the prior year. The company had left it blank.

In their words

“We knew we had GDPR obligations in theory. What we didn’t have was any operational procedure for the moment when something actually happened. The decision tree didn’t require us to become GDPR experts. It required us to answer four questions and follow the path. That’s what was missing — not knowledge of the law, but a way to act on it in the first three hours of a Friday afternoon.”

— General counsel, e-commerce company (anonymized)

Background

A solo internal medicine practice with fewer than ten staff and approximately 2,400 active patients (≤25 IT band; IT handled by the practice manager) uses an EHR platform, a patient portal, and a billing service operating under a Business Associate Agreement. The practice manager handles IT, HR, and compliance. No one in the practice had ever had to answer a HIPAA breach-reporting question.

What happened

The billing coordinator received an email appearing to come from the EHR vendor’s support team, asking her to verify her login credentials to resolve a billing sync issue. She entered her credentials before the page looked wrong. She closed the browser and told the practice manager. The practice manager reset the password and sent an all-staff email about suspicious emails. Then she turned to the physician and said: “Do we need to report this to anyone?” Neither of them knew the answer. The billing service flagged the event the following week as potentially involving protected health information. The practice ran both packs.

What the practice found when it ran the packs

Both packs were run the week following the credential event, after the billing service’s flag.

1. No phishing response procedure. The billing coordinator’s instinct — close the browser, tell the practice manager — was reasonable. What happened next was improvised. There was no documented sequence: verify whether credentials were used before resetting, pull EHR audit logs for the window between credential entry and password reset, determine whether PHI was accessed. The password was reset before anyone checked whether it had been used.
2. No HIPAA breach risk assessment procedure. Under 45 CFR §164.402, a covered entity must perform a four-factor risk assessment to determine whether an event constitutes a reportable breach of unsecured PHI. The practice had no template for performing or recording this assessment. Without it, the practice could not demonstrate to OCR that it had properly evaluated the event.
3. No audit log access process. The EHR platform maintains access logs. The practice did not know how to request them, who to call at the vendor, or what time window to specify. By the time the billing service flagged the issue five days later, the audit log review that should have happened within hours was being performed more than a week after the credential entry.
4. No BAA review record. The billing service BAA had not been reviewed in four years. Under the 2025 HIPAA Security Rule revisions, BAAs require specific incident notification timeframes. The existing BAA did not meet the updated standard.
5. No HHS OCR notification calendar. HIPAA requires individual notice within 60 days of breach discovery and annual HHS notification for breaches affecting fewer than 500 individuals. The practice had no documented breach discovery date, no individual notification letter template, and no record of prior annual submissions. Two previous events had never been assessed for breach status.

What the packs produced

• A phishing response procedure covering the first four hours: isolate the credential, pull audit logs before resetting the password, document the access window, determine whether PHI was in scope, and begin the HIPAA four-factor risk assessment. Posted in the break room; requires no IT expertise to follow.
• A HIPAA breach risk assessment template with a decision output of “reportable breach,” “not a reportable breach — document basis,” or “insufficient information — escalate.” The billing coordinator event was run through the template retroactively. The assessment concluded it was not a reportable breach based on log evidence showing no PHI access in the credential window. That conclusion is now documented.
• An EHR audit log request procedure — vendor contact, form to complete, minimum data to request — filed in the Foundations Pack asset register under the EHR system entry.
• A BAA review register listing all three current Business Associates, the BAA date, the incident notification timeframe in each agreement, and the date last reviewed. The billing service BAA was updated within thirty days.
• An OCR submission calendar with the annual small-breach reporting deadline, the 60-day individual notification deadline keyed to breach discovery date, and the OCR portal link. The two prior unassessed events were documented, run through the risk assessment template, and added to the annual log.

In their words

“The credential event probably wasn’t a breach. The logs supported that. But we couldn’t prove it at the time because we didn’t know to check the logs before resetting the password. The pack didn’t change what happened — it changed what we would do the next time, in the first twenty minutes, when it still matters.”

— Practice manager, healthcare practice (anonymized)

Background

A small engineering subcontractor (≤25 IT band; IT handled by the office manager) supports two prime contractors on DoD programs involving controlled unclassified information. The firm completed a NIST SP 800-171 self-assessment two years prior under deadline pressure and submitted a score to SPRS. The IR section of the SSP described a documented IR plan, a reporting chain, and a tested response procedure. None of those things existed in the form the SSP described. The C3PAO assessment notice — eleven weeks out — made that visible.

What happened

The office manager pulled the SSP to prepare for the C3PAO assessment. The IR section described controls as implemented. Several were aspirational. The gap had been sitting quietly for two years. The C3PAO notice forced the reconciliation. The firm ran both packs.

What the firm found when it ran the Foundations Pack and Insurance Readiness Pack

Both packs were run in sequence as a C3PAO pre-assessment preparation exercise.

Controls that did not exist as described:

1. No operational IR plan. The firm had a one-page policy document naming the office manager as point of contact and referencing NIST SP 800-61. It did not define what constituted a reportable incident, who had authority to invoke it, what the containment steps were, or how the DFARS 252.204-7012 72-hour reporting requirement would be operationalized. It did not provide the evidence the IR.2 and IR.6 assessment objectives call for.
2. No cyber incident reporting procedure. DFARS 252.204-7012 requires contractors to report cyber incidents to DoD via DIBNet within 72 hours of discovery. The firm did not know which systems were “covered contractor information systems” under the clause, had no active DIBNet account, and had never tested whether it could identify, document, and submit a report within 72 hours.
3. No CUI handling register. CUI was handled across a shared network drive, encrypted email, and a file-transfer portal maintained by one of the primes. No document listed what CUI categories the firm processed, where each was stored, who could access it, or the retention and destruction requirements.

Controls that existed but could not be demonstrated:

4. Controls practiced but undocumented. MFA was in use for VPN access, but no enrollment record showed which users were enrolled or whether exceptions had been granted. Informal rules about removable media existed but were written nowhere, and no training record covered media handling.
5. No incident history log. A phishing event eighteen months earlier — two of three targeted employees clicked — had never been logged or reported to DoD.

What the packs produced

The firm ran Foundations first to build the baseline registers, then used Insurance Readiness to organize everything the C3PAO would review.

• A CUI asset register documenting every system, drive, application, and communication channel touching CUI — data categories, access model, designated owner. This became the foundation for the revised SSP IR section and media protection procedure.
• An operational IR plan built to CMMC Level 2 requirements — defined incident categories, DFARS 252.204-7012 trigger threshold, containment and evidence-preservation sequence, 72-hour reporting checklist with DIBNet fields pre-mapped, and a named authority chain. Eight pages. Replaces the one-page policy.
• A DIBNet account registered and tested. The compliance lead submitted a test report, confirmed the account was functional, and documented the submission process.
• An MFA enrollment record created from the VPN configuration export. All fifteen CUI-access users verified enrolled. One exception — a field technician on legacy credentials — identified, remediated, and logged with a resolution date.
• A control evidence binder organized by CMMC domain, mapping each IR, AC, and MP control to its supporting evidence.
• The eighteen-month-old phishing event reconstructed, documented in the incident log, and assessed against the DFARS 252.204-7012 reporting threshold. The assessment determined it did not meet the threshold for DoD notification. That determination and analysis are now documented — which is itself a demonstrable control.

In their words

“The SSP described where we wanted to be. After two years, we had stopped reading it closely enough to notice the gap between the description and what we actually had. The C3PAO notice forced the question. The pack gave us a sequence for answering it — not a compliance checklist, but a process that produced the actual artifacts an assessor looks for. The difference matters.”

— Compliance lead, defense subcontractor (anonymized)

Background

A county public works department — permitting, inspections, contractor licensing, infrastructure project management — (≤25 IT band; IT shared with county services) had a cybersecurity IR plan on file, cited annually in its compliance checklist as in place. The plan had been drafted by county IT three years earlier and delivered as a completed document. It had not been read in full by the department’s current leadership. In the spring, the county participated in a CISA SLTT tabletop exercise. The facilitator’s opening question was: “Who here is the incident commander?” No one answered immediately. Three people looked at each other.

What happened

The CISA facilitator walked the room through a ransomware scenario using the department’s own IR plan as the reference document. Within twenty minutes: the named incident commander had retired fourteen months earlier; the CIO escalation path pointed to a position reorganized out of existence eighteen months prior; two of three staff named for system isolation decisions no longer worked for the county; and the evidence preservation drive path referenced in the plan had been migrated to a different system. The department had a written IR plan. The plan described an organization that no longer existed. The facilitator recommended the Foundations Pack before the next exercise.

What the department found when it ran the Foundations Pack

The pack was run over two working sessions following the tabletop, as a post-exercise baseline exercise.

1. No current authority matrix. The IR plan named roles, not people. The roles had changed. The department head believed she held incident authority. So did the IT coordinator. Neither had been told the other believed the same thing.
2. No system ownership register. The department used nine systems — seven county-managed, two department-managed. No document listed who owned each, who could authorize isolating it, or what the operational impact of isolation was. The permit system’s criticality was understood informally but never documented in a way that shaped response decisions.
3. No notification list with current contacts. The plan’s notification section referenced a county email distribution list not updated in two years. Three of seven addresses bounced. The county communications office — first external caller in the tabletop scenario — was not on the list.
4. No offboarding protocol connected to IR plan roles. The former operations manager’s credentials had been deactivated. Her named authority in the IR plan had not. No process connected HR offboarding to plan role updates.
5. No recovery priority sequence. The plan did not distinguish between systems. In a degraded-operations scenario, the department had no documented basis for deciding which system to restore first or what minimum service level was acceptable during recovery.

What the pack produced

• A current authority matrix — one page — listing the named individual in each IR role, their backup, contact information outside county email infrastructure, and specific decisions each role can make without escalation. Reviewed every six months; updated immediately on any named individual’s departure or role change.
• A system ownership register for all nine systems — current owner, county IT contact, authorization required to isolate, estimated operational impact of an eight-hour outage, and recovery priority tier.
• A notification list with current names, direct phone numbers, and personal email addresses for twelve contacts — including the shared services director, county communications director, county attorney’s office, and the state’s CISA regional advisor. Maintained separately from county email infrastructure.
• An IR plan amendment replacing the three outdated role assignments with current names and adding a maintenance trigger: plan updated within ten business days of any named individual separating, transferring, or changing roles. Ownership belongs to the department head, not county IT.
• A recovery priority sequence and minimum service level definition for each Tier 1 system, approved by the department head and filed with the county’s emergency management coordinator.

In their words

“The plan we had wasn’t wrong when it was written. It just described the department as it existed three years ago. No one’s job was to keep it current, so no one did. The tabletop showed us where the gaps were. The pack gave us the structure to close them in a way that would survive the next round of staff changes — because the register is the thing that gets updated, not the plan narrative.”

— Department head, county government agency (anonymized)