Delegated Regulation (EU) 2024/1772 Incident classification RTS

How the 2024/1772 incident classification RTS decides what is a major incident

A financial entity under DORA must decide whether an ICT-related incident is major, and Delegated Regulation (EU) 2024/1772 sets the test it applies. The major incident test in Article 8(1) has two gates. First, the incident must affect critical services. Second, either a malicious or unauthorised access has occurred that may cause data losses, or at least two other materiality thresholds are met. A severe outage touching critical services can therefore be major without any breach, and a security event with no data loss can still be major once it meets two thresholds. The compliance lead's first task is to map each incident type to these two gates before an incident happens, so the first classification is not made under pressure. Under-classification is the central risk: an incident scored as minor on first reading can run past the reporting deadlines before anyone reopens the question.

Article 9 supplies the thresholds the test counts. An incident can meet a threshold by affecting more than 10 % of clients or more than 100 000 clients of the affected service, involving more than 30 % of financial counterparts, or reaching more than 10 % of the daily average transaction number or value. For services supporting critical or important functions, duration over 24 hours or downtime over 2 hours also counts. Two or more member states affected and costs and losses over EUR 100 000 are further thresholds. Article 3 fixes the clocks: duration runs from occurrence until resolution, and downtime starts when a service becomes fully or partially unavailable and ends when regular activities return to the pre-incident level. Measuring these inputs is usually the hard part. Client counts, counterparty counts and transaction baselines must come from systems that can report them for the specific service, and cost figures need an agreed internal method. Confirm now which systems hold each input and how quickly they can be queried.

Two situations need specific handling. Under Article 8(2), recurring incidents that occur at least twice within 6 months with the same apparent root cause are treated as one major incident if together they meet the criteria, and this is assessed monthly by entities other than microenterprises and Article 16(1) entities. Small incidents that never cross a threshold alone can therefore become reportable. Record each classification decision with its inputs, timestamps and approver so a competent authority can follow the reasoning. Store detection, occurrence and resolution times as separate fields, since Article 3 depends on them. A case timeline in a tool such as DFIR-IRIS can hold those events, but the tool does not decide materiality; the entity's documented method does.

Which incidents, services and entities the classification rules reach

Before any incident can be classified, the entity has to decide which ICT services fall in scope, which entities get the lighter treatment, and how effects across borders are counted. Each card below is a scoping decision that changes how many incidents are major and how much recurring-incident work the team carries.

ICT services supporting critical functions

The materiality thresholds for downtime and duration apply most sharply to services that support critical or important functions. Start from the entity's register of critical or important functions and map each one to the ICT services, applications and infrastructure beneath it. Check whether a shared platform, such as a core banking or payment switch component, supports several functions, because one outage then affects more than one threshold. Record the mapping so the duration and downtime clocks can be applied per service.

Microenterprises and Article 16(1) entities

Article 8(2) requires the monthly recurring-incident assessment for most entities, but microenterprises and entities described in Article 16(1) of DORA are excluded from it. Confirm your status against the definition in DORA and the size criteria that apply in your member state before you design the monthly cycle. Exempt entities still classify individual incidents and still have to meet the reporting rules, so the exemption removes one recurring task, not the whole process.

Counting effects across member states

The threshold for two or more member states affected is a scoping question as much as a counting one. Map where clients, branches, counterparts and data subjects sit, including customers served through passporting or cross-border group entities. A single incident can cross the threshold without any one country showing a large effect. Document how you reached the count, because supervisors will ask how the figure was derived.

Recurring incidents with a shared root cause

Incidents that occur at least twice within 6 months with the same apparent root cause are treated as one major incident if together they meet the criteria. Your scope must include the logs and tickets that reveal a shared cause, which often sit in separate teams or in a provider's system. Define what counts as the same root cause in your procedure before the first monthly review, so the assessment is repeatable.

Third-party outages that reach the entity

An outage at a cloud host, SaaS vendor or managed service provider can meet the thresholds even though the entity does not operate the failing component. Inventory which third-party ICT services sit under each critical function and agree with each provider how it will notify you, what data it will give you, and how it measures downtime. The register of information and contract terms should match what your classification process needs to see.

Self-hosted open-source platforms in scope

For self-hosted open-source platforms run inside your own infrastructure, the entity owns the uptime and logs, so those components sit inside its classification scope without a provider to report on its behalf. Confirm which system generates the timestamps used to measure duration and downtime, and which log store will hold the evidence. If a community or commercial support contract is involved, confirm what that vendor will supply in an incident, because the entity still needs the facts.

How an assessor tests incident classification against the thresholds

