Article 50 Administrative penalties and remedial measures

Article 50 defines what supervisors can demand, order and fine when DORA is breached. This page explains the powers, the evidence an assessor expects and what preparing for supervision costs.

On this page

What DORA Article 50 lets supervisors do when an entity breaches DORA

Article 50 gives competent authorities investigation powers, the ability to order remedial measures and member-state administrative penalties for breaches of DORA. DORA itself sets no EU-wide fine amounts for financial entities, so the level of any penalty depends on the national law of the member state where the entity is supervised. For a compliance lead, the practical question is what a supervisor can demand, on what timetable, and what the entity must already have on file when that demand arrives. Article 50 is about consequences, not a control to build, but its powers shape which records the organization must keep ready.

Under Article 50(2), a competent authority can access any relevant document or data, carry out on-site inspections and investigations, and summon representatives for explanations. Under Article 50(4), it can order a breach to stop, require temporary or permanent cessation of a practice, and issue public notices naming the person and the breach. Before any of this happens, confirm with your national competent authority which of these powers its national law activates and how it expects documents to be produced. Article 50(6) requires decisions to be reasoned and subject to appeal, so the entity should also know its appeal route in advance.

The hard part is rarely the penalty itself. It is showing, quickly and in writing, that the management body approved the ICT risk framework, that known gaps were logged, assigned and closed, and that remediation actions were tracked to completion. Article 50(5) allows penalties to reach members of the management body under national law, which makes board minutes, risk acceptances and remediation trackers part of the evidence base. Agree with your advisers which of these records must exist before an inspection, and test whether you can retrieve them within a day. An implementation partner can prepare these systems and records, but only the organization owns its governance decisions.

Which entities and roles fall under Article 50 penalties

Article 50 penalties reach far beyond the bank or insurer that holds the licence. They touch the people who run the entity, the ICT providers it relies on, and the national authority that decides what to enforce. Scope decisions made early determine which records must exist when a supervisor asks for them.

Financial entities named in Article 2(1)

Article 2(1) applies DORA to 20 types of financial entity, from credit institutions and payment institutions to insurers, crypto-asset service providers and securitisation repositories. Each type is exposed to the same Article 50 powers, but the sectoral rules around it differ. Confirm which point of Article 2(1) your entity falls under before you map your obligations, because that mapping sets what an inspector will ask to see.

Management body members

Under Article 50(5), penalties and measures against a legal person can also be applied, under national law, to members of the management body and to other individuals responsible for the breach. In practice this means board and executive records, such as approvals of the ICT risk framework and sign-off of the resilience strategy, can become personal evidence. Ask counsel how your member state applies this provision before the first inspection.

Other individuals responsible

The national reach under Article 50(5) is not limited to directors. Heads of ICT, security, risk and operations may be named where they were responsible for a breach, such as an unpatched system or an unreported major incident. Map who owns each control in your organization and keep the approvals, tickets and meeting minutes that show who decided what, so responsibility can be traced quickly.

ICT third-party service providers

Providers are not directly fined by the financial entity's regulator for their own clients' breaches in the same way, but their contracts, access rights and service records determine whether the entity can demonstrate compliance. Under Article 50(2), authorities can demand any relevant document or data, so the register of information, contract terms and audit rights must be retrievable on request. Confirm which provider records your contracts oblige the provider to supply and how fast.

National competent authority under Article 46

The competent authority named under Article 46 for each type of financial entity applies the powers in Article 50, and the ECB handles significant credit institutions. The authority decides whether to use inspections, corrective orders or pecuniary measures, so the same breach can be handled differently across member states. Identify your authority early, check its published expectations, and confirm which documents it has asked for in past supervisory communications.

Scoping decisions and required records

The scope you choose determines which records must exist: a microenterprise or a simplified-regime entity keeps a different set than a full-scope bank. An inspector can require access to any relevant document or data under Article 50(2), so a gap in scope documentation is itself a finding. Record the scoping rationale, the date it was approved, and who approved it, and revisit it whenever the business or its ICT services change.

How a supervisor tests readiness for Article 50 powers

This table walks through the supervisory actions a competent authority can take under the Article 50(2) powers, the evidence it typically asks for, and the gaps it most often finds. Read each row as a question the authority will put to the organization, and use the evidence column to check whether your files can answer it without delay.

