DORA recurring incidents: when minor incidents add up

When do recurring DORA incidents become one major incident?

Recurring incidents that are not individually major count as one major incident if they occurred at least twice within six months, share the same apparent root cause and together meet the major criteria. That rule comes from Delegated Regulation (EU) 2024/1772, Article 8(2), and it applies even when every single outage was too small to report on its own. Consider a payment institution whose card authorization service drops for a few minutes several times a month because the same database connection pool is exhausted. Each event may look minor, but if the repeated events together affect enough clients, transactions or downtime to meet the classification criteria, the entity must treat them as one major incident.

The answer is different for each organization because it depends on three records the entity already keeps or should keep: its incident register, its classification assessment for each event, and its root cause records. The register must show the dates, affected services and clients for every ICT-related incident. The classification assessment must apply the six criteria in Article 18(1) of DORA consistently across events, so that repeated events are measured the same way. The root cause records must show whether two events really share an apparent root cause. Ask your team whether these three records can be queried together for any six-month window. If they cannot, the monthly assessment the Delegated Regulation expects will be slow and hard to defend.

The organization owns this assessment and the decision that follows from it. An implementation partner can design the register fields, set up the monthly review and prepare the evidence showing how the test was applied, but no outside party certifies the result or issues a finding on it. Your competent authority may ask to see how you ran the test, so keep the monthly assessments, the reasoning behind each root cause link and any decision not to aggregate. Confirm with your competent authority which secure electronic channel and aggregated reporting format apply to your entity, and check the current detail in the DORA incident reporting operational instructions.pdf).

How the monthly recurring incident assessment works

The monthly sequence checks whether minor incidents that share an apparent root cause, occurring within six months, combine to meet the major incident criteria. It produces a documented decision that the compliance function reviews, so the outcome can be shown to a supervisor.

Pull new minor incidents from the register
Each month, the incident owner or operations lead exports every ICT-related incident recorded since the last assessment, including incidents that were classified as non-major at the time. The register must hold all ICT-related incidents, so this step depends on the recording discipline set out under Article 17. The step is done when the extract is complete, dated and signed off as the basis for the run, with its source system and export time noted.
Group incidents by apparent root cause
The analyst clusters the extracted incidents by their apparent root cause, such as the same faulty configuration change, the same unpatched component or the same failing third-party dependency. Grouping is provisional at this stage and should be based on the evidence in the incident record, not on assumptions. The output is a list of candidate clusters, each with the incident references and a short note explaining why they were linked.
Check the six-month window
For each cluster, the analyst confirms that at least two incidents occurred within a six-month period. Incidents that fall outside that window are set aside for the current run, though they remain in the register and may matter for later analysis. The check is complete when each cluster shows the dates of its incidents and states whether the threshold of two occurrences within six months is met.
Test the combined result against the major criteria
For every cluster that passes the window check, the analyst assesses the combined effect of the incidents against the classification criteria in Article 18(1) and the thresholds in the classification regulation. The test asks whether the incidents together meet the major criteria, for example by aggregating clients affected, downtime and economic impact. Where the combined result meets the criteria, the cluster is treated as one major incident. The step closes with a written calculation that shows the inputs and the result for each criterion.
Record the outcome as a documented decision
The analyst records the outcome for every cluster, including clusters that did not qualify, in the incident assessment log. Each entry states the incident references, the root cause rationale, the window dates, the criteria result and the decision, whether major and reportable or not. Records that show no major outcome still count as evidence, because they show the assessment took place. The step is done when every cluster has a decision and a named owner.
Route reportable outcomes into the reporting process
Where a cluster is treated as a major incident, the incident is entered into the reporting process under Chapter III, and the aggregated form required for recurring incidents is prepared. Ownership of the reporting decision stays with the financial entity even if reporting is handled by a provider or group function. The step is complete when the reporting workflow holds a reference to the assessment log entry, so the link between the decision and the report can be traced.
Obtain compliance function review
The compliance function reviews the month's assessment log, sampling the clustering rationale and testing the criteria calculations against the source records. The reviewer can challenge groupings, ask for missing incidents to be added and request a re-run of any cluster. The review is complete when the reviewer signs the log and any corrections are recorded with their dates. This review is what turns the assessment into a governed control rather than an informal spreadsheet.
Confirm the scope exclusions before the run
Before the first run, the compliance function confirms whether the entity is a microenterprise or falls under Article 16(1), because those entities are excluded from the monthly assessment under Article 8(2) of Delegated Regulation (EU) 2024/1772. Excluded entities still need a documented policy for recurring incidents and pattern analysis. The confirmation should be a written decision with its basis, filed with the policy documents, so a supervisor can see why the monthly run does or does not apply.

