Article 19 DORA major incident reporting: requirements and evidence

What DORA Article 19 requires when a major ICT incident happens

When a major ICT-related incident hits a financial entity, the compliance lead's first question is which clock is running and what must be sent to the competent authority. Under DORA Article 19, the answer is a staged set of reports: an initial notification, an intermediate report and a final report, each tied to a deadline. The trigger is classification of the incident as major, which is decided under the criteria in Article 18 and the thresholds in the delegated rules. Under Article 5 of Delegated Regulation (EU) 2025/301, the initial notification is due within 4 hours of classifying the incident as major and no later than 24 hours after the entity becomes aware of it. The intermediate report follows within 72 hours of the initial notification, and the final report is due no later than one month after the latest intermediate report. The rule exists because supervisors need to see serious incidents early and in a form they can act on, not discovered late or reported with gaps.

Article 19 also requires the entity to inform clients without undue delay when a major incident affects their financial interests, so the client-notification duty runs in parallel with the regulatory reports. Organizations often find the hard part is not the forms but the inputs. Deciding classification quickly requires agreed criteria and a named decision-maker who can act outside business hours. Impact figures such as affected clients, transactions, data and downtime are often estimates at first, and the final report must replace them with actual values. A timeline that survives review must record when the entity became aware, when it classified the incident, and what was decided and by whom. Confirm with your competent authority which templates and channels it uses, and check the current DORA text on EUR-Lex against your internal procedure before the first real incident.

Which entities, incidents and teams fall under DORA Article 19 reporting

Article 19 reporting applies to a defined set of financial entities, but the reporting route, the systems in scope and the people who hold the duty all depend on how an organization is classified. Settle these questions before the first incident, because they decide who gets notified and who signs off each report.

Financial entities named in Article 2(1)

Article 2(1) lists 20 types of financial entity, from credit and payment institutions to insurers, crypto-asset service providers and securitisation repositories. Check your license or registration against that list first, because the list sets which competent authority you report to. Entities outside the list may still face incident reporting under other regimes, so confirm that with counsel.

Significant credit institution route

A significant credit institution reports major incidents to its national competent authority, which passes the report to the ECB immediately. The bank still owns the report and its content, so the internal workflow must reach the national authority, not the ECB directly. Confirm with your supervisor how significance was determined and who your named contact is.

NIS2 copy requirements

Article 19(1) allows member states to require copies of major incident reports to NIS2 authorities or CSIRTs. Financial entities identified as essential or important entities under NIS2 may therefore file the same incident with two bodies. Map each national requirement now, since the copy routes and formats differ by member state.

Which systems count as ICT

Reporting covers major ICT-related incidents, so the scope depends on what your organization treats as an ICT system. Self-hosted open-source platforms, identity services, logging pipelines and backup tooling all run on ICT infrastructure and can be in scope. Document the inventory and the boundary decisions so an incident on any listed asset can be traced to a reporting obligation.

Third-party incidents flowing back

When a cloud host, managed service or software vendor suffers an incident that affects your services, the duty to classify and report sits with you as the financial entity. Contracts should require providers to notify you quickly and share the facts you need for the initial notification and later reports. Test that flow with the provider before an incident occurs.

Teams that hold the duty

Reporting needs named owners across security operations, IT operations, legal, compliance and the management body, since classification and sign-off cannot wait for a single team. Record who classifies, who drafts, who approves and who deputizes when the primary owner is unavailable. If you outsource reporting under Article 19(5), the entity stays fully responsible, so keep those roles on your side.

How an assessor tests DORA incident reporting

This table compares what an assessor samples, checks and asks for when testing Article 19 reporting, and where organizations usually fall short. Read each row as a test step paired with the evidence that passes it and the finding that typically follows a gap.

