DORA is no longer a project. It is a reporting cycle you are inside of.

The deadlines chain off each other, which is the part most runbooks get wrong. Under the reporting technical standards a major ICT-related incident requires an initial notification within four hours of classifying it as major, and in any case within 24 hours of becoming aware of it; an intermediate report within 72 hours of that initial notification; and a final report within one month of the intermediate report, or of the latest updated intermediate report. None of the later clocks run from the incident itself.

There is a weekend and bank-holiday derogation allowing submission by noon on the next working day — but it is not available to credit institutions, central counterparties, trading venue operators, or entities designated essential or important under NIS2. For most Luxembourg financial entities, in other words, it is not available.

The four-hour figure is not the hard part. Classification is. Somebody has to decide that this incident is major, and that decision determines whether a clock is running at all. It is a judgement with supervisory consequences, made under pressure, often at night — exactly the kind of decision that must not be automated, and exactly the kind that needs a name, a deputy and a rehearsed route before it is needed.

Significant cyber threats may be notified voluntarily. Many entities never decide in advance whether they will, which means the question gets debated during the event.

Article 30 sets what must be in a contract between a financial entity and an ICT service provider, and it does so in two tiers that are frequently conflated. Article 30(2) applies to every ICT contract: description of the functions and services, the locations of provision and of data processing, data protection and availability, access to and recovery of data on insolvency, service level descriptions, incident assistance, cooperation with competent and resolution authorities, termination rights and notice periods, and participation in security awareness.

Article 30(3) applies only where the ICT service supports a critical or important function, and that is where the demanding clauses live: quantitative and qualitative performance targets, unrestricted rights of access, inspection and audit, participation in threat-led penetration testing, and exit strategies with an adequate transition period. If a redraft lands on your desk with unrestricted audit rights attached to a marginal service, the criticality assessment is the conversation to have first.

Two honest positions matter here, and we hold the second one ourselves. There is no DORA compliance status available to a supplier in general — the regulation creates no certification scheme for providers, most of its obligations rest on the financial entity, and a vendor cannot self-declare its way into conformity. The exception is real and worth knowing: ICT providers designated critical by the European Supervisory Authorities under the oversight framework are supervised directly, with joint examination teams, inspections and penalty payments. That designation applies to a short list of systemically important providers, and a small consultancy is not on it.

So what a supplier like us can honestly offer is this: we accept the clauses of article 30, and we can evidence the things those clauses promise. We are not a CSSF-regulated entity and not a PSF de support, and we say so in the same sentence every time. A supplier claiming DORA compliance on their own behalf is telling you something that is not available to them — which is useful information about the supplier.