This table sets out each test step an assessor performs on incident classification under Delegated Regulation (EU) 2024/1772, the evidence requested for it and the findings that most often appear. Read each row as a test the entity should be able to pass with its own records before an examination begins.

Test step	What the assessor does	Evidence requested	Common finding
Register sampling	Selects incidents from the incident register across the period, including minor-looking events and those closed without escalation	Full incident register extract, ticket history and the criteria used to select the sample	Register omits low-severity or internally resolved incidents, so the sample cannot show completeness
Article 3 timing check	Compares occurrence, detection, resolution and downtime timestamps against logs and change records	SIEM and monitoring timestamps, ticket audit trail, service status history	Duration measured from detection instead of occurrence, or downtime end date taken from ticket closure rather than service restoration
Article 8 re-performance	Recalculates whether the incident affected critical services and whether the malicious access or two-threshold test is met	Service mapping showing which services support critical or important functions, and the access or data-loss analysis	Classification recorded as major with no written reasoning, or service criticality not linked to a documented mapping
Article 9 threshold re-performance	Recomputes each quantitative threshold from source data: client share, counterpart share, transaction volume, duration, member states, costs and losses	Client counts per service, counterparty lists, transaction statistics, cost and loss workings with sources	Missing client counts, thresholds applied on estimates, or cost figures with no calculation attached
Multi-state and cost thresholds	Tests whether the member state count and the EUR 100 000 cost and loss figure were measured on the stated basis	Affected-jurisdiction analysis and cost ledger extracts linked to the incident ID	Cost figure excludes internal labor or later losses without a documented reason, or jurisdictions not counted
Article 8(2) recurring-incident review	Checks whether incidents with the same apparent root cause recurring within six months were aggregated and whether the monthly assessment ran	Monthly review minutes, root-cause linking records, aggregation calculations	Root-cause linking undocumented, monthly review skipped in quiet months, or microenterprise scope applied without basis
Classification decision trail	Confirms who classified the incident, when, and whether reclassification after new facts was recorded	Approval records, version history of the classification field, reclassification notes	Thresholds applied without a recorded calculation, or classification changed with no date or rationale
Significant cyber threat test	Checks whether threats were assessed against the Article 10 test and the decision not to notify was reasoned	Threat assessment records and decisions on notification	No record that threats were assessed when no notification was made

Implementing the classification process step by step

This sequence turns the classification criteria of Delegated Regulation (EU) 2024/1772 into a working process that can flag a major incident within the reporting timelines. Each step produces a artifact that the next step depends on, so the output of the last step is an operating classification process the organization has tested.

Map critical services, clients and counterparts
Start by listing every ICT service that supports a critical or important function, using the function inventory and the register of information. For each service, record the number of clients it serves, the number of financial counterparts that depend on it, the daily average transaction number and value, and the member states where clients sit. Assign an owner from the business and an owner from IT to each service. The step is complete when every critical service has a baseline for each metric, signed off by the business owner, and the baselines are stored where the incident team can reach them during an incident.
Source each threshold metric from systems
For each metric in the baselines, name the system that produces it, such as the client database, the transaction ledger, the monitoring platform or the counterparty register. Write down the query or report, the refresh frequency and the person who can run it outside business hours. Test that each source returns a figure within the time the incident team needs during a live event. The output is a metric source register that shows, for every threshold, where the number comes from and who can confirm it. Gaps found here should go into the incident response plan as open actions.
Set incident time capture rules
Define how the start and end of an incident are recorded. Duration runs from occurrence until resolution, and downtime runs from the moment a service becomes fully or partially unavailable until regular activities are restored to the pre-incident level. Write rules for how the team records the occurrence time when detection lags behind the event, and how it records partial unavailability. Have the rules approved by the incident manager and the service owner. The output is a time capture standard and a logging template that every responder uses, so that the timestamps in the incident record can be defended to a supervisor.
Build the classification decision logic
Translate the criteria into a decision tree that the incident manager can follow. First test whether the incident affected a critical service. Then test whether malicious, unauthorized access that may cause data losses occurred. If not, count how many other materiality thresholds are met and compare the count with the two-threshold requirement. Add the costs and losses test with its EUR 100 000 level. Document each branch with the source metric and the rule. Review the logic with legal and compliance so that the reasoning can be reproduced later. The output is a written classification procedure with worked examples, labeled as illustrative, and a decision record template.
Configure recurring incident aggregation over six months
Set up the incident register so that each incident is tagged with its apparent root cause and its date. Configure a monthly review that searches for incidents sharing a root cause within a rolling six-month window and counts how many times each has occurred. When recurring incidents reach the threshold in Article 8(2) and together meet the criteria, the review flags them as one major incident. Confirm with the compliance lead whether your entity is exempt from monthly assessment because it is a microenterprise or falls under Article 16(1). The output is a recurring incident register and a monthly review checklist with named reviewers.
Run a tabletop test of the full process
Build a realistic but fictional scenario, labeled as illustrative, that touches at least two critical services and includes a partial outage and a possible unauthorized access event. Walk the incident team through time capture, metric sourcing, the decision tree and the recurring incident check, recording each decision and each delay. Measure whether the team reached a classification decision using only the documents and sources in the process. The output is a test report listing gaps, owners and corrective actions. Repeat the test after corrections, and keep the reports as evidence for supervisors and auditors that the process works in practice.

