The report route: where a suspicious email goes, and what happens to it

The question a compliance lead asks after the second campaign is always the same: how do we raise the report rate? The answer is not a better poster or a sterner note from the CIO. It is infrastructure. Give people one place to send a suspicious message, somebody behind it who reads what arrives, and an answer when they do.

Most programmes measure the number before building the thing it measures. This is how to build it.

Why the report rate is the number that matters

A phishing programme produces several figures. Click rate, credential submission rate, time-to-click and repeat exposure describe the same event from different angles: how often the population failed. They are useful, and they are all retrospective. Report rate is the only measure in the set that reflects a behaviour the organisation actually wants somebody to perform.

It is also the only one that shortens anything. A click rate tells you, after the exercise, what proportion of staff would have been compromised; a report tells you while it is still happening that a message is in the estate. Time-to-first-report is the interval between a real phishing email arriving and somebody knowing about it, and that interval decides whether the response is containment or forensics.

CERT-In states the purpose of social engineering and process testing in one sentence: "The purpose is to evaluate overall awareness and the effectiveness of security processes, not to single out individuals" (CISG-2025-02 §15.2.2(iii), pp. 55–56). A report route is one of those security processes. Report rate and time-to-first-report are the two numbers that measure whether it works.

The obligations above the programme are measurement obligations. RBI requires a bank to "evaluate the awareness level of employees periodically", and requires an NBFC to run a "formal mechanism to measure and track the effectiveness of such training through periodic assessments or testing". SEBI asks regulated entities to "periodically assess level of employee cybersecurity awareness, for e.g., through phishing test success rate, etc." The table below gives the paragraph and page for each. A programme that can show its population learning to report is showing more awareness than one which can only show it clicking less.

A mailbox or a button

There are two ways to give people somewhere to send it, and the choice usually gets made on a licence rather than on the merits.

The button wins on friction and on data quality, and friction is the variable that moves the report rate. The mailbox wins on coverage: a route unavailable to contractors and to staff on unmanaged devices does not measure them, it excludes them. Publish both if you can. If you can carry one, make it the mailbox, which has no licensing dependency and no population it cannot reach.

Somebody has to read it

An unstaffed mailbox is worse than no mailbox. It does not merely fail to catch the real message; it teaches the population that reporting achieves nothing, and that lesson is durable. The report rate you go on to measure is an accurate measurement of what you built.

Ownership is a name, not a team. Four things should be settled before the route is announced.

1. Who reads it, and during which hours. Publish the hours honestly. A route read on working days between 09:00 and 18:00 is a real control; one advertised as always-on and read on Monday morning is a liability.
2. What triage decides. Each report resolves to one of a short list: simulation, real phishing, spam, or legitimate mail the user was right to query. Keep it short enough that two people classify the same message the same way.
3. What happens on a confirmed one. Search the estate for other copies, remove them, block the sending infrastructure, and establish whether anybody acted before the report arrived. One report is a sample from a delivery, not the delivery.
4. Where it escalates. Once a report is confirmed real it stops being an awareness matter and becomes an incident, handled under the incident response plan and whatever notification obligations bind the entity. A lookalike domain or an app impersonating the organisation belongs on a different path: takedown, which the RBI Directions place on banks through external service providers (Commercial Banks ¶148).

One design rule is worth holding even though nobody is auditing the route. CERT-In requires that testing of general staff use anonymised or statistical techniques, "ensuring no individual is personally identified or penalized" (§15.2.2(iii)). Hold the route to the same standard: the reporter's identity should travel no further than the person who replies, and never to a line manager as a performance signal.

The mailbox also accumulates forwarded messages, much of it personal data belonging to non-employees. The reasonable security safeguards of the DPDP Act apply to it (s.8(5)), as does the obligation to erase personal data "as soon as it is reasonable to assume that the specified purpose is no longer being served" (s.8(7)(a)). Set the retention period when you build the route.

Acknowledgement is the part everyone skips

A person who reports something and hears nothing back has learned that the route is a void. They will not report the next one, and the next one is the real one.

A working route sends two things: an immediate automatic receipt confirming arrival, and a human outcome saying what it turned out to be and what was done. Set a target for the second and treat a miss as a defect; same working day is achievable at most volumes.

Three rules govern what the acknowledgement says.

• Thank the report, not the accuracy. A false positive costs a minute of triage; a suppressed true positive costs the incident. Answer a wrong report as warmly as a right one, or the population starts filtering on your behalf and you never see what it filtered.
• Say what it was. "A real credential-phishing attempt; we have removed it from the other mailboxes it reached" turns one person's caution into a visible outcome.
• Never rank the reporters. A leaderboard builds the machinery of individual attribution, invites the negative version of the same list, and rewards volume over judgement.

One point applies only while a simulation is running. An automatic reply saying "this was a test" broadcasts the campaign to the whole population within minutes of the first report. Acknowledge receipt neutrally while the window is open, and reveal at the debrief.

What the route does to your numbers

Report rate and time-to-first-report exist as metrics only if the route exists. A programme that measures report rate before building a route is measuring the absence of a mailbox, and the improvement it records next quarter is the mailbox rather than the population.

Build the route, publish it, let it settle, then baseline. A change to the route is a change to the instrument: rates either side of a mailbox-to-button migration are not comparable, and any series spanning one should say so.

Fix two definitions in writing before the first campaign; both get computed inconsistently.

• Report rate is reporters as a proportion of the population that received the message, not of the population that clicked. Somebody who clicks and then reports counts in both, and the pair says more than either alone.
• Time-to-first-report runs from delivery, not from the start of the campaign. It estimates how long a real campaign would have run unobserved.

Duplicate reports of the same message are not noise. They are the breadth of the delivery, and they are how triage sizes what it is looking at before anyone queries the mail logs.

Hold four things: one address everyone can reach, a named owner with published hours, an acknowledgement that arrives, and written definitions of the two numbers before the first campaign runs. Without them, the report rate on the dashboard measures the route and not the workforce.