Treat it as a possible incident first and a research report second. Confirm what was accessed, contain the weakness, preserve evidence, and bring in your incident lead and counsel. Then reply to the researcher, ask them to stop and delete what they hold, and keep the thread open.
Why the routine changes
Most reports describe a flaw. This one describes a flaw that was already used on real data. CISA's directive reflects the distinction: its sample ranking includes an incident category for cases where confidentiality, integrity or availability has already been compromised. It also requires agency policies to include a statement prohibiting the disclosure of any personally identifiable information discovered to any third party, which is a useful idea for your own rules.
OWASP's guidance tells researchers to respect privacy and not to access or retain more data than needed to show the issue, and says personal data should be redacted before reporting. A researcher who followed that advice may have seen only a sample. Do not assume it, and do not assume the opposite.
First hour
| Step | Action |
|---|---|
| 1 | Alert your incident lead using your existing incident plan |
| 2 | Reply briefly to the researcher, thank them and ask for details |
| 3 | Reproduce in an isolated copy, not on production |
| 4 | Identify the vulnerable component and decide on containment |
| 5 | Preserve logs for the relevant period before any rotation |
| 6 | Involve your privacy and legal contacts early |
| 7 | Record every step with times |
This post is not legal advice. Notification duties depend on your jurisdiction, contracts and the data involved, and your counsel should decide them.
What to ask the researcher
- What exactly did you access, and how many records?
- When did you do it, and from which address?
- Did you copy or store any of it?
- Has anyone else seen it?
- Will you delete what you hold and confirm that?
Ask in a calm tone. A researcher who sees you as hostile may go public. A researcher who sees a competent team usually cooperates.
Contain and investigate
Closing the hole is the priority. Review access logs to learn whether anyone else used the same flaw. Researcher traffic usually looks like a small, clean pattern. Attackers look different, and their logs can show earlier use. Decide whether the weakness can be shut off by a configuration change while a full fix is built.
Communication discipline
Limit the circle to people who need to know. Do not discuss it in open chat channels. Do not speculate about the researcher's motives in writing. Do not threaten them. Our post on researcher testing limits, privacy and scope shows how to talk about boundaries in your policy before this happens.
After the case
Update your policy to say clearly what testing may touch, and what to do on seeing personal data: stop, report, and delete. Safeguard's compliance and evidence automation can help keep incident records and control evidence organized, though legal conclusions stay with your counsel. A free scan can also check your dependencies for known issues.
Quick check
Do we have to tell customers right away?
That depends on facts, law and contracts. Ask counsel immediately. Do not delay the investigation while waiting.
Should we treat the researcher as an attacker?
Decide on evidence and your policy. Good faith reporting with minimal access is different from copying data at scale.
Sources
- CISA BOD 20-01: Develop and Publish a Vulnerability Disclosure Policy
- OWASP Vulnerability Disclosure Cheat Sheet
Last reviewed: 19 October 2026.