How recurring incidents and significant cyber threats are classified

Under Article 8(2) of Delegated Regulation (EU) 2024/1772, a series of incidents can become one major incident even when none of them is major alone. The trigger is recurrence: incidents that occur at least twice within six months and share the same apparent root cause. Once they are treated together, the entity tests the combined effect against the same criteria and thresholds it uses for a single event, and if the aggregated incidents meet them, they are reported as one major incident. The practical task is to make the root cause field meaningful. Recording a common root cause at the time of each incident, for example a recurring misconfiguration in a particular load balancer, lets the entity see the pattern in its case records rather than reconstructing it at reporting time. The assessment runs monthly for most entities. Microenterprises and entities covered by Article 16(1) of DORA are outside this monthly duty, so the entity should confirm which group it falls into before setting its review calendar.

Article 10 covers significant cyber threats, which are cyber threats the entity judges to be significant enough to warrant notification. The regulation sets out the factors an entity should weigh, including the likelihood that the threat could materialize into a major incident, the critical services and assets it could reach, and the indicators of compromise and attack techniques involved. Entities should document how they reach that judgment for each threat, because reviewers will test the reasoning, not only the outcome. Under Article 11, a major incident or threat is relevant to other member states where it has a material impact on clients, entities or branches there, or where a third party in another member state is affected. Entities operating across borders should map their client and service footprint by member state so they can answer that question quickly. Article 12 governs the details to share, and the entity should confirm the current content requirements with its competent authority, since they feed the reporting templates in Implementing Regulation (EU) 2025/302.

Which evidence shows the classification decisions hold up

An assessor reviewing a major incident call will ask for the record behind each classification, not just the outcome. The cards below cover the records that connect an incident to its threshold results, and the routines that keep those records current between audits.

Classification decision record per incident

Keep one decision record for every incident, showing the date and time it was logged, the critical or important functions affected, which of the six classification criteria were assessed, and the result. Record who made the call and who approved it. For each incident that was not classified as major, the record should still explain why, because a reviewer will test the negative decisions as closely as the positive ones. Use one record per incident so the trail from alert to decision is never split across tools.

Threshold calculation worksheets

Each Article 9 threshold needs a worksheet that shows the input data, the source system it came from, the denominator used, and the calculated percentage or amount. Record the reference period for client counts, transaction numbers and counterpart counts, so a reviewer can rerun the calculation and reach the same result. Keep the worksheets versioned, and note any estimate used where the measured figure was not yet available at the time of the decision.

Duration and downtime timestamps

Article 3 measures duration from occurrence to resolution, and downtime from the moment a service becomes fully or partially unavailable until regular activities return to the pre-incident level. Store the timestamps from monitoring, ticketing and the service owner's confirmation, and record the time zone used. Where the two sources disagree, keep both values and the reason the final value was chosen, since the 24-hour and 2-hour limits can turn on a few minutes.

Recurring-incident review minutes

Under Article 8(2), recurring incidents that occur at least twice within six months with the same apparent root cause can count together as one major incident. Minute a monthly review that lists each candidate pair or group, the root cause analysis behind the grouping, the combined threshold results, and the outcome. Entities other than microenterprises and Article 16(1) entities must hold this review, so confirm which obligation applies before the first cycle.

Cyber threat assessment records

For significant cyber threats, keep the assessment that compares each threat against the criteria in the RTS, the intelligence sources consulted, and the decision on whether notification was made. Record which member states were considered, since cross-border relevance under Articles 11 and 12 affects what is shared. Retain records of threats judged not significant, with the reasoning, so the absence of a notification can be shown to be a considered choice.

Sign-off trail and threshold re-verification

Keep a dated sign-off trail for each decision and for each change to thresholds inputs, such as a new client count after a product launch or a service moved to a new hosting platform. Re-verify the threshold inputs whenever a service, client base or critical function changes, and at a fixed review interval set by the entity's policy. Confirm with the competent authority how it expects these reviews to be documented, since DeployOpen prepares the records and the entity owns the decisions.

