Is there a DORA certification? No, and what that means for your audit plan
A customer, contract or supervisor now asks for DORA evidence, and the first question is usually whether a certificate exists. It does not. DORA sets no certification scheme, and no auditor can certify that an entity is DORA compliant overall. Compliance is tested by competent authorities using their powers under Article 50, which include access to documents and data, on-site inspections and investigations, and orders for corrective measures. Your audit plan should therefore be built around what a supervisor can request and read, not around a badge to display. In practice, the evidence set has four parts. The first is the framework review report: Article 6(5) requires the ICT risk management framework to be documented and reviewed at least yearly and after major ICT-related incidents, and the report must be available to the competent authority on request. The second is internal audit. Entities other than microenterprises must have the framework audited regularly by auditors with sufficient ICT risk expertise and independence, under Article 6(6) and (7), and critical findings must go through a formal follow-up. The third is documented evidence of each control, such as policies, registers, test results and remediation records. The fourth is outsourced verification, which Article 6(10) allows, but the entity stays fully responsible for it. The organization owns its controls and its sign-off. An implementation partner can prepare systems, configurations and evidence packs, but it cannot issue a report or attestation of compliance. The one exception is the threat-led penetration test. Under Article 26(7), the competent authority issues an attestation that a TLPT met the requirements, which allows mutual recognition of the test between authorities. This is an attestation about a test, not about the entity's overall compliance, and it only applies to entities that must run TLPT. Confirm with your competent authority whether your entity is in that group and how the attestation is requested. Plan for the rest of your evidence as a continuous record, because the review report, internal audit and supervisory requests will test it whether or not any external label exists.
What supervisors check instead of a certificate
DORA has no certificate to show, so the evidence question moves to the supervisor. Under Article 50(2), the competent authority can call for documents, inspect premises, question people and order fixes, and the cards below set out each of these powers and what it means for your preparation.
Access to documents and data
Under Article 50(2), the competent authority may access any relevant document or data your entity holds. In practice this means the framework documentation, the annual review report, internal audit reports, the register of information and incident records must exist in retrievable form before a request arrives. Ask whether your ICT risk documents can be produced quickly, in a consistent electronic format, and whether they match what your operational systems actually do.
On-site inspections and investigations
The authority may carry out on-site inspections and investigations at your premises. Supervisors can compare what your documents describe with what runs in your data centers, cloud accounts and offices. Gaps usually surface when a written procedure names a system, tool or owner that no longer exists. Confirm that your asset inventory, access records and configuration evidence can be shown during a visit without preparation work by staff.
Summoning representatives for explanations
Under Article 50(2), the authority may summon representatives to explain matters. Those called are typically management and control function holders who must answer for decisions, not only technical staff. Your management body should understand the framework well enough to explain risk acceptance, third-party concentration and resilience testing choices. Consider rehearsing these explanations and naming who speaks for each topic.
Corrective and remedial measures
The authority can require corrective and remedial measures for breaches it identifies. These orders turn findings into deadlines, so your remediation tracking must show which finding was closed, by whom and with what evidence. Article 6(7) already requires a formal follow-up process for critical audit findings, which gives you a ready record to show. Confirm who owns that process and how fast it escalates to the management body.
Who tests you and who decides
Article 46 assigns supervision to the national competent authority for each type of financial entity, and that authority decides how and how often to test. The ECB supervises credit institutions classified as significant, and the ESAs act as Lead Overseers for critical ICT third-party providers. Before preparing, confirm which authority covers your entity type and whether a second body reviews your ICT providers, since each may ask for different evidence.
How the review report and internal audit serve as evidence
Since no one can certify DORA compliance, the evidence an entity hands a supervisor is its own documented record, and two items sit at the center of it: the annual review of the ICT risk management framework and the internal audit of that framework. Article 6(5) requires the framework to be documented and reviewed at least once a year (periodically for microenterprises), and again after a major ICT-related incident and after supervisory instructions or conclusions from testing or audits. The entity does not file this review by default. It must produce a report on the review when the competent authority asks for one, so the practical job is to keep each review dated, decided and ready to hand over. Confirm with your supervisor whether it expects an annual copy in advance or only on request.
Article 27 of Delegated Regulation (EU) 2024/1774 sets the form of that report. It must be submitted in a searchable electronic format and open with the entity's identity, its group structure, the services it provides, its critical functions and dependencies, and an executive summary of its risk and security posture. Teams often write this summary last and then find that the identity and dependency sections were never kept current. Keep those sections as living records, linked to the asset inventory and the register of ICT third-party arrangements, so the report can be assembled from source data rather than rebuilt for each request. The report also records what changed, which is where the post-incident and post-test reviews must appear.
Article 6(6) and (7) add the internal audit layer. Entities other than microenterprises must have the framework audited on a regular basis by auditors with sufficient ICT risk expertise and independence, and every entity must run a formal follow-up process that verifies and remediates critical ICT audit findings in a timely way. An auditor's report without a closed-out remediation log is weak evidence, so ask for both. Under Article 6(10), the verification itself may be outsourced to intra-group or external undertakings, but the entity remains fully responsible for it. A consultant, including an implementation partner, can prepare evidence and test controls, yet the board and management body still own the conclusions. Write that accountability into the engagement letter.
Who does what when compliance is shown
The financial entity owns the ICT risk management framework and every control in it. Under Article 6 the management body carries the responsibility for approving and overseeing that framework, and the entity remains fully responsible even where it outsources verification. The review report on the framework, which Article 6(5) requires at least once a year and after major incidents, is the entity's own document, and it is submitted to the competent authority on request.
- Management body sign-off: Board or equivalent approval of the framework, policies and review report, recorded in minutes or formal resolutions.
- Review report ownership: The entity writes and maintains the review report in a searchable electronic format, opening with its identity, group structure, services, critical functions and dependencies.
- Audit follow-up: The entity runs the formal process that verifies and remediates critical findings from internal audit and testing.
- Accountability for outsourced work: Under Article 6(10), outsourced verification does not transfer responsibility to the vendor or auditor.
- Evidence custody: The entity keeps the documents and data that a competent authority can request under its Article 50 powers.
Before relying on any outside party, confirm which of these documents your management body will sign and who in the organization is accountable for each.
An implementation partner helps the entity build the technical side of the evidence. DeployOpen plans, implements, configures, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, and it runs security testing when that is in the written scope. The partner prepares systems and records. It does not decide the entity's risk appetite, approve the framework, or certify the outcome.
- System preparation: Configuration, hardening, logging and backup of the platforms the entity runs, built to the entity's documented ICT risk management policies.
- Documentation support: Drafting of technical procedures, asset records and configuration baselines that the entity reviews and adopts.
- Evidence generation: Exports of logs, access records, change history and test results organized so the entity can present them to an assessor.
- Security testing when scoped: Application, API and infrastructure testing delivered under a written scope, with findings handed to the entity for remediation.
- Independence boundary: DeployOpen does not issue audit reports, attestations or certifications. Only independent auditors, assessors and the competent authority issue those.
Ask any partner to state in writing which artifacts it delivers, which decisions remain with your management body, and that it will not sign assurance statements on your behalf.
Independent auditors test the framework when the entity engages them, and competent authorities test compliance using their Article 50 powers. Those powers include access to documents and data, on-site inspections and investigations, and requirements for corrective measures. For threat-led penetration testing, the authority issues the attestation that a test met the requirements under Article 26(7). That attestation is the only authority-issued document the Regulation provides for, and no body certifies overall DORA compliance.
- Internal audit requirement: Under Article 6(6), entities other than microenterprises need internal audit by staff with sufficient ICT risk expertise and independence. This is the entity's own function, which may be staffed in-house or by an independent party.
- External assessment: An auditor may review the framework and evidence, but the report describes findings. It does not certify compliance.
- Supervisory inspection: The competent authority may request documents, interview representatives and inspect sites, then require remedial measures.
- TLPT attestation: Issued by the authority after a threat-led test, which supports mutual recognition between authorities.
- Scope of opinion: Confirm with any auditor exactly what the report will and will not state, and whether it is intended for your management body, your regulator or a contract counterparty.
Before engaging an auditor, confirm with your competent authority which documents it expects to see and whether it accepts external reports as supporting evidence.
How a supervisory review usually unfolds
Article 50 gives competent authorities a set of powers they can use in sequence, from a request for information through to corrective measures. Each phase produces a concrete output, and an entity that keeps its evidence current can answer each one without rebuilding its records.
Receive a request for information
The competent authority opens the review by asking the financial entity for documents, data or explanations. The request states what the authority wants to see, and the entity assigns an owner to each item, such as the ICT risk management framework, the register of information or the most recent review report under Article 6(5). The output is a log of what was requested, by whom, and when it was answered, so every later submission can be traced to the original request. The authority sets its own timing for responses, so the entity should confirm the expected deadlines and submission channel in writing.
Review submitted documents and data
Supervisors examine the material against the Regulation and the technical standards it refers to. They look at whether the framework is documented, whether the annual review took place, and whether the documents match what the entity's own systems show. Where a review report is requested, supervisors expect the searchable electronic format described in Delegated Regulation (EU) 2024/1774. The output is a set of questions, gaps or inconsistencies that the authority chooses to pursue. Entities should confirm with their authority which documents it prioritizes before the first submission.
Hold explanations with responsible representatives
Where documents leave questions open, the authority can summon representatives of the entity to explain how controls work in practice. The people called are usually the ones accountable for the areas in question, such as ICT risk, operations, or third-party management. The output is a record of the explanations given, including any points the entity agrees to verify or document further. Preparing these representatives means making sure their accounts match the written evidence, since differences between the two are often what triggers the next phase.
Carry out on-site inspections or investigations
Article 50 allows the authority to carry out on-site inspections and investigations where document review and explanations are not enough. Inspectors can examine premises, systems, records and how staff follow procedures in day-to-day work. The output is a set of observations and collected evidence, which the entity normally has an opportunity to review and respond to. Entities should confirm the scope, notice and conduct rules that apply in their member state and keep their own copies of anything provided during the inspection.
Record findings and assess breaches
Once documents, explanations and any inspection evidence are in, the authority assesses whether the entity has met the requirements it is being reviewed against. This assessment sorts findings into those that show no breach, those that need improvement, and those that amount to a breach. The output is a findings record that sets out each issue, the requirement it relates to and the evidence relied on. Entities benefit from checking each finding against their own records early, because factual errors corrected at this stage are simpler to resolve than disputed conclusions later.
Require corrective and remedial measures
Where the authority finds breaches, Article 50 allows it to require corrective and remedial measures. These are specific actions the entity must take to bring its arrangements into line, such as fixing a control, updating a policy or strengthening a third-party contract. The output is a formal set of required measures, each tied to a finding. The entity should plan who will deliver each measure and what evidence will show it is complete. Penalties, where they apply, are set under national law and are covered separately in the DORA penalties guidance.
Verify remediation and close the review
The entity implements the required measures and provides evidence that each one is complete. The authority checks that evidence, and its review ends when the findings are resolved or when it decides further supervision is needed. The output is either a closed review or a continued supervisory process with clear conditions. An internal follow-up process that tracks critical audit findings to remediation, as Article 6(7) requires, gives the entity a ready record for this stage.
What to have ready before a supervisor asks
DORA has no certificate to show a supervisor, so the file you present is the evidence itself. The six items below are what a competent authority can ask for under its Article 50 powers, and each one is only useful if it is current, dated and owned.
Current framework documentation
Your ICT risk management framework, with its policies, strategy and procedures, must be documented and reviewed. Check that every document carries a version number, an approval date from the management body, and a review date that falls within the year. Compare the document set against the requirements in Article 6 and the detailed rules in Delegated Regulation (EU) 2024/1774, and flag anything that describes a system you no longer run.
Dated framework review report
The annual review of the framework, and any review triggered by a major incident or supervisory instruction, must be written up and available on request. Check that the report opens with the entity's identity, group structure, services, critical functions and dependencies, and includes an executive summary of risk and security posture, as Article 27 of Delegated Regulation (EU) 2024/1774 requires. Confirm that it is in a searchable electronic format and that its date matches the review it records.
Internal audit scope and tracked findings
Entities other than microenterprises must have the framework audited regularly by auditors with sufficient ICT risk expertise and independence. Check that the audit plan states its scope and the auditor's independence, and that each finding has an owner, a due date and a closure record. The follow-up process must show timely verification and remediation of critical findings. A list of findings with no closure dates is a gap a supervisor will notice quickly.
Evidence for each control
A policy describes intent, but a supervisor tests operation. For each ICT control you rely on, identify the artifact that proves it ran: an access review export, a patch report, a backup restore log, a change approval record. Check that each artifact has a date, a source system and a retention period, and that you can reproduce it on request without rebuilding it from memory.
Register and inventory currency
The ICT asset inventory and the register of information must match what is running today. Pick three recent changes, such as a new cloud region, a retired service or a new subcontractor, and trace each one through the inventory and the register. Confirm that identifiers are consistent across both records. Stale entries here undermine every other document in the file.
Named owner for each document
Every policy, register, report and audit record needs a named individual who answers for its accuracy, not just the team that maintains it. Check that owners are recorded in the document itself, that they know what they are responsible for, and that the management body has approved the set. Where you outsource verification of compliance, Article 6(10) allows it, but the entity remains fully responsible, so the internal owner must still be named.
Frequently asked questions about DORA compliance evidence
Can an auditor certify that we are DORA compliant?
No. DORA sets no certification scheme, so no auditor, consultant or certification body can issue a DORA certificate or an external attestation of overall compliance. Compliance is tested by the competent authority for your type of financial entity, using its powers under Article 50, including access to documents and data, on-site inspections and investigations, and corrective measures for breaches. Your organization owns its controls and evidence. An independent auditor can test parts of the framework and give you an opinion, but that opinion is an input for your own governance and for the supervisor, not a DORA certificate. Ask any firm offering a DORA certificate to show which legal provision it relies on.
Can a consultant issue a DORA certificate for our firm?
No. Consultants can prepare systems, controls, policies and evidence, and they can help you test them, but they cannot issue a DORA certificate or attestation. The only document an authority issues under DORA is the attestation that a threat-led penetration test met the requirements of Article 26(7), and that is issued by the competent authority, not by a vendor. A consultant engagement therefore ends with working evidence and a gap position you can show a supervisor, not with a certificate. When you scope a consultant, confirm in writing which deliverables are documents and test results, and who signs the framework review and the governance decisions inside your organization.
What must the ICT risk management review report contain?
The review report on your ICT risk management framework is the central document a supervisor reads first. Under Article 6(5), the framework must be documented and reviewed at least once a year (periodically for microenterprises), after major ICT-related incidents, and after supervisory instructions or testing or audit conclusions, and the report is submitted on request. Article 27 of Delegated Regulation (EU) 2024/1774 requires it in a searchable electronic format, opening with your identity, group structure, services, critical functions and dependencies, followed by an executive summary of your risk and security posture. Ask your team to map each section to a named owner and to a data source, so the report can be refreshed without rebuilding it each year.
Can we outsource the internal audit of our ICT risk framework?
You can outsource the work, but not the responsibility. Article 6(6) requires entities other than microenterprises to have the framework audited internally on a regular basis by auditors with sufficient ICT risk expertise and independence. Article 6(10) allows verification of compliance to be outsourced to intra-group or external undertakings, and the entity remains fully responsible for that verification. Independence is the test a supervisor will apply, so the auditor should not be the team that designed or operated the controls. Ask any provider how it separates audit from implementation, who signs the audit opinion, and how critical audit findings enter your formal follow-up process, which Article 6(7) requires for all entities.
What does the TLPT attestation cover, and what does it not?
The TLPT attestation is the only authority-issued document DORA provides for. Under Article 26(7), the competent authority issues an attestation that a threat-led penetration test met the requirements, which allows the test to be mutually recognized between authorities. It covers the one threat-led test performed under the regime, and it confirms that the test met the requirements, not that your whole framework is compliant. It does not replace basic testing, the framework review, internal audit or the register of information. Confirm with your authority which testing cycle and test scope apply to your entity, and plan the test's evidence so it can be submitted in the form the authority expects.
What does the work require from our internal team?
Most of the accountability and much of the knowledge must stay inside your organization. Your management body approves the framework and its policies, your control owners run the controls day to day, and your risk, compliance and audit functions decide what the evidence means. An implementation partner such as DeployOpen can plan, implement, harden, document and test self-hosted open-source platforms inside your own infrastructure, and prepare the evidence, but it cannot make these decisions for you. Expect the internal team to need time for governance reviews, to sign off on documents and to answer supervisor questions. Ask a provider to name which roles they will work alongside and which decisions remain with your staff.
How DeployOpen works on this
DeployOpen prepares the systems, controls and records that an entity's own review of its ICT risk management framework will draw on. We do not issue attestations or certificates. Independent auditors and the competent authority make those judgments, and the entity remains responsible for its own controls and verification.
How we scope
- Written scope agrees which self-hosted open-source platforms, ICT services and entities the review covers before work starts.
- Scope names the documents, logs and records the entity expects to produce for an internal audit or a supervisory request.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing, and a quote follows directly from that scope.
How we build
- We configure logging, access controls, backup and monitoring in the client's own cloud accounts, data centers or air-gapped networks.
- We structure the records that show how the framework is reviewed, updated after incidents and followed up on audit findings.
- We run security testing on the platforms in scope and track remediation of findings so the entity can show timely verification.
How we hand over
- Handover includes configuration documentation, evidence mapped to the entity's own control list, and a clear record of open items.
- Review report inputs are prepared in a searchable electronic format, covering identity, group structure, services and dependencies.
- The entity's staff receive the runbooks and evidence procedures needed to reproduce results without depending on the partner.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement ends.
- Retainers can keep evidence current between annual reviews, after major incidents and following supervisory or audit feedback.
- Questions about what an independent auditor or competent authority will accept should go to that party directly, and we can confirm them in scope.
