Dark-Web Alert Response Checklist
A practical checklist for responding to exposed credentials, leaked company information and other dark-web findings.
A dark-web alert may indicate that an email address, password, authentication token, company document or other sensitive information has appeared in criminal data. The alert must be validated before conclusions are drawn, but it should not be ignored.
Treat a dark-web alert as intelligence to investigate, not automatic proof of an active breach. Validate the finding before drawing conclusions.
Step 1 — Record the Alert
- □ Date and time received
- □ Monitoring provider
- □ Alert reference
- □ Affected company or domain
- □ Affected account or asset
- □ Type of information exposed
- □ Alleged source
- □ First-seen date
- □ Confidence or severity rating
- □ Screenshot or evidence reference
- □ Response owner assigned
Step 2 — Validate the Finding
- □ Confirm the identity belongs to the organisation
- □ Confirm whether the account still exists
- □ Confirm whether the employee still works here
- □ Confirm whether the domain remains active
- □ Confirm whether the data appears genuine
- □ Check whether the exposure is historic
- □ Check whether the result is duplicated
- □ Check for similarly named organisations
- □ Check whether the source is credible
- □ Record any uncertainty
Step 3 — Secure the Account
- □ Disable account where necessary
- □ Reset password to a unique password
- □ Revoke active sessions
- □ Revoke refresh tokens
- □ Remove app passwords
- □ Review MFA methods
- □ Remove unknown authentication methods
- □ Review account recovery details
- □ Confirm MFA is enabled
- □ Review privileged access
A password reset is not enough if an attacker holds an active session, authentication token or infected device.
Step 4 — Review Activity
- □ Check recent sign-ins
- □ Check unfamiliar devices
- □ Check impossible travel
- □ Check failed login attempts
- □ Check mailbox forwarding
- □ Check inbox rules
- □ Check delegated access
- □ Check OAuth app permissions
- □ Check recent password changes
- □ Check security-information changes
- □ Check administrative activity
Step 5 — Check the Device
- □ Identify the device used by the account holder
- □ Check for information-stealing malware
- □ Review endpoint security alerts
- □ Review browser extensions
- □ Review installed applications
- □ Isolate where compromise is suspected
- □ Preserve evidence
- □ Rebuild if confidence cannot be restored
- □ Avoid entering new passwords on a suspected infected device
Step 6 — Assess Exposed Data
- □ Password
- □ Username or email address
- □ Session cookie
- □ Authentication token
- □ Personal data
- □ Customer data
- □ Employee data
- □ Financial information
- □ Source code or API key
- □ VPN or remote-access details
- □ Confidential documents
- □ Other
Step 7 — Escalate
- □ Incident-response lead informed
- □ Senior management informed
- □ IT or security provider informed
- □ Data-protection lead informed
- □ Legal adviser informed
- □ Cyber insurer informed
- □ Suppliers informed where relevant
- □ ICO notification assessed
- □ Police or Action Fraud advice considered
- □ Communications plan activated where required
Step 8 — Contain Related Risk
- □ Search for password reuse across other accounts
- □ Rotate related credentials
- □ Review shared accounts
- □ Review similar usernames
- □ Review former-employee accounts
- □ Review supplier access
- □ Check other domains
- □ Check remote-access services
- □ Review privileged accounts
- □ Block malicious infrastructure where appropriate
Step 9 — Document the Outcome
- □ Alert confirmed
- □ Alert unconfirmed
- □ False positive
- □ Historic exposure
- □ Active compromise identified
- □ No evidence of compromise
- □ Accounts secured
- □ Sessions revoked
- □ Devices reviewed
- □ Data-breach assessment completed
- □ Follow-up actions assigned
- □ Closure approved
Step 10 — Prevent Recurrence
- □ MFA strengthened
- □ Password policy reviewed
- □ Password manager adopted
- □ Old accounts disabled
- □ Privileged access reviewed
- □ Devices remediated
- □ Endpoint controls improved
- □ Monitoring profile updated
- □ Alert routing confirmed
- □ Staff guidance issued
- □ Incident exercise scheduled
- □ Next review date recorded
Record: owner · date · actions · action owner · next review date.
Want the full explanation?
Read our Technology Intelligence article for a plain-English explanation of what Google has launched, how AI-assisted dark-web monitoring works and what businesses should do when an alert appears.
Plain-English Takeaway
Treat a dark-web alert as intelligence to investigate, not automatic proof of an active breach. Confirm the affected account or asset, change exposed credentials, revoke active sessions, investigate the device and review sign-in activity. Escalate serious findings, preserve evidence and record exactly what was checked and changed.
Downloadable guide
Download the Dark-Web Alert Response Checklist
A printable checklist for validating a dark-web finding, securing exposed accounts, reviewing activity and documenting the response.
Download PDFFree download. No email address required.
Want the full business explanation?
The Technology Intelligence article covers why this matters, where it helps and what to watch out for.
Read the full Technology Intelligence articleRelated Knowledge Centre resources
Cyber Resilience Readiness Guide
Review your critical systems, IT suppliers, incident response, backups and business-continuity arrangements.
View guide