DORA: what counts as technical evidence
DORA has applied since 17 January 2025. Most of it is governance, testing and contracts. A narrow slice — cryptography, certificates, the asset register, and the facts your financial customers now ask you for in writing — leaves traces anyone can observe from outside. This guide walks that slice article by article, and is explicit about where it stops.
Written by the SkyQon engineering team · Last verified 6 August 2026
What DORA actually requires
The Digital Operational Resilience Act — Regulation (EU) 2022/2554 — is a Regulation rather than a Directive. There is no transposition step and no national variation to check: the same text applies in every Member State, and it has applied since 17 January 2025.
It is organised in five blocks. ICT risk management sits in Articles 5 to 16. Incident management and reporting run from Article 17 to Article 23. Digital operational resilience testing occupies Articles 24 to 27. ICT third-party risk, which is where most suppliers first meet DORA, runs from Article 28 through the oversight framework to Article 44. Information sharing closes the set at Article 45.
Two provisions set the tone. Article 5(2) makes the management body define, approve, oversee and be responsible for the ICT risk management framework — the same personal accountability NIS2 places on management under its Article 20. And Article 9(1) requires financial entities to continuously monitor and control the security and functioning of their ICT systems. That adverb does real work: a control described as continuous is not evidenced by an artifact produced once a year.
Official text: Regulation (EU) 2022/2554
Two audiences, and the second one is usually surprised
DORA binds financial entities directly — banks, insurers and reinsurers, investment firms, payment and electronic money institutions, trading venues, crypto-asset service providers, and the rest of the list in Article 2. Those firms know they are in scope.
ICT third-party service providers are a different case. Unless the European Supervisory Authorities designate you critical under Article 31, DORA does not regulate you directly. It reaches you through your customers, and it reaches you hard. Article 28(4) requires the financial entity to run due diligence before signing. Article 28(5) permits contracting only with providers that comply with appropriate information security standards, and for services supporting critical or important functions requires the entity to take due consideration of the provider's use of the most up-to-date and highest quality information security standards. Article 30 then fixes what the contract has to contain.
So for most suppliers, DORA does not arrive as a letter from a supervisor. It arrives as a fifty-question due-diligence pack from a customer's procurement team, followed by contract language you did not draft, followed by the same pack again from the next customer three weeks later.
The consequence is plain: for a supplier, DORA readiness is a sales problem before it is a compliance problem. The firms that answer quickly, consistently and with something verifiable attached close faster than the ones that reopen the spreadsheet every time.
Which articles leave externally observable traces
Most of DORA is invisible from outside your perimeter, in the same way most of NIS2 is. A handful of provisions are the exception, because what they govern is exactly what a client, a browser or a mail server can see for itself.
| Provision | What it requires | Observable from outside |
|---|---|---|
| Art. 8 | Identify, classify and document ICT assets and their dependencies; maintain inventories and keep them updated. | The externally reachable part of the estate, and the cryptographic identities serving it. |
| Art. 9 | Continuous monitoring and control; integrity and confidentiality of data at rest, in use and in transit; security of the means of transferring data; cryptographic key protection and encryption. | Every TLS handshake your public services complete, and the certificates behind them. |
| Art. 24–25 | A resilience testing programme; Article 25(1) names vulnerability assessments and scans, open source analyses and network security assessments among the appropriate tests. | Continuous external assessment — an input to the programme, never the programme itself. |
| Art. 26–27 | Threat-led penetration testing for entities identified as required to perform it, with requirements on testers. | Nothing. TLPT is a scoped exercise with an agreement behind it. |
| Art. 28–30 | A register of information covering all ICT contractual arrangements; pre-contract due diligence; mandatory contract content. | A supplier's own external posture, and most of the technical facts a register row needs. |
| RTS Art. 6 | A documented policy on encryption and cryptographic controls, including how cryptographic technology gets updated as cryptanalysis advances. | The algorithms, key sizes and protocol versions your estate negotiates in real handshakes. |
| RTS Art. 7 | A register of all certificates and certificate-storing devices for assets supporting critical or important functions, and prompt renewal ahead of expiry. | Whether the register matches reality, and whether renewals actually happened in time. |
Everything else — incident classification, business continuity, exit plans, board oversight, contractual audit rights — is internal or contractual, and no outside-in tool can see it. Any product claiming to evidence DORA as a whole is describing something it cannot observe.
The RTS is more specific than the Regulation
Article 15 of DORA asked the European Supervisory Authorities to develop technical standards harmonising the ICT risk management tools, methods, processes and policies. The result is Commission Delegated Regulation (EU) 2024/1774 of 13 March 2024, and it is where the cryptography requirements stop being abstract.
Article 6 requires a documented policy on encryption and cryptographic controls, built on an approved data classification and ICT risk assessment. Article 6(2) sets out what it must cover: encryption of data at rest and in transit, of data in use where necessary, of internal network connections and of traffic with external parties. Article 6(3) requires criteria for selecting cryptographic techniques that take account of leading practices and standards, and obliges an entity that cannot meet them to adopt mitigation and monitoring measures instead.
Then comes the paragraph that matters most. Article 6(4) requires the policy to include provisions for "updating or changing, where necessary, the cryptographic technology on the basis of developments in cryptanalysis". That is crypto-agility written into EU financial law, years before anyone will agree on a post-quantum migration date. Article 6(5) completes it by requiring any mitigation adopted under (3) or (4) to be recorded, with a reasoned explanation — an evidence duty stated in the text rather than inferred from it.
Article 7 covers key management, and two of its paragraphs are unusually concrete. Article 7(4) requires a register of all certificates and certificate-storing devices, covering at least ICT assets that support critical or important functions, kept up to date. Article 7(5) requires prompt renewal of certificates in advance of their expiration. Both are measurable, both are testable against reality, and both are the kind of thing a spreadsheet stops reflecting within a quarter of being written.
Official text: Delegated Regulation (EU) 2024/1774
Why the policy is not the evidence
A policy is a design control: it states what should happen. What supervision and customer due diligence ask about is whether it did happen, across the period, over the whole estate. That is operating effectiveness, and it is a different artifact.
DORA is unusually explicit about this, which makes the target easier to hit than under a text that only says "have a policy". Article 6(5) of the RTS asks you to record mitigations and explain them. Article 28(3) requires the register of information to be produced to the competent authority on request. Article 24(5) requires procedures to prioritise, classify and remedy every issue that testing reveals — a remediation record, not a findings list.
Applied to the cryptographic estate, the difference is concrete. A policy mandating strong transport security is design. A record showing what every public endpoint negotiated each week for eleven months, that four exceptions appeared on dated occasions, and that each was closed within a defined window, is operating effectiveness. Only the second one answers "show me".
The Register of Information, and why the questionnaires got harder
Article 28(3) requires every financial entity to maintain and update a register of information covering all contractual arrangements for ICT services, at entity level and at sub-consolidated and consolidated level, distinguishing arrangements that support critical or important functions from those that do not. Entities report to their competent authority at least yearly on new arrangements, provider categories and the services involved, and must produce the full register on request.
A register is only as good as the facts in its rows, and most of those facts belong to the supplier: legal entity and identifier, the type of ICT service, where the service is performed and where data is processed and stored, subcontracting arrangements, and the terms governing audit, exit and data return. Article 30(2) makes several of these contractual requirements outright — including the obligation to state the regions or countries involved and to notify the customer in advance of any change.
That is why suppliers to EU finance now receive the same structured question set from every customer, several times a year, on slightly different templates. The information rarely changes. The cost is entirely in re-answering it.
One boundary, stated honestly: the register is the financial entity's obligation and cannot be delegated. A supplier cannot discharge it. What a supplier can do is make it cheap to fill — publish the answers once, keep them current, and attach evidence that a reviewer can verify without a call.
The fourth party behind your third party
Article 29 is titled "Preliminary assessment of ICT concentration risk at entity level", and its two paragraphs ask different questions. Article 29(1) is about concentration on the direct provider: whether the arrangement means contracting a provider that is not easily substitutable, or stacking several critical arrangements on the same provider or on closely connected ones. Article 29(2) is about what sits behind that provider — where a contract permits subcontracting of a critical or important function, the entity has to weigh the benefits and risks, consider subcontractors established in third countries, and assess whether long or complex subcontracting chains would impair its ability to monitor the function at all.
In the trust layer the question stops being abstract. Which certificate authority signs the certificates across the estate. Whose nameservers the zones delegate to. Whose mail infrastructure the domains rely on. These are shared upstream dependencies that nobody contracted deliberately, and they concentrate quietly: a distrust event at one CA, or an outage at one DNS provider, takes down everything that depended on it simultaneously.
This particular concentration, at least, is measurable from outside — for your estate and for your suppliers' estates, without anyone's cooperation. Whether a given concentration is acceptable is a risk decision that stays with you — but you cannot make it on a dependency you never counted.
What SkyQon evidences, stated exactly
SkyQon's DORA evidence covers eight categories. Each carries the provision it feeds and a coverage level stated on the face of the artifact, and the wording comes from a versioned mapping that is rendered verbatim into the signed report — so what you read here is what a reviewer reads there.
| Evidence category | Provision | Coverage |
|---|---|---|
| Cryptography and crypto-agility — post-quantum readiness of the certificate estate and the ability to migrate as cryptanalysis advances | Art. 9 / RTS Art. 6 | Direct |
| Transport and certificate hygiene — protocol versions, validity and expiry, key and signature strength, eIDAS qualification | Art. 9 | Direct |
| Email authentication — SPF, DKIM, DMARC and TLS-RPT posture across monitored domains | Art. 9 | Direct |
| DNS security — DNSSEC, CAA and DNS hygiene across monitored domains | Art. 9 | Direct |
| Continuous attack-surface evidence — shadow, misconfigured and dead assets, feeding the vulnerability-assessment side of testing | Art. 24–25 | Supporting |
| Monitoring continuity — demonstrated continuity of external monitoring across the period | Art. 24–25 | Supporting |
| Cryptographic identity register — a de-duplicated register of every certificate and identity across scanned, auto-renewed, discovered and non-TLS assets | Art. 8 | Supporting |
| Fourth-party and concentration — shared upstream certificate authority, DNS and mail dependencies, and how concentrated they are | Art. 28–30 | Supporting |
Four direct, four supporting, none described as compliance. Direct means our telemetry is the primary evidence for that provision. Supporting means it is one input among several you will still need to assemble yourself.
On the supplier side the same telemetry drives a shareable trust page your financial customers can read without an account, a Register of Information field set you fill once, a generated Article 30 addendum, and a signed evidence report carrying a content hash anyone can recompute against our public verifier. Suppliers you register yourself are graded from the same public signals, so the concentration question can be asked one layer further out.
What it does not evidence
Incident reporting under Articles 17 to 23 is outside the product. We detect and timestamp; we do not submit to a national competent authority. Those submissions follow Article 19's sequence of an initial notification, an intermediate report and a final report, on templates and within time limits set under Article 20.
Threat-led penetration testing under Articles 26 and 27 is out of scope entirely. So is the buyer side of the register: SkyQon furnishes supplier-side evidence and is not a governance platform that manages a financial entity's Register of Information for it.
Two boundaries inside what we do cover. The concentration analysis measures certificate authority, DNS and mail dependencies; hosting, network-level and content-delivery concentration are not included, because we have no dependable source for them and a bad inference would be worse than a declared gap. And supplier grading is measurement of an external trust surface, not a security rating built on breach or botnet telemetry — a different product category with different data behind it.
Finally, the framing. Everything is described as aligned to DORA, never as DORA compliance or certification. Article 5(2) puts approval and oversight on your management body, and no artifact from any vendor moves it.
A practical sequence
- Work out which side of the contract you are on. Financial entities owe the obligations. Suppliers inherit them through Articles 28 to 30. Plenty of firms are both, and the two roles need different artifacts from the same underlying data.
- Build the certificate register before someone asks for it. RTS Article 7(4) asks for one covering at least critical or important functions, kept current. Every serious due-diligence pack asks you to describe it. Discovering the estate is the part that takes weeks.
- Make renewal evidence a by-product. Article 7(5) wants prompt renewal ahead of expiry. The proof is a dated record of renewals that happened on time — capture it automatically, because it cannot be reconstructed afterwards.
- Answer the crypto-agility clause with a plan, not a claim. Article 6(4) expects provisions for changing cryptographic technology as cryptanalysis develops. If you cannot yet, Article 6(5) expects the mitigation and the reasoning to be written down. An inventory of what you run today is the first half of either answer.
- Write your register answers once. Legal entity, service type, locations, sub-processors, security contact, notification windows, recovery objectives, exit terms. Publish them where a customer can self-serve, and the fifth questionnaire costs what the first one did — nothing.
- Count your upstream concentration before a customer counts it for you. One certificate authority, one DNS provider and one mail platform behind an entire estate is a defensible choice and an indefensible surprise. The difference is whether you brought the number to the meeting.
Common questions
Is there such a thing as DORA certification?
No. DORA places obligations on financial entities and creates an oversight regime for providers designated critical under Article 31. Nothing in it certifies anyone compliant, and no vendor can grant such a status. Treat the claim as a signal about the vendor.
Does DORA apply to me if I only sell software to a bank?
Not directly, unless you are designated a critical ICT third-party service provider. It reaches you through your customer's obligations under Articles 28 to 30: due diligence before signing, specific contract clauses, and a register row that has to be kept current.
Which article covers cryptography?
Article 9 at level one — particularly 9(2) on data at rest, in use and in transit, 9(3)(a) on the security of the means of transferring data, and 9(4)(d) on key protection and encryption. The detail that matters in practice is in the RTS: Article 6 for encryption and cryptographic controls, Article 7 for key and certificate management.
Where does post-quantum fit?
In RTS Article 6(4), which requires provisions for updating cryptographic technology as cryptanalysis develops. It does not name post-quantum cryptography — it did not need to. A migration plan is the natural answer, and an inventory of what you currently run is its precondition.
Is an external scan enough for Articles 24 and 25?
No. Article 25(1) lists vulnerability assessments and scans among many test types, inside a programme Article 24 requires you to design, run with independent testers, and apply at least yearly to systems supporting critical or important functions. Continuous external assessment feeds it; it does not replace it.
How does this differ from NIS2?
Different scope, different supervisors, largely the same technical evidence underneath. DORA is a Regulation applying directly since January 2025; NIS2 is a Directive that binds you through national law. If you already produce evidence for one, most of it re-serves the other.
Read the companion guide: NIS2 Article 21(2) — what counts as evidence
Produce this evidence for your own estate
The DORA Trust Center add-on turns continuous monitoring into a shareable supplier-readiness page, Register of Information support, a generated Article 30 addendum and a signed, hash-verified evidence report — with coverage levels stated honestly on the face of it. It is available as an add-on on any paid plan. Start with a free check to see what yours currently looks like.