Supervisory actionEvidence requestedCommon findings
Document and data requestsCurrent ICT risk management framework, management body approvals, incident logs, register of information extracts and testing reports, with version history and datesPolicies exist but approval dates are missing, or documents describe a process the organization does not actually run
On-site inspection of systems and premisesEvidence that access, logging, backup and change controls operate as documented, shown on live systems or recent samplesControls are documented but cannot be demonstrated on the systems in scope, or scope differs from the register of information
Summoning representatives for explanationsNamed owners for each critical or important function, with a clear account of responsibilities and escalation pathsStaff give inconsistent answers about who owns a control, or the person responsible has changed without a record
Interviews with the management bodyMinutes showing the management body reviewed ICT risk, approved the framework and was briefed on major incidents and testing resultsBoard packs lack substance, or there is no evidence the management body challenged the risk position
Review of corrective and remedial measuresFindings register with owners, deadlines, status changes and closure evidence tied to root causeRemediation actions are open without owners or dates, or closed items lack evidence that the underlying weakness was fixed
Check that decisions and measures are reasonedWritten rationale for risk acceptance, exceptions and remediation priorities, with the factors considered such as severity and durationExceptions are granted informally, or the reasoning for accepting a residual risk is absent from the record
Test of tracking across breachesConsolidated view of prior findings, recurring incidents and how each one was addressed over timeThe same weakness reappears across reviews because earlier findings were closed without verification

Preparing the records a supervisor will ask for

This sequence turns the penalty and remedial powers in Article 50 into a set of records that can be produced quickly when a competent authority asks for documents, data or explanations. Each step ends with a named artifact that the organization owns and can show to an inspector.

  1. Map each DORA obligation to a named owner

    Start with the DORA articles that apply to your entity type, then assign each obligation to a single accountable owner, usually a function head, with a named deputy. The owner confirms in writing which evidence they hold and where it lives. The output is an obligations register with owner, deputy and evidence location for every line. The step is complete when no obligation is left without a name.

  2. Keep a breach and remediation log

    Record every identified breach of a DORA requirement, including near misses and gaps found by internal audit, testing or a supplier. Each entry states the requirement affected, the root cause, the remediation action, the owner and the closure evidence. Because Article 50 lets authorities order corrective and remedial measures, this log shows how the organization responded before the regulator asked. The output is a remediation register that is reviewed by the risk function at a set cadence.

  3. Record management body approvals and challenge

    Article 50(5) allows penalties and measures to reach members of the management body, so the record of their decisions matters. Keep signed minutes showing that the body approved the ICT risk framework, the policies and the remediation plans, and that it questioned material findings. Where the body delegated a decision, record the delegation and the reporting line back to it. The output is a set of signed management body minutes and a decision log that matches the obligations register.

  4. Build an index for rapid document production

    Article 50(2) gives authorities the power to access any relevant document or data, so the organization should be able to produce material on short notice. Build an index that maps each supervisory question to the document, system report or data extract that answers it, with version, date and owner. Confirm with your competent authority which formats it accepts and whether a secure transfer channel is required. The output is a controlled index that is version-managed and checked against the current policy set.

  5. Rehearse a supervisory information request

    Run a internal exercise in which a small team receives a mock request for documents, data and a short explanation from a named member of staff, with a fixed internal deadline agreed in advance. Observe whether the owners can locate the records, whether the minutes and remediation log agree with each other, and whether the spokesperson can explain the position without guessing. Record the gaps and fix them in the index. The output is an exercise report with actions assigned and closed.

  6. Confirm the penalty factors and appeal route

    Article 51(2) lists factors authorities consider when setting a penalty, including intent or negligence, duration, cooperation and previous breaches. Use these factors to test your own records: can you show when a breach started, how fast it was contained and how you cooperated? Confirm with counsel the national appeal route and the national rules for penalties and publication under Article 54. The output is a short legal note, kept with the index, that states who decides on responses and how decisions are appealed.

How penalty levels are set under Article 51

Article 51(2) does not set a fine. It lists the factors a competent authority must weigh when it decides how severe a penalty or remedial measure should be. The first is whether the breach was committed intentionally or through negligence, which is why the record of how decisions were made, who approved risk acceptances and whether known gaps were escalated matters as much as the technical failure itself. The authority also looks at materiality and gravity, meaning how important the breached requirement is to the entity's operational resilience, and at duration, meaning how long the gap stayed open. Degree of responsibility asks who in the organization owned the control and whether that ownership was clear on paper and in practice.

