Accountability should sit with leadership, security owners, and managers together. Employees need a clear reporting path, but the organisation is responsible for defining it, communicating it, and making escalation safe and easy. If nearly half of staff know about an attack and do not report it, the control failure is cultural and procedural, not just individual.
Who carries the reporting burden when staff stay silent?
Accountability for non-reporting is shared, but it does not start and end with the individual employee. Leadership is accountable for setting expectations, managers are accountable for reinforcing them, and security teams are accountable for making reporting simple, trusted, and actionable. The question is less about blame than whether the organisation has built a reporting culture that turns suspicious activity into timely response. When that chain fails, the weakness is usually in governance and operating practice, not just awareness.
For a cyberattack or suspicious activity to be reported quickly, people need to know what counts as reportable, where to send it, and what happens next. That is why incident communication is part of security governance, not an optional awareness exercise. CISA’s public guidance on cyber threats and advisories is a useful reminder that detection and escalation depend on clear reporting pathways, not just technical controls. In practice, many security teams learn about a suspicious event only after employees have assumed someone else would raise it.
How accountability should be assigned in practice
In a healthy reporting model, accountability is layered. Employees have the duty to report what they see. Managers have the duty to create a local environment where reporting is expected and not punished. Security or incident response owners have the duty to receive, triage, and act on reports. Senior leadership owns the policy, the resourcing, and the tone that determines whether staff believe reporting is worth the effort.
This matters because silence after detection is often a process failure. If staff do not report suspicious email, unusual login prompts, or signs of compromise, the organisation loses time, evidence, and containment opportunity. The issue is not always lack of training. Often it is uncertainty about severity, fear of being wrong, or frustration that prior reports disappeared into a black hole. A reporting process only works when the expected action is obvious and the response is visible.
- Define what must be reported in plain language, including low-confidence suspicions.
- Give staff one obvious route for escalation, with backup channels when normal systems are unavailable.
- Ensure incident owners acknowledge reports quickly so employees know the signal was received.
- Track whether managers reinforce reporting norms or quietly discourage escalation.
Where this guidance breaks down is in organisations that treat reporting as a one-way obligation without a functioning response path; in that case, staff will usually stop reporting even if they were trained to do so.
When silence becomes a control failure rather than an individual mistake
Tighter reporting expectations often increase operational overhead, requiring organisations to balance speed of escalation against false alarms and staff fatigue. That tradeoff is real, but it does not remove accountability from leadership. The practical question is whether the organisation has made it safe for people to raise concerns early, even when they are not certain a real incident is underway.
There are a few common edge cases. In heavily distributed or remote environments, reporting failures often reflect weak local management rather than policy absence. In high-pressure teams, staff may suppress reporting because they think it will be seen as poor judgement. In some organisations, repeated unclosed tickets or slow responses teach employees that reporting has no value. Those are governance failures, and they are usually more damaging than a single missed report.
There is also a distinction between not knowing and choosing not to act. If the organisation has not clearly explained the reporting process, accountability for the lapse sits primarily with leadership and control owners. If the process is clear and the employee deliberately withholds a report, individual accountability matters too. But even then, the broader question remains whether the culture rewarded silence more than escalation.
Practitioners should treat repeated non-reporting as a signal that the control design is not working, not as proof that staff simply need more reminders. That is especially true when people can describe the suspicious event after the fact but did not feel able to act at the time.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Reporting failure is a governance and accountability weakness affecting risk oversight. |
| DE.CM-01 — Monitoring for Anomalies and Events | Employee reports feed detection when technical monitoring misses suspicious activity. | |
| RS.CO-02 — Communications | Clear, trusted reporting paths are essential to incident communication and coordination. | |
| Recommendation — Assign reporting ownership and escalation duties so suspicious activity reaches decision-makers quickly. Use incident reports as a monitored detection input and triage them with defined response times. Define and test reporting channels so staff can escalate suspicious activity without ambiguity. | ||
| CIS Controls v8 | 17.2 — Establish and Maintain an Incident Response Process | Non-reporting directly affects incident response intake and organisational coordination. |
| 6.2 — Establish and Maintain a Secure Configuration Process | Policy-backed process clarity reduces friction and inconsistency in reporting paths. | |
| 14.1 — Establish and Maintain an Awareness and Training Program | Staff need to recognise what must be reported and how quickly it should happen. | |
| Recommendation — Document who receives reports and how escalation moves from intake to response. Standardise the reporting workflow so employees have one reliable escalation route. Train employees to recognise suspicious activity and report it immediately through the approved channel. | ||
| MITRE ATT&CK | T1566 — Phishing | Suspicious activity reporting often begins with phishing or lure recognition. |
| T1078 — Valid Accounts | Suspicious login prompts or account misuse should be escalated as possible valid-account abuse. | |
| Recommendation — Treat reported phishing as actionable telemetry and enrich it for broader hunting. Investigate user-reported account anomalies for signs of unauthorized valid-account use. | ||
Practitioner Guidance
What to prioritise: Make reporting the easiest action in the workflow, not an extra task. The first fix is usually clarity: staff should know exactly what counts as suspicious, who receives it, and how fast the organisation responds.
What to verify: Test whether reporting is actually usable under pressure. A policy that exists on paper but cannot be used from the employee’s normal tools, shift pattern, or access level will fail at the moment it matters.
Decision rule: If people are failing to report because the process is unclear or unrewarded, treat it as a control design issue. If they are clearly instructed and still suppressing known activity, treat it as a conduct and accountability issue as well.
Practitioner takeaway: The strongest reporting programmes do not rely on blame; they make escalation normal, visible, and low-friction, then hold leaders accountable when that path is not trusted or used.
Related resources from NHI Mgmt Group
- Who is accountable when suspicious activity is discovered after deposits have already been accepted?
- Who is accountable when a third-party notices suspicious identity activity first?
- Who is accountable when suspicious activity is missed in an AML programme?
- Who is accountable when enhanced due diligence reveals suspicious activity?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
