Plays Incident Response

BSides Plays Incident Response

Speakers: Maya Kaczorowski, Whitney Merrill

Conference: BSidesSF 2025 — April 26-27, 2025, San Francisco

YouTube: Watch the full talk

Reading time: ~7 minutes

TL;DR

Maya Kaczorowski and Whitney Merrill turned their BSidesSF session into a live incident response tabletop, walking the audience through a realistic vendor data breach scenario at a fictional fintech company. The exercise surfaced critical, often-overlooked practices: who can declare an incident, when to loop in legal counsel, how to communicate internally without inadvertently creating legal exposure, and what user notification actually requires.

Introduction

Most incident response training happens in abstract: slide decks listing phases, checklists of best practices, frameworks like NIST or SANS. What rarely gets simulated is the texture of a real incident — the cognitive overload, the competing priorities, the temptation to wait and see when a data analyst flags a drop in sign-ups on a Friday afternoon.

Kaczorowski and Merrill brought precisely that texture to their talk. Kaczorowski is a security practitioner, and Merrill is privacy counsel who handles incident response continuously. The scenario they constructed — a vendor-side bug that caused one user's uploaded ID document to appear in another user's account, affecting approximately 20,000 customers across a global fintech — is realistic in its origins, its complications, and its messiness. The audience played the role of engineers responding in real time, voting on decisions via Canva emoji reactions.

▶ Watch: Setting up the scenario (02:00)

Level One: Recognizing and Declaring an Incident

The scenario begins on a Friday afternoon. A data analyst notices sign-ups are slightly lower than usual and asks whether any product changes were recently pushed. An engineer investigates, rolls back the most recent deployment, and sees no improvement. Then the engineer actually tests the sign-up flow themselves: they scan their ID, and the document displayed in the application belongs to someone else — specifically, a person named Eric Chang.

The audience's instinct in voting was to contact the security team immediately. But the security team is at BSidesSF and not online. What then?

▶ Watch: The first decision points (04:00)

When the vendor responds and confirms it is their fault but does not provide a fix timeline, the audience converged on the right answer: declare an incident. The presenters paused here to extract lessons from the opening scenario:

• Anyone can declare an incident. There should be no gatekeeping. Waiting for a security team member to certify the situation allows conditions to worsen.
• Have one canonical place to report incidents. A single Slack channel is sufficient. Fragmented reporting creates information gaps.
• Train the entire organization, not just the security team. Non-security employees are often the first observers of anomalous behavior.
• Set up a security@ email address. Vendors frequently have no way to contact an organization except through whoever manages the commercial relationship. A published security contact removes this dependency.

Level Two: Investigation, Containment, and Calling a Lawyer

▶ Watch: Looping in counsel and the attorney-client privilege framework (08:00)

Once an incident is declared, the audience becomes the incident response team. Multiple simultaneous questions arise: pull logs, shut down the affected service, email the vendor for a fix timeline, and loop in counsel. The audience correctly identified all of the above as necessary.

Merrill stepped into her actual professional role here as Whitney, the privacy counsel at the fictional Hyperfinance. Her first instruction was to place all incident communications under attorney-client privilege. Her second was to be looped into every single communication going forward.

This section of the talk surfaced practical legal guidance that rarely appears in technical security training:

• Do not use the word "breach" unless counsel instructs you to. "Breach" is a legal determination with regulatory and notification implications. Using it casually in internal communications can create evidentiary problems.
• In-person communications are preferred for sensitive incident information. Slack messages, emails, and tickets are all discoverable.
• Counsel's questions during an incident are specific and immediate. Merrill's email to the engineer asked: How many people are affected? Where are they located? What is the timeline of the issue? Who had access to the data? Was the exposure temporary or ongoing?

The answer to those questions revealed the scope: 20,000 customers had received another individual's driver's license or national ID image. The issue had been occurring intermittently for weeks. Most affected customers were in the United States.

▶ Watch: Scope, decisions, and shutting down the service (12:00)

Level Three: Decision-Making Under Pressure

The next phase required shutting down the affected service. Shutting down sign-ups costs the company money, and the scenario made this explicit — the fictional company's growth mission was a constant counterweight to security decisions. The presenters used this tension deliberately, because real incidents face exactly this pressure.

The decision to shut down required executive alignment. The best practices extracted from this phase:

• Use a RACI model for incident decisions and align on it before incidents happen. Knowing who is responsible, accountable, consulted, and informed before an incident makes execution significantly faster.
• Bias toward reversible decisions. Shutting down a service is reversible. Not shutting it down and allowing continued data exposure is not.
• Run tabletops at every level, from hands-on-keyboard to board of directors. Incidents that reach the board are handled better when the board has been exposed to the scenario structure in advance.

Level Four: Communication, Remediation, and Notification

▶ Watch: Internal communications and the press leak risk (14:02)

After the service is shut down, two problems remain: communicating internally and notifying affected users. The internal communication challenge is complicated by the attorney-client privilege framework — incident details cannot be freely shared across the organization. The presenters noted that internal communications during a sensitive incident should go through appropriate channels, and that whoever is managing the press relationship should be the only organizational voice to journalists.

On external notification, Merrill walked through the regulatory landscape. Obligations vary by jurisdiction and data type. For a global company, this means analyzing:

• Which users are in jurisdictions with mandatory breach notification laws
• Whether the incident meets materiality thresholds for SEC filing if the company is publicly traded
• Whether law enforcement notification is required

The exercise concluded when the vendor provided a fix and it was deployed. The audience had not yet notified users, raising the question of what communication, if anything, was owed. The audience voted to notify users. Merrill's guidance: even when notification is not strictly legally required, work with counsel and a communications expert to communicate transparently. The reputational upside of proactive disclosure almost always exceeds the cost.

▶ Watch: User notification and regulatory obligations (18:03)

Notable Quotes

"An incident is a disruption to a service that could result in the loss of confidentiality, availability, and integrity. Anyone can declare an incident. No worries, no harm." — Maya Kaczorowski at 06:00

"Don't use words like 'breach' unless the counsel instructs you to do so. Breach is a legal determination." — Whitney Merrill at 14:02

"Think about decisions that are easily reversible versus those that are not. For easily reversible decisions, bias towards moving quickly." — Maya Kaczorowski at 12:00

Key Takeaways

• Anyone on the team can and should declare incidents. Empowering non-security employees to report anomalies shortens detection and response timelines. Create a single, known reporting channel.
• Loop in legal counsel early. Privacy counsel shapes the entire incident strategy — from what to log and preserve, to what to say in vendor communications, to whether and when to notify regulators. Getting counsel involved after the fact limits their ability to help.
• Establish communication protocols before the incident. Know who makes decisions, who communicates with executives, who talks to the press, and how updates are cadenced. Reliable communication prevents micromanagement and reduces fear, uncertainty, and doubt among stakeholders.
• Plan for vendor failures. "Cyber resiliency" means knowing what happens when a third-party service goes down or is compromised. Not every vendor failure requires a backup, but the critical ones should have a known fallback.
• Incident response is not just a security team problem. From the growth engineer who noticed the anomaly, to the legal counsel who managed disclosure, to the comms team that drafted the user notification — incident response is a whole-organization discipline.