Financial strength, profits gained or losses avoided, and losses caused to third parties shape the amount in a different way. An authority may consider the entity's capacity to pay, the economic benefit of skipping a control, and harm to customers or counterparties. Member states set the actual amounts and maximum levels in their own national law, so a reader operating across several EU countries should ask local counsel or the relevant competent authority which penalty ranges and procedures apply to each entity. DORA itself sets no EU-wide fine schedule for financial entities.

Cooperation and previous breaches carry the most practical weight for a well-run program. Authorities consider how quickly the entity reported, provided documents and explained its position, and whether it executed corrective measures. Keep a dated remediation log that links each finding to the corrective action, the owner, the closure evidence and the management body's review. Prior findings that were closed without durable fixes can count against the entity, so track recurring themes across audits, testing and incidents, not just individual items. Confirm with your supervisor how it expects remediation progress to be reported.

Evidence that shows an entity can answer supervisory action

When a competent authority opens an inspection or investigation under Article 50, it asks for documents and data, and it expects them to be available without a scramble. The cards below describe the records that answer those requests and how to keep each one current between inspections, so the entity can show what it knew, what it decided and what it fixed.

Document index for DORA artifacts

Maintain a single index that maps every DORA policy, procedure, register and report to its owner, approver, approval date, review cycle and storage location. Article 50(2) gives authorities the power to access any relevant document or data, so the index is the first thing an inspector uses to find proof. Check quarterly that each linked file exists, is the approved version and matches the last review. Confirm that the index itself is version controlled and that superseded documents are kept for the period your national authority expects.

Breach and incident log

Record every ICT-related incident and every breach of a DORA obligation in one log, with the date of detection, classification, reporting decisions, root cause, containment steps and the person accountable. Authorities assessing a penalty under Article 51(2) weigh intent or negligence, gravity and duration, so the log must show when the entity knew and how quickly it acted. Review entries monthly and confirm that near-misses and internal control failures are logged, not only externally reported events.

Remediation tracker with owners and dates

Track every finding from internal audit, testing, supervisory letters and post-incident reviews in a tracker that names one accountable owner, a target date, the status and the evidence that closes the item. Article 50(4) allows authorities to order a breach to cease and to require temporary or permanent cessation of a practice, so inspectors will test whether past commitments were met. Flag overdue items to the management body and record every change to a target date with a reason and an approver.

Management body minutes showing oversight

Minutes should show that the management body reviewed ICT risk, incidents, testing results and remediation status, asked questions and recorded decisions. Article 50(5) allows penalties to reach members of the management body under national law, so minutes are the record that shows individual engagement. Check that each meeting includes a dated agenda item on DORA, that dissent and follow-up actions are recorded, and that papers were circulated before the meeting.

Supervisory correspondence register

Keep a register of every letter, request, notice and meeting with a competent authority, including the reference number, the request, the response, the deadline and the person who handled it. Authorities reviewing a case consider previous breaches and cooperation under Article 51(2), so this register shows the pattern of engagement over time. Confirm that every commitment made to a supervisor appears in the remediation tracker and that responses were sent on time.

What preparing for supervisory action costs

Most of the cost of preparing for supervisory action is internal. Article 50 lets a competent authority require access to documents and data, run on-site inspections and summon representatives for explanations. The people who answer those requests are the management body, the ICT risk owner, the compliance lead and the staff who run incident and third-party processes. Their time is paid from the existing payroll budget, so it rarely appears as a separate line item, but it is the largest component in practice.

  • Management body time: Board and committee members must understand the ICT risk framework well enough to take decisions and answer for them, since Article 50 allows penalties to reach members of the management body under national law.
  • Records of decisions: Minutes, risk acceptances and approvals need named owners and dates. Reconstructing them under pressure takes far more time than keeping them current.
  • Named control owners: Each control needs a person who can explain it, show its evidence and say when it last ran.
  • Recurring effort: Board reporting, control reviews and incident post-mortems recur every cycle, so this cost does not end after the first readiness exercise.
  • Backfill for inspections: Staff answering an inspection are not doing their regular work, so ask how the plan covers their absence.

Ask your provider or advisers to estimate these hours against your own roles, and confirm them with your HR and finance teams before relying on any figure.

Criminal penalties and publication of decisions

