Remediation plan agreement: stages and deadlines
A remediation plan is the document an authorised digital asset entity agrees with its supervisor once a deficiency has been identified. The process moves through five stages: notice, draft plan, negotiation, approval and closure. Each stage carries its own deadline, and missing one moves the file from agreement into enforcement.
What changes once the plan is agreed
Before agreement, the deficiency sits as an open finding. The supervisor can escalate at any point, and escalation is discretionary rather than automatic. Once the plan is agreed, the relationship changes: the entity now has a defined path with checkpoints, and the supervisor's attention shifts from whether a plan exists to whether the entity is meeting it.
This is the point of no return referenced in the title. Before agreement, the entity can still shape the content of the plan. After agreement, the terms are fixed, and departure from them is treated as a new deficiency rather than a negotiation point.
What to do
- Compliance officer: log the notice the moment it arrives and record the deadline it sets for a response.
- Compliance officer with legal counsel: draft the remediation plan, listing each finding separately with a proposed fix and an internal owner.
- Legal counsel: check whether the deficiency touches shared processing arrangements with another entity. Where data is processed jointly, the underlying Joint controller arrangement step by step should be reviewed before the plan is submitted, since an unresolved allocation of responsibility often resurfaces as a separate finding later.
- Senior management: sign off the draft before submission. A plan submitted without internal sign-off is routinely rejected at intake.
- Compliance officer: submit the plan through the channel the supervisor specifies in the notice, not through general correspondence.
- Compliance officer: track the negotiation stage and respond to every supervisory query within the deadline given, even if the substantive answer is not yet ready.
Who decides and how long it takes
The competent authority that issued the original authorisation decides whether a plan is acceptable. There is no separate appeal forum for the negotiation stage itself; disagreement is resolved by revising the draft, not by escalating to another body.
| Stage | What happens | Typical pace |
|---|---|---|
| Notice | Supervisor sets out the deficiency and the deadline for a first response | Short, fixed by the notice |
| Draft plan | Entity proposes fixes, owners and internal milestones | Set by the entity within the notice deadline |
| Negotiation | Supervisor raises questions, entity revises the draft | Repeats until both sides accept the text |
| Approval | Supervisor confirms the plan as binding | Single decision, not further negotiable |
| Closure | Entity reports completion, supervisor confirms the finding is resolved | Follows the milestones set in the plan |
The pace of each stage is set case by case, and the supervisor has discretion to extend or shorten it depending on the severity of the finding. A minor documentation gap moves faster than a finding tied to client asset segregation.
Common forks
If the finding concerns the scope of the authorisation itself rather than an operational gap, the correct route is often not a remediation plan at all but a change to the licence. Where the entity needs to move between authorisation categories, the process resembles a Conversion of an application step by step more than a remediation negotiation, and mixing the two routes slows both.
If the deficiency touches ownership of code, models or other work product used in the service, the entity should be ready to show who holds the underlying rights before the supervisor asks. The way this is demonstrated follows the same logic as Economic rights ownership of results how it is proved, and a plan that skips this proof is commonly sent back for revision.
If the finding involves how the entity communicates changes to token holders, the closure stage may require evidence that disclosures were actually published, not only drafted. Practice in this area is covered separately in Publication practice in tokenised rights, and it is worth checking before closure is submitted.
What this page does not cover
This page describes the agreement process and its stages. It does not set out the substance of any particular finding, nor does it state what counts as an acceptable fix for a given deficiency — that depends on the finding itself and is decided case by case. It also does not cover appeal routes against a refused authorisation, which follow a different procedure entirely.
Verified
This procedure reflects current supervisory practice for authorised digital asset entities and is reviewed as that practice develops. No statutory citations are given on this page; the process described concerns stages and deadlines, not the legal basis for supervision itself.
Related reading
A similar stage-by-stage structure applies outside remediation, for instance when a supervised entity has to set up ongoing reporting to the same authority. See Regulatory reporting set-up step by step for the comparable process.
FAQ
How long does remediation plan agreement take in practice?
There is no fixed duration. The notice sets the first deadline, and each following stage is paced by how quickly the entity and the supervisor converge on an acceptable draft. A narrow finding closes faster than one touching multiple parts of the business.
Which documents are needed to start?
At minimum: the supervisor's notice, a draft plan listing each finding with a named internal owner, and internal sign-off from senior management. Where the finding touches shared data processing or work product ownership, supporting records for those arrangements should be ready in parallel.
What happens if the other side does not respond?
If the entity misses a deadline, the supervisor typically treats the silence as non-agreement and moves towards escalation. If the supervisor is slow to respond during negotiation, the entity should follow up in writing and keep a record of the attempt, since this record matters if the timeline is later disputed.
Where a finding turns out to rest on how a token itself was classified rather than on an operational gap, the cost of that mismatch can be substantial. That situation is addressed separately in When a token is classified differently than expected.