What Implementing Regulation 2025/302 asks entities to produce for incident reports
A compliance lead who must send major incident reports under DORA needs to know one thing first: the report has to arrive in a fixed format, with fixed definitions, on fixed steps. Implementing Regulation (EU) 2025/302 supplies exactly that. It is the implementing technical standard under DORA Article 20, first paragraph, point (b), and it sets the Annex I template for initial notifications, intermediate reports and final reports on major ICT-related incidents, together with the Annex II data glossary and instructions that tell you what each field means. For significant cyber threat notifications, the regulation uses the Annex III template and the Annex IV instructions. Beyond the templates, the regulation sets operating rules: how reports are combined, how recurring incidents are aggregated, how submissions travel through secure channels, how an incident is reclassified from major to non-major, and how a third party may report on behalf of an entity.
The risk the regulation addresses is practical. Supervisors receive reports from many entities about similar events, and they can only compare those incidents if the same fact is recorded the same way every time. Inconsistent, late or incomplete reports prevent that comparison and slow the supervisor's response. The hard part for most organizations is not reading the template but gathering the data it requires. Impact figures, affected services, the chain of events and the status of each stakeholder usually sit in separate ticketing, monitoring and vendor systems, and some of it depends on an ICT provider's own records. Before the first incident occurs, map each template field to a named data source and a named owner, and confirm which of those sources you can reach within the reporting deadlines set by the delegated regulation on incident reporting.
Which entities, incidents and providers the reporting templates reach
The templates in Implementing Regulation (EU) 2025/302 apply only once an entity, incident or provider falls inside DORA's reporting rules. Five scoping decisions determine how much reporting work an organization carries, and each one should be settled and documented before the first incident occurs.
Financial entity types in scope
Article 2(1) of DORA covers 20 types of financial entity, from credit and payment institutions to insurers, crypto-asset service providers and securitisation repositories. Map your legal entity type against that list before anything else, because the reporting duty follows the entity, not the group or the service. Entities in a group may each carry their own reporting obligation, so confirm which legal entity is the notifying party for each incident.
Major incident classification
Whether a report is required depends on whether an incident is major under the classification criteria in Delegated Regulation (EU) 2024/1772. Only major incidents trigger the initial, intermediate and final reports described in Annex I. Document how your incident tooling records classification decisions, and confirm that the thresholds applied to each incident can be traced back to that decision record.
Voluntary significant cyber threat notices
Notification of significant cyber threats is voluntary under DORA, and the Annex III template and Annex IV instructions apply only when an entity chooses to notify. Decide in advance who has authority to make that call, which threats meet the significance test, and how voluntary notices are kept separate from mandatory incident reports. Confirm with your competent authority how it expects these notices to arrive.
Individual reporting for significant entities
Article 7 of the regulation allows a third party to file one aggregated report for an ICT provider incident affecting several entities in one member state, but only if the supervising authority permits it. Significant credit institutions, trading venue operators and central counterparties must still report individually. Check whether any of your entities fall into these categories before designing a shared reporting arrangement.
Third-party reporting on your behalf
Under Article 6, an entity that outsources incident reporting must inform its competent authority before the first notification, giving the third party's name, contact details and identification code. The entity remains responsible for the content and deadlines. Confirm that the outsourcing arrangement, the notification to the authority and the contract terms are all in place before any incident occurs.
Recurring incidents in aggregated form
Article 3 requires recurring incidents to be reported in aggregated form rather than as separate reports each time. Your incident register should therefore tag repeat events against a common root cause, so the aggregation logic can be applied consistently. Ask your authority which recurrence patterns it expects you to aggregate, because the boundary between a recurring incident and a new one drives how many reports you file.
Initial, intermediate and final reports and significant cyber threat notices
The initial notification is the first formal submission on a major ICT-related incident. Entities complete the template in Annex I of Implementing Regulation (EU) 2025/302, reading each field against the data glossary and instructions in Annex II. The notification is an early picture, so entities should expect many fields to be partial and should record which facts are still unknown rather than leaving fields blank without explanation.
- Template and glossary: Use the Annex I template with the Annex II glossary open, so every field carries the meaning the regulation intends.
- Incident identifier: Assign the identifier once and carry it unchanged into every later report.
- Known facts only: Record what the team can verify at the time, and mark open items so the next report can close them.
- Secure channel: Submit through the electronic channel the competent authority makes available, as Article 4 requires.
- Timing: Check the deadline set in the incident reporting RTS before the clock starts running in your own process.
Confirm with your competent authority which channel and format it currently accepts before an incident occurs.
Intermediate and final reports update the initial notification as the incident develops and as root cause, impact and recovery become clearer. They use the same Annex I template and the Annex II instructions. The ESA operational instructions of 16 September 2026 ask entities to send at least one intermediate report per month until the final report is filed, which means reporting continues even when the picture has not changed much.
- Monthly cadence: Diary a recurring intermediate report so a quiet month is still documented.
- Monetary fields in thousands: Report amounts in thousands of units, as the operational instructions request.
- Consistent identifiers: Keep the incident identifier unchanged from initial notification to final report.
- Narrative updates: Describe what changed since the last submission, including containment, recovery and any reclassification.
- Final report closure: Confirm that root cause, impact and remediation are complete before filing the final report.
Check that your finance and operations teams agree on the monetary figures before each submission, because the same loss should not appear differently across reports.
Article 2 of Implementing Regulation (EU) 2025/302 allows the initial, intermediate and final reports to be combined into a single submission, provided the deadlines for each are still met. The rule is useful for incidents that are resolved quickly, but it does not remove the need for each stage of information. Entities should decide in advance whether they will combine, and document that decision in their incident procedure.
- Deadline test: Confirm that combining will not push any required stage past its deadline.
- Content completeness: A combined report must still contain the information each separate report would have carried.
- Identifier continuity: The combined submission keeps the single incident identifier.
- Authority expectations: Ask the competent authority how it treats a combined submission before relying on it.
- Internal record: Keep an internal log showing which stages were combined and why.
Confirm with your competent authority whether it has a preference on combined reports and how it counts them against the monthly intermediate report expectation.
Significant cyber threat notifications are separate from major incident reports. Entities use the template in Annex III and the instructions in Annex IV of Implementing Regulation (EU) 2025/302 (Articles 1 and 8). Under DORA, notifying a significant cyber threat is voluntary, so the team should treat it as a deliberate decision with its own record rather than as a by-product of incident handling.
- Separate template: Use Annex III, not Annex I, for threat notices, and follow Annex IV for instructions.
- Threshold decision: Record why the threat is considered significant, using the criteria in the classification RTS.
- Voluntary status: Document that the notice is voluntary, so reviewers do not read it as an admission of a major incident.
- Update path: Decide whether the threat will be updated if it turns into a major incident and which template then applies.
- Secure channel: Use the same authority channel as incident reports.
Confirm with your competent authority how it wants threat notices handled alongside major incident reports, since the Commission's review and the pending Digital Omnibus may change routing.
The ESA staff operational instructions dated 16 September 2026 were agreed with competent authorities to make submissions consistent. They sit alongside the regulation's templates and ask for three practical behaviours: monetary fields in thousands of units, incident identifiers that never change, and at least one intermediate report per month until the final report. Teams that build their reporting workflow around these points avoid most rejections for formatting and continuity reasons.
- Units: Configure the reporting tool to convert and display amounts in thousands.
- Identifier control: Generate the identifier at case creation and lock it so it cannot be reassigned.
- Monthly schedule: Automate reminders for the intermediate report until closure.
- Audit trail: Keep versioned copies of each submission to show what was sent and when.
- Evidence link: Tie each reported figure and status to a case record that a reviewer can trace.
Read the operational instructions in full, and confirm with your competent authority whether any national practice adds requirements on top of them.
How a supervisor tests incident reporting against the templates
This table sets out how a competent authority is likely to test major incident reports against the Annex I and Annex III templates, what evidence it asks for, and where submissions usually fail. Read each row as a test the supervisor runs, the evidence you should have ready, and the finding that most often follows a weak result.
| Test area | Evidence the supervisor requests | Common findings |
|---|---|---|
| Sampling reports against internal logs | Incident register, detection and triage records, and the timestamps that link each reported incident to internal tickets | Reported incidents with no matching internal record, or internal major incidents never reported |
| Tracing identifiers from initial notice to final report | Initial notification, every intermediate and final report, and the change history of the incident identifier | Identifier changed between the initial notification and the final report, breaking the chain of reports |
| Checking monetary field units | Finance inputs used for estimated costs and losses, with the unit conversion applied before submission | Amounts entered in full units where the ESA instructions ask for thousands |
| Checking report cadence | Schedule of intermediate reports and the dates each was sent until the final report | Missing intermediate reports, or gaps of more than one month between submissions |
| Secure-channel submission | Records showing submission through the channel the competent authority made available, with access controls on the sender | Reports sent by email or unapproved tools, or no record of who submitted them |
| Outsourced reporting notices (Article 6) | Notice to the competent authority before the first notification, with the third party's name, contact details and identification code | No notice on file, or the notice names a provider that no longer handles reporting |
| Reclassification decisions (Article 5) | Documented reasoning for moving an incident from major to non-major, with dates and approver | Downgrades made without a recorded assessment, or reclassification not reflected in later reports |
| Aggregated reporting (Articles 3 and 7) | Evidence that recurring incidents or provider-caused incidents were grouped only where the rules and authority permission allow | Aggregation used without authority permission, or individual reporting skipped for significant entities |
How to build a reporting process that fills the templates correctly
This sequence turns the Annex I and Annex II templates into a working internal process, so each initial notification, intermediate report and final report can be produced from the same incident record without rework.
Map the Annex II glossary to incident fields
Start with the data glossary and instructions in Annex II, and list every field the templates in Annex I ask for. For each field, name the internal system, owner and data source that holds the answer, such as the ticketing platform, the SIEM, the finance team for monetary amounts, or the service catalogue for affected services. Flag fields with no owner or no source. The output is a field-to-source register signed off by the incident response lead and the compliance owner, and it is complete when every template field has a named source and a fallback owner.
Define incident identifiers that persist
Set a naming scheme for incident identifiers that is assigned once, at the first internal record, and never changed. The ESA operational instructions of 16 September 2026 ask that identifiers stay unchanged from the initial notification through to the final report, so the scheme must survive reclassification, merges and tool migrations. Document the rule in the incident management procedure and confirm that the case management tool keeps the identifier as an immutable reference. Done when a test incident keeps one identifier across every linked record and export.
Set the intermediate report cadence
Build a calendar and escalation path that produces at least one intermediate report per month until the final report is sent, as the ESA operational instructions of 16 September 2026 require. Assign a named owner for each cycle, a reviewer, and a trigger that refreshes the report when material facts change, such as new impact figures or a root cause finding. The output is a cadence register linked to each open major incident, and the step closes when the register shows the next due report for every open case.
Register secure submission channels
Identify the secure electronic channels your competent authority makes available under Article 4 of the regulation, and confirm with the authority how access is requested, who holds credentials and how credentials are rotated and revoked. Record the channel, the named users and the backup contact in the reporting procedure. Test that each named user can log in and submit a dummy notification where the authority allows it. The output is a channel access record that shows who can submit and who approves access changes.
Document outsourced reporting arrangements
If a third party will prepare or submit reports for you, document the arrangement under Article 6. Before the first notification, the entity must inform its competent authority of the third party's name, contact details and identification code. Record the division of tasks, data access, sign-off rights and the escalation path in a written agreement. If the provider may submit one aggregated report under Article 7 for an incident affecting several entities, confirm the authority permits it and note which entities must still report individually. The output is a signed arrangement record and a notice to the authority, and the step closes when both exist.
Test the process with a tabletop exercise
Run a tabletop exercise on a scenario that involves an ICT provider, a monetary loss and a recurring incident. Walk the team through the initial notification, one intermediate report, reclassification from major to non-major and the final report, using only the field register, identifier scheme, cadence calendar and channel records built in earlier steps. Record every field that could not be filled, every handoff that stalled and every approval that was missing. The output is an exercise report with a remediation list, and the step closes when each gap has an owner and a fix date. Independent reviewers, including your internal audit function or an external assessor, may review the report, but the entity owns the process and its results.
How the incident record feeds each report in the chain
The point of this section is that every figure, identifier and timestamp in the incident chain should come from one single incident record, not from separate documents that someone re-types at each deadline. Implementing Regulation (EU) 2025/302 asks for an initial notification, intermediate and final reports, and, where they apply, an aggregated report or a reclassification to non-major. Those submissions are different templates, but they describe the same event. If the initial notice says one thing about the affected services and the final report says another, the inconsistency is visible to the supervisor. The operational instructions published by the ESAs add two constraints that make a shared record necessary: the incident identifier must stay unchanged from the initial notification to the final report, and at least one intermediate report must be sent each month until the final report. A team that tracks these in spreadsheets will eventually break one of them.
In practice, the record should hold the fields that the Annex I template and the Annex II data glossary require, with each field tagged by the report it feeds. Monetary values should be stored once, in the unit the operational instructions require (thousands of units), so that the figures do not drift when they are converted between drafts. Timestamps for detection, classification and each notification should be recorded at the moment they occur, because the deadlines in the reporting rules are counted from those events. For outsourced reporting under Article 6, or an aggregated submission under Article 7, the record also needs the third party's details and the list of affected entities, so that each submission draws on the same facts. Platforms such as DFIR-IRIS, which keep a case as one record with a full audit trail and can generate reports from case data, can support this pattern, but the mapping from case fields to template fields must be designed and tested by the organization.
Before building any forms or report generators, the organization should confirm the exact field names, formats and mandatory indicators in the official Annex I template and Annex II glossary, and check any later operational instructions that amend how they are filled in. The template is the authority, not a summary of it. Ask the competent authority which secure submission channel it has made available under Article 4, and confirm whether it accepts the combined initial, intermediate and final report permitted by Article 2. Once the mapping is agreed, run a dry-run with a sample incident and compare each generated report against the record, so that gaps are found before a real major incident forces the issue.
Evidence that shows reports were filed correctly and on time
Each artifact below answers a question an assessor will ask: what was filed, when, through which channel, by whom, and why the classification or aggregation was chosen. Together they let an organization trace every major incident from first notification to final report. Keep them current between audits, not only at audit time.
Submitted report copies with timestamps
Keep a copy of every initial notification, intermediate report and final report exactly as submitted, with the submission timestamp and the confirmation the competent authority returned. Annex I and Annex II set the template and data glossary, so the stored copy should match that structure field by field. Check that the incident identifier is the same on every version, and that monetary fields follow the thousands-of-units convention in the ESA operational instructions. Store the files in write-once or versioned storage so no version can be silently replaced.
Incident record audit trail
The internal case record is the evidence that ties each filed report to the facts behind it. It should show who opened the incident, every change to classification and severity, each data point later used in a report, and the reason for each update. DFIR-IRIS, for example, keeps a case as one record of assets, indicators, tasks and evidence with a full audit trail, which an assessor can follow from notification to closure. Confirm that edits to closed cases are logged and that the export used for a regulator can be regenerated from the same record.
Secure channel registrations
Article 4 requires submission through secure electronic channels made available by the competent authority. Keep records showing which channel your organization registered for, which named users hold access, when access was granted and removed, and how credentials are protected. Review the list after staff changes, because a report sent by a former employee through a lapsed account is hard to defend. Retain the authority's onboarding confirmations so you can show the channel was in place before the first notification.
Outsourcing notifications with provider identification codes
Under Article 6, an entity that outsources incident reporting must tell its competent authority before the first notification. That notice should name the third party, give its contact details and carry its identification code. Keep the signed notice, the date it was sent, and the authority's acknowledgment. Pair it with the outsourcing contract and the reporting duties it assigns, so an assessor can see that the outsourced reporter, not the entity, controls the filing. Recheck the notice whenever the provider or its contacts change.
Aggregated report authorizations
Article 7 allows a third party to file one aggregated report for an incident caused by an ICT provider that affects several entities in one member state, but only where the competent authority permits it. Keep the written authorization, the list of entities covered, and the date it was granted. Confirm that the authorization still applies to each entity in the group, since significant credit institutions, trading venue operators and central counterparties must report individually. An aggregated filing without a current authorization on file is a finding waiting to happen.
Reclassification decisions with rationale
Article 5 sets out how an incident moves from major to non-major. Each reclassification needs a decision record that states the original classification, the new one, the facts that changed, the person who approved the change, and the date. Link the record to the incident audit trail and to any report already filed, along with the corrective notice sent to the authority. Review these records periodically against the classification criteria, because an unexplained downgrade is one of the first things an assessor will test.
What building and running the reporting process costs
This table lists the cost components of building and running a major incident reporting process under Implementing Regulation (EU) 2025/302, showing who is paid for each, whether it is one-time or recurring, and what drives it up. No figures are given because none were supplied, so use the table to structure a written scope and quote request.
| Cost component | Who is paid or who carries it | One-time or recurring, and main drivers |
|---|---|---|
| Analyst time for classification and drafting | Internal incident response, compliance and reporting staff, or an external provider billed by time or fixed scope | Recurring. Driven by incident volume, the number of templates completed per incident, and the number of intermediate reports required |
| Case management tooling or licenses | Software vendor or open-source platform operator, including hosting and support | Mostly one-time setup, with recurring hosting, maintenance and upgrades. Driven by user count and data retention needs |
| Integration with SIEM and EDR | Implementation partner or internal platform engineers for connectors, mappings and testing | One-time build, with recurring maintenance when log sources or alert formats change. Driven by number of source systems |
| Secure submission channel setup | Internal team, coordinated with the competent authority's channel requirements | One-time onboarding, with recurring access management. Confirm channel rules with your competent authority |
| Legal review of notifications | Internal legal counsel or external law firm | Recurring per incident, plus periodic review of templates. Driven by incident severity and cross-border impact |
| Tabletop exercises and external review | External facilitator or assessor, plus internal participants | Recurring, usually annual or per material change. Driven by scope, number of entities and number of ICT providers involved |
| Auditor sampling and evidence preparation | Independent auditor or supervisor's reviewer, plus internal evidence owners | Recurring at each review cycle. Driven by the number of incidents sampled and how complete the records are |
| Outsourced reporting arrangements | Third party that submits reports, with notification to the competent authority under Article 6 | Recurring service fee and one-time notification. Driven by the number of entities and providers covered, and any aggregated reporting under Article 7 |
Who owns reporting, who prepares the process, and who assesses it
The financial entity remains the party that notifies its competent authority. Under the regulation, the entity owns the classification of an incident as major or non-major, the content of each initial, intermediate and final report, and the decision to submit. Senior management should approve the reporting procedure and the people authorized to sign off each submission, because the entity is accountable for what the authority receives.
- Classification decisions: Named owners decide materiality against the criteria and record the reasoning, including any later reclassification under Article 5.
- Report sign-off: An accountable role approves each initial, intermediate and final report before it goes through the secure channel.
- Identifiers and monetary fields: Staff keep the incident identifier unchanged from first notification to final report and follow the ESA operational instructions on units and monthly intermediate reports.
- Outsourcing decisions: If a third party submits reports, the entity informs its authority under Article 6 before the first notification and names the third party.
- Records: The entity keeps evidence of each decision and submission for supervisory review.
Confirm internally who holds each of these roles and whether your deputies are named and trained.
An implementation partner helps the entity prepare the operating side of reporting. Work typically covers designing the reporting workflow, mapping the Annex I and Annex III templates and the Annex II and Annex IV instructions to internal fields, configuring case management and evidence handling, and building evidence packs that show how the process runs. The partner works inside the entity's own infrastructure and does not submit reports or represent the entity to its authority.
- Process design: Drafting the escalation path, decision points, and handoffs between security, operations, legal and management.
- Tool configuration: Setting up a case platform such as DFIR-IRIS, which keeps each case as one record with assets, indicators, tasks, evidence and an audit trail.
- Evidence packs: Assembling timelines, logs and records that let internal reviewers and assessors trace each report to its source data.
- Tabletop support: Running exercises that test the reporting deadlines, the Article 7 aggregation scenario, and the secure channel steps.
- Documentation: Writing runbooks and templates the entity's staff can maintain after handover.
Ask any partner for a written scope that states which of these tasks it performs and which remain with your staff.
Only the competent authority supervising the entity, or an independent assessor the authority or the entity engages for that purpose, evaluates whether reporting meets the regulation. The authority receives and assesses the reports, can request further information, and holds the powers under DORA's supervisory chapter. DORA does not create a certification for incident reporting, so no partner or consultant can issue a compliance certificate for it.
- Supervisor role: The authority decides whether reports are complete and timely and whether an incident was classified correctly.
- Independent assessment: An external assessor can test the design and operation of reporting controls and report findings to the entity.
- Partner limits: A partner that designed the process should not also be the party that independently tests it, since its work is then being judged by itself.
- Evidence requests: Expect authorities to ask for classification records, submission logs and the reasoning behind outsourcing or aggregation choices.
- Sector variation: Confirm with your authority how it expects reports to be delivered and what it will accept as evidence.
Before you engage any assessor, confirm with your competent authority which evidence it expects and whether an independent review is required in your case.
Where incident reporting usually falls short and how to close it
Most weak incident reports under Implementing Regulation (EU) 2025/302 fail on process rather than on content: identifiers drift, monthly updates lapse, and figures or channels are not set up in advance. Each card below names one gap, why it matters for the template and data glossary, and the closure action to assign before the next incident.
Incident identifiers changing between reports
Entities often assign a new internal reference when the final report is drafted, or when a case moves between teams. Operational instructions issued by the ESAs ask that the incident identifier stay unchanged from the initial notification to the final report. Closure action: generate the identifier once at triage, store it as a fixed field on the case record, and block edits to it in the workflow tool so every template version carries the same value.
Missing monthly intermediate reports
Teams often treat the intermediate report as optional once the initial notification is filed, then miss the monthly cadence while the incident stays open. The operational instructions ask for at least one intermediate report per month until the final report is sent. Closure action: create a calendar obligation at the moment of classification, tied to the incident owner, with a named backup and a standing review of open major incidents at each monthly governance meeting.
Monetary fields not in thousands
Financial impact fields entered in whole units are a frequent source of rejected or queried submissions, especially when finance and security teams prepare figures separately. The operational instructions ask that monetary fields be reported in thousands of units. Closure action: agree the conversion rule with finance in advance, document it in the data glossary worksheet used by the reporting team, and have a second person check every amount before submission.
Secure reporting channels not registered
Article 4 requires submission through secure electronic channels made available by the competent authority, so a channel that exists in theory but was never set up, tested or assigned to staff can delay a notification at the worst moment. Closure action: confirm with the competent authority which channel applies, register named users and credentials in advance, run a test submission outside an incident, and record who holds access and how it is recovered when a person leaves.
Outsourced reporting not documented
Where a provider or group function files reports on the entity's behalf, Article 6 requires the entity to inform its competent authority before the first notification, giving the third party's name, contact details and identification code. Gaps appear when the arrangement exists in practice but not in writing or with the authority. Closure action: confirm the notification was made and filed, record the delegation in the ICT incident procedure, and set a review date when the contract or contact person changes.
Recurring incidents not aggregated
Repeated low-level events that share a root cause, such as the same failing integration or a recurring phishing pattern, can be reported as separate incidents when Article 3 expects recurring incidents to be reported in aggregated form. This inflates the volume of reports and hides the pattern from supervisors. Closure action: review incident logs each quarter for shared causes, group matching records under one case with linked occurrences, and confirm the aggregation approach with the competent authority before using it in a submission.
Questions buyers ask about 2025/302 reporting
How much effort does it take to get ready for 2025/302 reporting?
Effort depends mostly on how far your incident process already matches the template's data fields. Regulation (EU) 2025/302 requires you to populate an Annex I template for initial, intermediate and final reports, following the data glossary in Annex II, and a separate Annex III template for significant cyber threat notifications. Most of the work sits in mapping your ticketing, detection and communication records to those fields, defining who fills each field and when, and testing the submission path. Ask any partner to split its estimate into mapping, workflow design, tooling changes and test runs, and to state which of those you would own afterward.
How long does a reporting build take?
The timeline is set by the written scope, not by the regulation, so confirm it in the statement of work before work starts. The variables that move it most are the number of systems that feed incident data, whether a case management platform already exists, how many entities or legal units report, and how long your competent authority takes to confirm access to its secure electronic channel. Ask for milestones tied to mapping, build, testing and handover, and for a plan that covers the deadlines the regulation sets for each report.
What does the work need from our team?
Plan for named contributions from incident response, security operations, IT operations, legal or compliance, and the people who sign off regulatory submissions. Incident responders must confirm how they record classification, timing and impact. Compliance must confirm which entity reports and which authority supervises it. Engineering owners must provide access to log sources and ticketing data. Expect these people to review draft templates and rehearse a reporting exercise, because the reports are only as accurate as the records behind them.
Can we do the 2025/302 reporting work in-house?
Yes, if your team has the incident data, the regulatory knowledge and the capacity to maintain the templates. The regulation is public, so an internal team can build the mapping, the workflow and the submission steps. Consider whether you have people who can keep the process current when the ESAs update operational instructions, and who can run the rehearsals. Organizations often bring in outside help for the initial build and then keep the process in-house. DeployOpen can prepare and document these systems, but it does not file reports for you or certify your process.
Can a third party submit incident reports on our behalf under Article 6?
Yes. Under Article 6 of Regulation (EU) 2025/302, an entity that outsources its reporting must inform its competent authority before the first notification is made. The notice must give the third party's name, contact details and identification code. Your organization remains responsible for the reporting obligation, so the contract, access controls and review steps should be set out before the first incident. Confirm with your competent authority what format it expects for the notice.
What does Article 7 aggregated reporting permit?
Article 7 allows a third party to submit one aggregated report for an incident caused by an ICT provider that affects several entities, provided those entities are in a single member state and supervised by the same authority, and the authority permits it. Significant credit institutions, trading venue operators and central counterparties must still report individually. Before relying on aggregation, confirm with your authority whether it has granted permission and which entities fall inside the group.
Which reporting details should we check before the first real notification?
Check that incident identifiers stay unchanged from the initial notification to the final report, and that monetary fields are reported in thousands of units, as the ESA staff operational instructions of 16 September 2026 ask. Confirm that at least one intermediate report is sent each month until the final report. Also confirm how you will combine reports under Article 2, when you will reclassify an incident from major to non-major under Article 5, and whether your channel access works. Rehearse these steps with a test incident before you need them.
How DeployOpen prepares incident reporting for DORA entities
DeployOpen works on the systems and evidence that feed DORA incident reporting: case handling, data capture, secure submission paths and the records an entity needs for the template in Annex I and the data glossary in Annex II. DeployOpen prepares and documents these systems inside the client's own infrastructure. The entity owns its incident process and submissions, and the competent authority is the only party that receives and assesses the reports.
How we scope
- Engagements are fixed-scope, with the reporting entities, incident sources and reporting roles agreed in writing before work starts.
- The written scope records which Annex I and Annex III templates and Annex II and Annex IV instructions the systems must support.
- Scope also names the outsourced reporting arrangements, if any, that need notice to the competent authority under Article 6.
How we build
- We deploy self-hosted open-source case management in the client's cloud accounts, data centers or air-gapped networks.
- We configure case records to hold assets, indicators, tasks, evidence and a full audit trail for each incident identifier.
- We set up intake from SIEM, EDR and REST sources, a consolidated timeline, and report generation from case data.
How we hand over
- We document the reporting workflow, field mapping to the data glossary, and the monthly intermediate report routine.
- We deliver evidence procedures, including SHA-256 verification and chain of custody for logged artifacts.
- Handover includes runbooks for keeping incident identifiers unchanged from initial notification to final report.
How we support
- Ongoing support, upgrades and continuous testing of the reporting systems are available as retainers.
- Retainers can cover updates when the competent authority's secure channel or the operational instructions change.
- Confirm with the competent authority which secure electronic channel applies before the first notification.