Test area	What the assessor checks	Common finding
Population and sampling	The full register of incidents classified as major, compared with the reports actually filed. The assessor selects a sample of major incidents across the review period, including any that were downgraded or never reported.	Incident log does not reconcile with the reporting register, so some major incidents were never assessed for reporting.
Classification timestamp	The time the incident was classified as major, recorded in the incident file with the approver's identity and the classification basis.	Classification time is missing or recorded after the reporting clock was already close to expiry.
Initial notification timing	Whether the initial notification was submitted within 4 hours of classification and no later than 24 hours after awareness, as set in Delegated Regulation (EU) 2025/301 Article 5. The assessor compares system timestamps with the submission receipt.	Timestamps show the 4-hour window was missed, or awareness time was set later than the first alert in the monitoring tool.
Intermediate report timing	Whether the intermediate report followed within 72 hours of the initial notification, and whether it was updated when status or handling changed significantly.	No record of why an update was skipped after a significant change in incident status.
Final report timing	Whether the final report was filed no later than one month after the latest intermediate report, with root cause analysis completed and actual impact figures replacing estimates.	Final report filed with estimated impact figures, or root cause analysis still open at submission.
Weekend and holiday rule	Whether deadlines falling on a weekend or bank holiday were moved correctly, and whether the entity's category allowed the noon rule for each report type.	Entity applied the noon extension to initial notifications or intermediate reports where the exception applies to it.
Client notice records	Evidence that affected clients were told without undue delay when the incident affected their financial interests, with the date, channel and content of each notice.	Notices sent late, sent to a subset of affected clients, or lacking the information needed to act.
Outsourced reporting notices	If a third party files reports, a notice to the competent authority before the first report, plus the contract and proof that the entity kept full responsibility.	Outsourcing not notified before the first report, or contract leaves responsibility with the provider.
Evidence integrity	Case records, timestamps and submission receipts that can be traced back to source logs, with an audit trail showing who edited each report.	Reports rebuilt from memory or spreadsheets, so timestamps cannot be verified against system records.

How to build a reporting process that meets the deadlines

The sequence below turns Article 19 into a working process: agreed criteria, prepared templates, a clock that starts from awareness, named roles, and a rehearsal that proves the chain works before a real major incident tests it. Each step closes with an artifact you can show an assessor.

Define major-incident criteria against Article 18
Start from the classification rules in Article 18 and the materiality thresholds in Delegated Regulation (EU) 2024/1772, then write down which incidents your organization treats as major and who makes that call. Compliance, operations and the ICT risk function should agree the decision points, including how recurring incidents are counted. This step is done when a signed classification procedure names each decision point, its owner and the record kept of the decision. Ask your reporting counterpart or consultant to confirm the thresholds still match the current regulation before sign-off.
Set the reporting clock from awareness
Map the time limits in Delegated Regulation (EU) 2025/301 onto your incident timeline: the initial notification is tied to classifying the incident as major and to becoming aware of it, so the earlier trigger governs. Record the moment of awareness and the moment of classification as separate timestamps in your ticketing or case tool. This step is done when the timeline template captures both timestamps and the deadline calculation is written into the runbook with a worked example labeled as illustrative.
Build the initial, intermediate and final report templates
Prepare one template for each report under Article 19(4), using the content fields and formats set in Implementing Regulation (EU) 2025/302. Keep estimates and confirmed figures in separate fields so the final report can replace estimates with actual impact data. Assign an owner to each field, such as the incident commander for status and the forensic lead for root cause. This step produces approved templates, versioned and stored with the runbook, and each template should be checked against the current technical standard before it is used in a live report.
Document the weekend and bank-holiday rule
Write the calendar rule from Delegated Regulation (EU) 2025/301, Article 5(4) and (5), into the runbook: deadlines that fall on a weekend or bank holiday move to noon on the next working day, except for initial notifications and intermediate reports from credit institutions, central counterparties, trading venue operators and NIS2 essential or important entities, which do not get that extension. Confirm with your competent authority which bank holidays apply in each member state where you operate. The step is complete when the runbook shows the exception list, the holiday calendar in use and an on-call rota that covers weekend incidents.
Assign escalation roles and decision rights
Name the people who classify, approve, submit and sign each report, plus deputies for each role, and state who may contact the competent authority. Include the step for informing affected clients under Article 19(3) and the approval route if you outsource reporting under Article 19(5), with the prior notice to the authority required by Implementing Regulation (EU) 2025/302. The output is a RACI table and an escalation chart attached to the runbook, and both must be checked against current staffing so that no role depends on one person.
Rehearse the process with a tabletop exercise
Run a tabletop exercise using a hypothetical major incident, labeled as illustrative, and walk the team through detection, classification, drafting and submitting each report on the clock you set. Record where the team missed a handoff, could not find a template field or lacked a decision right, and assign fixes with owners. The output is a rehearsal record with timestamps, findings and remediation items. Repeat the exercise after material changes to systems, staffing or the regulation, and keep each record as audit evidence.
Store the process as controlled evidence
Bring the criteria, clock, templates, calendar rule, roles and rehearsal record into one document set under version control, with an approver and review date for each item. Link the process to your case management record so every incident shows its reports and timestamps in one place. The step is done when an independent reviewer can trace one past or test incident from detection through each submitted report using only these artifacts. Ask any implementation partner to deliver these outputs in your repository so the evidence stays with your organization.

