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.
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.
| Term | What it is | Example |
|---|---|---|
| Event | Any observable trace of activity | A Microsoft 365 sign-in |
| Alert | An event flagged as suspicious by a tool or rule | Sign-in from an unusual country |
| Near miss (NIS2) | An event that could have compromised the system but was prevented | Phishing blocked before the click |
| Incident | A confirmed compromise | Account used by an attacker to send fraudulent invoices |
| Significant incident (NIS2) | An incident with serious consequences | Production down for several days |
| Personal data breach (GDPR) | An incident affecting personal data | Customer 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:
- has caused or is capable of causing severe operational disruption of services or financial loss for the entity;
- 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.
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.