Cyna
Crisis and continuity · 6 min read

What is a cybersecurity incident?

A cybersecurity incident compromises the availability, integrity or confidentiality of data or services. The NIS2 definition, examples and reporting thresholds.

Analyst triaging a security alert into an incident

A cybersecurity incident is an event that compromises the availability, authenticity, integrity or confidentiality of data, or of the services that run on information systems. That is the definition used in the NIS2 Directive (Article 6). A hijacked account, files encrypted by ransomware or a data leak are incidents; a mere alert is not, at least not yet.

This article is part of our incident response series. For the full picture, see What is incident response?.

The official definition, in plain English

NIS2 defines an incident as an event compromising the availability, authenticity, integrity or confidentiality of stored, transmitted or processed data, or of the services offered by, or accessible via, network and information systems. Four properties are at stake:

  • Availability: the service or data cannot be reached (encrypted servers, blocked email, denial of service).
  • Integrity: data has been changed without authorisation (bank details altered on an invoice, tampered configuration).
  • Confidentiality: data has been seen or copied by someone who should not have it (exfiltration, a mailbox read by a third party).
  • Authenticity: you can no longer trust where an action or message came from (spoofed identity, an account used by an attacker).

NIST takes a similar line in SP 800-61 (Revision 3, April 2025): an incident actually or imminently jeopardises the security of information or a system, or breaches a security policy.

Event, alert, incident: keeping them apart

An IT estate generates events all the time (logins, file changes, network traffic). Some trigger an alert because they look malicious. An alert only becomes an incident once analysis confirms that a compromise has happened or is under way.

TermWhat it isExample
EventAny observable trace of activityA Microsoft 365 sign-in
AlertAn event flagged as suspicious by a tool or ruleSign-in from an unusual country
Near miss (NIS2)An event that could have compromised the system but was preventedPhishing blocked before the click
IncidentA confirmed compromiseAccount used by an attacker to send fraudulent invoices
Significant incident (NIS2)An incident with serious consequencesProduction down for several days
Personal data breach (GDPR)An incident affecting personal dataCustomer file copied

That triage is what a SOC does: sort alerts, discard false positives and confirm real incidents. See What happens when a managed SOC detects an attack?.

When an incident becomes “significant” under NIS2

For entities in scope of NIS2, the directive provides for the reporting of significant incidents. Article 23(3) sets two criteria. An incident is significant if it:

  1. has caused or is capable of causing severe operational disruption of services or financial loss for the entity;
  2. has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.

The directive then provides for an early warning within 24 hours, an incident notification within 72 hours and a final report within one month. National laws set out the detail and the authority to notify; as of 13 September 2026, France had not yet adopted its transposition law. See Is incident response mandatory?.

Personal data breaches

The GDPR has its own concept: the personal data breach (Article 4(12)), meaning the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. Where it poses a risk to individuals, Article 33 provides for notification to the supervisory authority within 72 hours of becoming aware of it. A single incident can therefore fall under both NIS2 and the GDPR.

Some real-world examples

  • Ransomware encrypts a small business’s file servers.
  • A Microsoft 365 account is compromised and used to phish customers.
  • An attacker exploits a flaw in an internet-facing firewall.
  • A former supplier still logs in through a forgotten account.
  • A customer database turns up for sale on a forum.

For a full breakdown, see What types of cybersecurity incidents are there?.

Why getting the classification right matters

Reporting deadlines run from the moment the organisation becomes aware of the incident. Fast triage means the right people are brought in on time: the response team, senior management and, if the incident escalates, a crisis team. See Incident response vs crisis management.

Conversely, treating every alert as an incident wears teams out. Hence the value of continuous monitoring that does the sorting around the clock, backed by a CERT that takes over once an incident is confirmed. See CERT, CSIRT and SOC: what are the differences?.

Talk to an expert

Want to know how your alerts, or your clients’, are triaged? If you already work with a Cyna partner, they are your first point of contact. Otherwise, get in touch.

Under attack? Report an incident: Cyna’s on-call team is available 24/7.

Frequently asked questions

Is a blocked phishing attempt an incident?

Usually not, as nothing was compromised. NIS2 calls this a near miss. It is still worth logging, because a run of targeted attempts can be the prelude to a more elaborate attack.

Is a hardware failure a cybersecurity incident?

It can be in the broad NIS2 sense, which covers any event compromising service availability whatever the cause. In practice, whether the cause is malicious decides who handles it: IT operations or the incident response team.

Who decides that an event is an incident?

Initial triage is often done by a SOC or the MSP. The final call, and above all the decision to report to an authority, usually rests with the affected organisation, supported by its legal adviser where needed. See Who should you contact after a cyberattack?.

Should minor incidents be recorded?

It is advisable. The GDPR (Article 33(5)) provides for every personal data breach to be documented, even when it is not notified. Beyond that, an incident log helps spot trends and shows that incidents are being handled.

Sources & methodology
  1. Directive (EU) 2022/2555 (NIS2), Articles 6 and 23, EUR-Lex
  2. Regulation (EU) 2016/679 (GDPR), Articles 4 and 33, EUR-Lex
  3. NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, April 2025

This article provides general information for guidance only. It is neither legal advice nor a contractual commitment from Cyna: service terms are those of the contract agreed through your partner MSP. For any regulatory question, consult your legal adviser.

Ready to sign

The SOC your clients
will ask for tomorrow.

Let's plug in your first line in 30 minutes. Personalised demo, quote within 24h, end-to-end human support.

Reply within 24hISO 27001 certified24/7 managed SOC