A journal of trust,
identity & influence.

INSIDESocial engineering
← All stories
At workWorkplace guide

The first response to a security report can decide whether there is a second one

A reporting culture is built in ordinary replies, not awareness posters. Make it possible to say what happened before someone knows how serious it is.

Non-pixel editorial illustration of people passing a clear message through an open organizational doorway.
Original editorial illustration. Not a photograph or evidence of an individual incident.

A person has clicked something they now distrust. They do not know whether a page loaded, whether a sign-in completed or whether the message was genuine. Before reporting, they have another question: what will happen to them if they admit the uncertainty?

That moment is part of the security system. A technically excellent reporting address is not useful if employees expect humiliation, an argument about why they clicked or a form that requires answers they do not have. The first report should begin containment and clarification, not a test of the reporter’s expertise.

Useful first reportWhat happened, when and which account or device was involved.
Useful first replyAcknowledgment and a clear next step.
Useful reviewWhich conditions made the mistake possible or hard to report?

Start with the reporting experience

The UK NCSC’s security-culture principles call for quick, accessible routes to ask for help and fair treatment of innocent mistakes. The guidance also emphasizes feedback and learning. That is an organizational responsibility, not an instruction for an anxious employee to become braver on demand.

The following framework is our editorial application of that principle. It is not a certified incident-response procedure. Teams should adapt it to their systems, staffing and obligations, with responsibility for investigations remaining with the appropriate specialists.

Begin by trying the route as an ordinary employee. Can someone find it without access to the account they may have lost? Does it work outside the office? Can a contractor use it? Is there a clear alternative when the reporting tool itself appears in the suspicious message? Each question exposes a different barrier.

Ask for observations before conclusions

“Was this phishing?” is a reasonable question for the security team. It is a poor prerequisite for submitting a report. A person should be able to say “I am unsure” and still reach someone who can help.

The first intake can distinguish simple observable actions: received, opened, clicked, entered information, approved a prompt, downloaded, installed, paid, or shared a file. Those descriptions are imperfect but useful. They avoid forcing the person to choose a technical label such as session theft or malicious consent before anyone has examined the evidence.

Intake question What it helps establish What not to demand initially
Approximately when did this happen? A time window for investigation A perfectly reconstructed timeline
Which account or device was involved? Who can take appropriate containment steps Every device identifier from memory
What did you actually do? The likely type of exposure A confident diagnosis of the attack
Is the interaction still active? Whether immediate interruption is needed More engagement with the suspicious person
What records already exist? Available evidence Reopening a link to collect more

Make uncertainty an acceptable answer in each field. A required field that only permits precise answers can manufacture false precision. That is worse than an honest estimate because the responder may build the wrong timeline around it.

A short first-report template

Here is an illustrative template a team can adapt for its approved reporting channel:

I am reporting a message or interaction I am unsure about. It happened at approximately [time]. The account or device involved was [identifier]. I [describe the action]. The interaction [is / is not] still active. I have [existing message, screenshot or reference] available. Please tell me the next safe step.

This is original example wording, not a message from a real incident. It deliberately does not ask the reporter to include a password, one-time code, private customer record or identity document. Evidence collection should happen through the organization’s approved process, not by attaching everything to an ordinary group email.

A phone route may be necessary when the device cannot be trusted or the account is unavailable. Accessibility matters too: not everyone can complete a long written explanation under pressure. The objective is a usable first connection, followed by proportionate clarification.

The reply should reduce uncertainty

“Thanks for telling us. We have your report. Please stop using that link and keep the original message. We will contact you through [established route]” is more useful than silence or an immediate lecture. The exact instruction depends on the incident; the structure is acknowledgment, immediate guidance and a known next contact.

Do not promise a response time the team cannot meet. If there is no around-the-clock service, say which urgent route actually exists. An impressive-looking reporting portal with an unattended queue can create false confidence at precisely the wrong moment.

Avoid requests that resemble the attack being investigated. A responder who unexpectedly asks for a login code teaches the employee that security staff are allowed to override the rule. A good reporting process also explains how the employee can verify the responder.

Separate containment from the later review

During the immediate response, focus on understanding the exposure and limiting harm. The employee’s emotional state, workload and memory will not necessarily support a detailed retrospective at that moment. Returning later to examine the process is different from withholding urgent help until a complete explanation is available.

A review can ask whether the message matched a real workflow, whether an approval interface was understandable, whether the deadline was credible and whether the employee knew where to ask. Those questions create changes a team can implement. “Be more careful” rarely identifies an owner, a system change or a testable outcome.

Fair treatment does not mean ignoring deliberate misconduct. It means not treating every innocent mistake as misconduct or using a security report as permission for public humiliation. Organizations should make the distinction explicit through their established policies rather than leaving it to the mood of the first responder.

Measure friction, not just clicks

A falling report count is ambiguous. It might mean fewer suspicious messages, or it might mean that people no longer expect useful help. Similarly, a high report count can reflect a healthy willingness to ask, not a workforce that has become less capable.

Useful local measures might include how long it takes to locate the reporting route, how often a form is abandoned, whether reports receive acknowledgment and whether an incident leads to a documented process improvement. These are suggested diagnostic questions, not universal benchmarks or proof of causation.

Keep the measurement proportionate. Publishing individual “worst clicker” rankings can undermine the behavior the organization wants. Gather only the information needed for the security purpose, restrict access appropriately and explain how it will be used. Consult the relevant internal privacy and employment specialists when designing monitoring.

Close the loop without exposing the person

A short follow-up can tell the reporter whether the issue was resolved and whether any further action is needed. A broader lesson can be shared without distributing a person’s name, private correspondence or an embarrassing screenshot. Focus the lesson on the decision and the improved control.

The NCSC’s layered phishing guidance places user-facing measures alongside technical and operational defenses. Our reading is that reporting should connect those layers: the employee provides observations, responders investigate, and the organization changes a control where the evidence supports it.

For the workflow side, continue with help-desk identity resets. For a common source of silence, read manufactured urgency. A workable security culture gives people somewhere to take uncertainty before it becomes an avoidable delay.

Found a factual error or a source that has changed?

Send a correction →