What counts as the same apparent root cause

Recurring-incident aggregation only works if the entity can show why several incidents belong together. The cards below cover the common causes entities use to group incidents, and how to record the reasoning so it can be tested later.

Shared component failure

Incidents that trace back to the same software library, database node, load balancer or certificate store often share an apparent root cause even when the symptoms differ. Check whether the affected services depend on the same component, using the asset inventory and dependency maps rather than memory. Record the component name and version so a reviewer can confirm the link. Illustrative example: two outages in different business services both traced to one expired internal certificate.

Configuration change

A configuration change that was pushed to several systems can cause incidents that look unrelated in the monitoring tools. Compare change records, deployment logs and configuration baselines for the period before each incident. Where the same change ticket, script or template touched more than one affected system, the grouping rationale should cite that ticket.

Third-party provider fault

When incidents are caused by the same ICT third-party service provider, the apparent root cause sits in the provider's service, even if the entity's own systems showed the symptoms. Link each incident to the contract, service identifier and provider notification or status report. Confirm with the provider how it classifies its own faults, because its explanation may later change the grouping.

Process or control gap

Repeated incidents sometimes come from the same missing or weak step, such as a skipped approval, an unmonitored backup job or a patch that was never scheduled. The grouping test here is whether each incident would have been prevented by the same control. Document the control expected, the control that failed to operate, and the evidence that shows the gap.

Recurring capacity limit

Incidents caused by demand exceeding capacity, such as memory exhaustion at month-end or queue saturation during peak payment runs, form a pattern tied to load rather than to a single defect. Compare capacity metrics and load timelines across incidents. Note the limit reached and the trigger, so that a recurring pattern is distinguished from a one-off spike.

Documenting the grouping rationale

Each grouping should be recorded with the incidents involved, the shared factor, the evidence reviewed and the date of the decision. Keep the rationale in the incident register so that an assessor can follow it. The initial grouping is provisional: when the final root cause analysis identifies a different cause, the entity should update the grouping, record the change and explain why it was made.

How aggregated reporting handles recurring incidents

When recurring incidents are treated as one major incident, the entity does not file a separate major report for each occurrence. Instead, the occurrences are reported in aggregated form under Article 3, so the authority sees a single major incident built from the pattern. The aggregation applies only when the recurring incidents are not individually major, share the same apparent root cause and together meet the major criteria.

Trigger: at least two occurrences within six months with the same apparent root cause.
Monthly assessment: review the pattern every month, except for microenterprises and entities under Article 16(1).
Cumulative impact: assess clients, duration, geographical spread, data losses, service criticality and economic impact across all occurrences together.
Occurrence log: record each occurrence, its date and its link to the suspected root cause so the aggregate can be justified later.

Check with your competent authority how it expects aggregated submissions to be structured and how it wants individual occurrences listed.

Root cause procedures and the duty to spot patterns

Article 17 of DORA turns incident handling into a record-keeping and learning duty, not only a reporting duty. Under Article 17(1) and (2), the financial entity must record all ICT-related incidents, not just the major ones, and must have procedures that identify root causes, document them and address them so the same failure does not come back. For recurring incidents, this is where the six-month test begins to matter: an entity cannot judge whether several minor events share an apparent root cause unless each one was logged with enough detail to compare. The incident log is the foundation of the recurrence analysis, so every ticket needs a root cause field, even when the entry is marked provisional.

Article 22 of Delegated Regulation (EU) 2024/1774 adds the policy duty. The ICT-related incident management policy must document the incident process and analyse significant or recurring incidents and the patterns in their frequency. In practice, the analysis is a periodic review of the incident log grouped by affected service, component, vendor, change type and apparent cause. A useful review asks which services fail most often, whether incidents cluster after particular changes or releases, whether one provider or certificate, configuration template or batch job keeps reappearing under different ticket titles, and whether the time between recurrences is shrinking. Those questions also feed the monthly assessment described above. Confirm with your own policy owner how often the review runs and who signs it off, because the regulation sets the duty but leaves the cadence to the entity's documented process.

