When to Declare an Incident

One of the most consequential decisions in cyber security is knowing when to escalate a security event from “something to investigate” to a formally declared incident. Declare too late and the threat has time to spread, evidence is lost, and regulatory timelines are compressed. Declare too early on every minor alert and you create response fatigue, wasting resources and eroding confidence in the process.

Getting this balance right requires predefined criteria — not gut feeling in the moment. Your organisation needs clear, documented thresholds that remove ambiguity and empower your team to act quickly.

Events vs Incidents

Not every security event is an incident. Understanding the distinction is fundamental:

• Security event: Any observable occurrence in a system or network. A failed login attempt, an antivirus alert, a firewall block — these are all events. Most are routine and handled automatically.
• Security incident: An event, or series of events, that indicates a genuine threat to the confidentiality, integrity, or availability of your systems or data, and that requires a coordinated response beyond normal operations.

The challenge is that many incidents begin as ordinary-looking events. A single phishing email is an event. That same phishing email, once a user has clicked the link and entered their credentials, becomes an incident requiring investigation and response.

Defining Declaration Criteria

Your IR plan should include specific criteria that trigger a formal incident declaration. These typically fall into categories:

1. Confirmed compromise. Evidence that an attacker has gained unauthorised access to systems, accounts, or data. Examples: compromised credentials confirmed through log analysis, malware detected on a production system, unauthorised data exfiltration observed.
2. Significant business impact. Any event that disrupts critical business operations, affects customer-facing services, or threatens data the organisation is legally obligated to protect.
3. Regulatory trigger. Any event that may require notification to a regulator, such as a potential personal data breach under GDPR or a network disruption affecting essential services under NIS2.
4. Ransomware or destructive attack. Any indication of ransomware deployment, data destruction, or extortion should be immediately declared as an incident — these threats escalate rapidly.

Severity Levels

Once an incident is declared, it should be assigned a severity level that determines the scale and urgency of the response. A common three-tier model:

• Critical (P1): Active, widespread attack affecting core business operations or involving confirmed data breach of sensitive/personal data. Full IR team activated. Executive sponsor notified immediately.
• High (P2): Confirmed compromise with limited scope, or significant threat that could escalate. Core IR team activated. Executive sponsor notified within one hour.
• Medium (P3): Suspicious activity requiring investigation but no confirmed compromise or immediate business impact. Technical team investigates. Incident Commander monitors.

Action Steps

• Review your IR plan for specific, written incident declaration criteria — not vague guidelines.
• Confirm that severity levels are defined with clear escalation requirements for each level.
• Ensure frontline staff (help desk, SOC analysts) are trained on when and how to escalate events.
• Test the declaration process in your next tabletop exercise — present ambiguous scenarios and see if the team reaches consistent decisions.