Data Breach Response 101.

Company data on the dark web usually means one of four things.

• Employee or customer logins.
• Files taken in a data breach.
• Access to your network that someone is selling.
• Stealer logs from infected devices.

You may learn about it from a monitoring alert, a security researcher, a customer, a journalist or a post on a leak site. Each source is a claim, not proof. The first job is to find out whether the claim is true.

This guide is the response side. For how the watching works, see the dark web monitoring entry.

Start small and calm. Name one person to lead and keep a written log of who did what and when.

• Save the original alert, post or message with its date and link. Take a screenshot too, because posts are often deleted.
• Ask for a data sample if the source offers one, and compare it with your own records. Real data matches your own records. Also check whether the same data already appeared in an older leak, because recycled data is often reposted as new.
• Do not pay, negotiate or buy the data back without legal and leadership approval. Paying does not guarantee the data is deleted.
• Do not open unknown files from the post on a work computer.

If the claim is real, treat it as a security incident and follow your incident plan. Our template is in the incident response plan template guide.

Now work out the size of the problem. Write down what the data contains, where it likely came from and how old it is.

• Logins: which accounts, which systems, and whether they have multi-factor authentication.
• Personal data: whose it is, in which countries, and what fields it holds.
• Secrets: API keys, tokens, certificates and passwords stored in files or code.
• Business files: contracts, source code and internal documents.

If the data looks like it came from an infected computer, the device matters as much as the account. A password reset will not help while the malware is still running. Check how leaked credentials are reused before you decide how wide to look.

Containment means limiting how the data can be used against you. Do the steps that match what you found.

• Reset the exposed passwords and end active sessions to cut off access through the stolen login.
• Revoke and replace exposed keys, tokens and certificates.
• Turn on multi-factor authentication for the affected accounts if it was missing.
• Isolate and clean infected devices, then reset the passwords saved on them.
• If a supplier or partner was the source, ask them for their findings and review the access they have.

Then look at your logs for sign-in attempts that used the exposed data, from the day it was likely taken until now.

Involve your legal or privacy lead early. They decide what the law requires and what to say.

Many laws require notice after a breach of personal data. Under the EU GDPR, for example, the organization responsible for the data (the controller) must tell its supervisory authority without undue delay. Where feasible, that is within 72 hours of becoming aware of a personal data breach. The duty does not apply when the breach is unlikely to put people’s rights and freedoms at risk. Rules differ by country and, in the United States, by state, so do not rely on a general guide for the reporting deadlines.

Plan messages for affected people, customers, partners, your insurer and staff. Keep them short and factual, and say what people should do, such as changing a password. Do not guess about the cause before you know it.

A leak rarely stays in one place. The same data can be reposted, sold again or combined with other leaks, so keep watching for it after the first response. For a comparison of the options, read Dark Web Monitoring Tools: What to Use and When.

Hold a short review once things are calm. Ask how the data got out, how long it took to notice, which step was slowest and what to change in your plan. Update the plan and run a practice drill.

Brandefense dark web monitoring matches findings to your domains, brands and staff so a team can start the steps above sooner.