Article 52 lets member states use criminal penalties instead of administrative ones for breaches that their national law already criminalises. The Regulation does not decide which conduct is criminal, so the answer sits in each country's penal code. A financial entity or its managers should therefore check, for each jurisdiction where it operates, whether national law makes any DORA-related breach a criminal offence, and whether that offence can reach individuals as well as the firm. Local counsel should confirm this, because the same conduct can attract a fine in one member state and a prosecution in another. Criminal exposure also changes how incidents are escalated internally, since a decision about reporting or record-keeping may carry personal consequences for the people who make it.

Article 54 requires that non-appealable penalty decisions be published, and that publication remain in place for no longer than five years. Publication is where a supervisory outcome becomes a reputational event. Clients, counterparties, auditors and other supervisors can read the entity's name, the breach and the sanction, often without any context about the remediation that followed. For a firm that serves other financial entities, a published decision can trigger due diligence questions in procurement and in ICT third-party reviews. The practical step is to ask the firm's legal team which publication rules apply in each relevant member state, including whether the authority may publish on an anonymised basis, and to confirm the exact retention period with them rather than assuming the five-year maximum applies.

What limits the damage is evidence that was created before any enforcement began. Keep a dated record of the breach assessment, the remedial plan, each corrective step and its verification, and the board or management body decisions that approved them, because these show the authority that the failure was identified and handled. Maintain a clean chain between the incident log, the regulatory notifications and the remediation tracker, so that the timeline can be explained quickly. Cooperation and prompt remediation are factors the authority must weigh under Article 51(2), so the same records that support a defence against publication also support a lower penalty. An implementation partner can help build and organize these records, but the entity owns the decisions and the authority, not the partner, determines any outcome.

Where entities fall short when a supervisor acts

Article 50 gives competent authorities broad powers to inspect, order remediation and sanction. The gaps that draw the most scrutiny are rarely exotic; they are missing records of who decided what, remediation that nobody owns, and breach logs that cannot be reconstructed. Each card below names one gap and the check that closes it.

No record of management body oversight

Article 50(5) allows penalties to reach members of the management body under national law, so the board's role must be provable. A supervisor will ask for minutes showing that directors reviewed ICT risk, approved the framework and received incident and testing reports. Check that each ICT decision has a dated resolution, a named approver and a recorded discussion. Where minutes are thin, add a standing agenda item for ICT risk and keep the supporting papers with the minutes.

Remediation without owners or deadlines

When an inspection or internal test finds a weakness, Article 50(2) allows the authority to require corrective and remedial measures. An open finding with no accountable owner and no due date reads as a control that is not operating. Assign each finding to a named role, set a target date and record every change to that date with a reason. Review overdue items at each management meeting so the file shows that gaps were tracked to closure.

Incomplete breach and incident logs

Authorities weigh gravity, duration and losses to third parties when they set a penalty, as Article 51(2) describes. A log that omits start times, affected services or the decisions taken makes those factors impossible to demonstrate. Standardize the fields for each event, including detection time, classification, containment steps, notifications sent and closure date. Keep the log append-only so entries cannot be quietly edited after a supervisor asks for it.

Unclear individual accountability

Article 50(5) reaches individuals responsible for a breach, not only the legal entity. If staff cannot say who owns an ICT risk, a supplier relationship or a backup regime, responsibility defaults to the firm and the individuals become hard to assess. Publish a responsibility matrix that maps each DORA obligation to a role and a named holder. Update it when people change roles, and confirm with counsel how national law applies to individual liability.

Cooperation gaps during inspections

Authorities may access any relevant document or data, carry out on-site inspections and summon representatives for explanations. Delays, incomplete document sets or staff who cannot explain a control undermine the cooperation factor in Article 51(2). Prepare an inspection file with current policies, the register of information, test reports and the incident log. Name a single coordinator and rehearse how representatives answer questions about specific controls.

Questions buyers ask about Article 50 readiness

Does DORA set fixed fines for breaching Article 50 requirements?

No. DORA sets no EU-wide fine amounts for financial entities. Article 50(3) requires each member state to lay down its own rules on administrative penalties and remedial measures, and those rules must be effective, proportionate and dissuasive. The amounts, the penalty types and the procedure therefore come from the national law of the state where your entity is supervised. Confirm the current national rules with your competent authority or national legal counsel before you set a budget for exposure.