Supervisors usually ask to see evidence rather than a statement that patterns are reviewed. Expect requests for the incident policy and procedure, the complete incident register with classification and root cause fields, the pattern review records with their dates and approvers, and the corrective actions opened from each finding with their owners and closure evidence. Illustrative example: if a payment routing service has four minor outages in five months, each with a different ticket title but a shared expired certificate in the load balancer, the review should show that link, the change to automated renewal and the check that confirms the fix held. Ask your team whether your incident tool can tag incidents by component and root cause, and whether a query can produce that view for a supervisor within a day, because a register that cannot be searched is hard to defend.

What makes recurring incident work heavier or lighter

Recurring incident work grows or shrinks with a small set of drivers. Each one below is a point where the organization can add structure before a pattern of minor events turns into a reportable major incident.

Incident volume and tagging

The more incidents an entity logs, the more pairs it must compare each month to test whether two or more share an apparent root cause. Keep one register for all ICT-related incidents, including those judged minor, so the monthly assessment works from a complete list. Check whether the register captures every incident, not only those that reached the service desk.

Classification quality at intake

Recurring incidents are only detected if the first classification is consistent. Assess each incident against the six classification criteria at intake, record the reasoning, and reclassify when new facts emerge. Inconsistent intake decisions are the most common reason a pattern goes unnoticed.

Root cause tagging

A same root cause test only works if the root cause field is filled in with a consistent taxonomy. Free-text tags such as "network issue" hide patterns that a controlled list of causes would reveal. Ask who sets the tag, when it is reviewed, and whether a provisional tag is updated once forensic work completes.

Number of ICT providers involved

Incidents that pass through several ICT third-party providers are harder to correlate because each provider keeps its own logs and tickets. Establish a contact list and a log-sharing arrangement with each provider before an incident occurs. Confirm which provider contracts give you timely access to the event data you need for root cause work.

Legacy systems

Older platforms often generate noisy alerts, lack consistent logging and depend on undocumented manual workarounds. These conditions produce repeated low-impact events that look unrelated. Inventory legacy components, confirm which ones write audit logs, and decide whether a recurring fault in such a component justifies a dedicated root cause review.

Entities and jurisdictions

Groups with several legal entities or operations across member states must compare incidents across all of them to detect a pattern. Central correlation of incidents avoids each unit reviewing its own minor events in isolation. Confirm which supervisor receives aggregated reports and how each entity's register feeds the group view.

Who is paid for recurring incident work

This table breaks down who pays for the recurring incident work DORA expects, from monthly assessment to independent review. Read each row for whether the cost is one-time or recurring and what pushes it up. No figures are given because none were supplied for this topic, so use the drivers to frame your quote request.

Cost component	Who is paid or who carries it	One-time or recurring	What drives the cost
Monthly recurrence assessment	Internal incident and compliance staff, who review each cluster of incidents against the six-month and same-root-cause test	Recurring	Number of incidents logged each month, how many business units report them, and how often the assessment is documented
Incident register and pattern analysis tooling	Your organization pays for licences or hosting, or builds the register in an open-source ticketing or logging platform	Mostly one-time setup, then recurring upkeep	Volume of incident records, integration with monitoring and service desk tools, and retention periods for evidence
Process and evidence design	An implementation partner, under a written fixed scope, defines the recurrence procedure, root cause steps and aggregated report format	One-time	Number of ICT systems in scope, how many entities or group companies share the process, and existing incident maturity
Root cause procedure and policy updates	Internal security and operations leads, with optional partner support to align the ICT-related incident management policy	One-time, with periodic review	Size of the policy set, changes in the ICT estate, and any supervisor feedback on incident patterns
Aggregated reporting to the competent authority	Internal staff or a contracted reporting provider, where the entity remains responsible for the submission	Recurring	Number of recurring incidents to aggregate, reporting channel requirements, and whether reports are combined with other notifications
Independent review by an auditor or assessor	Your organization pays an independent firm if it chooses an external review of the recurrence analysis	Optional, recurring if repeated	Scope of the review, sample size of incident files, and whether the review covers third-party-caused incidents

