Give support staff a one page card: how to recognize a security report, a safe holding reply, what never to do, and where to forward it the same day. A researcher who writes to the wrong inbox should still reach the security team within hours.
Why this matters
Researchers who cannot find a security contact try whatever is available: the contact form, web chat, social media, a phone number. OWASP's guidance lists exactly those as common fallbacks, and recommends that frontline staff monitoring contact addresses, chat and phone lines know how to handle security reports and who to escalate to. If your policy and security.txt file are easy to find, fewer reports arrive this way, but some always will.
What a security report looks like
Teach staff to notice these signals:
- the word vulnerability, exploit, bypass, injection or proof of concept
- a message that says "I found a way to see other customers' data"
- a screenshot of an admin page or an error with internal paths
- an email that mentions disclosure, bounty or deadlines
- a customer who says their account was accessed by someone else
That last one may be an incident, not a research report. The card should say that account takeover reports go to the incident route.
The card
| Step | What staff do |
|---|---|
| 1 | Do not try the steps described |
| 2 | Do not discuss details in public channels or social replies |
| 3 | Reply with a holding message |
| 4 | Forward the full message to the security address today |
| 5 | Mark the ticket private and add a note with the forward time |
| 6 | Do not promise a reward, a fix date or a CVE |
A safe holding reply
Keep it plain: thank them, say the message has been passed to the security team, and say someone will write from the security address. Avoid asking for more technical detail in the support thread. Let the security team ask, because they can offer a better channel.
Practice with a drill
Once a quarter, send a harmless fake report to a support inbox and time how long it takes to reach the security owner. The goal is under one business day. If the drill fails, change the card, not the person.
Public posts and social media
Someone may post a vulnerability publicly on social media or in a community forum. Staff should not argue or ask for details in the thread. OWASP advises requesting details for a relevant member of staff rather than sharing vulnerability details with whoever answers first, especially over social media. Move the conversation to the security address and tell the poster politely.
Link it to your policy
Your disclosure policy should say how to report. The support card should say the same, so staff and researchers hear the same answer. See who should own the security inbox for the receiving side.
Quick check
Should support ask the reporter for a proof of concept?
No. Let the security team ask. Support may not be able to store or handle sensitive material safely.
What if the report seems like spam?
Forward it anyway. The security team can discard it faster than support can judge it.
Sources
Last reviewed: 19 October 2026.
