Reportable Incident

Expanded Definition

A reportable incident is not just any security event. It is an event that crosses a defined threshold for notification under law, regulation, contract, or internal policy. In practice, that threshold may be based on confirmed compromise, material service impact, exploitation of a known weakness, loss of availability, or risk to users and dependent services. In the EU Cyber Resilience Act context, reporting is tied to the severity and exploitability of the issue, so a vulnerability may become reportable only once there is evidence that it is actively exploited or likely to create serious harm. For NHI and AI systems, the question increasingly includes whether secrets, service accounts, model access, or agent tool permissions were abused in a way that creates downstream impact. The distinction matters because incident classification drives who is notified, how fast, and with what evidence. For the regulatory baseline, practitioners often cross-check against ENISA guidance on DORA and the reporting logic described in the EU AI Act resource hub when AI systems are involved. The most common misapplication is treating every detected anomaly as reportable, which occurs when teams skip threshold analysis and classify technical alerts as external-notification events.

Examples and Use Cases

Implementing reportable-incident handling rigorously often introduces a triage burden, requiring organisations to balance faster notification against the cost of investigating incomplete evidence.

• A product vulnerability is discovered, but it is only reportable once threat intelligence or logs show real exploitation rather than theoretical exposure.
• A cloud service outage affects customers, and the incident becomes reportable because contractual notice windows and regulatory materiality thresholds are triggered.
• An AI assistant is manipulated into disclosing credentials or producing unsafe actions, and the event is escalated as reportable because it affects control integrity and user trust. The Anthropic report on first AI-orchestrated cyber espionage campaign is a useful reference point for how AI-enabled abuse can change incident classification.
• A privileged service account tied to an NHI is hijacked, and the incident becomes reportable because secrets exposure creates lateral movement risk and possible customer impact.
• A regulated software update reveals a serious weakness in a connected device, and the organisation must decide whether the issue meets the external-notification criteria under the CRA timeline.

For incident teams, the core task is to separate internal security events from those that trigger formal disclosure duties. That often means mapping severity, exploitability, data sensitivity, and operational impact to the relevant reporting rule before making a notification decision.

Why It Matters for Security Teams

Security teams that misunderstand reportable incidents can miss statutory deadlines, overreport low-value events, or send inconsistent notifications that erode trust. The practical risk is not only legal exposure. Misclassification can also break forensic preservation, confuse executive decision-making, and create conflicting messages across legal, privacy, product, and operations functions. In identity-heavy environments, reportability often hinges on whether compromised secrets, delegated tokens, federation trust, or privileged machine identities were used to access sensitive systems. That makes NHI governance a direct part of incident readiness, not a separate discipline. When agentic AI is part of the environment, a reportable incident may emerge from tool misuse, prompt injection, or unauthorized action taken by an autonomous system with execution authority. Guidance from CISA’s Known Exploited Vulnerabilities Catalog and ISO/IEC 27001 helps teams align operational triage with documented control expectations. Organisations typically encounter the true cost of a reportable incident only after a regulator, customer, or partner asks why notification did not occur on time, at which point the threshold decision becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Who is accountable when a reportable CMMC incident affects CUI?
• Who is accountable when a reportable cyber incident affects CUI in GCC High?
• Why is NHI ownership attribution important for incident response?
• How do attackers turn a supply-chain incident into wider NHI compromise?