The ACN baseline guidance describes significant-incident typologies through a practical model built on three elements: condition, compromise, and object of compromise. This model helps organizations decide when notification obligations are triggered and how incidents should be classified consistently.
Sources: ACN baseline reading guide, ACN baseline obligations determination
Key takeaways
- The typology model supports repeatable qualification of significant incidents.
- The triggering condition is linked to the entity having evidence of the incident.
- Compromise type and object of compromise determine how the event is framed in notification workflows.
- Details for each incident code are defined in official baseline documentation.
Sources: ACN baseline reading guide
Model components in practice
1. Condition
The condition is the circumstance that triggers notification obligations. In operational terms, this is tied to the moment the organization acquires evidence of a relevant incident.
2. Compromise
Compromise describes the nature of the security event (for example, loss of confidentiality, loss of integrity, or service-level violation, depending on the applicable typology).
3. Object of compromise
The object identifies what is impacted, such as data or service/network components, according to the incident typology in scope.
Sources: ACN baseline reading guide, ACN baseline obligations determination
How to use the model in operations
| Step | Operational question | Expected output |
|---|---|---|
| Evidence checkpoint | Do we have objective evidence of incident occurrence? | Timestamped evidence record |
| Typology mapping | Which compromise pattern applies? | Incident-type classification |
| Object identification | What asset/service/data set is affected? | Impact object statement |
| Decision support | Does the case meet notification criteria? | Escalation and notification decision |
Sources: ACN baseline reading guide
90-day implementation checklist
- Standardize incident records with explicit fields for condition, compromise, and object.
- Align SOC/CSIRT triage to the typology model before escalation decisions.
- Define evidence-quality criteria for "incident evidence acquired" checkpoints.
- Run simulation drills to test consistent typology assignment across teams.
- Maintain a decision log linking typology assessment to notification outcomes.
FAQ
Does the model replace technical investigation?
No. The model structures classification and notification decisions, while technical investigation remains necessary to determine scope and root causes. Source: ACN baseline reading guide
When does the notification clock start?
The timing references are tied to when the organization has evidence of a significant incident, as defined in official documentation. Source: ACN baseline reading guide
Where are code-level details (IS categories) defined?
Details are defined in the official call documentation and ACN baseline annexes. Source: ACN baseline obligations determination
Related guides in this series
Related reading
- NIS2 baseline obligations in practice: master overview for governance, controls, and incident operations
- NIS2 Article 25 in Practice: Incident Notification Obligations and Operating Timeline
- NIS2 Significant Incident IS-1: Confidentiality Loss Affecting Digital Data
- Aegister NIS2 Compliance Service
