Appearance
Incident Classification
Four things are classified on an incident. They are independent, and treating any of them as a proxy for another produces the wrong answer.
1. Category — what kind of event
| Category | Covers |
|---|---|
operational | Process and operational disruption |
cyber_technology | Security and technology events |
fraud_financial_crime | Internal and external fraud |
compliance_regulatory | Regulatory breaches |
privacy_data_protection | Personal data events |
third_party | Provider-originated events |
conduct_market | Conduct and market events |
Category drives who is notified and which specialist process applies.
2. Severity — how bad
Low, Medium, High, Critical.
Severity reflects the operational impact of the event: disruption, affected customers, data exposure, duration.
Severity does not determine loss and does not determine reportability
A Critical incident with zero financial loss is entirely normal. So is a Medium incident that becomes reportable and a High incident that does not.
Severity, loss and reportability are set independently, from different criteria.
3. Impact — what was affected
Impact assessment records the affected dimensions: customers, data, services, obligations, reputation, and the extent of each.
Impact is where the operational reality is captured. It is what the severity rating should be justified by, and what the regulatory reportability assessment draws on.
4. Regulatory reportability — what must be told to whom
| Status | Meaning |
|---|---|
not_reportable | Assessed as below the reporting threshold |
potentially_reportable | Under assessment |
confirmed_reportable | Assessed as reportable |
submitted | Report submitted to the authority |
regulator_acknowledged | The authority has acknowledged receipt |
Alongside the status, the record carries the regulatory bodies involved and the statutory reporting deadline.
Reportability is a legal test, not a severity threshold
Reporting obligations are governed by materiality thresholds, jurisdictional definitions and statutory deadlines that differ by authority and by incident type.
A personal data breach affecting 40 records may be reportable within 72 hours. A service outage affecting 40,000 customers may not be reportable at all. OrviQ does not derive reportability from severity, because the relationship is not a function.
Reporting deadlines
Where a reporting deadline is recorded, it projects into the GRC Calendar as an incident reporting deadline, and drives escalation.
This is one of the highest-value calendar entries in the platform. A missed statutory notification deadline is frequently a more serious regulatory matter than the incident that triggered it.
Classifying well
Classify early, revise deliberately. An incident's initial classification in the first hour is a working hypothesis. Revising it as facts emerge is normal; every change is recorded.
Assess reportability separately from severity. Get the compliance or legal function to make the reportability call, and record their reasoning.
Record why a decision was not to report. A not_reportable assessment with a documented rationale is defensible. One without is an omission that will be questioned.
Use potentially_reportable honestly. It is the correct status while the assessment is genuinely open, and it keeps the deadline visible.
AI assistance
AI can suggest a classification with reasoning and an advisory notice. It is heuristic and advisory: it never sets the classification, and it never assesses reportability.
Requires incident.ai_assist.
Permissions
| Action | Permission |
|---|---|
| View classifications | incident.read |
| Set and update category, severity, impact and reportability | incident.manage |
| Generate AI classification suggestions | incident.ai_assist |
Example
Incident INC-2026-0014 — Payment file duplication.
| Classification | Value | Basis |
|---|---|---|
| Category | operational | Process failure in batch submission |
| Severity | High | 1,412 duplicate transactions; 14 released to customers; customer-facing impact |
| Impact | Customers: 14 affected; Services: retail payments degraded 3 hours; Data: none; Obligations: payment execution accuracy | |
| Reportability | not_reportable | Assessed by Compliance against the operational incident reporting threshold; below both the value and customer-count thresholds; all 14 transactions reversed within 4 hours with no customer detriment. Rationale recorded and reviewed by Legal |
Contrast — INC-2026-0019 — Misdirected correspondence.
| Classification | Value | Basis |
|---|---|---|
| Category | privacy_data_protection | |
| Severity | Medium | 62 items of correspondence sent to incorrect addresses |
| Reportability | confirmed_reportable | Personal data disclosed to unauthorised recipients; meets the notification threshold. Deadline 72 hours from awareness |
The Medium-severity privacy incident was reportable. The High-severity payments incident was not. Any system deriving one from the other would have got both wrong.
Troubleshooting
"Severity is High but the incident is not reportable." That is normal and correct. They are independent assessments.
"The reporting deadline is not on the calendar." Ensure the deadline is recorded on the incident and the incident is open.
"AI suggested a classification I disagree with." It is advisory. Set the classification you assess to be correct.
"Reportability changed after we investigated." Expected. Revisions are recorded with actor and timestamp.