An outage at a software vendor is an incident in the vendor's own process. At a bank, an insurer or a payment institution that runs a critical or important function on that software, the same outage is something else: a candidate major ICT-related incident under Article 19 of Regulation (EU) 2022/2554, DORA, with a report to the supervisor due within four hours of classification, an intermediate report within 72 hours, and a final report with root causes within a month. The classification criteria come from Article 18, the thresholds from Commission Delegated Regulation (EU) 2024/1772 of 13 March 2024, in force since 15 July 2024, and the content and time limits of the reports from Commission Delegated Regulation (EU) 2025/301 of 23 October 2024, in force since 12 March 2025, with the template in Implementing Regulation (EU) 2025/302 of the same date. This article reads the three acts from the Official Journal on CELLAR on 12 September 2026, from the vendor's side: which of your outages cross the thresholds, which clocks then run at your customer, and which facts in its report only you can supply. It is not legal advice.
Why the customer's clock is your clock
Article 17 of DORA requires the financial entity to run an incident management process that classifies incidents by priority, severity and the criticality of the services affected, and Article 19(1) requires it to report major incidents to its competent authority. Nothing in DORA requires the vendor to report anything to anyone; the vendor's obligation is contractual, and it is point (f) of Article 30(2): the obligation to provide assistance to the financial entity, at no additional cost or at a cost determined ex ante, when an ICT incident related to the service occurs. Since the entity's reports have to contain facts about the incident that sit in the vendor's logs, that assistance clause is, in practice, a duty to supply those facts inside the entity's time limits. The clause checklist carries the clause; this article is what it costs to honour.
The six criteria and the thresholds that make an incident major
Article 18(1) of DORA lists six criteria: clients, financial counterparts and transactions affected, including reputational impact; duration and service downtime; geographical spread; data losses; criticality of the services affected; and economic impact. The Delegated Regulation turns each into a materiality threshold, and Article 8(1) makes an incident major where it has affected critical services, as defined in Article 6, and either the data-losses threshold of Article 9(5)(b) is met or two or more of the other thresholds are met.
Critical services, Article 6, means the incident affects ICT services or systems supporting a critical or important function of the entity, or financial services that require authorisation or are supervised, or constitutes a successful, malicious and unauthorised access to the entity's systems. A vendor whose product supports a critical or important function passes this gate by definition.
The thresholds of Article 9 are: for clients, counterparts and transactions, more than 10 percent of the clients using the affected service, or more than 100 000 clients, or more than 30 percent of financial counterparts, or more than 10 percent of the daily average number or value of transactions, or any client the entity has identified as relevant; for reputational impact, media coverage, repetitive complaints, likely inability to meet regulatory requirements, or likely loss of clients with material impact; for duration and downtime, a duration longer than 24 hours or a service downtime longer than two hours for ICT services supporting critical or important functions; for geographical spread, an impact in two or more member states; for data losses, any impact on availability, authenticity, integrity or confidentiality that adversely affects the entity's business objectives or regulatory compliance, or any successful malicious unauthorised access that may result in data losses; and for economic impact, costs and losses that exceed or are likely to exceed 100 000 euro.
Read from the vendor's side, two of those are yours. A two-hour outage of a product that supports a critical or important function meets the downtime threshold on its own; an incident that lasts more than 24 hours from occurrence to resolution meets the duration threshold, and Article 3 makes duration run from occurrence, or from the log entry that shows occurrence, not from detection. Add one more threshold, a second member state among the customer's clients, or a data-integrity effect, and the incident is major. Article 8(2) adds that recurring incidents with the same root cause, at least twice within six months, count together, so a flaky release that fails three customers for forty minutes each month can become one major incident in aggregate.
The three reports and their clocks
Article 19(4) of DORA sets three submissions, and Article 5 of Delegated Regulation (EU) 2025/301 sets their time limits: the initial notification as early as possible and in any case within four hours of the classification of the incident as major, and no later than 24 hours from the moment the entity became aware of it; the intermediate report at the latest within 72 hours of the initial notification, even where nothing has changed, with an updated intermediate report when regular activities are recovered; and the final report no later than one month after the intermediate report or its latest update. Where the entity classifies the incident as major later than 24 hours after becoming aware, the four hours run from classification. An entity that cannot meet a limit informs the authority before the limit expires and explains why. A limit that falls on a weekend or bank holiday moves to noon of the next working day, except for credit institutions, central counterparties, trading venues and entities that are essential or important under NIS2, for whom the initial and intermediate limits do not move.
Compare the clocks you may already know. The CRA's 24-hour early warning and the 24-hour and 72-hour notifications of NIS2 run from the vendor's own awareness. DORA's clocks run at the customer, and the four hours from classification is the shortest of the three regimes.
What each report contains, and which facts are yours
Article 1 of Delegated Regulation (EU) 2025/301 lists the general information of every submission: the entity's name, LEI and type, who submits, contacts, the parent undertaking, the currency. Article 2 lists what the initial notification contains: the entity's incident reference, the date and time of detection and of classification, a description, the criteria on which it was classified as major, the member states impacted, how it was discovered, where available its origin, whether a business continuity plan was activated, and any other relevant information. Article 3 lists the intermediate report: the authority's reference, the date and time of occurrence, the date and time of recovery of regular activities, how the criteria were fulfilled, the type of incident, the threats and techniques used by a threat actor where applicable, the affected functional areas and business processes, the affected infrastructure components, the impact on clients' financial interests, reporting to other authorities, the temporary measures taken or planned, and indicators of compromise. Article 4 lists the final report: the root causes, the dates and times when the incident was resolved and the root causes addressed, the resolution, information for resolution authorities, direct and indirect costs and losses and financial recoveries, and recurrence.
Of those, the facts that sit in the vendor's systems and nowhere else are: the time of occurrence, from your logs; the time of detection, from your monitoring; the duration and the downtime, measured the way Article 3 measures them; the origin and the type of incident; the threats and techniques, and the indicators of compromise, where the incident was an attack; the affected infrastructure components; the temporary measures and the time of recovery; the root causes, the time they were addressed, and the resolution. Everything else, clients affected, transactions, member states, costs, reputational impact, is the customer's to count, but it counts against your list of affected tenants and regions.
What the assistance clause turns into
Point (f) of Article 30(2) prices the assistance ex ante or not at all, and the reports above say what the assistance is. Within the customer's first four hours you owe the time of detection, a description, the origin where known, and your assessment of downtime so far, because the customer classifies on those. Within 72 hours you owe the time of occurrence from the logs, the components affected, the measures taken and, if an attacker was involved, the techniques and the indicators of compromise, because the intermediate report is due whether or not the incident is over. Within a month you owe the root cause analysis with dates. A vendor with several financial customers owes the same facts to each of them on each of their clocks, which is why Article 7 of Implementing Regulation (EU) 2025/302 lets a third-party provider to whom reporting has been outsourced file one aggregated report for several entities, but only where the incident originates at that provider, the entities are in one member state under one authority, each has classified it as major, and the authority has permitted aggregation.
What an ISO 27001 incident process already holds
The acts name no standard, and what follows is StandardOS's reading of where an ISO/IEC 27001:2022 management system holds the facts, with no presumption of conformity. The times of detection, occurrence, recovery and resolution are the incident record of A.5.24 to A.5.27 (planning, assessment, response, learning) if the record carries timestamps, and the logging and monitoring controls, A.8.15 and A.8.16, are where occurrence is read from. The affected components are the asset inventory, A.5.9. The root cause and the measures are the same incident record. The evidence collection control, A.5.28, is the one that produces indicators of compromise a customer's report can carry. What the standard does not give you is the customer's thresholds: a two-hour downtime on a critical function is not a severity level in ISO 27001, it is a number from Article 9(3)(b), and the incident process has to know which customers run critical or important functions on which components to raise it in time.
What to do before the first four-hour request
Record occurrence, detection, recovery and resolution as timestamps in the incident record, and measure downtime the way Article 3 does, from the first partial unavailability to full restoration. Keep a list of which customers run critical or important functions on which components and regions, so that a two-hour outage triggers the assistance clause for the right customers without waiting for them to ask. Write the assistance deliverables into the contract as the facts above with their times, and price them ex ante. Then bring the incident record to the due diligence, because the vendor policy article shows that incident reports are one of the five reports every financial customer's policy requires, and the DORA hub holds the dates of the Regulation and its acts.