The 4-hour, 24-hour, 72-hour and one-month clocks explained

The reporting clocks under DORA start from two different events, and confusing them is the most common way firms miss a deadline. Under Article 5 of Delegated Regulation (EU) 2025/301, the initial notification is due within 4 hours of classifying an incident as major, and no later than 24 hours after the entity became aware of it. The 24-hour outer limit runs from awareness, not from classification, so a team that takes many hours to classify an incident can still be late even though the 4-hour window has not yet closed. The classification decision therefore has to be time-stamped and made quickly, with the awareness time recorded separately in the incident record.

The intermediate report is due within 72 hours of the initial notification, and it is not a one-off. Under Article 19(4) of DORA, an intermediate report is also required when the status of the incident or its handling changes significantly, with updates as needed. Teams should define in their procedures what counts as a significant change, such as a new affected service, a change in the expected recovery time, or a newly confirmed data compromise, and assign an owner who watches for those triggers. Each update should be logged with its own timestamp so the regulator can see how the picture developed.

The final report is due no later than one month after the latest intermediate report, and it is the point where estimates give way to facts. It must rest on a completed root cause analysis and on actual impact figures that replace the provisional numbers used earlier. Confirm before an incident occurs which internal function owns the root cause analysis and how long forensic work usually takes in your environment, because that work sets how early the final report can realistically close. Where a deadline falls on a weekend or bank holiday, Article 5(4) and (5) of the same regulation moves it to noon on the next working day, but the exceptions for initial notifications and intermediate reports by credit institutions and certain other entities mean that rule must be checked against your entity type before relying on it.

Evidence that proves each report was timely and complete

An assessor reconstructing a major incident will test two things: whether each report left the entity inside its deadline and whether its content matched what the entity knew at the time. The cards below cover the records that prove both, and the routine that keeps them current between audits.

Incident record with timestamps

The case record is the spine of the evidence file. It should show when the incident was detected, when it was classified as major, and when the entity became aware of it, because the initial notification clock runs from classification and the outer limit runs from awareness. Each timestamp needs a named source, such as a SIEM alert or a classification decision, and a person who recorded it. Check that the three times can be reconciled in one timeline.

Submitted reports and transmission receipts

Keep each initial notification, intermediate report and final report as the exact file transmitted to the competent authority, together with the receipt, acknowledgement or portal confirmation showing the submission time. A draft saved in a shared folder does not prove timeliness. Store the filing channel used, since a report sent by a route the authority does not accept can be treated as not filed.

Change log for report updates

Each intermediate report and any update must be traceable to the version it replaced. A change log should record what changed, the date, the reason and who approved it, so an assessor can see that status changes were reported when they became significant. Version control on the report drafts, with preserved prior versions, answers the question of what was known on a given day.

Root cause analysis and impact figures

The final report depends on a completed root cause analysis and on actual impact figures that replace earlier estimates. Keep the analysis document, the data sources used for each impact figure, and the dated decision that moved a figure from estimate to actual. The gap between the first estimate and the final number is often what an assessor asks about first, so explain it in the file.

Client notices and their basis

Where a major incident affects clients' financial interests, keep every notice sent, its send date, the recipient list and the reason each client was included or excluded. For a significant cyber threat, keep the protective measures communicated. Records showing that notices went out without undue delay are stronger when they connect to the classification date in the incident record.

Outsourcing agreement and pre-filing notice

If a third party files reports on the entity's behalf, the entity remains fully responsible. Keep the signed outsourcing agreement, the service description, and proof that the competent authority was told of the outsourcing before the first report was filed. Confirm with the authority which notice format it expects, because the notice is only useful if it predates the first filing.

What meeting Article 19 reporting costs in money and effort

This table breaks the cost of Article 19 reporting into its components, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to build a quote request and to see where self-hosted open-source tooling removes license spend, while the effort of templates, drills and evidence upkeep remains. No price or duration is stated because none is supplied for this topic; confirm figures in writing against your own scope.