What meeting the classification requirement costs

This table breaks the cost of running incident classification under Delegated Regulation (EU) 2024/1772 into its components, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. No figures are given because none are supplied for this topic, so use the questions in the final column when requesting quotes from any provider.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it, and what to ask for in a quote
Tooling for case records and classification	Software vendors or hosting providers, plus internal staff for setup	Setup is one-time, licences or hosting recur	Number of incident sources and case volume. Ask whether the case platform keeps a full audit trail and evidence hashing, and what it costs to self-host versus subscribe.
Engineering to connect incident and client data	Internal platform engineers or an implementation partner under a fixed-scope agreement	Mostly one-time, with upkeep when systems change	Number of systems feeding client counts, transaction volumes and downtime timestamps. Ask which data fields the quote assumes and who maintains the mappings.
Building the classification logic	Internal risk team or an outside consultant	One-time, with periodic review	Complexity of the thresholds for critical services and the number of member states involved. Ask how Article 3 duration and downtime measurement is implemented.
Monthly recurring incident review	Operations or risk staff, time measured in staff hours	Recurring every month	Volume of incidents with the same apparent root cause within six months under Article 8(2). Ask how grouping decisions are recorded and who signs them off.
Evidence upkeep	Internal compliance and security staff	Recurring	Retention of classification decisions, thresholds applied and supporting records. Ask how the platform exports evidence for supervisors.
External review of thresholds	Independent reviewers or consultants	Periodic, often tied to changes in services or the regulation	Scope of review and number of services classified. Ask for a written scope listing what is reviewed and what is excluded.
Auditor or supervisor sampling	Independent auditors or the competent authority, not the implementation partner	Occasional, on the auditor's or authority's schedule	Sample size and depth of testing chosen by the auditor. Ask your auditor which records they expect to sample before preparing evidence.
Ongoing support and updates	Implementation partner under a retainer, or internal staff	Recurring	Changes to the classification logic, new services and upgrades to the case platform. Ask what the retainer covers and how changes are scoped.

How DFIR-IRIS supports case records behind classification

DFIR-IRIS, an open-source case management platform licensed under LGPL-3.0-or-later, keeps each incident as a single case record. Instead of scattering facts across chat threads, tickets and spreadsheets, the team attaches everything that bears on the incident to one place, which makes it easier to show later how a classification was reached.

Affected assets: Record the systems, services and client-facing components involved, so the scope of the service affected can be traced from the case.
Indicators of compromise: Store IOCs against the case so that malicious or unauthorised access findings can be tied to specific evidence.
Tasks and owners: Assign response tasks to named people with status, which shows who acted on the incident and when.
Evidence items: Link artefacts directly to the case rather than leaving them on individual workstations.
Audit trail: Every change to the case is logged, so reviewers can see how the record evolved.

Before relying on this structure, confirm which fields your classification process needs, such as client counts, transaction figures and cost estimates, and whether you will hold them in DFIR-IRIS custom fields or in a separate register.

Where classification programs usually fall short

How do we produce client and counterpart counts for a major incident on demand?

Most programs cannot do this quickly, because client and counterpart counts sit in billing, CRM or core banking systems while the incident team works from tickets. Article 9 of the RTS uses thresholds based on more than 10 % of clients or more than 100 000 clients of the affected service, more than 30 % of financial counterparts, and more than 10 % of daily average transactions by number or value. Close the gap by mapping each critical service to the system of record that holds its client and counterpart identifiers. Write a query that returns affected counts for a given time window, and store daily baselines so the denominator exists when an incident happens. Test the query in a tabletop exercise. Ask your team to confirm which counterparts fall under the RTS definition and which system holds the transaction data.

Why do incident durations come out shorter than the RTS requires?

Teams usually start the clock at detection, but Article 3 measures incident duration from occurrence until resolution. Service downtime runs from the moment a service becomes fully or partially unavailable until regular activities return to the pre-incident level. Close the gap by recording occurrence timestamps from log evidence, not from alert timestamps. Reconstruct the earliest relevant event from SIEM, EDR and application logs, and store it as its own field. Keep detection, acknowledgement, containment and resolution as separate fields so the difference stays visible. Then check the 24-hour duration and 2-hour downtime thresholds for services supporting critical or important functions against the corrected times. For example, an alert raised at 09:00 may follow activity that began the previous evening, and the duration must start from that earlier point.

How do we link recurring incidents that share a root cause?