What does preparing for Article 50 cost, and what drives it up?

No researched figure is available for this, so treat any number you see with caution. Costs come from three places: internal staff time, external advisers who review your governance and evidence, and the technical work needed to produce evidence for your ICT controls. Article 50 itself adds little new technical spend; most of the cost sits in the controls it would later examine. The main cost drivers are the number of ICT systems in scope, how much evidence already exists, the number of ICT third-party contracts to review, and how many legal entities you run. Ask any provider for a fixed-scope quote with the scope, deliverables and assumptions written out.

How long does it take to get ready for supervisory powers?

No researched timeline is available, and the duration depends on how far your DORA programme already stands. Readiness for Article 50 is mainly about being able to show an authority the documents and data it can request under Article 50(2), and about having a clear way to respond to remedial measures. If your policies, ICT risk framework and incident records are already current, the work is largely verification and organisation. If they are not, it is a longer programme that should be planned as part of wider DORA compliance. Ask any partner to state the timeline in writing, with the dependencies it assumes.

What do authorities need to see during an inspection?

Article 50(2) gives competent authorities at least the power to access any relevant document or data, carry out on-site inspections and investigations, and summon representatives for explanations. In practice, your team should be able to produce:

  • Current ICT risk management documents and board approvals
  • Incident records, classifications and reports
  • Test results and remediation tracking
  • Contracts and register entries for ICT third-party providers

Keep these in a controlled location with clear owners, so a request does not depend on one person's memory.

Can our own team handle Article 50 readiness without outside help?

Yes, many teams do this in-house, provided they have the right people and time. The legal responsibility stays with your organisation in every case. Internal teams usually need compliance, security, risk and operations staff who can assemble evidence, and someone who understands the national penalty regime. Outside help is most useful for gap analysis, evidence review and technical preparation of systems. DeployOpen prepares systems, controls and evidence under a written, fixed scope, but it does not issue audit reports, attestations or certifications, and it does not decide your legal position. Only independent auditors and certification bodies issue those.

What must the management body sign off and why does it matter?

Article 50(5) allows penalties and measures against legal persons to be applied, under national law, to members of the management body and to other individuals responsible for a breach. That means board members and executives can be personally exposed, depending on national rules. Before an authority asks, the management body should have approved the ICT risk management framework, the relevant policies and the resilience strategy, and should have records showing it reviewed reports on ICT risk and incidents. Keep minutes that show these decisions were taken with enough information. Confirm the personal exposure under your national law with qualified counsel.

What does a partner handle, and what stays with our organisation?

A partner can prepare systems and evidence: configure and document controls, assemble the records an authority may request, and test that evidence can be produced quickly and accurately. The organisation keeps ownership of its controls, its legal position, its regulatory communications and its decisions on penalties and remedies. An independent auditor or competent authority is the only party that assesses compliance or issues a report. Put this split in the written scope, so each deliverable has a named owner. Ask any provider which deliverables it covers and which remain your responsibility.

How DeployOpen prepares evidence for DORA supervision

DeployOpen works on the systems and records a competent authority would ask to see when it exercises its Article 50 powers. We prepare evidence for the organization, which owns its controls and remains responsible for its compliance, and we do not issue reports or attestations; supervisory findings come from the authority itself.

How we scope

  • Engagements are fixed-scope, with the systems, entities and DORA requirements in scope agreed in writing before work starts.
  • The written scope states which records, logs and documents will be prepared for inspection requests under Article 50.
  • Scope also names who inside the organization owns each control, decision and sign-off that an authority may question.

How we build

  • We configure self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks so that access and change records exist.
  • We set up logging, retention and access controls so that documents and data can be produced promptly when an authority requests them.
  • We help document remedial actions with dated owners, so that corrective measures for any identified breach can be shown as tracked and completed.

How we hand over

  • Handover includes configuration records, control descriptions and evidence packs mapped to the requirements in scope for your review.
  • We document how records would be retrieved for an on-site inspection, including who answers questions and where originals are held.
  • Deliverables are written for your management body, which can be held accountable under national law for breaches of DORA.

How we support

  • Ongoing support, upgrades and continuous testing are available as retainers, so evidence stays current after the initial engagement.
  • Retainers can cover periodic review of logs, access records and remediation tracking against the agreed scope.
  • Ask us to confirm in writing which support tasks sit in a retainer and which would need a new scope and quote.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.