The message arrives on a Tuesday morning from a company you barely remember doing business with. "We recently experienced a security incident," it begins, and somewhere in the third paragraph it mentions that email addresses and passwords were among the data taken. One of the addresses is yours, or rather the organization's. Maybe the notice came from Have I Been Pwned instead, or from the browser itself, in a small gray bar: this password appeared in a data leak.
A breach notice is a weather report, not a burglary in progress. Nobody is inside your accounts yet, as far as the notice knows. What leaked from that vendor is a password and the address it was paired with, and on its own that pair opens exactly one door, the vendor's. The problem is what the automated side of the internet does next. Within days, leaked pairs are fed into every login page attackers can reach, on the assumption that a password used once was used twice. That assumption is correct often enough to pay. The response below is built around beating it, and it takes an hour if the vault is in good shape.
First, find out what actually leaked
Read the notice slowly, because the details change the response. Which service was breached? Were the passwords stored hashed, which slows an attacker down, or in plain text, which does not? Was payment or personal data in scope? And when did the breach happen, as opposed to when the company got around to telling you? A gap of months means the leaked password has been circulating for months.
Then verify the notice before clicking anything in it. Breach notices are themselves a favorite phishing costume, because an alarmed person clicks. Go to the service by typing its address or using the vault's saved link; a genuine incident will be posted there too. While you are checking, run the organization's other addresses through Have I Been Pwned. Today's notice is a good reason for the full check, and it is item 9 on the security baseline checklist anyway.
Write down the service, the affected addresses, and the data types. That is the first line of the incident log entry you will finish in step five.
Rotate the breached account
From the vault, change the password on the breached service to a fresh, generated one. Turn on two-factor authentication (2FA) there if the service offers it. If a payment method was stored in that account, review it, and if card data was in scope, watch the statements for the next few cycles. This step closes the one door the notice was about. The rest of the hour is about the doors it did not mention.
Hunt the family tree
Here is the real work. A reused password rarely travels alone; it has siblings. "Bakery2019" has a cousin named "Bakery2020" and a brother with a symbol added at the end, and an attacker's software tries those variations automatically. Search the vault for the leaked password and anything close to it, and list every account that uses one of them. Be honest about the list; this is the one place in the playbook where optimism costs money.
Rotate each account in blast-radius order. The organization's email goes first, because it resets the password on nearly everything else. Hosting, the registrar, and the DNS provider follow, then social accounts, then anything near money, then the rest. Yesterday's password audit used the same order, and if you ran it, the family tree may already be small.
Accounts that never made it into the vault deserve a separate line. Memory will surface them: the old survey tool, the font site, the conference portal. Each one you recall gets rotated, entered in the vault, and added to the inventory with an owner's name beside it. Every breach notice, handled this way, makes the vault more complete than it was before the notice arrived.
Raise the walls the breach tested
Confirm 2FA is on for every account that can change the website, the DNS, the hosting, or the email. The October post "Turn On 2FA Everywhere" listed those eight account types in order. A leaked password against a 2FA door is a non-event, which is the whole point of the second factor.
Then tell the colleagues whose addresses appeared in the notice, plainly and without blame: which service, what to rotate, and in what order. Forward them these steps. The person who learns about a breach from you on Tuesday is in a far better position than the one who learns about it from a locked account in December.
Close the loop
Write the incident log entry: the breach, the date of the notice, the size of the family tree, and the rotations completed. Then record the finding the family tree revealed. If the reused-password list ran long, the vendor's breach was not the real finding; the finding is that the unique-password rule from Chapter 2 is not yet practice at your organization. Write that down too, because it belongs in the quarterly review, and because the next notice will test whether anything changed. Confirm that the annual Have I Been Pwned check sits on the security baseline cadence, and the hour is over.
The version of this that takes five minutes
Vendors will keep getting breached. That is weather, and no small organization controls it. What the organization does control is whether any single leak is a one-account event. With every password unique and vault-generated, and 2FA on everything that matters, the next notice collapses to step two and a shrug: change the one password, log it, move on. The hour this post describes is what it costs to get there once. After that, breach notices become what they should have been all along, a minor chore with a line in the log.
Get the playbook before you need it. The full sequence, with blanks for the service breached, the addresses affected, the family tree, and every rotation, is the "Your Password Is in a Breach" playbook from the Web Emergency Playbook. The sampler is provided at no cost. Print it while it is still a weather report.