5.3: When the Alert Fires
When the Alert Fires
Some Tuesday, the email arrives: “You’re one of 3.2 million users affected by a breach at…” Maybe it comes from HIBP, maybe from the company itself, maybe as a badge in your password manager. This lesson is the drill for that day, written down now, while nothing is wrong, because procedures invented mid-incident are bad procedures.
The whole thing runs about twenty minutes. Set a timer if that helps; part of the point is that this has a beginning and an end. You’re not “dealing with being hacked.” You’re running four known steps for a known kind of event.
First, thirty seconds of triage
Read the alert for two facts: which site, and what data (the notice or the HIBP entry lists categories — email addresses, passwords, payment cards, and so on). And one warning before you click anything, straight from Spot the Scam: breach news attracts fake breach emails. “Your account was compromised, click here to secure it” is itself a phishing formula. Never log in through the alert’s own links. Open the site the way you always do, through your password manager’s entry, which, as you know from 2.3, won’t fill on an impostor.
Step 1: Change that password (5 minutes)
Log in to the breached site, let the manager generate a fresh password, save. Done. This is what Module 2 already bought you: because the old password was unique, this one change ends the incident’s reach. There is no second site where that password also worked. If the breach included payment cards, add a call to your card issuer for a replacement number. (Transaction alerts, next lesson, catch any misuse in the meantime.)
Step 2: Hunt for reuse — trust, but verify (5 minutes)
You migrated in 2.4, but run the check anyway. Open the manager’s report (Watchtower or its equivalent) and search for the burned password. The migration was opportunistic, and this is the moment a straggler surfaces: the one old account that still shares it. If the report finds the password anywhere else, change it there too, now. If it finds nothing, which is the expected result, you’ve verified that the blast radius is one site. Five minutes well spent for that certainty.
Step 3: Check active sessions (5 minutes)
If attackers used the leaked credentials before you rotated them, a password change alone may not evict a session that’s already signed in. Most important sites have a security page listing active sessions or “where you’re logged in” (Google, Apple, banks, and social platforms all do). Open it on the breached account. Either you recognize every device and location, or you hit sign out everywhere, which costs you one re-login and removes any squatter. While the page is open, glance at the recovery settings. A forwarding rule or a recovery number you didn’t add is the one finding that upgrades this from errand to incident.
Step 4: Rotate recovery codes if 2FA was in scope (5 minutes)
If the breached account carried 2FA and the breach touched account data rather than just an email list, regenerate its recovery codes. The old set becomes invalid, and the new set goes into the manager’s notes, exactly where the originals lived (3.4). Cheap insurance against the case where stored codes were part of the haul.
If it’s worse than a breach notice
This drill covers your data leaking from a company. If what you’re looking at is evidence that someone is in an account — mail you didn’t send, money moved, settings changed — that’s a different playbook, and the Safety Center owns it. Start at I think I was scammed, which routes to step-by-step recovery guides for email takeover, SIM swap, and remote-access cases. Know those pages exist today. Bookmark them, and with luck you’ll never need the bookmark.
Twenty minutes, four steps, one bookmark. Next: the accounts where the stakes are actual money, and the five levers that protect them.