Let’s start with the hard question: if a four-hour payment-authorization outage is not major under DORA, what evidence would make that defensible to a supervisor six months from now?
The enforcement context matters, but it cannot replace the classification test. We need to separate anxiety from criteria. Today’s decision is narrow: does this outage meet DORA’s major ICT-related incident threshold and start the initial notification clock, or do we document it as non-major with a clear evidence pack?
I want the room focused on five things first:
- Was payment authorization a critical or important function for this entity?
- How many clients, transactions, counterparties, or business lines were actually affected?
- Did the four-hour duration, service unavailability, transaction value, or geographic spread cross DORA major-incident indicators?
- When did the firm have enough facts to classify the incident — because that is the clock question.
- If we choose “non-major,” what proof must be attached so the decision survives supervisory review?
Sofia, your regulatory lens will anchor us, but I do not want a legal answer floating above the facts. James, we need the operational evidence trail. Pierre, quantify business impact tightly. Alex, only pull us into root cause if it changes classification. Lena and Elena, keep us honest on supervisor posture and cross-border sensitivity.
The output is a regulatory decision note. Short, defensible, and decision-ready.
Sofia, anchor this. We have an EU-regulated financial entity with a four-hour payment-authorization outage yesterday and no reliable impact counts yet. The decision is whether it meets DORA major ICT-related incident classification and starts initial notification to the competent authority, or whether we document non-major with evidence. Give me the DORA classification test as a decision rule: which criteria are mandatory, which thresholds matter, when the classification/initial-notification clock starts, and what facts would make a non-major decision defensible despite supervisors focusing on reporting discipline. Do not give a generic DORA overview; make the call conditional on the missing facts.
Halil, the decision rule is this: treat the outage as potentially major unless the entity can evidence that the affected payment-authorisation service was not supporting a critical or important function and did not meet the materiality criteria in Commission Delegated Regulation (EU) 2024/1772. The classification criteria to test are the DORA RTS criteria in Articles 1–8: affected clients/financial counterparts/transactions, reputational impact, duration/service downtime, geographical spread, data loss, criticality of affected services, and economic impact. For this fact pattern, the decisive branch is duration/service downtime plus criticality: a four-hour payment-authorisation outage is hard to defend as non-major if that service supports payment execution, customer access to funds, transaction approval, or another critical/important function. Missing impact counts do not by themselves justify delay if the service-downtime and criticality limb is met.
On timing: the EBA description of the DORA reporting technical standards states the initial notification is due 4 hours after classification and no later than 24 hours after detection, with an intermediate report at 72 hours and a final report at 1 month. So the clock is not “when impact counts are reliable”; it starts from detection for the outer 24-hour limit, and from classification for the 4-hour initial notification window. If the incident occurred yesterday and payment authorisation was actually unavailable for four hours, my cautious legal position is: classify as major and submit the initial notification, unless Legal/ICT risk can contemporaneously document why the DORA Article 8 classification test was not met. Commission Implementing Regulation (EU) 2025/302 also expressly contemplates later reclassification from major to non-major where further assessment shows the incident never met the Article 8 criteria, so over-reporting with later correction is safer than missing the initial clock.
A non-major decision is defensible only if the file shows: the outage did not affect ICT services supporting a critical or important function; actual service downtime under the relevant DORA threshold; no material client/counterparty/transaction impact once counts are known; no cross-border/geographic spread; no data loss affecting confidentiality, integrity, authenticity, or availability; no material reputational impact; and no economic-loss threshold met. The memo should record detection time, classification time, affected systems, payment flows blocked or degraded, compensating manual processes, customer-facing impact, and why each 2024/1772 criterion was or was not met.
James, take the operational evidence lens. For a four-hour payment-authorization outage, what minimum facts must the GRC lead obtain within the next hour to classify under DORA without guessing? I want the evidence trail: incident start/end, service downtime, affected critical function mapping, transaction/client impact, workaround availability, data integrity/confidentiality, third-party dependency, and root-cause confidence. Also tell us when the organization likely had 'enough facts' to start the classification decision clock.
Halil, for the next hour I’d have the GRC lead collect only classification-grade facts, not a full RCA. Minimum evidence: exact awareness time, impact start, recovery/end time, and whether the four hours were full outage or degraded authorization; measured service downtime from monitoring and transaction logs; mapping of the payment-authorization service to a DORA critical or important function; number/value of failed, delayed, duplicated, or reversed transactions; number and relevance of affected clients or financial counterparts; countries/branches/channels affected; whether a workaround existed and how much traffic it actually carried; any evidence of data loss, integrity failure, confidentiality breach, or malicious unauthorized access; named third-party dependency if a processor, scheme, cloud, or network provider was involved; and root-cause confidence stated as “known / suspected / unknown” with supporting ticket, log, change, or provider evidence.
The practical classification trigger I’d watch is this: DORA’s criteria include clients/counterparties/transactions, duration and service downtime, geographical spread, data losses, critical services affected, reputational impact, and economic impact. The RTS evidence says service downtime over two hours for ICT services supporting critical or important functions meets the duration/service-downtime threshold. So for a four-hour payment-authorization outage, if payment authorization maps to a critical or important function, they likely had enough facts to start the classification decision as soon as the outage crossed the two-hour mark — they should not wait for full root cause. Root-cause uncertainty goes into the report as uncertainty.
On timing: the initial notification obligation is tied to classification as a major ICT-related incident — as early as possible, within four hours of classification, and no later than 24 hours from awareness, based on the official DORA reporting standard evidence. My operational call: open the DORA classification record immediately, preserve the logs now, assign named owners for each evidence field, and have Legal/GRC make the classification call once the critical-function mapping plus downtime and impact facts are confirmed.
Pierre, quantify the business impact tightly. For a four-hour payment-authorization outage at a financial entity, which numbers determine major vs non-major under DORA: clients affected, transaction count/value, percentage of daily/peak authorization volume, geographies, business lines, counterparties, economic loss, and reputational signal? Give practical thresholds or proxies a GRC lead can defend, and say what impact pattern would push you to notify even if the legal threshold is borderline.
For a four-hour payment-authorization outage, my board-level read is this: under DORA, the outage is not priced by duration alone. If payment authorization is a critical service, a four-hour downtime likely clears the DORA downtime trigger because the RTS uses service downtime over two hours for critical/important functions as a key threshold. But to call it major, I would look for one more materiality trigger: >10% of daily transaction count or value affected, >10% of clients using the service or >100,000 clients, >30% of relevant financial counterparties, impact in two or more EU Member States, economic loss above roughly €100,000, data loss, or clear reputational impact.
Practical GRC thresholds I would defend for a payments entity:
- Non-major leaning: single country, single business line, under 10% daily authorization count/value, under 100,000 clients, no key counterparties, no press/social/regulator signal, loss under €100k, and clean recovery inside four hours.
- Major leaning: outage hits peak hours where the four-hour window represents 10%+ of daily auth volume or value, affects two or more Member States, disrupts high-value card, merchant acquiring, SEPA, ATM, or corporate payments lines, or creates failed settlement/merchant/counterparty knock-on effects.
- Notify even if borderline: if customers cannot pay at scale, merchants publicly complain, call-center volume spikes, social media or press picks it up, VIP/corporate clients are affected, or the failed authorizations cluster in a high-visibility geography or business line. That reputational pattern can turn a technically borderline incident into a board-disclosable operational resilience event.
My simple decision rule: four hours + critical payment service + 10% daily volume/value or cross-border impact = notify as major unless counsel has a very strong contrary view. The downside of over-notifying is administrative; the downside of under-notifying is regulatory, market, and trust damage.
Alex, keep this narrow: root cause only matters if it changes DORA classification or response. For yesterday's four-hour payment-authorization outage, what technical facts would distinguish a routine availability failure from a cyber/ICT incident with data-integrity, resilience, or third-party-risk implications? What should be checked immediately so we don't classify non-major and later discover an intrusion, service provider incident, or transaction-integrity issue that changes the regulatory answer?
Halil, the key discriminator is whether this was just “the payment switch fell over” or whether it touched DORA impact criteria. DORA defines payment-related incidents around adverse impact to availability, authenticity, integrity, confidentiality of payment-related data or payment services. And RTS 2024/1772 treats “duration/service downtime” as material where downtime is over 2 hours for ICT services supporting critical or important functions. So a four-hour authorization outage is already in dangerous territory if that authorization path supports a critical or important function. Don’t let “no breach found yet” lull people into a non-major classification.
Immediate technical checks:
- Transaction integrity: reconcile auth requests, approvals, declines, reversals, duplicate messages, delayed settlements, and ledger/core-banking state. Look for “authorized but not recorded,” “declined but captured,” replayed ISO/payment messages, or queue reprocessing errors.
- Data integrity/confidentiality: check whether payment data, tokens, customer identifiers, routing tables, HSM/key-management events, or fraud-rule configs changed during the outage window.
- Cyber evidence: review privileged access, API gateway/WAF logs, IAM changes, EDR alerts, database writes, config pushes, CI/CD deployments, and admin sessions before and during the outage. Root cause being “availability” does not prove it was non-cyber.
- Resilience facts: confirm whether failover worked, whether RTO/MAO/MTPD was breached, whether backups/queues recovered cleanly, and whether degraded processing created backlogs or transaction loss.
- Third-party dependency: identify whether the failure originated in a processor, cloud, telecoms, HSM provider, fraud-scoring service, card scheme interface, or managed ICT provider. ENISA guidance specifically expects incident handling to account for ICT services, systems, or products from suppliers and service providers.
- Scope: count affected clients, counterparties, transactions, jurisdictions, and member states. RTS evidence flags clients/transactions, duration/downtime, geographical spread, reputational impact, data losses, and economic impact as classification criteria; geographical spread is material where impact reaches two or more Member States.
My blunt take: classify cautiously until reconciliation and access-log review are done. A four-hour outage can be boring plumbing. Or it can be the smoke from a transaction-integrity fire. The first 24 hours should prove which one.
The room has narrowed the problem from “we don’t have impact counts yet” to “we may already have enough to start a defensible classification clock.” Sofia, James, Pierre, and Alex all converged on the same core point: a four-hour payment-authorization outage is not just an operational inconvenience under DORA if that authorization service supports a critical or important function. Duration and service downtime matter, and several of you pointed to the two-hour threshold for critical or important ICT services as the danger line.
At the same time, we should be careful not to overstate what has been proven. We still do not have the impact counts, transaction value, client numbers, geographic spread, economic loss, or a verified root cause. Pierre’s framing is useful here: duration alone is a strong signal, but the major/non-major decision is better defended when tied to additional materiality evidence such as transaction volume, affected clients, cross-border impact, counterparties, reputational impact, data loss, or economic loss. James gave us the evidence trail the GRC lead needs within the next hour: exact timing, full outage versus degradation, monitoring and transaction logs, critical-function mapping, workaround effectiveness, third-party involvement, and any signs of integrity, confidentiality, or malicious activity.
Alex’s contribution keeps the technical scope disciplined. Root cause is not the main question unless it changes classification or response. But integrity and cyber indicators cannot be ignored, because a payment-authorization outage can create downstream inconsistencies even if no breach is yet confirmed. “No reliable impact counts” and “no breach found yet” are not the same as evidence of low impact.
The next thing we need to sharpen is Sofia’s regulatory position. It sounded close to saying that a four-hour outage of a payment-authorization service supporting a critical or important function may be enough, by itself, to classify as major and trigger notification timing. Before the room relies on that, we should test whether DORA treats that as a standalone major criterion, or whether the entity still needs another materiality threshold to be satisfied or at least reasonably suspected.
Claim: Your position sounded like a four-hour outage of a payment-authorization service supporting a critical or important function is enough to classify as major under DORA, because duration/service downtime plus criticality is decisive.
Counter-evidence: Pierre framed it as: four hours plus criticality is dangerous, but for a major classification he would look for one more materiality trigger such as >10% daily transaction value/count, >100,000 clients, cross-border impact, >€100k loss, data loss, or reputational impact. Please reconcile this precisely: under the RTS, is 'service downtime over two hours for a critical/important function' itself the additional materiality trigger, or must there be another non-duration impact criterion?
Halil, Pierre is right on the legal structure. Under Commission Delegated Regulation (EU) 2024/1772, “critical services affected” is the mandatory gateway, but it is not by itself the second materiality trigger. Article 8 says an incident is major where it has affected critical services under Article 6 and either Article 9(5)(b) is met — the special data-loss / malicious unauthorised access route — or two or more of the other Article 9 materiality thresholds are met. The RTS also states that service downtime longer than 2 hours for ICT services supporting critical or important functions is a materiality threshold. So: a four-hour outage gives you one Article 9 threshold, not automatic major classification, unless the special Article 9(5)(b) route applies.
So the reconciled rule is: payment-authorisation outage + critical/important function + >2 hours downtime = high-risk and one threshold met; it becomes major only if one additional Article 9 threshold is also met, such as affected clients/transactions, reputational impact, geographical spread, data loss, or economic impact. Pierre’s framing is therefore the more precise classification test. My practical advice remains cautious: if counts are unavailable, do not call it non-major casually; document a live “pending classification” assessment, capture detection/classification times, and make the initial notification if a second threshold is reasonably indicated or cannot be ruled out within the reporting window.
A defensible non-major decision would say: critical service affected, yes; downtime threshold met, yes; but no evidence yet of the second Article 9 threshold — no material client/counterparty/transaction count, no cross-border/geographic spread, no data loss or unauthorised access, no reputational impact, and no economic-loss threshold met. That memo must be contemporaneous, because supervisors will focus on whether the entity applied the RTS test on time, not whether it waited for perfect impact counts.
The important correction here is that “critical service plus four hours down” is not the whole DORA major-incident test. Sofia has tightened the legal structure: the affected critical service is the gateway, and the four-hour outage of an ICT service supporting a critical or important function gives us one materiality threshold — service downtime beyond two hours — but not automatic major classification on its own.
That changes the room’s working position. The incident is clearly in a danger zone: payment authorization, critical or important function, and four hours of downtime are enough to treat it as high-risk and to start gathering evidence urgently. But unless the special Article 9(5)(b) path applies — data loss or malicious unauthorized access in the relevant sense — the team still needs at least one more Article 9 threshold before calling it major. That second threshold could come from affected clients or transactions, economic impact, reputational impact, geographical spread, data loss, or another qualifying materiality factor. So Pierre’s challenge was well taken: we should not collapse “one decisive-looking threshold” into the full classification test.
The caveat is practical rather than academic. In a live incident, incomplete impact counts do not mean the organization can safely wait passively. The four-hour outage already creates enough regulatory significance that the GRC team should be documenting the classification reasoning, the missing evidence, and the basis for any provisional position. What we do not yet have is the additional confirmed threshold that would make the major classification firm, unless facts emerge around malicious access or data loss.
That is why the next turn should move from “what is the classification test?” to “what does the firm do today?” If the outage happened yesterday, has been recovered, and the impact numbers are still incomplete, the hard question is timing: whether the team should notify, prepare a draft, record a provisional non-major assessment, or escalate internally while the second threshold is still being verified.
Sofia, pin down the timing and the note. Assume the outage occurred yesterday and recovered after four hours; the GRC team is deciding today with impact counts still incomplete. Under DORA reporting standards, when exactly does the initial notification clock start — detection/awareness, classification as major, or when the second threshold becomes reasonably knowable? If we classify as non-major now, what wording should the decision note use to avoid looking like delay-by-uncertainty?
Halil, the timing rule is: the assessment starts at awareness/detection, but the initial notification clock is tied to classification as major, with a hard outer discipline rule. Commission Delegated Regulation (EU) 2025/301 states that the initial notification must be submitted as early as possible, within 4 hours from classification as a major ICT-related incident, and no later than 24 hours from the moment the financial entity became aware of the ICT-related incident. If the entity did not classify it as major within that first 24 hours but later does classify it as major, the initial notification is due within 4 hours from that later classification. The “second threshold becomes reasonably knowable” is not itself the formal clock; it is the factual point at which classification should be made. If the second threshold was reasonably knowable yesterday, treating today as a fresh clock is risky.
For the note, I would avoid “impact counts incomplete, therefore non-major.” Use wording like: “As of [time/date], the incident affected a critical/important payment-authorisation ICT service and exceeded the service-downtime threshold. The entity has assessed all available evidence against the Article 9 materiality thresholds and, at this time, has not identified a second threshold: no confirmed material client/counterparty/transaction threshold, no known cross-border/geographic spread, no data loss or unauthorised access, no reputational impact, and no economic-loss threshold. Classification remains under active review, with named owners and evidence sources for each outstanding metric; if any second threshold is confirmed or becomes reasonably indicated, the incident will be reclassified as major and the initial notification submitted within 4 hours of that classification.”
That framing makes the non-major decision defensible because it is not delay-by-uncertainty; it is a contemporaneous criteria-by-criteria classification decision with a reclassification trigger. But if payment logs, customer complaints, settlement disruption, or management reporting already suggest a second Article 9 threshold, I would not wait for perfect counts — classify major and notify.
The timing issue is now much sharper: DORA does not give the team a comfortable “wait until every impact count is complete” window. Sofia’s point is that awareness or detection starts the assessment obligation, but the formal initial-notification deadline attaches to classification as a major ICT-related incident, with an outer constraint: as early as possible, within four hours of major classification, and no later than 24 hours from awareness if the incident is already classifiable within that period.
That matters for the facts we are testing. If the outage happened yesterday, lasted four hours, and the service was a critical or important payment-authorisation ICT service, then the key question is not simply “when did GRC finish the count today?” It is whether the second threshold was reasonably knowable yesterday. If it was, then a decision today may not reset the clock cleanly. Sofia is also steering us away from a weak file note that says, in effect, “counts incomplete, therefore non-major.” The safer note is a time-stamped assessment: what was known, which threshold was already met, what remains unverified, what evidence is being gathered, and whether major classification has or has not been reached on the available facts.
There is still uncertainty in the room because we have not verified the missing impact counts or any other second threshold. But the compliance posture is clearer: incompleteness is not a shield if the available evidence already supports classification, and delay becomes hard to defend once classification should reasonably have been made.
That sets up the next lens well. We have the legal timing mechanics; now we need to look at how a supervisor might read the same behavior in practice, especially if supervisory attention is already on incident-reporting discipline rather than just the underlying outage.
Lena, take the supervisory-intelligence lens, not the legal test. The user says supervisors are currently focused on incident-reporting discipline. For an EU financial entity facing a four-hour payment-authorization outage that meets criticality plus >2h downtime but lacks confirmed second materiality threshold, what pattern of supervisory behaviour should the GRC lead expect? Is the bigger risk over-notification noise, under-classification,... [arg clipped]
Halil, supervisory-intelligence read: the GRC lead should expect supervisors to look less at “did you file everything?” and more at whether the entity can show a disciplined classification clock — awareness time, when it became classifiable, why the second threshold was or was not met, and when escalation would have occurred.
On the facts given, the outage crosses a hard DORA signal: service downtime over 2 hours for ICT services supporting critical or important functions. But the RTS pattern for a major incident still points to critical services affected plus either malicious unauthorised access with possible data loss, or two additional criteria met. So if the second materiality threshold is genuinely unconfirmed, I would not call this cleanly major on evidence alone — confidence: moderate.
The bigger supervisory risk is under-classification or late reclassification, not good-faith over-notification noise. A four-hour payment-authorisation outage is too close to the reporting perimeter to sit in a queue; if treated as non-major, the file needs a contemporaneous rationale and a trigger for immediate upgrade. If it is classified as major, the timing discipline is tight: initial notice within 4 hours of classification and no later than 24 hours from awareness, with follow-on reporting cadence expected.
Lena’s supervisory read shifts the emphasis from a simple yes-or-no filing question to the evidence trail around classification. The important point is that a four-hour payment-authorization outage is already close enough to DORA’s major-incident perimeter that supervisors would expect a disciplined clock: when the entity became aware, when the incident became classifiable, what thresholds were known at that moment, and what facts would trigger an immediate upgrade.
She is not saying the incident is automatically major on the limited facts we have. Her caveat is important: downtime above two hours for ICT services supporting critical or important functions is a strong signal, but the major-incident pattern still depends on the broader RTS criteria — for example, critical services plus malicious unauthorized access with possible data loss, or enough additional materiality criteria being met. If that second threshold is genuinely unconfirmed, calling it “cleanly major” would overstate the evidence. Her confidence is moderate, not absolute.
But the supervisory risk she flags is practical: this is not the kind of outage that should sit in an ordinary investigation queue while the reporting clock quietly burns. If the entity decides it is not yet major, that decision needs to be documented contemporaneously, with a clear reason and a clear trigger for reclassification. If it is classified as major, the filing discipline becomes tight very quickly.
That naturally takes us to the threshold matrix. We now need to turn the discussion from supervisory posture into a decision note a GRC lead could actually use: which DORA RTS criteria are already satisfied by a four-hour payment-authorization outage, which remain unknown, and what evidence would move the incident from “near the perimeter” to “major and reportable.”
Pierre, tighten the threshold matrix for the decision note. For a four-hour payment-authorization outage, list the practical DORA RTS materiality thresholds you would expect GRC to test and evidence: clients, financial counterparties, transaction count/value, duration/service downtime, geographic spread, data loss/unauthorised access, reputational impact, and economic loss. Mark anything that is qualitative or requires business-... [arg clipped]
Halil, for the decision note I’d make GRC evidence this matrix:
| DORA RTS criterion | Practical materiality threshold to test | Evidence/proxy |
|---|---|---|
| Clients | >10% of clients using affected payment service, or >100,000 clients | unique impacted cardholders/merchants/corporates; failed auth users |
| Financial counterparties | >30% of relevant counterparties | schemes, processors, correspondent banks, merchant acquirers |
| Transaction count | >10% of daily average transactions for the affected service | failed/timeout authorizations vs normal daily and peak-hour baseline |
| Transaction value | >10% of daily average value for the affected service | value of failed/timeout auths; use comparable periods if exact count/value unavailable |
| Duration / downtime | Incident duration >24h, or service downtime >2h where it supports critical/important functions | a four-hour payment-auth outage likely clears the downtime test if auth is critical |
| Geographic spread | Impact in 2+ EU Member States | BIN geography, merchant location, processing entities, customer domicile |
| Data loss / unauthorised access | Qualitative/materiality test | any integrity/confidentiality issue, unauthorised access, or regulatory/business-objective impact |
| Reputational impact | Qualitative/materiality test | press/social pickup, regulator attention, repeated complaints, material client/counterparty loss risk |
| Economic loss | >€100,000 actual or likely direct/indirect cost | lost fees, compensation, SLA credits, incident cost, customer remediation |
My notification bias: if the four-hour window hits peak authorization hours, crosses 10% daily count/value, affects two Member States, or creates visible merchant/customer failure, I’d notify even if counsel says one limb is borderline. The board question is not “can we argue this down?” — it is whether under-notification creates a larger regulatory and trust-loss exposure than early reporting.
Pierre has now made the classification test much more concrete: the room is no longer talking about “a four-hour outage” in the abstract, but about a structured DORA materiality matrix that GRC can evidence tonight. The key shift is that the outage duration is only one lane in the analysis. For payment authorization, if the service is critical or important, four hours likely satisfies the downtime signal because the RTS threshold to test is service downtime above two hours. But Pierre’s framing also forces the team to check the other lanes: affected clients, counterparties, transaction count, transaction value, geographic spread, and any data loss or unauthorized access dimension.
The practical thresholds he put on the table are useful because they translate supervisory language into evidence requests: more than 10% of clients or more than 100,000 clients, more than 30% of relevant counterparties, more than 10% of daily average transaction count or value, impact across two or more EU Member States, and the separate qualitative test for data or access compromise. We should preserve the caveat, though: these are decision-note thresholds to test and document, not proof that every threshold has been crossed. The only item that appears strongly indicated from the facts so far is the four-hour downtime of a payment-authorization capability, assuming it is indeed classified as supporting a critical or important function.
That means the next question is not “do we like the matrix,” but “can the institution operationalize it defensibly under time pressure?” James is the right person to take this forward: convert Pierre’s matrix and Sofia/Lena’s supervisory posture into a tonight-ready evidence workflow, showing which teams supply which data, what proxies are acceptable if exact transaction metrics are delayed, how to timestamp awareness and classification, and how to support a filing decision without overstating facts that are still unverified.
James, convert this into a defensible evidence workflow for tonight. Given Sofia/Lena's position — critical service affected is the gateway, four-hour downtime is one materiality threshold, major needs the special malicious/data-loss route or another materiality threshold — what exact sequence should operations/GRC follow in the next 60 minutes before signing major vs non-major? Include what evidence is sufficient to document non... [arg clipped]
Halil, I’d run this as a 60-minute evidence gate, not a debate. First 15 minutes: Ops proves the timeline — awareness time, impact start, recovery time, monitoring screenshots, incident ticket, and whether payment authorization was fully unavailable or only degraded. In parallel, GRC pulls the service map showing whether payment authorization supports a critical or important function, because that is the gateway Sofia and Lena are relying on. If that mapping is not documented, do not guess — record “criticality unconfirmed” and escalate to the accountable service owner immediately.
Minutes 15–40: split the evidence into “major-supporting” and “non-major-supporting.” Major-supporting: service downtime over two hours for a critical/important function; evidence of successful malicious unauthorized access; data integrity/confidentiality/availability loss; affected client or counterparty counts; failed/delayed transaction count and value; multi-country impact; reputational trigger; estimated direct economic loss; third-party dependency failure. Non-major-supporting evidence is not “we think it was small.” It is documented proof: critical-service mapping reviewed; four-hour downtime confirmed as only one threshold; no confirmed malicious access from SIEM/EDR/IAM logs; no data loss/integrity issue from reconciliation and database checks; transaction backlog fully reconciled; affected clients/transactions below internal DORA threshold worksheet; workaround availability and actual usage logged; third party confirms no broader incident if applicable.
Minutes 40–60: GRC signs one of three states — major, non-major with evidence, or classification pending due to missing facts. My operational line: the organization likely had enough facts to start the classification decision clock once it knew payment authorization was a critical/important service and the outage had passed the two-hour service-downtime threshold; it did not need final root cause. But to sign major, under Sofia/Lena’s framing, it needs that additional route: malicious/data-loss evidence or another materiality threshold. If those are actively disproven and logged tonight, non-major is defensible; if they are merely unknown, do not sign non-major yet.
James has turned the room’s legal classification question into an operational evidence gate: tonight’s job is not to argue toward a preferred outcome, but to collect enough proof to make the DORA assessment defensible. The important change is process discipline. Ops must first establish the basic incident timeline — when awareness occurred, when impact began, when recovery happened, what monitoring and tickets show, and whether payment authorization was fully unavailable or merely degraded.
He also reinforced Sofia and Lena’s key dependency: the classification hinges on the affected service and its criticality mapping. If payment authorization is documented as supporting a critical or important function, the four-hour downtime becomes a strong materiality signal. If that mapping is not documented, James is clear that the team should not fill the gap with assumptions. The correct record is “criticality unconfirmed,” followed by escalation to the accountable service owner.
The second useful move is separating evidence that supports a major incident finding from evidence that genuinely weighs against it. On the major-supporting side, James listed the evidence lanes the team should test: downtime over two hours for a critical or important function, successful malicious unauthorized access, loss of data confidentiality, integrity, or availability, affected client or counterparty counts, failed or delayed transaction count and value, multi-country impact, reputational triggers, direct economic loss, and third-party dependency failure. On the non-major side, the standard is not “we feel the impact was limited.” It has to be documented proof that the relevant thresholds were not met or remain unconfirmed.
So the room’s practical conclusion is now fairly tight: a four-hour payment authorization outage may be enough to trigger a materiality concern if the critical-or-important service link is evidenced, but “major” should still be recorded through the full threshold matrix, especially if the malicious-access or data-loss path is being considered. We are ready to synthesize this into the final decision logic: what can be concluded now, what must be escalated, and what evidence gaps should be preserved explicitly rather than smoothed over.
Decision: do not sign a clean “non-major” classification on the facts currently stated. A four-hour payment-authorization outage likely affects a critical or important function and exceeds the DORA service-downtime threshold, but that alone is not automatically major. Classify as major and notify if any second materiality threshold is met or cannot be disproven now; classify as non-major with evidence only if the evidence pack affirmatively rules out the second threshold and malicious/data-loss route.
Four-hour downtime is one DORA materiality threshold if payment authorization supports a critical or important function.
Major classification needs either the special malicious/data-loss route or another materiality threshold.
“Impact counts incomplete” is not a defensible non-major rationale.
The initial notification clock is tied to major classification, but delay is risky if the facts were reasonably knowable yesterday.
Complete the DORA classification matrix within 60 minutes: criticality, downtime, clients, transactions, counterparties, countries, reputation, economic loss, and data/malicious-access checks.
If any second threshold is met or cannot be disproven, classify as major and notify immediately.
If classifying non-major, attach evidence proving thresholds were tested and not met.
Record awareness time, classification time, approver, rationale, and seven-day upgrade triggers.