Cost component	Who is paid and for what	One-time or recurring, and main cost drivers
Case management tooling	Software vendor or open-source deployment. Self-hosted DFIR-IRIS (LGPL-3.0-or-later) removes license fees, but hosting, patching and backup remain your costs.	Licensing is recurring for commercial products. Drivers: number of users, retention, integrations, and whether you run it in your own infrastructure.
SIEM and EDR licensing	Existing security platform vendors. Reporting depends on alert feeds, so these costs usually already sit in the security budget.	Recurring. Drivers: data volume ingested and endpoint count. Confirm whether the contract covers the log retention you need for the final report.
Engineering time for templates and integration	Internal engineers or an implementation partner who builds report templates, classification fields and feeds from SIEM, EDR and ticketing into the case tool.	Mostly one-time, with changes when reporting fields or the Delegated Regulation (EU) 2025/301 format change. Drivers: number of data sources and how well incident records are already structured.
Drill and tabletop time	Internal incident response, compliance and management staff, plus any external facilitator you hire.	Recurring. Drivers: how often you rehearse the 4-hour initial notification path and the 72-hour intermediate report path, and how many teams must take part.
Evidence upkeep	Internal compliance and security staff who keep timelines, IOC records, chain-of-custody logs and report versions current.	Recurring for every incident. Drivers: incident volume, how many incidents are later reclassified, and how well the case tool keeps an audit trail.
Outsourced reporting service	A third-party provider, under the outsourcing arrangement permitted by Article 19(5). You remain fully responsible.	Recurring or per-incident, depending on the contract. Drivers: service scope, 24-hour coverage, and the notice the authority must receive before the first report under Implementing Regulation (EU) 2025/302.
External review of reports	Independent legal, regulatory or security advisers who check draft notifications before submission.	Often incident-driven. Drivers: how many major incidents occur and whether your templates already cover the required content.
Auditor or supervisor sampling	Your internal audit, or an external auditor selected by you, who tests a sample of incidents against your records. Competent authorities supervise compliance; they do not certify it.	Periodic. Drivers: the number of incidents in the sample period and how quickly your records can be retrieved and matched to the reports filed.

How DFIR-IRIS supports the incident evidence trail

DFIR-IRIS is a self-hosted case management platform for incident response. Its core unit is the case, a single record that holds the assets affected, indicators of compromise, tasks assigned to responders and the evidence collected. For DORA purposes, this means the facts behind an initial notification, intermediate report and final report can be traced to one place rather than scattered across chat threads and spreadsheets.

Assets and IOCs: Affected systems, accounts and indicators are attached to the case so the scope described in each report can be checked against the record.
Tasks: Containment, recovery and review actions are tracked with owners, which supports the handling narrative regulators ask about.
Full audit trail: Changes to case data are logged, so the team can show who recorded or altered a fact and when.
Role-based access: Case access can be limited to the people who need it, which helps where incident data includes personal or client information.
Single source for reporting: Figures used in the reports come from the same case, reducing drift between the initial notification and the final report.

Before relying on this model, confirm with your own team how cases are opened for incidents that are not yet classified as major, and who has authority to close them.

Where incident reporting programs usually fall short

Most reporting failures under Article 19 come from timing and records, not from missing forms. The gaps below cluster around the moments when the clock starts, when the reporting decision is made, and when someone else is doing the reporting for you.

Late classification decisions

The initial notification clock under Delegated Regulation (EU) 2025/301 starts from the moment an incident is classified as major, but it cannot run past 24 hours after awareness. An entity that defers classification while it gathers facts can miss the outer limit without ever filing late on paper. Check whether your procedure sets a named decision owner and a documented time at which classification must be made.

Missing awareness timestamps

The 24-hour outer limit runs from the moment the entity became aware of the incident, so the record must show when that happened. Teams often log when a ticket was opened or when a severity was set, not when a person first had enough information to recognize a possible incident. Check that your case records capture the first alert, the first human awareness and every reclassification with a timestamp.

Outsourcing not reported before the first report

Article 19(5) lets an entity outsource reporting to a third party, but the entity stays fully responsible. Implementing Regulation (EU) 2025/302 requires the competent authority to be told of the outsourcing before the first report is filed. Where a managed SOC, legal firm or consultant files on your behalf, confirm the notice has gone in and the contract names who files, when and from which data.

Client notice omissions

Article 19(3) requires clients to be informed without undue delay when a major incident affects their financial interests. Notices are often drafted for the regulator and then forgotten, or sent to a general mailbox that no client-facing team reads. Check that your register of clients who may be affected can be pulled quickly and that each notice is logged with a date, recipient and content.

Final reports without root cause

The final report is due no later than one month after the latest intermediate report, and under Article 19(4) it follows completion of the root cause analysis with actual impact figures replacing estimates. Teams that submit a final report while the investigation is still open often present estimates as facts and leave the cause undetermined. Check that the investigation has a closure criterion and that the root cause workstream starts at detection, not at reporting.