How post-incident reviews feed back into recurring incidents

Article 13(2) of DORA requires a post-incident review after a major ICT-related incident that disrupts core activities. The review checks whether procedures were followed and whether the actions taken were effective, and it looks at specific points: how promptly the entity responded, the quality and speed of forensic analysis, and how escalation and communication worked. For entities other than microenterprises, the resulting changes must be communicated to the competent authority on request. For a recurring-incident programme, the review is the moment to ask whether this major incident is the latest instance of a pattern that the monthly assessment should already have flagged.

A review can expose a recurring pattern that the monthly assessment missed for a simple reason: the monthly check looks at individual incidents against the six-month, same apparent root cause test, and the root cause may only become clear once forensic analysis is complete. Illustratively, a review might find that three earlier incidents logged as unrelated shared a misconfigured change window that the post-incident analysis has now traced. The reviewer should check the incident register for earlier entries with the same component, vendor or change type, then confirm whether the prior records were classified with root cause fields that are accurate enough to support aggregation. Ask the reviewer to record any such link explicitly, and do not wait for the next monthly cycle to act on it.

The post-incident review and the monthly recurring-incident assessment should draw on one incident register, not two. Each entry should carry a shared root cause reference, the date of each occurrence, the classification decision and the review outcome, so that a finding in one process updates the other. Confirm with your incident management owner which system holds the register, who may change root cause fields, and how changes are dated. Under Article 17(2) the root cause must be identified, documented and addressed, so the register is the evidence that links the review's findings to the aggregated report. Keep the register under the same retention rules as the rest of your incident evidence.

Questions buyers ask about DORA recurring incidents

Must a small financial firm run the monthly recurring incident assessment?

Not always, but the exemption is narrow. Microenterprises and entities covered by Article 16(1) of DORA are excluded from the monthly assessment under Delegated Regulation (EU) 2024/1772, Article 8(2). Every other financial entity, whatever its size, must check each month whether incidents that were individually below the major threshold occurred at least twice within six months, shared the same apparent root cause and together meet the major criteria. Small firms still have to record all ICT-related incidents and analyse patterns in their frequency. Confirm your status with your competent authority before you rely on the exemption.

How long does it take to set up recurring incident tracking?

No reliable duration can be given in general, so treat any single number with caution. The time depends on how many sources feed your incident records, such as ticketing, monitoring, service desk and provider notifications, whether records already capture root cause and affected services, and how consistently the Article 18(1) classification criteria are applied today. Fixed-scope engagements start with a written scope, deliverables and timeline agreed before work begins. Ask for a plan that lists each data source, the recurrence rule, the monthly review step and the evidence each step produces.

What does the team need to provide for a recurrence process?

The process needs inputs from several parts of the organization:

Incident records with timestamps, affected services, affected clients and a root cause field that is filled in consistently
Access to the ticketing, monitoring and provider reporting systems where incidents originate
Named owners for the incident process and for the monthly review, with the contact lists that the ICT-related incident management policy must keep under Delegated Regulation (EU) 2024/1774, Article 22
Approved policy text and evidence that the management body has reviewed it

Without consistent root cause data, the same-root-cause test cannot be applied, so that gap should be closed first.

Can we run recurring incident analysis in-house?

Yes. DORA places the duty on the financial entity, and nothing in the Regulation requires an external party to perform the monthly assessment. Your team keeps ownership of the decision on whether incidents are major, of the root cause conclusions and of what is reported to the competent authority. Outside help can be useful for building the pattern rule, reporting templates and dashboards with open-source tooling, and for preparing the evidence that the process runs. DeployOpen plans, implements and documents self-hosted platforms inside your environment and prepares systems and evidence, but it does not issue reports or certifications. Decide early which steps your staff can sustain after handover.

Will an auditor or supervisor review our recurring incident process?

Supervision comes from the competent authority, which uses its powers under Article 50 of DORA. DORA sets no certification scheme for incident management, so there is no authority-issued certificate for this process. The only authority-issued attestation the Regulation provides for is the one confirming that a threat-led penetration test met the requirements under Article 26(7). Independent auditors may test the process as part of your wider assurance work, and your authority may ask for the monthly assessment records, the root cause analyses and the post-incident reviews. Ask your auditor and authority what evidence they expect before you finalize the design.

