Which authority supervises DORA compliance for your firm
Article 46 of DORA maps each type of financial entity to the competent authority that already supervises it under its sector law, so your DORA supervisor is most likely the body that licenses or prudentially supervises your firm today. For credit institutions classified as significant under the Single Supervisory Mechanism Regulation, the European Central Bank is the competent authority. Your first task is to confirm which authority that is, in writing, before you start preparing evidence, because the supervisor determines the format, the reporting channel and the questions an inspection will ask.
Article 46 is about who supervises, not about a control your firm implements. It does not ask you to build anything. What it does is fix the counterpart for every DORA submission, inspection and remediation request that follows. Confirm your supervisor by checking your licence type, your sector directive (for example the Capital Requirements Directive, PSD2 or Solvency II) and any notice your authority has published on DORA. Record the answer in your governance file so that the management body can point to it.
Identification gets harder when a firm holds several licences, sits inside a group with entities regulated in different sectors, or serves clients across borders through branches or passporting. A payment institution with an investment service licence, or a group with a banking subsidiary and an insurance subsidiary, may face more than one national authority. Article 19(1) then requires member states to designate a single competent authority for incident reporting, which can differ from the authority that supervises the rest of your DORA obligations. Map every legal entity and licence, note which authority covers each one, and ask each authority to confirm its role in writing.
Which entities and authorities the mapping covers
Article 46 does not create one DORA regulator. It hands supervision to the authority that already oversees each entity under its sector law, with the ECB taking significant credit institutions. The cards below set out the decisions that determine which authority you answer to.
Credit institutions and the CRD authority
For most credit institutions, the competent authority for DORA is the authority already designated under the Capital Requirements Directive. Start by confirming the entity's licence type and its current prudential supervisor, since that supervisor is the one Article 46 points to. Check the supervisory correspondence and licence documents you already hold, and confirm with the authority if the entity has a mixed or unusual status.
Significant credit institutions and the ECB
Credit institutions classified as significant under the Single Supervisory Mechanism Regulation fall under the ECB as competent authority for DORA rather than the national authority. Classification is made under the SSM framework, so confirm the entity's current status with its supervisory team before planning reporting and evidence routes. A group with both significant and less significant members may face two different authorities across its entities.
Payment and e-money institutions
Payment institutions and electronic money institutions are supervised for DORA by the PSD2 authority designated under their sector law. Their ICT incident reporting, testing and register of information obligations therefore flow to that authority. Check whether the entity also holds other permissions, because a payment business that is part of a banking group can change which supervisor applies to which activity.
Insurers and the Solvency II authority
Insurance and reinsurance undertakings answer to the Solvency II authority for DORA compliance. Confirm which authority holds the entity's Solvency II supervision, especially for cross-border groups where the home and host supervisors differ. Map your evidence requests to that authority's expectations rather than assuming a generic financial regulator applies.
Entities with several supervisors
An entity can hold several licences, or sit inside a group, and be supervised by more than one authority. Article 19(1) then requires member states to designate a single competent authority for incident reporting, so one authority receives major incident reports even though others supervise the rest of DORA. Ask the entity's regulators which authority is the single incident reporting point and document the answer in your reporting procedure.
Confirming the mapping before you build
Record for each legal entity its licence types, sector supervisor, any SSM classification and the incident reporting authority. Keep this as a dated register that the compliance and operations teams both review. Changes in licence scope or classification are the most common reason the mapping goes stale, so set a review trigger tied to licence changes.
How incident reporting and TLPT responsibilities can be concentrated
Article 46 lets an entity be supervised by one authority in most cases, but some financial entities fall under more than one national authority, and DORA addresses that gap in two places. Under Article 19(1), member states must designate a single competent authority for incident reporting where an entity is supervised by more than one national authority. The entity then sends its major incident reports to that one body, which can share them with the others. For a firm operating across several supervised activities in one country, this removes the need to build parallel reporting paths for each licence, but it does not change what must be reported or the deadlines that apply.
Threat-led penetration testing is handled separately. Article 26(9) allows member states to designate a single public authority for TLPT matters in the financial sector, and Article 26(10) allows competent authorities to delegate TLPT tasks to another national financial authority. An entity should therefore ask its supervisor, in writing, which body receives its TLPT plans, attestations and remediation evidence, and whether the same body coordinates testers or only receives results. The answer may differ from the body that supervises the entity day to day, so the test programme owner needs to map both relationships before scheduling a test.
The European Commission's Digital Omnibus proposal, COM(2025) 837 of 19 November 2025, would change how major incident reports are routed. It would amend Article 19 so that reports and voluntary threat notifications go through a single entry point under NIS2. Procedure 2025/0360(COD) was awaiting committee decision as of October 2026, so the proposal may still change or may not be adopted in its current form. Confirm the current status on the European Parliament's Legislative Observatory) and with your national authority before you build reporting procedures around a single entry point.
How a competent authority tests DORA supervision readiness
This table compares the four supervisory activities a competent authority is likely to run under DORA, with the test approach, evidence requested and common findings for each. Read it as a preparation checklist: each row shows what the authority will ask for and where entities usually fall short. The main takeaway is that supervisors test whether records exist, are current and show remediation, so evidence must be ready before any request arrives.
| Supervisory activity | Test approach and evidence requested | Common findings |
|---|---|---|
| Confirm supervisor and scope | Authority confirms which national competent authority, or the ECB for significant credit institutions, supervises the entity under Article 46, and which entities sit in the group. Evidence: licence or authorisation record, group structure chart, list of in-scope legal entities. | Group entities assumed to fall under the wrong authority, or a single-authority reporting route not confirmed where several supervisors apply. |
| Request the register of information and policy set | Authority asks for the current register of information on contractual arrangements and the approved ICT policies, with approval dates and management body sign-off. Evidence: register extract, board minutes approving policies, version history. | Register incomplete or out of date with contract changes, policies approved late or not reviewed, and no link between register entries and risk assessments. |
| Review incident and TLPT records | Authority samples major incident reports, classification decisions and any threat-led penetration test files, checking timeliness and consistency. Evidence: incident logs, classification rationale, reports sent to the authority, TLPT scope and closure documents. | Classification not documented, reporting clocks missed, incidents recorded only in tickets, and TLPT findings absent from the risk register. |
| Examine remediation of findings | Authority traces earlier supervisory findings and test results to closed remediation actions, owners and deadlines. Evidence: findings tracker, remediation plans, retest results and management reporting. | Findings marked closed without retest evidence, recurring root causes, and no escalation to the management body when remediation slips. |
Steps to confirm your supervisor and prepare for first contact
This sequence establishes which authority supervises each entity in your group, who handles incident reporting, and where that decision is recorded, so the first contact with a supervisor starts from a documented position. Each step ends with a named output that a compliance lead or auditor can check.
Confirm the entity type under Article 2(1)
Start by matching each legal entity in scope to one of the 20 financial entity types listed in Article 2(1), points (a) to (t), or to the ICT third-party service provider category in point (u). Compliance or legal counsel does this with the licence or authorisation documents in hand, not from the group's marketing description. The output is an entity type register with one row per legal entity, the licence reference and the point of Article 2(1) that applies. Confirm any borderline case, such as a microenterprise or a non-EU branch, with the authority rather than assuming the answer.
Identify the sectoral authority and significance status
For each entity, name the national competent authority already designated under the sector's legislation, such as the Capital Requirements Directive authority for credit institutions or the Solvency II authority for insurers. For credit institutions, check whether the ECB classifies the bank as significant under the Single Supervisory Mechanism Regulation, because Article 46 gives the ECB that role for significant institutions. The output is a supervisor assignment column added to the entity register, with the source for each assignment, such as the licence letter or the supervisor's published list.
Map every licence and supervisor across the group
Build a map of all licences, authorisations and registrations held by the group, including subsidiaries, branches and cross-border passports. Where one legal entity holds several licences, or a group member is supervised by more than one national authority, record each supervisor separately. Compliance and group legal teams usually own this step, with input from the business lines that hold the licences. The output is a group supervision map that shows every entity, its licences and every supervisor that may receive DORA communications.
Decide the single point of contact for incident reporting
Where an entity is supervised by more than one national competent authority, Article 19(1) requires the member state to designate a single competent authority for incident reporting. Ask each relevant national authority which body is designated for your entity, and confirm whether the answer is final or pending. Record the designated authority, its reporting channel and the internal owner who will hold that channel. The output is a written designation note per member state, confirmed by the authority in writing where possible.
Confirm TLPT responsibilities with the national authority
Article 26(9) and (10) allow member states to designate a single public authority for threat-led penetration testing matters in the financial sector, or to let competent authorities delegate TLPT tasks to another national financial authority. Ask each relevant authority whether it handles TLPT directly, delegates it, or relies on a designated body, and whether the same arrangement applies to the entities in your map. The output is a TLPT responsibility line in the supervisor register, with the name of the body that receives TLPT correspondence.
Record the mapping in the governance file
Write a signed mapping memo that sets out the entity types, sectoral authorities, significance status, incident reporting point and TLPT body for each entity, and attach the supervisor contact register. The management body or the delegated governance committee should approve the memo, because the mapping is part of the ICT risk governance record that a supervisor will request. The output is an approved memo with a version number, a date and a list of the source documents used.
Assign an owner and set a review trigger
Name one accountable owner for the supervision map and the contact register, and record a deputy. The owner should review the map when a licence changes, when an entity joins or leaves the group, when a national authority changes its designation, or when the Commission or the ESAs issue a decision that affects supervision. Your organization decides the review frequency and documents it in the governance file. The output is a named owner and deputy, a review log and a documented trigger list, so the mapping stays current before the first supervisory contact.
Evidence that shows the supervisor mapping is correct
Article 46 only works if the organization can show which authority supervises each entity and why. The five records below connect the legal structure, the mapping, governance approval, the reporting contact and the regulator dialogue. Keep them in one controlled set so a change in one record prompts a review of the others.
Legal-entity and licence register
List every legal entity in the group, its home member state, the authorizations it holds and the sectoral law that applies to each. Include the date each licence was granted, varied or withdrawn. Check the register against the company registry extracts and licence documents, not against internal org charts, because org charts often lag reorganizations. Assign one owner who must update the register within a set internal deadline after any licence event.
Written entity-to-authority mapping
For each entity, record the competent authority that supervises it under its sector's legislation, and note any cases where the ECB applies because the credit institution is classified as significant. Where more than one national authority is involved, record which one is designated for incident reporting under Article 19(1). Ask legal counsel to sign off the reasoning for borderline entities, such as those with mixed activities.
Management body approval record
Keep minutes showing that the management body reviewed and approved the entity-to-authority mapping, the reporting designation and any TLPT arrangements. Record the version approved, the date and the attendees. DORA places responsibility for the ICT risk framework on the management body, so an approval that is missing or undated weakens the whole mapping when an authority asks who owns it.
Designated incident reporting contact
Document the named contact, deputy and escalation path for communications with the authority that receives incident reports. Confirm the contact details in the authority's own channels and test that the reporting route works before it is needed. Update the record whenever staff change or the single reporting authority changes, and check it at least once a year.
Supervisory correspondence log
Log each letter, information request, inspection notice and meeting with a supervisor. For every item, record the date, the authority, the subject, the responding owner and the closing date. The log shows whether the mapping has been challenged or confirmed over time. Store the original correspondence in the same evidence repository so that the log and the source documents can be checked together.
What mapping supervisory responsibility costs
This table breaks down the internal and external effort of confirming which authority supervises each licence, and marks which items are one-time and which recur. Read it as a checklist for requesting a scoped quote, since no figures for these items were supplied and the real cost depends on your group structure. The main takeaway is that licence count, member state count and structural change drive most of the recurring effort.
| Cost component | Who is paid or who spends time | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Legal and compliance time to confirm the mapping | Internal legal and compliance staff, or outside counsel if engaged | One-time, then recurring at each review | Number of licensed entities and the sectoral directives each one falls under |
| Legal review of licences in each member state | External counsel or national legal specialists, where in-house capacity is limited | One-time per member state, plus updates when licences change | Number of member states, licence types and whether national authorities have issued guidance on Article 46 designations |
| Confirming the Article 46(a) position for significant credit institutions | Internal regulatory affairs, with ECB contact where classification is unclear | One-time, then recurring when classification changes | Whether any credit institution in the group is classified as significant under the Single Supervisory Mechanism Regulation |
| Governance time for board or management body approval | Management body members and company secretariat | Recurring, usually tied to the annual review cycle | Number of group entities requiring separate approval and the board calendar |
| Designating a single incident reporting authority where several authorities apply | Internal legal, with national authorities consulted on Article 19(1) arrangements | One-time, then recurring if the designation changes | Number of national authorities involved and whether member states have already made a designation |
| Periodic refresh after structural change | Internal legal, compliance and group finance teams | Recurring, triggered by events | Mergers, acquisitions, new licences, new member states and changes to national supervisory arrangements |
| Documentation and record keeping of the mapping | Internal compliance or governance staff, or an implementation partner preparing the register | One-time setup, recurring maintenance | Format used, whether the mapping links to the register of information and how often entities change |
| Advisory support from an implementation partner | Consultant or implementation partner, under a written scope | Usually one-time for setup, optional recurring support | Clarity of the scope, number of entities and whether the partner prepares evidence or only documents the mapping |
Who owns the supervisory mapping and who can help
Your legal and compliance team owns the supervisory mapping. It decides which financial entity type your organization falls under, which authority already supervises that entity under its sectoral law, and whether any credit institution is classified as significant. It also owns the relationship with that supervisor, including notifications, correspondence and any reply to an information request. Accountability sits with the management body, which must approve the mapping and any position taken with a regulator.
- Entity classification: Confirm the Article 2 category that applies to each legal entity in the group, not only the parent.
- Authority mapping: Record which national authority supervises each entity under its sectoral legislation and document the basis.
- Significance decisions: For credit institutions, confirm whether the ECB applies directly under the Single Supervisory Mechanism Regulation.
- Supervisor contact: Name the owner of communications with each authority and keep a log of submissions.
- Board approval: Obtain management body sign-off on the mapping and on any interpretation that affects scope.
Check that the mapping is reviewed when licences, group structure or sectoral rules change, and that someone is named to answer for it.
An implementation partner prepares the technical and documentary material that the mapping relies on. That includes the register of information, the evidence folder for each supervised entity and the technical records of ICT systems, logging, incident handling and testing. The partner works inside your environment and produces records you can hand to counsel, auditors or supervisors. It does not interpret the Regulation for your entity, decide which authority applies, or advise on whether a licence is required. Those questions go to qualified counsel and to the authority itself.
- Register and records: Build the data structures and populate the register of information from your system inventory.
- Evidence folder: Organize configuration exports, logs, test reports and change records so each claim can be traced.
- Scoping support: Identify which systems and services fall under each entity once the legal scope has been decided.
- Gap visibility: Report where records are missing or inconsistent, without ruling on legal outcomes.
- Independence limit: Do not accept sign-off on legal classification or supervisory status from the partner.
Confirm in the written scope which deliverables are technical and which, if any, require counsel, and ask who signs each record.
The competent authority supervises DORA compliance for the entities it already oversees under sectoral law, such as the Capital Requirements Directive authority for credit institutions or the Solvency II authority for insurers. Under Article 50, it holds the supervisory, investigatory and sanctioning powers needed to carry out its duties. It can request information, inspect and impose penalties. It does not issue a DORA certificate or certify your systems, and DORA provides no certification scheme for this purpose.
- Supervision: The authority assesses compliance through its own inquiries, inspections and reviews.
- Designation: Where more than one authority applies, the member state designates a single authority for incident reporting under Article 19(1).
- TLPT delegation: Member states may assign TLPT matters to a single public authority or delegate them under Article 26(9) and (10).
- Enforcement: Penalties and remedial measures follow the powers in Article 50, not the work of any vendor or partner.
- Contact route: Direct questions about your authority and its procedures to the authority, and confirm the current procedure on its website.
Before engaging, confirm with the authority which submissions it expects and in what format.
Where firms get the supervisor question wrong
Most supervisor errors under Article 46 start with an assumption nobody tested, usually about who holds the licence or how the entity is classified. The four gaps below are common, and each ends with a check you can run before the next reporting cycle.
Assuming the national authority supervises everything
Article 46 gives the ECB the competent authority role for credit institutions classified as significant under the Single Supervisory Mechanism Regulation. A bank that has been reclassified can therefore find that its DORA supervisor has changed, while its national authority still holds the sector licence. Confirm the current classification with the ECB and your national authority, then record who supervises which obligations. Closing action: write the supervisor for each DORA obligation into your compliance calendar and name the ECB joint supervisory team as a standing contact.
Missing a second licence abroad
An entity authorized in one member state may also run a branch or cross-border activity that brings a second national authority into play. Article 19(1) requires member states to designate a single competent authority for incident reporting where an entity is supervised by more than one national authority, so the answer to who receives reports depends on the whole footprint. Inventory every licence, passport notification and branch, then ask each authority how it expects incident reports to be routed. Closing action: keep one table of licences, branches and the designated reporting authority, and update it before any new market launch.
Naming no single incident reporting contact
When two authorities could receive a major incident report, teams often send it to both, to neither, or to whichever contact they remember. Each route can delay the initial notification or create conflicting records of the same event. A named reporting owner, with a deputy and a documented channel for each authority, removes that ambiguity during a live incident. Test the route in an exercise, because a contact that works on paper may not answer at 2 a.m. Closing action: appoint one primary reporting contact and one deputy, write their names and the authority channel into the incident runbook, and walk through the route in a tabletop exercise.
Letting the supervisor mapping go stale
Mergers, acquisitions, new licences, changes to a branch network or a reclassification by the ECB can each move the entity to a different supervisor. A mapping written at implementation then becomes a liability, because the incident and register obligations keep pointing at the old authority. Tie the mapping to your change management process so that any corporate transaction triggers a review. Ask legal and compliance to confirm the new licence and classification position in writing. Closing action: add a supervisor check to every merger, licence or classification change request, and sign off the updated mapping before the change takes effect.
Questions buyers ask about Article 46
Who supervises a payment institution under DORA?
The competent authority already designated under the sector's legislation supervises DORA compliance for the entity. For a payment institution or electronic money institution, that is normally the authority responsible for supervision under PSD2 in the member state where it is authorized. Article 46 makes this assignment, and Article 50(1) gives that authority the supervisory, investigatory and sanctioning powers it needs for DORA. In practice, the supervisor that already licenses and oversees the firm is usually the one that assesses its ICT risk management. If the firm operates across borders, confirm with counsel and the national supervisor how branches, agents and host-state rules affect which authority receives reports and conducts inspections.
How is the ECB's role decided for a bank?
The ECB becomes the competent authority only for credit institutions classified as significant under the Single Supervisory Mechanism Regulation. Article 46(a) sets this rule, so the bank does not choose its supervisor. Classification follows the SSM criteria, and the bank's group structure can matter when entities sit inside a supervised group. Less significant credit institutions remain with their national competent authority. Because the status can change, ask the supervisor to confirm the current classification in writing and check whether group-level arrangements apply. Keep in mind that the ECB's role as competent authority is separate from the ESAs' direct oversight of critical ICT third-party providers, which applies to the providers, not to the banks that use them.
Does DORA issue a compliance certificate for our organization?
No. DORA sets no certification scheme, so there is no DORA certificate that a regulator or certification body issues to show an entity complies. Competent authorities supervise compliance using their Article 50 powers, which include inspections, information requests and enforcement. The only authority-issued attestation the Regulation provides for is the one confirming that a threat-led penetration test met the requirements of Article 26(7). Be cautious with any offer that promises a DORA certificate, seal or badge. An organization can commission an independent assurance review if its board or customers want one, but that is a separate commercial choice. Ask any provider exactly which document they will issue, who signs it, and what legal weight it carries.
What drives the effort of mapping DORA obligations to our supervisor?
The effort depends mainly on how many regulated entities sit in the group, how many member states they operate in, and how many sectoral regimes apply. Each entity needs a clear answer to which authority supervises it, which authority receives incident reports under Article 19(1) if more than one is involved, and which TLPT arrangements apply under Article 26(9) and (10). Other drivers include the quality of existing supervisory documentation, the number of ICT services that support critical or important functions, and whether the organization already has an inventory of its ICT assets and providers. No standard figure exists for this work, so ask any partner for a written scope that lists entities, jurisdictions and deliverables, then compare quotes against that same scope.
Can an internal team handle DORA supervisory readiness alone?
Yes, an internal team can do this work, because the organization owns its obligations and the controls behind them. The legal interpretation still needs qualified counsel, and the supervisor's expectations should be confirmed directly. An implementation partner, such as DeployOpen, can prepare systems, controls and evidence within a fixed scope agreed in writing before work starts. That partner does not issue reports or certificates, and the supervisor makes the assessment. Internal teams usually need outside help when they lack capacity, when several sectoral regimes overlap, or when technical evidence such as logs, backups or testing records must be produced quickly. Decide which parts the team will own and which parts to outsource, and document that split.
Does the Digital Omnibus change where incident reports go?
Not yet. The Commission's Digital Omnibus proposal COM(2025) 837, dated 19 November 2025, would amend DORA Article 19 so that major incident reports and voluntary threat notifications pass through a single entry point under NIS2. As of October 2026, the European Parliament's Legislative Observatory lists procedure 2025/0360(COD) as awaiting committee decision. Until any amendment is adopted and applies, current Article 19(1) rules continue, and where more than one authority supervises an entity, a single competent authority is designated for incident reporting. Plan reporting routes against current law, track the procedure, and confirm with counsel and the national authority which route will apply to your entities.
How DeployOpen prepares your evidence for supervisory review
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure so that the systems and records behind your DORA supervision are ready for the authority that oversees your entity. DeployOpen prepares systems, controls and evidence; your competent authority and your own governance remain responsible for the compliance position.
How we scope
- Written scope names which supervisory authority applies to your entity and which records that authority is likely to request.
- Scope lists the in-house platforms, cloud accounts or data centers covered by the engagement and the systems excluded.
- Deliverables, timelines and responsibilities are agreed in writing before any work starts, as engagements are fixed-scope.
How we build
- Platforms are deployed and configured in your own environment so that logs, access records and configuration history stay under your control.
- Controls are implemented and tested against the evidence your competent authority would expect to see for each requirement.
- Gaps found during build are logged with owners and remediation steps so your team can decide what to fix first.
How we hand over
- Documentation covers system design, configuration baselines, control mappings and the location of each evidence source.
- Evidence packs are organized by requirement so your compliance team can answer an authority request without reconstructing records.
- Your staff receive walkthroughs so they can operate, explain and update the platforms after the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover, when your scope requires them.
- Retainer scope should be confirmed in writing, including how changes to supervisory expectations or platform versions are handled.
- Ask your competent authority which records it accepts and in what format before finalizing the evidence structure.