Weekend and holiday clock errors

Under Delegated Regulation (EU) 2025/301, deadlines falling on a weekend or bank holiday move to noon on the next working day, but initial notifications and intermediate reports from credit institutions, central counterparties, trading venue operators and NIS2 essential or important entities are excluded from that rule. Calendars that apply the general rule to every entity can produce a wrong deadline. Check that your reporting calendar is built per entity type and tested against a holiday period.

Questions buyers ask about Article 19 reporting

How long do we have to report a major ICT incident under DORA?

Under Delegated Regulation (EU) 2025/301, the initial notification is due within 4 hours of classifying an incident as major, and no later than 24 hours after you become aware of it. The intermediate report is due within 72 hours of the initial notification, and the final report no later than one month after the latest intermediate report. Deadlines that fall on a weekend or bank holiday move to noon on the next working day, except initial notifications and intermediate reports from credit institutions, central counterparties, trading venue operators and NIS2 essential or important entities, which do not get that extension. Because the 4-hour clock starts at classification, the classification step under Article 18 has to be fast and documented. Check the exact rules in the Delegated Regulation (EU) 2025/301 against your entity type.

What does meeting DORA incident reporting cost?

No single figure applies, because cost depends on your entity, incident volume and how much of the work is already in place. The main components are internal staff time for detection, classification, drafting and sign-off, one-time setup such as playbooks, report templates and tooling integration with your SIEM and EDR, and recurring costs such as on-call cover, drills, tool maintenance and any retainer for support. External work is paid for according to a written scope. Costs rise with the number of reporting entities, the number of systems to integrate, and whether you outsource part of the reporting duty. Ask any provider for a quote that separates one-time from recurring costs, names who performs each task, lists assumptions about incident volume, and states what is excluded. DeployOpen's work is fixed-scope and quoted from that written scope.

What does DORA incident reporting need from our own staff?

Your staff must own the decisions, because the reporting obligation sits with the entity. You need named people for incident management, classification, technical root cause analysis, legal and compliance review, and client communication under Article 19(3). Management must be able to approve reports within the short deadlines, which means someone with authority must be reachable at any hour. Technical staff need access to logs, asset inventories and the contacts for critical providers, and they need to rehearse the process through tabletop exercises before a real event. Expect staff time for drills, template upkeep and post-incident reviews as well as for live incidents. Confirm these roles in writing before any implementation work starts, so gaps show up during scoping rather than during an incident.

Can we run DORA incident reporting in-house?

Yes. Article 19 does not require an outside party, and an entity can run detection, classification, reporting and client notification with its own staff. The question is capacity and readiness. Test whether your team can classify and submit an initial notification within the 4-hour and 24-hour limits at any hour, drafts intermediate and final reports from evidence, and keeps the record complete. Gaps usually appear in after-hours coverage, evidence handling and the root cause write-up. An implementation partner can help build playbooks, configure self-hosted tooling, prepare templates and document evidence, while your team keeps ownership of every decision and submission. Use a tabletop exercise against the deadlines in Delegated Regulation (EU) 2025/301 to find out what your team can actually meet.

Can we outsource DORA incident reporting to a third party?

Yes, Article 19(5) allows the reporting obligation to be outsourced to a third party, but the entity remains fully responsible for compliance. Before the first report, the competent authority must be told about the outsourcing, as set out in Implementing Regulation (EU) 2025/302. Your contract should state who gathers data, who drafts each report, who approves it, how fast the provider must respond, and how information moves between the two parties during the 4-hour and 24-hour windows. A third party can prepare data and drafts, but the reports are still the entity's obligations, and the entity must be able to explain them to its supervisor. Ask providers how they will meet the deadlines, how they handle confidential information, and what happens if they fail to deliver. Independent auditors and supervisors, not implementation partners, assess whether the arrangement works.

Does the Digital Omnibus change where DORA incident reports go?

The Commission's Digital Omnibus proposal, COM(2025) 837 of 19 November 2025, would amend Article 19 so that major incident reports and voluntary threat notifications go through a single entry point under NIS2. The procedure, 2025/0360(COD), is awaiting committee decision as of October 2026, so it is not law yet. Until any amendment is adopted and applies, Article 19 as it stands governs your reporting, including the authority your national rules name. Plan your process so the reporting channel can be changed without rebuilding your playbooks, and record which authority receives each report. Monitor the procedure file in the European Parliament's Legislative Observatory) and confirm with your competent authority how any change would affect you.

