To let people report a security concern, you need one named route, a short list of what to include, a named role that receives it, an acknowledgment that the report arrived, and a log entry for each one. One route, not four. The most common reason concerns go unreported is not reluctance; it is that nobody is certain where to send them, so the message gets sent to whoever seems closest and then disappears.
This article is general information about process and recordkeeping. It is not legal, employment, compliance or security advice. Anything that touches employment terms, how a report about a person is handled, or what may be monitored belongs with an employment attorney and your organization’s HR advisors. Which obligations apply to you varies by organization, industry and jurisdiction.
Pick one named route to report a security concern
Multiple routes feel accommodating and work badly. Each one needs monitoring, each one has a different record format, and the existence of options is itself a reason to hesitate. Choose one and make it the answer to the question every time.
Three options that work, in rough order of how easy they are to maintain:
- A dedicated internal address. One mailbox, monitored by a named role rather than an individual, with at least two people able to see it so it is never unwatched.
- A short form. A handful of fields matching the list below, submitting into one place. The advantage is that the fields prompt the person for what is useful; the cost is slightly more friction than writing a message.
- A named person plus a backup. Smallest organizations only. State both names and say plainly that either is fine.
Whichever you pick, publish it in the four places people actually look: the onboarding sheet, the acceptable use document, wherever your internal process notes live, and the standing agenda of your awareness sessions. A route published once in a message a year ago is not published.
Keep a quiet secondary path for the case where the primary route is itself the problem, and name it in the same breath rather than making people work it out. One sentence is enough.
What to ask someone to include when they report a security concern
Ask for little. The point of the prompt list is to make the report easy to write, not to screen it. A report missing half the fields is still a report you want.
Four things, and treat all four as optional:
- What they saw or did, in their own words. No structure required.
- When it happened, approximately. “Earlier this morning” is usable.
- What systems, accounts, devices or documents were involved, if they know.
- What they have already done, if anything. This one matters most for the person receiving it.
State in the same place that an incomplete report is welcome and that they should not wait to gather detail before sending it. Waiting to assemble a tidy report is the behavior you least want, and the only reliable way to discourage it is to say so in writing next to the route.
Say explicitly that reporting something that turns out to be nothing is the correct outcome, not a wasted message. Most reports are routine and that is the system working.
Who receives it, and what they do first
Name a role, not a person, and name a backup role. The receiving role needs to be someone who can either act or escalate without asking permission first; a route that lands with someone who has to find an authorizer is a route with a stall built into it.
The receiver’s first three actions, in order:
- Acknowledge that it arrived. Short and plain. Thank them, confirm you have it, and say who is looking at it.
- Write the log entry. Before any assessment, so the record exists even if the matter resolves in ten minutes.
- Decide whether it needs anyone else, and if so, bring them in and note in the log who was brought in and when.
Acknowledgment is the step that determines whether the route gets used again. Confirm receipt without attaching a timeframe to what happens next. Promising a window you may not meet is worse than promising nothing, and the person reporting mainly wants to know their message did not vanish.
Two rules for the receiving role. Keep the circle small and need-to-know, particularly where the report concerns a person. And make a decision about who handles it rather than leaving it in a shared mailbox with everyone assuming someone else has it.
Log every report the same way
One row per report, in one place, in a format that does not change. The log is the deliverable, and it is genuinely useful: it tells you which of your processes keeps generating confusion.
| Field | What goes in it |
|---|---|
| Reference | A simple sequential number |
| Date received | The date the report arrived |
| Received by | The role that took it |
| Summary | One or two sentences, factual |
| Systems or items involved | As stated in the report, or unknown |
| Who was brought in | Names or roles, with dates |
| Action taken | What was done, in plain language |
| Date closed | The date it was closed out |
| Process note | Anything to change as a result |
The last field is what makes the log worth keeping. When three reports in a quarter all come from the same unclear step in a process, that is a process to fix rather than three unrelated events, and the pattern is only visible if the log records it.
Keep the log factual and limited to what happened. Where a report concerns a person’s conduct, the log entry records the administrative facts and the matter itself goes to your HR advisors and, where appropriate, an employment attorney. Do not use the log as a place to record judgments about people.
Review the log quarterly. Read the process notes column and nothing else first, then decide whether anything on it is worth acting on this quarter.
Make it clear that reporting early is always right
This is a statement you have to put in writing, in the same place as the route, because nobody infers it.
Write it plainly: reporting a concern early is always the right move, a report that turns out to be nothing is still the right call, and raising something will not be held against the person who raised it. Put the sentence in the acceptable use document, on the onboarding sheet, and in the awareness session that covers reporting. Repetition in different places is what makes it believable.
Then make the process match the sentence. Three things undo a well-written statement faster than anything else:
- Acknowledging some reports and not others. Every report gets acknowledged, including the ones that turn out to be nothing.
- Asking why someone did not notice sooner. The question produces nothing useful and makes the next report slower.
- Treating a self-reported mistake differently from one someone else noticed. Self-reporting is the behavior you most want, and people read how it is handled very closely.
Where a report involves something that touches employment terms or disciplinary matters, the handling of that is not a process question and should be worked out with an employment attorney and your HR advisors in advance, so that the receiving role is not improvising in the moment.
Getting the route to report a security concern running
Pick the route today, name the receiving role and a backup, write the four-item prompt list and the one-sentence statement about reporting early, and publish all of it in one place. Add the line to your onboarding sheet so every new person sees it in their first week. Start the log with a header row and leave it empty.
What this gives you is clarity about where concerns go and a retrievable record of what was reported and what was done. It does not prevent anything, and it should not be described internally as though it does. A named route that people use, with a log behind it, is a sound piece of process in its own right. For a reporting route one-pager and a copy of the concern log, see the Free Resources page on this site.