Can we outsource DORA incident reporting to a third party?
Yes, within limits. Article 19(5) of DORA allows a financial entity to outsource the reporting obligation for major ICT-related incidents to a third party, but the entity remains fully responsible for the reports and for their accuracy and timeliness. Before the first report goes out, the competent authority must be told about the outsourcing, and that notice must name the third party and give its contact details and identification code, as Article 6 of Implementing Regulation (EU) 2025/302 requires.
Whether the arrangement works depends first on who the third party is. A group entity that files on behalf of a regulated subsidiary raises different questions from an external provider, and both differ from an ICT provider that caused the incident itself. Check whether the reporting function is written into the contract and the internal incident policy, whether the named person can meet the initial, intermediate and final report deadlines, and whether your supervisor expects a separate notice for each outsourcing arrangement. Confirm these points with your competent authority, since its supervisory practice shapes what it will accept.
Where a provider is the source of an incident affecting several financial entities in one member state, Article 7 of Implementing Regulation (EU) 2025/302 allows one aggregated report, but only with the authority's permission and only where reporting has been outsourced to that provider. Significant credit institutions, trading venue operators and central counterparties must still report individually. DeployOpen can help prepare the systems, contract evidence and reporting runbooks that support such an arrangement, including the evidence an auditor or supervisor would ask to see. Responsibility for filing, and for any decision to outsource, stays with the financial entity and its supervisor.
How to set up outsourced reporting step by step
This sequence takes an entity from deciding to outsource DORA incident reporting to a live, accepted first report, with the competent authority informed and the contract and submission channels checked in advance. Each step ends with a record that shows it is complete.
Confirm the outsourcing decision and eligibility
The management body or the accountable executive confirms that the entity will outsource reporting to a third party while remaining fully responsible for every report under Article 19(5) of DORA. The compliance lead checks that the entity's reporting process, classification method and sign-off roles stay with the entity. The output is a signed internal decision that names the third party, the scope of reports it will prepare and submit, and the person who approves each report before submission.
Notify the competent authority before the first report
Before the first notification, the entity informs its competent authority that reporting is outsourced, as Article 6 requires. The notice gives the third party's name, contact details and identification code. The compliance lead sends it through the channel the authority specifies and keeps the sent notice and any acknowledgement. The output is a dated record showing the authority was told before any report went out.
Agree the reporting contract with the provider
Legal and procurement confirm that the contract with the third party covers incident reporting. Under Article 30(2), ICT services contracts must include incident assistance at no cost or a pre-agreed cost, cooperation with authorities, and clear service descriptions and locations. The contract should also set who reviews drafts, how quickly the provider must hand over information for each deadline, and what happens on termination. The output is a signed contract addendum that the entity's legal team has reviewed.
Map internal roles and information flows
The incident response lead and the third party agree who supplies facts, who approves wording, and who has authority to submit. The entity documents how incident data moves from its monitoring and ticketing systems to the provider and back for review. The output is a short reporting runbook with named roles, escalation contacts and the approval step that the entity keeps before any submission.
Test submission through the secure channels
Under Article 4, reports must be submitted through the secure electronic channels the competent authority makes available. The third party and the entity run a test submission through those channels, using the templates and operational instructions the authority publishes, and confirm that the submitting account, credentials and identifiers work. The output is a successful test submission record and a list of any template or access problems resolved before go-live.
Run the first live report under entity approval
For the first real major incident, the third party prepares the initial report using the agreed runbook, and the entity's approver checks content and accountability before the report is submitted. The entity keeps the submitted report, the approval record and the authority's acknowledgement. The output is an accepted first report and a short review of what worked and what needs changing in the runbook or contract.
What stays with the entity when a third party files
Outsourcing reporting moves the filing task, not the legal duty. The entity remains fully responsible for every report submitted on its behalf, so the cards below cover what it must still own, decide and be able to prove to its competent authority.
Timeliness and content of every report
Under Article 19(5), the entity stays fully responsible even when a third party submits the report. Deadlines and content are the entity's exposure, so it should hold a written reporting calendar, named internal reviewers and a record of who approved each submission. Check that the provider's filing workflow cannot send a report the entity has not seen. Illustrative: a provider files a late intermediate report because its ticket queue was full, and the entity is still the party the authority questions.
Classification and reclassification decisions
The entity decides whether an incident is major and whether it should be reclassified from major to non-major under Article 5. A provider can supply facts, but the judgment belongs to the entity. Keep the classification assessment, the criteria applied, the data used and the sign-off, and record every reclassification with its reasons. Ask the provider to commit to a timeline for supplying the impact data the entity needs to decide.
The final report and root cause
The final report, including the root cause analysis, is the entity's document even when the provider drafted it. Review the provider's root cause findings against the entity's own system knowledge and confirm that remediation dates are accurate and tracked. Retain the draft versions, the reviewer comments and the final approved text. Without these records, the entity cannot show that its management body reviewed the conclusions.
Oversight of the provider's filing
The entity must monitor how the provider handles reporting, not only read the output. Set service levels for notification, review cycles for filing quality and a method to test whether the provider's records match the entity's incident log. Schedule periodic reviews of the provider's access to the authority's secure channels and of who at the provider can submit. Record each review and any corrective action agreed.
Notice to the authority before first filing
Article 6 requires the entity to tell its competent authority before the first notification that reporting has been outsourced, naming the third party and giving its contact details and identification code. Keep a copy of that notice, the date it was sent and any acknowledgment. If the provider changes, the entity should confirm whether the authority needs updated information before the next report goes out.
Contract terms that support the entity
Article 30(2) requires ICT services contracts to include incident assistance, cooperation with authorities, and data return and location terms. For reporting, the contract should set who supplies data, within what period, at what cost, and what happens on termination. Ask the provider to confirm these clauses in writing and check them against the entity's own incident procedures before the outsourcing starts.
When one aggregated report covers several entities
A provider can file one aggregated report for an incident it caused only when several financial entities are affected, they sit in the same member state, their competent authority is the same, and reporting has been outsourced to that provider. The rule appears in Article 7 of Commission Implementing Regulation (EU) 2025/302, which applies the DORA reporting framework, and the authority must permit the approach before it is used. Permission is not automatic. Ask each relevant authority in writing whether it accepts an aggregated report for provider-caused incidents, and keep that answer on file before the first incident occurs. Some entities in the group may be supervised by different authorities, which removes them from the arrangement even if the provider and the incident are the same.
Two exclusions need a check against your own register. Significant credit institutions, trading venue operators and central counterparties must report individually, so a provider serving a mix of entities cannot bundle those reports even where the other conditions are met. Confirm the classification of each client entity, including whether a credit institution has been designated significant by the competent supervisor, and map the result to the list of entities covered by each outsourcing arrangement. Record the provider's name, contact details and identification code in the notice you send to each authority before the first report, as required by the outsourcing notification rule.
Recurring incidents follow a different aggregation rule. Under Article 3 of Delegated Regulation (EU) 2025/301, recurring incidents that are individually minor but repeated may be reported in aggregated form rather than one by one. For a provider, this means its incident log should tag each occurrence with a shared root cause reference and the entities affected, so the aggregated report can be produced from the same data as the individual reports. Confirm with your provider that its ticketing records capture these fields and that the same data reaches your team within the timelines you agreed in the contract.
Which reporting model fits your group or provider relationship
When your own team prepares and submits every report, no outsourcing arrangement exists, so no third-party notice to the authority is needed. The entity still owns every deadline, classification decision and field in each report, and the team carries the full workload during an incident.
- Authority notice: None for outsourcing, because no third party files on your behalf. Confirm that your competent authority's secure submission channel is set up and tested before an incident occurs.
- Combined reports (Article 2): The initial, intermediate and final reports may be combined if each deadline is still met. Plan the timeline so the initial report is not held back waiting for final content.
- Main risk: Capacity during an incident, especially outside working hours, when classification, containment and drafting compete for the same people.
- Preparation: Pre-fill report templates, define who classifies an incident and test access to the channel described in Article 4.
Check whether the people on call can meet the earliest reporting deadline without the report-writing lead being available.
Here a third party files reports for one financial entity. The entity stays fully responsible under Article 19(5) of DORA, so the filer acts for the entity and does not replace it in law. The authority must be told of the arrangement before the first report leaves the third party.
- Notice first: Inform your competent authority of the outsourcing before the first notification is filed. A report from an unnotified filer creates a supervisory gap that is hard to close after the fact.
- Identification details: The notice must give the third party's name, contact details and identification code, as the implementing rules require.
- Combined reports (Article 2): The same combination option applies, but the filer needs the entity's data early enough to meet each deadline.
- Main risk: The entity assumes the filer handles accuracy and deadlines, while the filer works from incomplete information. Access rights, data sharing terms and escalation contacts are often left vague.
Confirm that the notice has been filed, who keeps the deadline calendar and exactly which incident data the third party receives and when.
In this model, one group entity files reports for several financial entities within the same group. Each member remains a separate regulated entity with its own obligations, so the group filer does not change the member's responsibility or its classification of an incident.
- Notice per arrangement: Each member that outsources its reporting needs the notice described in the implementing rules, identifying the group filer by name, contact details and identification code.
- Aggregation limits: The aggregated report option in Article 7 covers incidents caused by an ICT provider. For an incident originating inside the group, confirm with each authority whether a single filing is acceptable, because the default is individual reporting.
- Combined reports (Article 2): Combination is available where deadlines are met, but each member's content must still be complete and accurate.
- Main risk: Members may sit under different competent authorities or be classified differently, so one filing can satisfy one supervisor and not another. Disagreement between members on severity can delay the filing.
Before relying on a group filer, ask each supervisor in writing how it will receive filings covering several members and who signs off each member's classification.
An ICT provider can file one aggregated report when it is the source of an incident that affects several financial entities in the same member state. The entities must be supervised by the same authority, and that authority must permit the approach. Significant credit institutions, trading venue operators and central counterparties must still report individually.
- Authority permission: The provider cannot aggregate on its own initiative. Obtain the authority's permission before the first aggregated report and confirm that the outsourcing notice is on file for each client that relies on it.
- Individual exceptions: Check whether any affected client is a significant credit institution, trading venue operator or central counterparty, since those clients must report separately.
- Combined reports (Article 2): Initial, intermediate and final content can be combined if deadlines hold, which matters when the provider's own analysis is still running.
- Main risk: A single report may not separate each client's impact, classification and recovery figures accurately. Clients may also lose sight of their own position if the provider's report is the only record they receive.
Check your contracts for incident assistance at no cost or pre-agreed cost, because aggregated filing depends on the provider's cooperation during the incident.
Contract terms the provider agreement must carry
Article 30(2) of DORA lists clauses every ICT services contract must contain. For incident reporting, the clauses that matter most are the ones that decide how fast the provider's data reaches your team and how your reports are assembled. Each card below names one clause, why it affects reporting timeliness, and what to ask the provider to confirm in writing.
Service descriptions and reporting scope
The contract must describe the ICT services in enough detail that you can tell which incidents originate in the provider's systems. Vague descriptions make it hard to decide who classifies an event and who starts the clock. Ask the provider to confirm in writing which services, components and support tiers fall under the agreement, and which logs and alerts it will share with you for classification.
Service and data locations
Where the service runs and where incident data is stored affects how quickly you can obtain evidence and which authority's rules apply to the records. Ask the provider to confirm, in writing, every location where your data is processed, stored or backed up, including subcontractor locations, and to notify you before any change that would move them.
Data protection and return
Incident reports rely on logs, timelines and affected-service data that the provider holds. The contract should set out how that data is protected, how long it is kept and how it is returned or deleted at exit. Ask for a named retention period for incident records and a defined export format, so that evidence is still available when a final report or supervisory request arrives.
Incident assistance at no or pre-agreed cost
This is the clause that most directly affects reporting deadlines. The provider must help you when an incident occurs, and the contract should say whether that help is free or what it costs in advance. Ask the provider to confirm its response commitments for incident support, who on its side will supply the root cause and impact data, and whether any assistance is billed separately.
Cooperation with authorities
Your competent authority may ask the provider for information directly or through you. The contract should oblige the provider to cooperate with your authority and to share information requested in the course of supervision. Ask the provider to confirm that it will respond to authority requests within the timeframe your reporting process needs and that it will support any supervisory inspection.
Termination rights
Termination rights matter for reporting because a provider that cannot meet incident commitments needs to be replaceable without delay. The contract should allow termination in defined circumstances, including repeated failure to support incident reporting. Ask the provider to confirm the exit assistance it offers and the notice it requires, so that outsourced reporting can move to another party before the next incident.
Participation in security awareness training
Staff at the provider who handle your incidents need to recognize events, escalate them and understand your reporting obligations. The contract should require the provider's staff to take part in your security awareness and training programmes where relevant. Ask the provider to confirm which training its incident responders complete, how often it is refreshed, and how it is recorded.
Who does what in an outsourced reporting setup
The financial entity remains fully responsible for every report, even when reporting has been outsourced under Article 19(5). Its compliance and incident owners keep the decisions that define the obligation: whether an incident is major, whether a reclassification is needed, and what the final report says about cause and impact. Outsourcing moves operational work, not accountability.
- Accountability: the entity's management body and incident owner remain responsible for the content and timeliness of every report.
- Major classification: the entity decides whether an incident meets the major threshold and documents the reasoning under the Delegated Regulation (EU) 2025/301 criteria.
- Authority notice: the entity informs its competent authority before the first report, giving the third party's name, contact details and identification code, as Article 6 requires.
- Final sign-off: an accountable officer approves each submitted report and the root cause content in the final report.
- Usually outsourced: report drafting, data collection from logs and tickets, and secure submission through the channels the authority provides.
Before signing any outsourcing arrangement, confirm in writing who approves each report version and how fast the entity can override a draft.
The third party that prepares or files reports works on the entity's behalf under a contract that must meet the ICT services requirements of Article 30(2). Its role is operational: gathering evidence, drafting the initial, intermediate and final reports, and submitting them on the agreed timetable. It cannot make the entity's classification or disclosure decisions.
- Drafting and data work: the reporter collects logs, timelines and impact data and turns them into the report fields the authority expects.
- Submission: the reporter files through the secure electronic channels provided by the competent authority, under the entity's credentials and approval process.
- Contract terms: the agreement should set service levels for reporting, data locations, cooperation with the authority and the entity's right to terminate.
- Provider-caused incidents: where the reporter is also the ICT provider that caused the incident, it may prepare one aggregated report only if the authority permits it under Implementing Regulation (EU) 2025/302, Article 7.
- Records: the reporter keeps evidence and audit trails that the entity can produce during supervision.
Check whether the reporter is an ICT provider with a conflict of interest in describing its own failure, and how the contract separates those roles.
The competent authority supervises the entity's compliance and sets the mechanics of reporting. It receives the notice of outsourcing, provides the secure channels for submission and decides whether an aggregated report for a provider-caused incident is allowed. It issues no certificate of reporting compliance, since DORA does not create a certification scheme.
- Notice of outsourcing: the authority must be told of the outsourcing before the first report, with the third party's details.
- Permissions: the authority decides whether one aggregated report may cover several entities affected by the same provider in a single member state.
- Individual reporting exceptions: significant credit institutions, trading venue operators and central counterparties must report individually.
- Supervision: the authority can examine reports, outsourcing arrangements and the evidence behind them under its Chapter VII powers.
- Channels and format: the authority defines the secure submission route and the templates that reports must follow.
Confirm with your authority which forms, portal and notice format apply to your entity type before you design the process.
How to choose a reporting partner or provider
A reporting partner takes on the mechanics of submitting DORA incident reports, but the financial entity keeps full responsibility for every deadline and every submission. The cards below set out the checks procurement should run before signing, and the questions to put to each candidate.
Deadline performance under the reporting timeline
Ask how the provider will meet the initial, intermediate and final report deadlines for a major incident, including out-of-hours coverage and who approves each submission. Ask for the escalation path when the provider's own systems are the cause of the incident, since that is the case where the provider is least able to report quickly. Test the process with a tabletop exercise before go-live, and record the timings achieved.
Secure channel access
Confirm that the provider can use the secure electronic channels that the competent authority makes available for submission, and who holds the credentials. Agree how credentials are issued, rotated and revoked, and how access is removed when the contract ends. A reporting partner that cannot reach the channel on time leaves the entity exposed even if the report is ready.
Named contacts and the identification code
The authority must be told the third party's name, contact details and identification code before the first report. Ask the provider to confirm each name it will put forward, its role and a backup for each role. Check that the identification code is correct against what the entity has registered, because a mismatch will delay acceptance of the outsourcing notice.
Sector and supervisor experience
Ask for evidence that the provider has prepared incident reports for entities supervised by the same authority and of the same type. Ask how it tracks changes to the reporting templates and operational instructions, and who updates its procedures when they change. Experience with one type of entity does not carry over automatically to a different supervisor.
Exit and transition terms
Write exit terms that cover the return of incident records, the handover of open reports, and the notice needed to appoint a new partner. Make sure the entity can notify the authority of a change of third party before the next report is due. Ask how long the provider keeps incident evidence after termination and how it is returned in a usable format.
Questions to ask before signing
Ask whether the provider will accept responsibility for its own errors in reports, what assistance it gives during a major incident at no or pre-agreed cost, and whether it will take part in training. Ask who the entity can call at any hour, and how the provider handles a request from the authority for more information. Note that DORA sets no certification for reporting providers, so ask for evidence of process and staffing rather than a badge.
Questions buyers ask before outsourcing incident reporting
Can a financial entity keep DORA incident reporting in-house?
Yes. Reporting under DORA is not mandatory to outsource, and an entity can run the whole process with its own staff and systems. Outsourcing is an option the Regulation allows under Article 19(5), not a requirement. The deciding factors are whether the team can meet the initial, intermediate and final report deadlines around the clock, whether it can classify incidents consistently under the incident classification criteria, and whether it can maintain secure submission through the channels the competent authority provides. Keeping reporting in-house means your own people carry the workload of collecting, validating and submitting each report, and that effort rises sharply during a major incident. Confirm your capacity against the reporting timelines in the technical standards before you decide.
What must the notice to the authority contain before outsourcing?
Under Article 6, an entity that outsources reporting must inform its competent authority before the first notification is submitted. The notice must name the third party, give its contact details and provide its identification code. Implementing Regulation (EU) 2025/302 also requires the authority to be told before the first report goes out, so the timing matters as much as the content. Prepare the notice early, confirm the provider's details are accurate and current, and make sure the contract names the same provider. If the provider changes, plan a fresh notice before the new arrangement takes effect. Check the exact format and channel with your authority, since national practice on how the notice is lodged can differ.
Can a group entity file incident reports for other group entities?
A group entity can handle reporting for other entities only within the outsourcing rules, and the entity that holds the obligation remains fully responsible. The reporting arrangement must be documented in the contract, and each relevant competent authority must be informed under Article 6 before the first notification. Where a provider causes an incident affecting several financial entities in one member state supervised by the same authority, Article 7 allows one aggregated report, but only if the authority permits it. Significant credit institutions, trading venue operators and central counterparties must still report individually. Ask your authority whether aggregation is available before designing the group workflow.
Who signs the final incident report when a third party submits it?
The financial entity signs off on the content, because it is the party that remains fully responsible under Article 19(5). The third party can prepare, format and submit the report, but accountability for accuracy and timeliness stays with the entity. In practice, this means the entity needs an internal approval step with named owners who review the root cause, impact and remediation sections before submission. Set the sign-off rules in your incident procedure and make sure the provider's staff know who approves what. Your own management body and internal records should show that the entity reviewed the content, not only that the provider sent it.
What effort does outsourcing incident reporting shift, and what stays with you?
Outsourcing moves the mechanical work of drafting, formatting, tracking deadlines and submitting reports to the provider, but it does not move the analysis or the accountability. The main drivers of effort are the number of incident types your entity handles, how well your internal logs and classification data are structured, the depth of information the provider needs from your teams during an incident, and how many authorities and reports each event triggers. Your staff still need to supply facts, approve content, and run the internal review. Effort also recurs: the onboarding of the arrangement is one-time, while ongoing coordination, testing of the escalation path and updates to the notice are recurring. Ask any provider to describe, in writing, which tasks it performs and which require your input.
What happens if the provider misses a reporting deadline?
The entity remains responsible for meeting the deadline, so a provider's delay is still the entity's failure in the eyes of the supervisor. Your contract should set escalation steps, named contacts, and the information the provider must give you as deadlines approach, so you can file yourself if needed. Test the fallback path before a real incident, including who has access to the submission channel and whether internal staff are trained to submit. Contract terms should also cover incident assistance, cooperation with authorities and termination rights, which Article 30(2) requires in ICT services contracts. Confirm with counsel how any liability is allocated, because the Regulation does not transfer regulatory responsibility to the provider.
What the Digital Omnibus could change later
The Digital Omnibus proposal, COM(2025) 837, would change where some DORA incident reports go. It proposes amending Article 19 so that major incident reports and voluntary threat notifications pass through a single entry point under NIS2. Procedure 2025/0360(COD) was awaiting committee decision as of October 2026, so the current Article 19 workflow still applies and the outsourcing steps described above remain the operative requirements. Treat the proposal as a possible future change, not a settled one.
Start by confirming status with your competent authority and by checking the procedure record on the European Parliament Legislative Observatory). Ask the authority whether it expects to receive reports through the current channels, whether it has said how the single entry point would work for entities that outsource reporting, and whether any transition period is planned. Record the answers and the date you asked, because the procedure can move quickly and your evidence of the outsourcing notification should show what you knew at each point.
Keep the contract with your reporting provider flexible. Write the reporting service description so that the provider submits through the secure channels the authority designates at the time, not through a named portal, and require the provider to support changes to submission routes, formats and contacts without a new procurement. Include a clause that obliges the provider to cooperate with any change to the reporting path and to update the notification you gave the authority. Build the change into your annual review of the outsourcing arrangement so that a new entry point does not leave reports unsent.