How do we tell affected clients about a major incident?

Under Article 19(3), you must inform clients without undue delay when a major incident affects their financial interests. For a significant cyber threat, you must also tell potentially affected clients which protective measures they can take. The message needs to be factual, consistent with what you have already reported to the authority, and updated as the picture changes. Prepare pre-approved templates, a contact list for each client group, and a sign-off route that does not delay notice. Keep a record of what was sent, to whom and when, because your supervisor may ask for it. Legal and communications staff should review the wording before the first message goes out, and the process should be rehearsed as part of your incident drills.

What does a DORA final incident report need to show?

The final report follows completion of the root cause analysis, and it replaces estimates with actual impact figures. Under Article 19(4), it should give a complete account of the incident, its cause, its effects and the handling that followed. Your engineers should keep a timeline built from logs, a record of actions and their owners, and evidence files with hashes and chain of custody. The open-source case management platform DFIR-IRIS keeps each case as one record of assets, indicators of compromise, tasks and evidence with an audit trail, builds a consolidated timeline, logs evidence with SHA-256 verification, and generates reports from case data. Confirm that its fields and outputs match your own reporting template and DORA requirements before relying on it, and test the report generation during a drill.

What the Digital Omnibus proposal could change for Article 19

The Commission's Digital Omnibus proposal, COM(2025) 837 of 19 November 2025, would amend Article 19 of DORA so that major ICT-related incident reports and voluntary significant cyber threat notifications pass through a single entry point under NIS2. Today a financial entity may need to send parallel reports to its financial competent authority, and in some member states to a NIS2 authority or CSIRT. The proposal aims to remove that duplication. As of October 2026, the European Parliament's Legislative Observatory lists the procedure, 2025/0360(COD), as awaiting committee decision, so the text can still change and nothing is yet in force. Until it is adopted and applied, the reporting rules in Article 19, Delegated Regulation (EU) 2025/301 and Implementing Regulation (EU) 2025/302 remain the binding basis for your filings.

The practical question for incident response leads is what would change in the workflow, not whether to comply today. The likely pressure points are the recipient of each report, the data fields and format, and the timing of the first notification relative to other NIS2 duties. Confirm with your competent authority whether it has published guidance on the single entry point, whether it expects the outsourcing notice required before the first report to be updated, and whether any existing reporting channels will be retired. Ask your incident response provider and any third party that files reports on your behalf to confirm how they would handle a changed submission route.

Build the reporting process so that the recipient, channel and template are configuration rather than hard-wired steps. Keep the classification record, timestamps for awareness and classification, and the report content separate from the transmission step, so that a change of addressee affects one component. Track the status of 2025/0360(COD) at a fixed review point, record each decision in your incident management documentation, and rehearse a major incident tabletop against both the current and the proposed routing. This keeps the 4 hour, 24 hour and 72 hour clocks under Delegated Regulation (EU) 2025/301 unaffected while the legislative outcome is still open.

How DeployOpen prepares DORA incident reporting for your team

DeployOpen prepares the systems, incident records and reporting workflow that let your team meet Article 19 deadlines for major ICT-related incidents. Your organization keeps ownership of its controls and of every report it files, and an independent auditor or assessor reviews the evidence where your supervisor or contract requires it.

How we scope

We agree a written scope covering which entities, systems and incident sources fall under your reporting workflow.
We confirm with you who classifies incidents as major, who files each report, and who approves it before submission.
We document which reporting steps you plan to outsource and confirm the competent authority is told before the first report, as Implementing Regulation (EU) 2025/302 requires.

How we build

We configure DFIR-IRIS so alerts from SIEM, EDR and REST sources open cases with assets, indicators and tasks attached.
We set up a consolidated investigation timeline and evidence logging with SHA-256 verification and chain of custody for each case.
We build report templates that draw initial notification, intermediate report and final report fields from case data, for your review and sign-off.

How we hand over

We deliver a runbook that maps each Article 19 step to its owner, deadline clock and evidence record.
We test the workflow with a tabletop exercise on an illustrative incident so your team sees each deadline in practice.
We document configuration, access settings and audit trail behavior so your staff can operate and explain the system to assessors.

How we support

Ongoing support, upgrades and continuous testing of the reporting platform are available as a retainer.
We can update templates and runbooks when the Delegated Regulation (EU) 2025/301 requirements or your supervisor's expectations change.
Please confirm with your competent authority and your legal team which final submission channel and format apply to your entity.