Most ticketing setups record recurrence only when an analyst happens to notice it. Article 8(2) treats recurring incidents that occur at least twice within 6 months with the same apparent root cause as one major incident, if together they meet the criteria. Close the gap by adding a mandatory apparent root cause field with controlled values, and a rule that flags any new incident sharing a value with one from the previous six months. Tools that keep related artifacts together can help. DFIR-IRIS keeps each case as a record of assets, IOCs, tasks and evidence, which makes shared assets and indicators easier to compare across cases. Confirm in your own deployment that the linking workflow, fields and searches work as you intend before relying on them. Once links exist, aggregate the combined impact against the Article 9 thresholds.

What monthly review record does incident classification need?

Article 8(2) requires recurring incidents to be assessed monthly by entities other than microenterprises and the entities named in Article 16(1). Supervisors look for a dated record showing that the review happened, who ran it, what was examined and what was decided. Close the gap by scheduling a monthly classification review with a named chair, a standing agenda and written minutes. The agenda should cover open incidents, the recurring-incident list, aggregated counts against thresholds and any reclassification. Keep the minutes in a controlled repository with version history and link each decision to the affected case records. Ask your competent authority or assessor which format and retention period they expect, and confirm both before the first review cycle.

How should we document decisions about significant cyber threats?

Significant cyber threat notifications are voluntary under DORA, but the RTS sets a test for deciding whether a threat is significant, and you need evidence of how you applied it. Close the gap by logging each threat assessment with the criteria considered, the evidence reviewed, the decision, the approver and the timestamp. Record decisions not to notify as carefully as decisions to notify. Link each threat entry to the intelligence source that prompted it and to a case record where one exists. Have internal audit sample threat entries each quarter to confirm that the reasoning is traceable. Check the wording of the test in Article 10 of the RTS against the official text on EUR-Lex and build your template from that wording.

Can our own team close these gaps, or do we need an implementation partner?

The organization owns its classification decisions, thresholds applied and sign-off. An implementation partner can prepare the data mapping, case fields, count queries, timestamp logic and review templates inside your own infrastructure. DeployOpen works this way, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Cost depends on the number of critical services, the number of systems of record involved, the log sources that must feed timestamps, and how many tools need configuration changes. Ask any provider for a written scope that lists the fields, reports, queries and training included, and whether one-time build work is separated from recurring run support. DeployOpen does not publish a price list, and a quote follows from the written scope.

What will an assessor check when testing our classification process?

Assessors and supervisors issue their own findings. An implementation partner can prepare the systems and evidence they will review, but it does not issue audit reports or attestations. Expect sample testing: whether durations start at occurrence, whether client and counterpart counts trace back to source systems, whether recurring incidents were linked and reviewed monthly, and whether significant threat decisions have records. Close the gaps before the assessor arrives by running a walkthrough on a set of past incidents, one per category, and by keeping an evidence pack for each case. The pack should hold the timeline, the source extracts, the classification decision, the review minutes and any reclassification. Confirm with your supervisor which evidence formats and sampling approach they expect.

How DeployOpen prepares classification systems and evidence

DeployOpen scopes classification work in a written, fixed-scope agreement that names the entity, the systems that feed incident records, the services in scope and the decision points the organization must own, such as who applies the criteria and who signs off a major classification. Before work starts, confirm which of your services support critical or important functions, because the Article 9 thresholds for duration and downtime apply differently to them. The written scope also fixes deliverables and timelines, and a quote follows from that scope. DeployOpen does not issue audit reports, attestations or certifications; the organization owns its classification decisions, and only an independent auditor, assessor or competent authority issues any assurance.

On the technical side, DeployOpen configures the case management platform, for example DFIR-IRIS, so that each incident becomes one case record with linked assets, indicators, tasks and evidence, and a full audit trail. Alerts from SIEM, EDR and REST sources are wired into case intake, and fields are mapped so that the measurements the RTS requires, such as incident start, detection, resolution and service restoration times, client counts, transaction volumes, affected member states and estimated costs and losses, are captured as structured data rather than free text. Ask for a written field map so you can check that the timestamps and counters match the definitions in Article 3 and Article 9.

For the assessor, DeployOpen prepares an evidence pack per incident and per recurring-incident group: the case timeline, the classification worksheet showing each criterion and threshold result, the reasoning behind any reclassification, and SHA-256 verified evidence logs with chain of custody. Recurring-incident tracking under Article 8(2), with its six-month window and monthly assessment, is set up as a saved review so the record shows it was checked. Testing support includes tabletop exercises with sample incidents and checks that the logic produces the same result for the same inputs. Confirm with your assessor which artifacts they expect before the pack is built.