Remediation plan agreement: what the decision maker looks at
A remediation plan gets agreed once the decision maker is satisfied it fixes the root cause, not just the symptom, and can be checked against dated milestones. The review turns on four points: cause, timeline, resourcing and verification. A plan missing any one of these is sent back for revision. It is not agreed as filed, and the clock on the underlying supervisory matter keeps running while it sits unagreed.
What the decision maker checks first
| Criterion | What it means | Why it matters |
|---|---|---|
| Root cause | The plan names the actual failure, not a symptom of it | A plan built on the wrong cause fails the next check |
| Milestones | Each step carries a date and a named owner | A deadline without an owner cannot be tested for compliance |
| Resourcing | Staff, budget and systems are actually allocated to the work | An unfunded plan is a statement of intent, not a plan |
| Verification | How completion will be evidenced and re-checked | Without a defined check, the file cannot be closed |
Stages of the procedure
- The gap is identified — by self-report, by a routine review, or by an inspection finding.
- The entity drafts a written plan with a root-cause section and a milestone table.
- The draft is submitted to the decision maker together with the supporting evidence.
- The decision maker reviews it and either agrees it, requests revisions, or rejects it outright.
- Once agreed, the plan becomes the reference document against which supervisory checks run.
- Completion is confirmed against the verification method the plan itself sets out.
Documents to prepare
The file needs a written root-cause analysis, a milestone table with named owners, evidence that resources have actually been allocated, and any prior correspondence with the decision maker on the same gap. Where the underlying failure touches shared processing arrangements, the file should also record who is accountable for which part of the fix — the same discipline that governs a Joint controller arrangement step by step. Missing an owner on any line is the single most common reason a draft comes back unagreed.
Timing and the point of no return
A straightforward plan, with a clear cause and realistic dates, is typically reviewed within a few weeks of submission. A plan touching several business lines or requiring system changes takes longer, because the decision maker checks resourcing against what the entity has actually committed elsewhere. The point of no return sits at the moment of agreement itself: once the plan is agreed, revising a milestone requires a fresh submission, not an informal update. Before that point, drafts can be revised freely; after it, changes go through the same review as the original plan.
Who agrees the plan
The decision maker is the competent authority that holds supervisory responsibility for the authorisation in question. It reviews the draft, may request a meeting or written clarification, and issues its position in writing. There is no informal or verbal agreement — a plan is either agreed in writing or it is not agreed. The same written-decision logic applies in adjacent authorisation steps, including how a Conversion of an application step by step is decided: the decision maker documents its position rather than signalling intent informally.
Three scenarios
If the gap was self-reported, the decision maker generally allows more time for the first draft, since the entity found the issue before supervision did. If the gap was found during an inspection, the timeline for the first submission is shorter and the bar for the root-cause section is higher. If a plan has already been rejected once, the second draft is reviewed against the same criteria plus an explicit account of why the first one failed — resubmission without that account is treated as incomplete.
What this page does not decide
This page describes how a remediation plan gets reviewed and agreed. It does not set out the substantive standard the underlying activity must meet — that depends on which authorisation and which activity are in scope, and is assessed case by case. It also does not cover disputes about whether a gap exists in the first place; that question is resolved before a remediation plan is drafted at all. Questions about evidence of design ownership in a related file, for instance where AI products and models — when an agency keeps the design files, are answered on their own page, not here.
Verified
Reviewed for accuracy on the date shown at the top of this page. The description of stages, criteria and timing reflects the procedural approach applied by supervisory authorities to authorisation holders in Lithuania and Estonia. This page does not cite specific legal provisions; where a client needs a sourced legal basis for a particular step, that is addressed directly in the file, not on this overview.
Related reading
Entities working through a remediation plan often need to set up reporting to the same authority at the same time — see Regulatory reporting set-up step by step for how that decision is reviewed.
FAQ
How long does remediation plan agreement take in practice?
A straightforward plan is usually reviewed within a few weeks. A plan touching several business lines or requiring system changes takes longer, since the decision maker checks resourcing before agreeing dates.
Which documents are needed to start?
A written root-cause analysis, a milestone table with named owners, evidence of allocated resources, and any prior correspondence with the decision maker on the same gap.
What happens if the other side does not respond?
If the decision maker does not respond within a reasonable period, the entity should follow up in writing and request a status update rather than assume silent agreement. A plan is only agreed once confirmed in writing.
Next step
If your business holds a digital-asset authorisation and needs a remediation plan drafted or reviewed before submission, our team can assess the draft against these four criteria before it goes to the decision maker. Related situations that often surface alongside a remediation review are covered in When a fork duplicates the token.