Quick answer
A workable playbook has six stages: detect, validate, contain, verify, review, record. The two that get left out are validation — because acting on unconfirmed findings destroys the process's credibility — and session invalidation, because a password reset that leaves existing sessions alive does not remove the attacker. Route by severity, or the playbook will be ignored inside a month.
What this is for
A credential exposure is a claim that a username and password belonging to your organisation are in someone else's hands. It arrives from a breach-data finding, a vendor notification, an employee report, or your own logs.
The value of a playbook is not that it contains steps nobody could think of. It is that the steps are decided in advance, by someone with time to think, so that the person handling it at 6pm on a Friday is executing rather than improvising. Write it before you need it.
Adapt what follows. A ten-person startup and a regulated 500-person company need the same shape and very different detail.
Stage 1 — Detect
Sources worth wiring in, roughly in order of signal quality:
- Identity provider alerts. Impossible-travel, unfamiliar sign-in, repeated MFA prompts. Highest quality because they describe your systems.
- Breach exposure findings for company addresses. Tells you a credential may be circulating, not that anything happened. See which addresses to check.
- Vendor notifications when a supplier is breached.
- Employee reports. "I clicked something." Make this trivially easy to do and never punish it, or it stops arriving.
- Your own logs. Authentication failures spread thinly across many accounts is the population-level signature of credential stuffing; per-account failure counts will not show it.
Each source needs a named owner and a route in. A finding nobody sees is not a detection.
Stage 2 — Validate
Skipping this is the most common way these processes die.
An exposure report is a claim. Before acting, establish:
- Is the identity real and current? Does the address belong to a current employee, a departed one, or a mailbox nobody owns?
- What kind of exposure is it? An address alone is not a credential. A credential with a password is. A confirmed sign-in is a compromise. The three call for different responses, and the vocabulary is in exposure versus compromise.
- Which credential? The password from a breached third-party service, or a credential to one of your systems? These are different incidents.
- Is it current? A password exposed in a dataset from six years ago that has since changed is a finding to note, not an incident to run.
- Is there corroboration? Does anything in your own logs support the claim? Corroboration raises severity sharply.
Record the outcome even when it is "no action". A validation stage that only produces records when something is wrong looks, in hindsight, like a process nobody ran.
Stage 3 — Route by severity
Not everything is an incident. Define bands in advance and put them in the document.
Low. Address-only exposure, no credential, no corroborating signal. Action: note it, remind the person about phishing, move on. No account changes.
Medium. A credential appears in breach data, unconfirmed whether it was reused on company systems. Action: reset the corresponding company credential, verify MFA, ask the person about reuse. Timeframe: same working day.
High. A credential to a company system is exposed, or a privileged account is involved, or there is corroborating log evidence. Action: full containment below. Timeframe: immediately.
Critical. Confirmed unauthorised access, or exposure of an identity provider, cloud console, domain registrar or DNS administrator account. Action: containment plus incident escalation, including whoever owns your disclosure obligations. Timeframe: now, and wake people up.
The bands are what make the playbook survivable. Treating everything as critical means the next real critical arrives to an exhausted team.
Stage 4 — Contain
The order matters, and steps 2 and 3 are the ones most often missed.
1. Reset the credential
Force a change on the affected account. NIST's guidance in SP 800-63B-4 is that a change is required where "there is evidence that the authenticator has been compromised" — which is exactly this situation, and it is also why the same document tells you not to force rotation the rest of the time.
Screen the replacement against a blocklist of known compromised values, which NIST also requires. Otherwise you may accept another already-public password.
2. Invalidate sessions and tokens
This is the step that decides whether containment worked. An attacker with a live session does not re-authenticate; a password change alone leaves them signed in. Revoke:
- Active sessions in the identity provider and in each affected application
- Refresh tokens and long-lived access tokens
- OAuth grants and connected third-party applications
- Application-specific passwords
- Remembered-device or trusted-device flags, so MFA is genuinely re-required
- API keys and personal access tokens the account holds
If your platform supports a single "sign out everywhere" that covers tokens rather than just browser sessions, know in advance whether it actually does.
3. Check persistence in the account itself
Access survives a password change through configuration an attacker added:
- Mail forwarding rules and filters, especially ones that forward and delete
- Recovery email addresses and phone numbers
- Additional MFA enrolments
- Delegated access and mailbox permissions
- Newly created API credentials
Reviewing this is what separates containment from the appearance of containment.
4. Contain laterally
Where was this credential reused? Ask the person directly, and ask in a way that gets a truthful answer. Rotate any shared credential they knew. If they held privileged access, treat the systems they could reach as in scope until you have looked.
Stage 5 — Verify
Confirm rather than assume:
- MFA is enrolled, and a weaker fallback is not still available. CISA notes that SMS and push factors are susceptible to common bypass techniques and that phishing-resistant options should be the priority; what MFA does and does not stop covers the limits.
- The new credential is in place and the old one fails.
- Sessions are actually gone — sign-in logs should show re-authentication.
- No unexpected recovery methods or forwarding rules remain.
- The account is not locked out of legitimate use, because a person unable to work will route around your control.
Stage 6 — Investigate proportionately
For medium and above, establish what was accessible during the exposure window. Defensively, that means reading your own log sources: authentication logs, mailbox audit logs, file access and sharing events, administrative action logs, and outbound mail for signs of the account being used to phish others.
Two questions decide the rest: was anything accessed, and was anything taken. If personal data may have been involved, your disclosure obligations are engaged and that is a different process with its own clock — know in advance who owns it.
Stage 7 — Record
Short, consistent, and written while it is fresh. For every case, including the ones you closed as no-action:
- When and how it was detected
- What was validated, and the severity band assigned
- What was reset, revoked and checked
- What was found, or that nothing was
- Who did it, and what time it closed
- One line on anything that made it harder than it should have been
The last line is the one that improves the playbook. Three cases in, the pattern in it is your next project.
What to build before you need it
- A named owner and a deputy. An unowned playbook is a document.
- Pre-agreed authority to lock an account without waiting for a manager, at defined severities.
- A contact path to the identity provider admin outside working hours.
- A written list of privileged accounts. You cannot prioritise what you have not enumerated.
- A tested "sign out everywhere" procedure. Test it on a volunteer account before an incident, because platform behaviour varies more than documentation suggests.
- A no-blame reporting culture, which is a control and not a value statement: teams that punish reports get fewer reports, not fewer incidents.
Detection inputs
Breach exposure findings are one input to stage 1. Compromised runs point-in-time searches against a configured breach intelligence provider — one identifier at a time, with no scheduled re-checking and no domain-wide scanning — so it fits as a review you run, not a feed you consume. You can check an identifier; its coverage is the provider's, and a nil result means nothing was found in the data checked rather than that nothing exists.
For the upstream question of which addresses to run through it, see which addresses to check. For the subject as a whole, the breach exposure guide.