To evaluate a breach report, ask six things in order: who is the source, what exactly was accessed, what are the dates, what is still unknown, which of your data or systems could be involved, and what the company has told customers to do. Answer those before you share the story or change anything.
1. Who is the source
A company statement, a regulator filing, a court document and a journalist quoting an anonymous person are four different levels of evidence. Note which one you are reading. A claim posted by the attacker is the weakest of all, because attackers have reasons to exaggerate.
If the story cites a primary document, find it. Reading the filing or the notice yourself takes five minutes and removes a layer of paraphrase.
2. What exactly was accessed
Look for nouns. "Systems" is vague. "A customer support database containing names and email addresses" is specific. Reports often swap one for the other as the story is retold, so check the original wording.
Write down the data types named: credentials, personal data, source code, internal documents, payment data. Each has a different consequence for you.
3. Which dates apply
A report usually carries three dates that people blur together: when the intruder got in, when the company noticed, and when it told the public. The gaps between them matter. If access began months before discovery, old credentials and tokens deserve a second look even if the public notice is recent.
4. What is still unknown
Good reports say what is not yet known. Early statements are often revised. Treat the first version as a snapshot and look for an update. If a report claims certainty about scope within a day or two, be a little skeptical in both directions.
5. Does it touch you
This is the question that decides your action. Are you a customer of the company? Do you use their product, their API keys, their package, their login provider? Do you share a vendor with them? If none of that is true, the story is interesting but not urgent.
If you are a customer, check what you have stored with them and whether any credentials of yours could be in the affected data.
6. What were customers told to do
Notices often contain the only concrete guidance: reset passwords, rotate keys, watch for phishing. Follow it, and add your own checks on top. The FTC guide for businesses notes that stolen credentials stay useful to attackers until they are changed, which is a good reason to rotate when in doubt.
Keep a short note of your answers. It becomes your record if someone asks later why you did or did not act.
Quick check
Should I act on a breach report the day it appears?
Act the same day only if you are a customer of the affected company or share a credential or key with it. Otherwise read, note, and revisit when the company issues an update.
Is an attacker claim enough to act on?
It is enough to start checking, not enough to announce. Verify against the company statement or a filing first.
Sources
Last reviewed: 19 October 2026.
