What DORA Article 18 requires for classifying ICT incidents
Compliance leads need to show two things under Article 18: that every ICT-related incident is classified, and that the major ones are identified correctly and early enough to feed the reporting clock. Article 18(1) requires each incident to be assessed against six criteria: clients, financial counterparts and transactions affected, including reputational impact; duration and service downtime; geographical spread; data losses; criticality of the services affected; and economic impact. Article 18(2) runs a separate test for cyber threats, asking whether a threat is significant based on the criticality of the services at risk, the number or relevance of clients or counterparts targeted, and the geographical spread of the areas at risk. Classification matters because it decides whether an incident is major under Delegated Regulation (EU) 2024/1772, and a major incident starts the reporting obligations in Article 19.
The hard part is consistency, not the first assessment. An incident that is minor at detection can become major as impact data arrives, so the organization needs a documented procedure that says who re-scores an incident, when, and on which data. Under Article 8 of Delegated Regulation (EU) 2024/1772, an incident is major where it affects critical services and either involves a successful, malicious and unauthorised access to network and information systems that may result in data losses, or meets two or more of the other materiality thresholds. Article 9 of the same regulation sets the quantitative thresholds, such as more than 10 % of clients, more than 30 % of financial counterparts, or costs and losses over EUR 100 000. Confirm each threshold against the regulation text before you encode it in a tool or form.
Recurring incidents need their own check. Under Article 8(2), incidents that are individually below the threshold count as one major incident if they occur at least twice within six months, share the same apparent root cause, and together meet the major criteria, and the assessment runs monthly unless an exemption applies. Ask your team to confirm how the monthly review is scheduled, who owns it, and where the root-cause evidence is kept. Records of each classification decision, including the rationale for those judged not major, are what an assessor will sample first.
Which incidents, systems and teams fall under Article 18 classification
Article 18 classification only works when the entity first decides which systems, services, third parties and people it covers. The cards below set out those scoping decisions so that every incident is assessed against the same boundary and the same accountable owners.
Critical or important functions
The materiality thresholds in Delegated Regulation (EU) 2024/1772 apply most strictly to services that support critical or important functions. Before classifying anything, the entity must map which business services and ICT systems support those functions, because a downtime threshold that is measured in hours for one service may be irrelevant for another. Ask who maintains that map and how often it is reviewed against the register of information.
Critical services in the incident scope
An incident can only be major if it affects critical services, so the entity needs a documented list of which services meet that test. Include self-hosted open-source platforms that run payments, customer onboarding, trading or reporting, even when no vendor contract exists for them. Confirm that the list is owned by the business process owner, not only by IT operations.
Third-party incidents that must be captured
Incidents at ICT third-party providers that affect the entity's services still need to be recorded and classified by the entity, even when the provider runs the system. Contracts should require providers to share timely incident data in a form the entity can apply the six criteria to. Check that cloud and managed service agreements specify how provider-side outage durations and affected client counts are reported.
Entities and branches in scope
Classification applies to each financial entity in the group that uses the affected ICT services, including subsidiaries and branches in other member states. An incident in one entity can count toward the two-member-state threshold or the client thresholds of another. Confirm which legal entities share platforms so that counts are aggregated consistently.
Cyber threats that need assessment
Article 18(2) requires classifying cyber threats as significant, so scope must cover threat intelligence, detection alerts and vulnerability reports that could affect critical functions. Decide which feeds, SIEM rules and EDR alerts feed the classification process. Record threats that are assessed and found not significant, since those decisions are part of the evidence.
Teams that hold classification decisions
The classification decision needs a named owner, typically the incident manager with input from the business service owner, and a documented escalation path to senior management. Define who can override a provisional classification and who signs off recurring incident assessments. Ask for role descriptions and a RACI showing the decision, not only the data collection, is assigned.
How the six criteria and materiality thresholds decide a major incident
The classification test works in two stages. Article 18(1) of DORA requires every ICT-related incident to be assessed against six criteria: clients, financial counterparts and transactions affected (including reputational impact), duration and service downtime, geographical spread, data losses, criticality of the services affected, and economic impact. Those criteria are qualitative until Delegated Regulation (EU) 2024/1772 turns them into measurable inputs. Before any incident is triaged, the organization needs a current list of its critical or important functions and the ICT services that support them, because the criticality criterion and the most common major-incident route both depend on that list. Confirm that the list is owned by a named function and reviewed when services change, since an incident's classification is only as reliable as the service map behind it.
Article 8 of the RTS sets the first route. An incident is major where it has affected critical services and either a successful, malicious and unauthorised access to network and information systems has occurred that may result in data losses, or two or more of the other materiality thresholds in Article 9 are met. The first branch needs evidence of the access event and an assessment of whether data could have been lost, which in practice means log coverage and forensic capability must exist before an incident happens. The second branch is a counting exercise. Article 9 sets thresholds such as more than 10 % or more than 100 000 clients using the affected service, more than 30 % of financial counterparts, more than 10 % of the daily average transaction number or value, duration over 24 hours or downtime over 2 hours for services supporting critical or important functions, impact in two or more member states, and costs and losses over EUR 100 000. Each threshold requires a baseline client count, transaction average and cost ledger that can be pulled quickly during an incident. Ask whether those baselines are documented and where they are stored.
Two practical checks follow. First, the clock matters: the assessment must be made from the data available during the incident, so the team should be able to answer each threshold question without waiting for a full post-incident review. Second, the thresholds are cumulative, so an incident that affects a critical service but triggers only one threshold may still be non-major, while the same incident might become major if a second threshold is confirmed later. Record each threshold decision with its supporting figures and timestamp, and confirm with the competent authority or your legal advisers how reclassification after new facts emerge is expected to be documented. Readers planning an external review of their classification method should ask the reviewer to test these records against a worked example, labelled as illustrative, rather than against the text of the RTS alone.
How an assessor tests incident classification
This table lists the steps an assessor performs on incident classification, from sampling incidents to reviewing recurring-incident and significant threat records. Read each row as a test the organization should be able to pass with its own records. The main takeaway is that assessors reconstruct each classification decision against the thresholds, so the reasoning must be written down at the time.
| Test step | What the assessor does | Evidence requested |
|---|---|---|
| Population completeness | Compares the incident register against ticketing, SIEM and service desk records to check that no ICT-related incident was left unrecorded. | Full incident log export with date range, reconciliation query and list of excluded records with reasons. |
| Sampling of incidents | Selects a sample across incident types, business services and periods, including incidents closed as minor, and tests each one. | Sample selection rationale, incident records with timestamps, and the classification entry for each sampled item. |
| Reconstruction against the six criteria | Rebuilds each classification decision by checking clients, counterparts, transactions, duration, geographical spread, data losses, criticality and economic impact against the record. | Impact assessment worksheets, client and transaction counts, downtime logs, data loss analysis and cost calculations. |
| Threshold check under Delegated Regulation (EU) 2024/1772 | Verifies that the major or non-major outcome follows the Article 8 and Article 9 materiality thresholds applied to the facts on file. | Threshold calculation sheets showing inputs, sources and the date each figure was taken. |
| Recurring-incident review | Checks the monthly assessment for repeated incidents, including the six-month window, shared apparent root cause and aggregated thresholds. | Monthly recurrence assessments, root cause tags, and records showing when two or more incidents were grouped. |
| Cyber threat significance records | Tests whether threats were assessed against criticality, number or relevance of clients or counterparts targeted, and geographical spread under Article 18(2). | Threat assessment records, intelligence sources, significance decisions and approvals by the responsible role. |
| Timing and version control | Compares when classification was recorded with when the incident was detected and whether later reclassification was documented. | Audit trail of edits, reclassification notes and approval timestamps. |
| Common finding: undocumented reasoning | Classification recorded as a label without the facts used, so the assessor cannot reproduce the decision. | Ask for the inputs and reasoning for each decision before the assessment starts. |
| Common finding: recurring incidents not reviewed | Monthly recurrence assessment skipped or performed only for major incidents, leaving grouped minor incidents unassessed. | Confirm the review runs every month and covers all incident categories in scope. |
Steps to build a classification method that holds up under review
The sequence turns the six Article 18 criteria and the Delegated Regulation (EU) 2024/1772 thresholds into a documented method that an examiner can follow from raw incident data to a classification decision, a major-incident call or a significant-threat call.
Map data sources to each classification criterion
Start by listing, for each of the six Article 18(1) criteria (clients, counterparts and transactions with reputational impact, duration and downtime, geographical spread, data losses, criticality of services, and economic impact), where the underlying data lives. Name the system of record, the owner and the refresh method, such as the ticketing platform for downtime, the customer master for client counts, and the finance ledger for cost. Include the data needed for the Article 18(2) cyber threat criteria, such as the service criticality register and client or counterparty exposure. Output: a criterion-to-source register signed off by the owners, with gaps flagged for remediation before any incident is classified.
Define the classification procedure and decision record
Write the procedure that tells an incident handler how to move from detection to a classification. It should set the order of checks, who may classify, who must approve a major call, and when the assessment is reopened as new facts arrive. Pair it with a decision record template that captures the value used for each criterion, the source and timestamp of that value, the threshold tested and the reasoning. Output: an approved procedure and a template that a reviewer can read without asking the analyst what they meant.
Configure materiality thresholds and escalation rules
Translate the Article 8 and Article 9 materiality tests of Delegated Regulation (EU) 2024/1772 into logic your tooling and staff can apply. Encode the critical services test, the malicious unauthorised access that may cause data losses, and the count of other thresholds met, and note which thresholds apply only to services supporting critical or important functions. Define escalation triggers so that a possible major incident reaches the reporting owner before the clock matters. Output: a threshold table with each rule, its input field, and a worked test case confirming the logic returns the expected result.
Add recurring incident tracking
Set up a register that links incidents sharing an apparent root cause and records their dates. The Delegated Regulation treats recurring incidents that are not individually major as one major incident when they occur at least twice within six months, share the same apparent root cause, and together meet the major criteria. Schedule the monthly assessment the regulation requires, with the exemptions for microenterprises and Article 16(1) entities checked against the entity's status. Output: a live recurrence log, a documented root cause field, and a monthly review record that shows who performed the assessment.
Build the cyber threat significance assessment
Create a separate assessment for cyber threats that have not yet caused an incident. Score each threat against the Article 18(2) and Article 10 conditions: whether it could affect critical or important functions or other entities, whether its probability of materialising is high, and whether it could meet the criticality, client or counterparty, or geographical spread tests. Record the basis for each score and the threat intelligence source. Output: a threat assessment form and log that show why a threat was or was not treated as significant, ready for the entity's voluntary notification decision.
Load the case workflow into an incident platform
Configure the chosen case management tool so that the classification fields, thresholds, recurrence link and decision record live in the same case as the timeline and evidence. For DFIR-IRIS, this means custom fields or tasks that enforce each step, an audit trail that captures every change to a classification value, and evidence hashes that support the facts relied on. Test that edits made after a classification leave a visible history. Output: a configured workflow with a documented change log and a test record showing the audit trail works.
Test the method against past incidents
Replay a set of past incidents, including at least one that was major, one that was not, one recurring pattern and one significant threat that did not materialise, through the procedure. Compare the outcome with the decision previously made and document each difference, its cause and the change made to the rule or the data. Have a reviewer who did not build the method check the reasoning. Output: a test report with pass or fail results, a list of corrections and sign-off by the accountable manager, which becomes the evidence that the method works before an examiner asks.
Evidence that proves classification works
Classification is only credible if an assessor can trace each incident from detection to a documented decision. The artifacts below form that trail, and each one should be kept current as incidents occur rather than rebuilt before an audit.
Written classification procedure
The procedure sets out how each of the six Article 18(1) criteria is measured, which data sources feed it, who scores it and when a decision is escalated. Check that it names the threshold values from Delegated Regulation (EU) 2024/1772 and states how an incident affecting critical services is handled. Version it, record its approver, and tie each change to a dated reason so the assessor can see how the method evolved.
Incident register with per-criterion fields
The register should hold one record per incident with a dedicated field for each classification criterion: clients and counterparts affected, duration and downtime, geographical spread, data losses, criticality of services and economic impact. Empty fields are a finding in themselves, so check that every record either carries a value or a documented reason why the value is not yet known.
Threshold calculation records
For each incident, keep the working that compares measured values against the materiality thresholds, such as the share of clients using the affected service, the share of financial counterparts, transaction volume, downtime and costs. Store the source of each input and the timestamp of the calculation. An assessor should be able to recompute the outcome from the record without asking the team for explanations.
Decision records with approver
Every major or non-major classification needs a decision record naming the person who made the call, the date, the criteria relied on and any dissent. Where the decision is made under time pressure, record the preliminary assessment and the later confirmation separately. Check that approvers hold the authority the incident procedure assigns to them, since an unsigned or out-of-role decision weakens the whole register.
Monthly recurring-incident reviews
Recurring incidents can count as one major incident when they occur at least twice within six months, share an apparent root cause and together meet the criteria. Keep a dated monthly review showing that the team searched for such patterns, the incidents compared, the root-cause hypotheses and the conclusion reached. Entities that qualify for the microenterprise or Article 16(1) treatment should confirm whether that cadence applies to them.
Cyber threat assessment and update history
Record each assessment of whether a cyber threat is significant, covering the criticality of services at risk, the number or relevance of targeted clients or counterparts, geographical spread and the probability of materialising. Pair these with an update history that shows every change to the register, procedure and thresholds, with reasons and approvers, so the evidence stays current between audits.
What meeting Article 18 classification costs in money and effort
This table breaks down the cost components of running Article 18 classification, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to shape a scoping conversation and to decide which parts to keep in-house. No price or duration figures are given because none were supplied for this topic, so the cost column names what to ask for in a quote.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives the cost |
|---|---|---|---|
| Tooling and licenses | Software vendor or the entity's own team for self-hosted tools | Recurring for commercial licenses, one-time for setup | Number of log sources, user seats and whether a hosted or self-hosted model is chosen. Open-source case tools such as DFIR-IRIS (LGPL-3.0-or-later) can remove most license spend, but hosting and support still apply |
| Engineering time to wire data sources | Internal engineers or an implementation partner under a written scope | One-time, with ongoing change effort | Number and variety of SIEM, EDR and other sources feeding incident triage, and how much data normalization is needed to derive the six classification criteria |
| Classification process design | Internal risk, incident response and compliance staff, sometimes with outside advisers | One-time, revisited after reviews | How many services are mapped as critical or important functions, and how many thresholds in Delegated Regulation (EU) 2024/1772 need a defined calculation method |
| Data for client, transaction and downtime measures | Business owners and data teams | Recurring as a monthly or per-incident effort | Whether client counts, transaction volumes and affected-service records already exist in reliable systems or must be reconstructed for each incident |
| Recurring incident assessment | Incident response team and reporting owner | Recurring, at least monthly under the 2024/1772 rule | Incident volume, number of root causes, and whether recurring incidents are tracked in one case record with a consistent root cause field |
| Evidence upkeep | Compliance and security staff | Recurring | Retention of classification worksheets, case timelines and threshold calculations, and how often threshold data is refreshed |
| External review | Independent advisers or internal audit, at the entity's discretion | Recurring or periodic | Scope of the review, complexity of the classification methodology and whether an outside specialist is needed for the first cycle |
| Auditor or supervisor sampling | Competent authority or independent assessor (not paid for issuing a certificate under DORA) | Recurring at each supervisory or audit cycle | How well classification decisions are documented, whether records can be retrieved quickly and whether calculations reproduce from source data |
Handling recurring incidents and significant cyber threats
Recurring incidents are the rule most likely to catch a team by surprise. Under Article 8(2) of Delegated Regulation (EU) 2024/1772, incidents that are not major individually are treated as one major incident when they occur at least twice within 6 months, share the same apparent root cause, and together meet the major criteria. The entity must assess this monthly, with the exception of microenterprises and entities under Article 16(1). The practical control is a recurrence register that records each incident's date, service, apparent root cause and the materiality figures used at classification, so that a monthly review can show why a set of incidents was or was not aggregated. An assessor will expect to see that the monthly assessment actually happened, that the root-cause label was applied consistently, and that the reasoning is written down even when the answer is no.
Significant cyber threats are classified differently. Article 18(2) of DORA sets the basis, and Article 10 of Delegated Regulation (EU) 2024/1772 applies the test: a threat is significant where it could affect critical or important functions or other entities, has a high probability of materialising, and could meet the criticality criterion or the client or geographical spread thresholds. Threat records should therefore capture the services at risk, the clients or counterparts targeted, the areas exposed, the probability reasoning, and the date of the classification decision. Because a significant threat is a classification rather than an incident, these records are often the first place a regulator looks when asking why an entity did or did not notify. Confirm with your competent authority how it expects threat assessments to be documented and whether any voluntary notification process applies to your entity type.
Where classification fails in practice and how to close each gap
Most classification failures are not caused by missing rules. They come from incident records that cannot answer the questions Article 18 asks, thresholds applied differently by each team, and recurring or threat-level events that never reach the assessment. The cards below pair each gap with a closure action the organization can check before its next incident.
No per-criterion data capture
Incident tickets often record severity and a narrative but not the facts each of the six Article 18(1) criteria needs: clients and counterparts affected, duration, downtime, geographic spread, data losses, service criticality and economic impact. Close the gap by adding one structured field per criterion to the incident record, with a named owner who fills it in during the incident rather than after closure. Check that a sample ticket can answer all six questions without a second investigation.
Thresholds applied inconsistently
Teams that hold their own private view of what a materiality threshold means will classify the same event differently. The Article 9 thresholds in Delegated Regulation (EU) 2024/1772 use percentages, counts, durations and cost limits that need agreed measurement methods, such as how the client base or daily transaction average is calculated. Close the gap by writing those calculation rules into the classification procedure and testing them against two or three past incidents. Record who approved each rule.
Recurring incidents not tracked
Individually minor incidents with the same apparent root cause can together become a major incident, but only if someone links them. Without a register that tags root causes and dates, the six-month window in Article 8(2) of Delegated Regulation (EU) 2024/1772 is easy to miss. Close the gap by assigning a root-cause code to every incident at closure and running a monthly query for repeated codes, which the rule requires for entities in scope of that assessment cadence. Confirm the query covers all business lines.
Cyber threats not assessed
Article 18(2) requires significant cyber threats to be classified, yet many security teams log threat intelligence without assessing it against the criticality, client or counterpart and geographic criteria. A threat that could affect critical functions and has a high probability of materialising is significant even when no incident has occurred. Close the gap by adding a short threat assessment step to the threat intelligence workflow, with a documented decision and the date it was taken, so that the absence of an incident is also evidenced.
Costs and losses not estimated
The economic impact criterion and the costs and losses threshold depend on figures that finance, legal and operations often hold in different places. When the estimate is missing, the classification cannot be finished inside the reporting window. Close the gap by agreeing with finance which cost categories count, such as staff time, external support, service credits and fines, and by estimating them at the first assessment with a stated method and a later update. Ask finance to confirm the categories in writing.
Classification decisions without an audit trail
A classification decision that cannot be reconstructed, including the data used, the rule applied and the person who signed it off, will be hard to defend to a competent authority. Close the gap by storing each decision with its timestamped inputs, version of the procedure and approver in the same case record as the incident. Tools such as DFIR-IRIS keep case records with an audit trail, but confirm that your configuration retains the classification fields and their history.
Who owns classification, who can help, and where the auditor stops
The financial entity owns every classification decision. Article 18 requires it to classify each ICT-related incident against the six criteria and to classify cyber threats as significant or not, and the management body remains accountable for the framework that does this. Internally, the work usually sits with the head of ICT risk or the security operations lead, with compliance and the people who run the affected services in the loop. The entity decides the thresholds it applies, records the reasoning for each call, and signs off the outcome where a major classification will trigger reporting.
- Decision ownership: Name who may classify an incident as major and who may overrule the first assessment.
- Assumptions log: Record how the entity counts clients, counterparts and transactions, since those counts drive the thresholds.
- Recurring incident review: Assign the monthly check for incidents that repeat within six months under the recurring-incident rule.
- Board visibility: Decide what the management body sees and how often.
- Sign-off trail: Keep the approval record that a supervisor will ask to see.
Check that each named decision maker can explain, without notes, why a recent incident was or was not classified as major.
An implementation partner can prepare the systems that support classification and the evidence that shows the procedure works. Typical work includes configuring a case management platform, mapping alert sources into cases, building templates for the six criteria, and writing the procedure document that staff follow. DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, so this work runs in the client's environment rather than on a vendor's hosted service. The partner does not decide whether an incident is major, and it does not sign classification records on the entity's behalf.
- Tooling setup: Configure case records, asset and evidence tracking, and audit trails in a self-hosted platform such as DFIR-IRIS, under the entity's control.
- Procedure drafting: Turn the entity's decisions into a written classification procedure with worked criteria.
- Test cases: Prepare sample incidents that exercise each threshold so the team can rehearse classification.
- Evidence preparation: Set up records that show classification decisions, timestamps and approvals.
- Handover: Train staff and document how the tooling is run and maintained.
Confirm in the written scope which deliverables the partner produces and which decisions remain with named entity staff.
Independent auditors and competent authorities test whether classification works in practice. DORA sets no certification scheme for incident classification, so no body issues a classification certificate. Supervisors use their powers under Chapter VII to review records, interview staff and check whether decisions match the criteria. An external assessor who also designed the procedure or made the decisions would be reviewing its own work, so independence depends on keeping design and assessment apart. Where a supervisor asks for a judgement, the entity provides the evidence and the reasoning, and the supervisor reaches its own view.
- Sample testing: Expect reviewers to select past incidents and trace each classification back to the criteria.
- Record review: Expect requests for the assumptions log, approval trail and recurring-incident checks.
- Interview testing: Expect staff to be asked how they would classify a scenario.
- No certificates: Do not accept any document that claims to certify DORA classification.
- Independence line: Keep the auditor out of decision ownership and out of procedure drafting.
Before the review, ask the auditor in writing which evidence they will sample and whether any part of the work falls outside their remit.
Questions about DORA Article 18 classification
How much effort does DORA incident classification take?
Effort depends mostly on how many services sit in scope and how well your incident data is recorded. Each incident must be scored against six criteria in Article 18(1): clients and counterparts affected, duration and downtime, geographical spread, data losses, criticality of services, and economic impact. Teams that already log incidents with timestamps, affected services and customer counts usually spend far less time per case than teams that reconstruct those facts after the event. Ask any provider to quote the work from a written scope that names the critical or important functions, the systems that support them and the data sources you will use. Effort also recurs, because every new incident needs scoring and the monthly review of recurring incidents must be repeated.
How long does setting up DORA incident classification usually take?
No fixed duration can be given here, because setup length depends on your environment, the number of systems in scope and the state of your existing logging. The timeline is driven by four things: mapping which services are critical or important, defining how each of the six criteria will be measured from your own data, agreeing thresholds with your compliance function, and testing the procedure on past or simulated incidents. Organizations with mature incident records tend to move faster. Ask a potential partner for a phased plan with named deliverables and dates in the written scope, and confirm the dates against your own change calendar. Also confirm the regulatory dates that apply to you, since DORA has applied since 17 January 2025.
Can we classify ICT incidents under DORA in-house?
Yes, a financial entity can run classification in-house, because the duty sits with the organization and not with any outside firm. The Article 18 criteria and the thresholds in Delegated Regulation (EU) 2024/1772 are applied by your own staff, and you remain accountable for every classification decision. Outside help is usually most useful for preparing systems, such as logging, case records and evidence handling, and for building a repeatable procedure. Consider in-house delivery if you have staff who understand both incident response and the materiality tests, and an incident record system that already captures affected clients, counterparts and transactions. Outsourcing the decision itself does not transfer responsibility.
What skills and inputs does classification need from our staff?
Classification needs staff who can read an incident in business terms and in technical terms. In practice, the work draws on:
- Incident responders who can confirm the start, end and scope of an outage or intrusion
- Service owners who know which functions are critical or important and how many clients rely on them
- Finance or risk staff who can estimate costs, losses and transaction volumes
- Data protection or legal staff who can confirm whether data was lost
- A compliance owner who signs off the classification and keeps the record
Before starting, confirm which of these roles exist in your organization, who will approve each decision, and where the supporting data will come from.
Does DORA certify that our incident classification is compliant?
No. DORA does not provide a certification scheme for incident classification, and no body issues a DORA certificate for it. Competent authorities supervise compliance using their powers under Article 50, and they judge whether your procedures, records and decisions meet the Regulation and its technical standards. The only authority-issued attestation the Regulation provides for relates to threat-led penetration testing under Article 26(7), which is outside this topic. Any firm that offers a DORA certificate for classification should be treated with caution. A useful outcome of an engagement is evidence your supervisor can review, not a certificate.
How are recurring incidents judged under DORA?
A series of incidents can count as one major incident even when none of them is major on its own. Under Article 8(2) of Delegated Regulation (EU) 2024/1772, recurring incidents are treated this way when they occurred at least twice within 6 months, share the same apparent root cause, and together meet the major criteria. Entities assess this monthly, except microenterprises and entities referred to in Article 16(1). In practice, keep a register that links incidents by root cause, date and affected service, so the monthly review can be run from records rather than memory. Confirm with your supervisor how they expect the link between incidents to be documented.
What makes an incident major under the DORA thresholds?
An incident is major when it affects critical services and either involves a successful, malicious and unauthorised access to network and information systems that may result in data losses, or meets two or more other materiality thresholds. Those thresholds in Article 9 of Delegated Regulation (EU) 2024/1772 cover client and counterpart shares, transaction volumes, duration and downtime for services supporting critical or important functions, impact in two or more member states, and costs and losses above EUR 100 000. Several thresholds have fixed numbers, so classification depends on accurate counts. Check the current text of the delegated regulation before finalizing your procedure, and keep the calculation for each threshold on file.
How DeployOpen prepares classification systems and evidence
DeployOpen plans, implements and documents the systems an organization uses to classify ICT-related incidents and cyber threats under Article 18 of DORA. The organization keeps ownership of its classification decisions, and an independent assessor or the competent authority judges whether the approach holds up.
How we scope
- Each engagement starts with a written scope that names the entities, services and incident sources covered by Article 18 classification.
- We map the six Article 18(1) criteria to the data fields your monitoring and case tools can actually populate.
- Scope also records which thresholds from Delegated Regulation (EU) 2024/1772 apply to your critical and important functions.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- We configure incident case records so each classification assessment captures criteria, sources, timestamps and the decision made.
- We set up alert triage from SIEM, EDR and other sources so that incidents enter a single case with a consistent classification workflow.
- We build recurring-incident tracking that flags events sharing an apparent root cause within the six-month window.
- We set up criteria for significant cyber threats so assessments of threat likelihood and reach are recorded consistently.
How we hand over
- Handover includes the classification procedure, decision records and configuration documentation your staff can maintain.
- We provide test cases showing how representative illustrative incidents move through each classification step.
- Evidence exports cover case history, audit trails and classification rationale that your internal audit or assessor can review.
- Your organization approves the final classification logic, and we document that approval for the file.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover threshold reviews when the delegated regulations or your service portfolio change.
- Before engaging, ask us to confirm which parts of the classification workflow are in scope and which remain with your staff or advisers.
