INC-003 Incident Classification and Escalation
Description
Incidents are classified by severity and type using a defined taxonomy. Classification determines escalation paths, notification requirements, and response SLAs. Criteria for classifying an event as a data breach or high-severity incident are documented and consistently applied. The taxonomy carries the external notification thresholds and criteria that bind the service, each stated as a measurable quantity or as an observable condition and, where a threshold is a proportion, with the population it is measured against and the system of record that population is read from, so a classification decision names every external trigger the incident crossed and the ones it did not. An attempted unauthorised access, use, disclosure, modification or destruction carries a band of its own, as does an interference with system operations that changed nothing, so an event with no effect is classified rather than closed unclassified. At a defined interval, closed incidents that fell below every threshold individually are grouped by apparent root cause and tested against those thresholds collectively, and a group that crosses one is classified as a single incident and carries what that classification requires.
Rationale
Consistent classification ensures the right people are notified at the right speed. Misclassification, particularly under-classification, is a major cause of delayed response and regulatory exposure. An external threshold is not a severity band: severity decides who is woken up, a threshold decides whether a submission is owed, and an organisation that cannot produce the population a proportional threshold is measured against cannot answer whether it had a reportable incident at all. That is why the population and its system of record are named in the taxonomy rather than worked out during the incident. The band for an attempt that changed nothing exists because more than one commitment makes such an event reportable, and an event with no effect otherwise leaves the process unclassified. Boundary: INC-005 holds what is submitted once a threshold is crossed, MON-010 measures the availability a threshold is compared against and keeps the service level objective, which is a commitment rather than a regulatory trigger, and INC-008 reviews one incident where the aggregation test here looks across closed ones and is not a review of any of them.
Applicability (9 profiles)
The band is now in the taxonomy. An attempted unauthorised access, use, disclosure, modification or destruction carries a band of its own, as does an interference with system operations that changed nothing, which is the reach of the 164.304 definition and the precondition for reporting such an event to the covered entity under 164.314(a)(2)(i)(C).
The taxonomy now carries the external notification thresholds and criteria that bind the service, with the population each proportional threshold is measured against, and aggregates closed sub-threshold incidents by apparent root cause. The figures this instrument supplies are the entries: Art. 3 fixes seven criteria, among them direct financial loss above the lower of EUR 500 000 or 5 % of turnover, trade secret exfiltration, death or considerable damage to health and a successful suspectedly malicious access capable of severe disruption; Art. 7 adds 30 minutes of complete unavailability, one hour of limited availability reaching the lower of 5 % of Union users or one million and the two data-compromise limbs; Art. 3(3) fixes the denominator by counting the natural and legal persons associated with business customers and not only the contracting ones; Art. 4 aggregates incidents recurring at least twice in six months with the same apparent root cause, tested quarterly under Annex point 3.4.2(b). For an organisation that also holds the managed-service-provider role, Art. 10 repeats the four Art. 7 criteria with the managed service or managed security service as the unit measured, applied to the systems it operates, administers or monitors on a customer's behalf. The NIS2-CIR-Art.10 disposition closes with the mapping this wave writes.
Framework Mappings (16)
| SEF-07 | Incident Management and Response | partial |
| SEF-07 | Incident Management and Response | partial |
| HIPAA-164.308.a.6.i | Security Incident Procedures | informative |
| HIPAA-164.314.a.2.i.C | Business Associate Contract Security Incident Reporting Term | informative |
| NIS2-Art.23.1 | Notification of Significant Incidents | informative |
| NIS2-Art.23.3 | Significant Incident Criteria | partial |
| NIS2-CIR-3.1 | Incident Handling Policy | informative |
| NIS2-CIR-3.4 | Event Assessment and Classification | informative |
| NIS2-CIR-Art.10 | Significant Incidents for Managed Service Providers and Managed Security Service Providers | full |
| NIS2-CIR-Art.3 | Significant Incident Criteria for the Relevant Entities | full |
| NIS2-CIR-Art.4 | Recurring Incidents | full |
| NIS2-CIR-Art.7 | Significant Incidents for Cloud Computing Service Providers | full |
| IR-4 | Incident Handling | informative |
| IR-6 | Incident Reporting | informative |
| GV-4.3-002 | AI Testing and Information Sharing Practices | GV-4.3-002 | informative |
| CC7.3 | Evaluates Security Events | informative |
Evidence (3)
Incident classification policy defining the severity taxonomy, classification criteria, escalation triggers, and response SLAs for each severity level.
Example: Incident Classification Matrix or IRP appendix (version-controlled) defining severity levels (e.g., P1–P4), classification criteria, data breach determination criteria, escalation requirements, and response SLA per level
Test: Request the incident classification policy or matrix. Verify: (1) severity levels are defined with explicit criteria; (2) data breach classification criteria are documented and consistent with GDPR Art.33 triggers; (3) each severity level has a defined escalation path and response SLA; (4) the matrix is referenced in the IRP and training materials.
Sample incident records showing consistent application of the classification taxonomy including severity assignment and escalation decisions.
Example: Incident records from the past 12 months (at least 5 incidents across severity levels) showing event type, initial classification, escalation actions taken, and any reclassification with rationale
Test: Request a sample of incident records from the last 12 months spanning multiple severity levels. Verify: (1) each incident record shows a severity classification; (2) classification is consistent with the documented criteria; (3) escalation actions match the requirements for the assigned severity level; (4) any reclassifications are documented with a rationale.
Incident classification taxonomy with its external threshold table, and the aggregation test results for the period.
Example: Incident Classification Standard v3.4 Annex B, with the Q2 2026 recurring-incident aggregation result dated 8 July 2026.
Test: Verify: (1) the taxonomy carries the external notification thresholds and criteria that bind the service, each stated as a measurable quantity or an observable condition, and the set reconciles to the obligations the compliance inventory holds, (2) every threshold expressed as a proportion names the population it is measured against and the system of record that population is read from, and that population can be produced, (3) a band exists for an attempted event that changed nothing, and an event of that kind in the period carries it, (4) each classified incident in the period records which external thresholds were tested and which were crossed, (5) the aggregation test ran at the defined interval in each period and covered the closed incidents that fell below every threshold individually, grouped by apparent root cause, (6) a group that crossed a threshold was classified as one incident and carries the submissions that classification required.
Questions (3)
Are incidents classified by severity and type using a defined taxonomy?
The classification matrix should explicitly include criteria for identifying a personal data breach (triggering GDPR notification obligations) and should be referenced in all incident triage processes.
How many severity levels are defined in your incident classification taxonomy?
Options run from the most granular taxonomy to the least. The control sets no number of levels. It requires each level to carry distinct criteria with a defined escalation path, a notification requirement and a response service level. The criteria for a personal data breach have to be among them.
Which of the following does the incident classification taxonomy carry?
Internal severity levels are not external thresholds: answer on the regulatory and contractual triggers, not on the priority scale. The population item is the one that decides whether the rest is usable, because a threshold set as a percentage of users is unanswerable until the denominator is defined and can be produced. The last two items look backwards across closed incidents and are the part most programmes have never built.