What happens if a recurring incident pattern is missed?

A missed pattern can mean that incidents which together meet the major criteria are not reported as one major incident, which may leave a reporting obligation unmet. It can also leave the root cause unaddressed, since Article 17 of DORA requires root causes to be identified, documented and addressed to prevent recurrence. Once a gap is found, document it, correct the classification with the competent authority's guidance and reassess whether the earlier incidents need a report. Member states must provide administrative penalties and remedial measures under Chapter VII, so a repeated failure can carry supervisory consequences. Test the monthly rule against past incident data to find gaps before supervisors do.

Questions to ask before hiring help with incident pattern analysis

Outside help with recurring incident analysis can speed up the work, but the regulated entity remains responsible for its incident process and its reports. The questions below help you test experience, ownership, scope, evidence and independence before any statement of work is signed.

Relevant DORA incident experience

Ask who on the team has worked on ICT incident classification under DORA, and whether they have applied the six-month, same root cause test in practice. Ask for a description of how they handled a pattern where several low-impact events were later combined into one major incident. Check that they understand the monthly assessment and the aggregated reporting form, not only the general concept of incident management. Ask how they keep up with updates to the supporting technical standards.

Ownership stays with the entity

Confirm in writing that the financial entity keeps ownership of its incident management policy, its classification decisions and its reports to the competent authority. The partner should prepare analysis and recommendations, while named staff approve them. Ask who signs off a recurring incident classification and who receives the record of that decision. A partner who offers to make classification calls on your behalf is taking on a role your management body must still control.

Written scope and deliverables

Ask for a fixed scope that lists the incident records to be reviewed, the period covered, the analysis method, the deliverables and the dates for each. Check whether the work includes root cause review, pattern analysis across incident frequency, or only a one-time data review. Confirm what is excluded, such as live incident response or regulator contact. Agree how changes to scope are documented and priced before work begins.

Evidence handed over

Ask which records the partner will return at the end of the work. Strong outputs include the incident register with classification notes, the pattern analysis method, root cause records, and the evidence that the monthly assessment was performed and reviewed. Confirm the format, the location where records will be stored, and how long the entity must keep them. Ask whether the partner retains any copies after handover and how that retention is governed.

Independence and conflicts

Ask whether the partner also operates the ICT systems that generated the incidents, since reviewing your own platform's failures can create a conflict of interest. Check whether the partner has a commercial relationship with any ICT provider involved in the incidents. Note that only an independent auditor, assessor or certification body issues reports or attestations. DORA sets no certification scheme for incident management, so a partner's analysis is an input to your own assessment, not a certificate.

How DeployOpen prepares recurring incident evidence

DeployOpen helps financial entities and their ICT providers prepare the systems, incident records and evidence needed to show how recurring incidents are detected, grouped and analysed under DORA. The organization keeps ownership of its controls and classification decisions, and DeployOpen supports the technical work and documentation within a written scope.

How we scope

We agree in writing which incident sources, platforms and services fall in scope for recurring incident tracking.
We confirm with you how incidents are logged today, including tickets, alerts and provider notices, before any build work starts.
Engagements are fixed-scope, with deliverables and timelines agreed in writing; ongoing support is available as a retainer.

How we build

We configure self-hosted incident tracking so each record carries fields for affected service, apparent root cause and occurrence date.
We set up reports that group incidents with the same apparent root cause and show counts across rolling six-month windows.
We document the monthly assessment procedure, with the review steps, owners and the evidence each review produces.

How we hand over

We deliver the incident records, pattern reports, procedure documents and configuration records inside your own infrastructure.
We walk your incident, risk and compliance teams through how each recurring-incident decision is recorded and who signs it off.
We state which parts of the classification decision remain with your management body and which tasks your auditor or supervisor will test.

How we support

We can help test the pattern analysis against a sample of past incidents so you can confirm the logic before supervisors ask.
We can update reports and procedures when your services, providers or incident sources change, under a retainer or a new scope.
Questions on how your competent authority expects recurring incidents to be reported should be confirmed directly with that authority.