Continuity Plan for Crypto Companies: What Regulators Require

Continuity Plan for Crypto Companies: What Regulators Require

Continuity Plan for Crypto Companies: What Regulators Require

🔐 Compliance · VASP Operations

Business Continuity Plan for Crypto Companies:
What Regulators Require

Every major crypto regulator — FSC, FSA, VARA, MAS, FCA — requires a BCP as a condition of licensing. Most VASPs either have no BCP or have one that would not survive a regulatory review. Here is what a compliant BCP actually looks like.

📋 5 sections · ~7 min read
🌐 VARA · FSC · MAS · FCA
Updated April 2026

1
Why regulators require a BCP — and what they actually check
What inspectors look for vs what most VASPs submit

2
The five scenarios every crypto BCP must cover
Cyberattack, key person loss, exchange halt, banking failure, custody breach

3
BCP structure: what the document must contain
Required sections, RTO/RPO definitions, roles and escalation

4
Testing and maintenance: the part most VASPs skip
Annual testing requirements, tabletop exercises, regulator evidence

5
BCP readiness checklist — before your next regulatory review
12-point checklist for VASP compliance officers

🔐 Section 1

Why Regulators Require a BCP — and What They Actually Check

A Business Continuity Plan is not a box-ticking exercise. For regulated VASPs, it is a mandatory document that regulators review at licensing, at renewal, and increasingly during thematic supervisory visits. Understanding what inspectors actually look for — as opposed to what most VASPs submit — is the difference between a document that passes and one that triggers remediation requirements.

🏭
What regulators are actually testing for
The substance behind the requirement
Operational resilience

Regulators require a BCP because they are responsible for the stability of the financial system and the protection of clients whose assets are held by regulated VASPs. When a VASP experiences an operational failure — cyberattack, key person loss, banking failure, custody breach — the regulator needs confidence that the business can either continue operating at a minimum service level or wind down in an orderly manner without client harm.

The BCP is the regulator’s evidence that the VASP has thought through its failure scenarios before they happen, allocated responsibility for managing them, and tested whether its response actually works. A BCP that was never tested, that names people who have left the company, or that describes systems that no longer exist is worse than no BCP — it signals that the licensee treats compliance as paperwork rather than practice.

📊
Which regulators require a BCP — and how explicitly
Jurisdiction-by-jurisdiction requirement
Universal requirement

Every major crypto licensing regulator explicitly requires a BCP as part of the licence application and ongoing compliance obligations. The specific framing varies but the substance is consistent: MAS (Singapore) requires business continuity management under its Technology Risk Management Guidelines; VARA (Dubai) requires operational resilience documentation as part of the rulebook; FSC (Mauritius) requires a BCP as part of the VASP licence application; FCA (UK) applies operational resilience rules to crypto asset firms; EU MiCA CASP requires a business continuity policy under Article 67.

  • MAS (Singapore): Technology Risk Management Guidelines — BCP mandatory
  • VARA (Dubai): Operational resilience requirements in VARA Rulebook
  • FSC (Mauritius): BCP required at VASP licence application stage
  • FCA (UK): Operational resilience rules apply to registered crypto asset firms
  • MiCA CASP (EU): Business continuity policy required under Article 67

🔍
What inspectors actually look for in a review
The five questions every BCP review asks
Review criteria

Based on regulatory guidance and supervisory practice across VARA, MAS, and FCA, inspectors reviewing a VASP BCP focus on five questions. First: does the BCP cover the scenarios that are actually relevant to this business? A generic template that does not address custody key management or exchange system failures is immediately identifiable as inadequate. Second: are the recovery time and recovery point objectives defined and realistic? Vague language (“restore within a reasonable time”) is insufficient. Third: are named roles current and do those people know their responsibilities? Fourth: has the BCP been tested in the last 12 months and is there evidence of the test? Fifth: has the BCP been updated following any material change to the business, systems, or personnel?

⚠️
The template BCP problem
The majority of VASPs applying for a first licence submit a generic BCP template downloaded from the internet or provided by a formation agent. These templates cover generic IT recovery scenarios and organisational platitudes. They almost never address the specific operational risks of crypto businesses: custody key management failure, blockchain network outages, smart contract exploits, or stablecoin depeg events. Regulators recognise these templates immediately and treat them as evidence of inadequate compliance infrastructure.

🎗 Section 2

The Five Scenarios Every Crypto BCP Must Cover

Generic BCPs cover generic risks — power outages, office fires, staff illness. A VASP BCP must additionally cover the scenarios specific to crypto operations. These five are the ones regulators focus on and the ones most likely to actually affect your business.

Five crypto-specific scenarios your BCP must address
VASP-specific
1
Cyberattack and system compromise Highest frequency

Crypto businesses are among the most targeted by cybercriminals globally. Your BCP must address: what happens when your exchange or custody system is compromised; who has authority to halt trading or withdrawals; how you communicate with clients during an incident; what your relationship with your cybersecurity incident response team looks like; and what your regulatory notification obligations are (most jurisdictions require notification within 24–72 hours of a material cyber incident). The BCP should reference your cybersecurity incident response plan — but must also address the business continuity dimension: what services can continue, which must halt, and how you restore normal operations.

RTO requirement: Define your target Recovery Time Objective for core systems. VARA guidance suggests critical systems should target RTO of 4 hours or less for exchange operations. MAS Technology Risk Management Guidelines require RTO documentation for all critical systems.
2
Key person dependency and sudden unavailability Most commonly overlooked

VASPs — particularly at early and growth stage — are frequently dependent on one or two individuals who hold critical knowledge: the technical architecture, the compliance programme, the banking relationships, or the custody key management procedures. The BCP must address what happens if these individuals are suddenly unavailable — through illness, resignation, or death. This requires: documented succession for each critical role; knowledge transfer documentation for critical processes; multi-signature or dual-control arrangements for custody and operational accounts; and cross-training so that at least two individuals can perform each critical function. Regulators specifically look for this — a VASP where one person holds all the keys (literally and figuratively) is an operational risk.

3
Trading halt or exchange platform failure Exchange-specific

For exchange operators, the BCP must define the conditions under which trading is halted, who has authority to halt it, and how clients are notified. It must also address the period of the halt: how are client orders handled, what happens to margin positions, and how is market integrity maintained during the halt and restoration period. The BCP should define a degraded service mode — what minimum services can be maintained (withdrawals only, read-only access) when full trading cannot be restored — and the conditions for returning to full operation. Market manipulation or extreme volatility scenarios that may require trading suspension should also be addressed.

Client communication is part of the BCP: Define in advance how and when you will communicate with clients during a halt or outage. Regulators assess client communication as part of operational resilience — a VASP that goes dark during an incident without communicating with clients has failed a fundamental operational requirement.
4
Banking and payment rail failure Universal risk

The fragility of crypto business banking is a known risk — crypto-friendly banking relationships are fewer and less stable than traditional financial services relationships. Your BCP must address what happens when your primary banking partner terminates the relationship, freezes accounts, or experiences its own operational failure. This requires: at minimum two banking relationships with different counterparties; documented procedures for switching fiat payment processing between banking partners; client communication procedures for deposit and withdrawal delays; and a minimum operational cash reserve held outside the primary banking relationship. The BCP should specify how long the business can operate using reserve funds if the primary bank relationship fails.

5
Custody breach or key compromise Custody-specific

For custodial VASPs and exchange operators holding client assets, a custody key compromise is the highest-severity operational scenario. The BCP must address: the immediate response to a suspected key compromise (halt all withdrawals, initiate key rotation); the forensic investigation process; client notification obligations and timing; regulatory notification requirements; and the process for restoring custody operations after key rotation. The BCP should also address partial compromise scenarios — where a subset of keys or a specific wallet is compromised — and the decision framework for determining whether to continue operations or initiate an orderly wind-down. Insurance arrangements for custody losses should be referenced. See our guidance on AML/KYC compliance for the regulatory notification framework that applies alongside BCP activation.

📄 Section 3

BCP Structure: What the Document Must Contain

A compliant VASP BCP is a structured document with defined sections — not a narrative essay. Regulators reviewing BCPs at licensing and renewal expect to find specific content in a logical structure. Here is the required architecture and what each section must address.

Mandatory sections — Part 1
Scope, risk assessment, and critical functions
Required at licensing
Reviewed at renewal
📋
1. Scope and purpose
Which legal entities, business lines, and geographies the BCP covers. What it does not cover (and why). The relationship between the BCP and related documents (incident response plan, disaster recovery plan, AML/CFT procedures). The BCP owner and review cycle. One page maximum — regulators want to see clarity of scope, not padding.
🎗
2. Business impact analysis and risk assessment
A structured assessment of: which business functions are critical (cannot be suspended without client harm or regulatory breach); which are important (should be restored within 24–48 hours); and which are non-critical (can be suspended for an extended period). For each critical function, define the maximum tolerable period of disruption (MTPD), the recovery time objective (RTO — how quickly must it be restored), and the recovery point objective (RPO — how much data loss is acceptable). Concrete numbers are required — “as soon as possible” is not acceptable.
👥
3. Roles, responsibilities, and escalation
A named BCP team with: BCP Owner (typically CEO or COO), BCP Coordinator (manages activation and execution), Technical Lead (systems recovery), Compliance Lead (regulatory notification), Communications Lead (client and media), and Legal Lead (contractual obligations during disruption). Each role must have a named primary and at least one named backup. Contact details for each. A clear escalation matrix: who declares a BCP event, who activates which response level, and who has authority to suspend services.

Mandatory sections — Part 2
Response procedures and recovery
Scenario-specific
Tested annually
🛠️
4. Scenario-specific response procedures
For each scenario covered (cyberattack, key person loss, trading halt, banking failure, custody breach — plus generic scenarios: office unavailability, third-party provider failure, pandemic/mass absence), a step-by-step response procedure with: immediate actions (first 1 hour), short-term actions (1–24 hours), and recovery actions (24+ hours). Each step should have a named responsible role, a target completion time, and a decision point. Procedures must be specific enough to be followed by someone who has not encountered the scenario before.
📡
5. Communication plan
Client communication: what triggers notification, what channels are used, what the message says. Regulatory notification: which regulators must be notified, within what timeframe, and by whom. Internal communication: how the BCP team is assembled, how decisions are recorded during an incident. A pre-drafted communication template for each major scenario type is a mark of a mature BCP — drafting a client communication during an active incident is not the time to start writing.
🔄
6. Recovery, testing, and maintenance
Criteria for declaring the BCP event resolved and returning to normal operations. The testing schedule (at minimum annual, with evidence retained). The review and update schedule (at minimum annual, plus ad-hoc following material change). A change log recording each update with date, reason, and approver. The BCP must be approved by the board or senior management — a document signed only by the compliance officer does not demonstrate board-level ownership of operational resilience.

💡
RTO and RPO — the numbers that matter most
The Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are the two figures regulators scrutinise most closely. RTO for client-facing systems should typically be 4 hours or less for exchange operations, 24 hours for back-office systems, and 48–72 hours for non-critical functions. RPO (the maximum data loss acceptable) for transaction records should be zero or near-zero — client transaction data must not be lost. Define these numbers based on your actual technical capability, not aspirationally — promising a 1-hour RTO you cannot deliver is worse than committing to 4 hours you can.

🧪 Section 4

Testing and Maintenance: The Part Most VASPs Skip

A BCP that has never been tested is a hypothesis, not a plan. Regulators know this, which is why testing evidence is increasingly a focus of supervisory visits. The testing requirement is not onerous — but it must be structured, documented, and regular.

Annual
Minimum BCP testing frequency required by most regulators including VARA, MAS, and FCA
48–72h
Typical regulatory notification window for material operational incidents requiring BCP activation
2+
Minimum number of banking relationships regulators expect VASPs to maintain for operational resilience
100%
Of VARA-regulated entities required to maintain and test a BCP under VARA Rulebook operational resilience requirements
👥
Tabletop exercise
The minimum annual requirement
Most common format

A tabletop exercise is a facilitated discussion where the BCP team walks through a scenario — “our primary exchange server has been compromised at 2am on a Friday” — and tests their decision-making against the documented procedures. No actual systems are tested; the exercise tests human response, decision authority, communication, and procedure accuracy. A tabletop exercise takes 2–3 hours, requires no technical disruption to operations, and produces a test report that demonstrates regulatory compliance. It is the minimum acceptable testing standard — not the gold standard.

The test report must document: the scenario tested, the date, the participants, the key decisions made, gaps or issues identified, and remediation actions assigned. This report is the evidence regulators request when they ask “when did you last test your BCP?”

🛠️
Technical failover testing
For systems with defined RTO commitments
Best practice

For VASPs with defined RTO commitments for critical systems, tabletop testing alone is insufficient — you need to actually test that your systems can recover within the committed timeframe. Technical failover testing involves activating backup systems, verifying data integrity, and measuring actual recovery time against the RTO. This should be done at least annually for primary exchange and custody systems, and documented with the same rigour as the tabletop exercise. If the actual recovery time exceeds the documented RTO, the BCP must be updated to reflect the realistic timeframe — not the aspirational one.

🔄
BCP maintenance triggers
When the annual cycle is not enough
Ongoing obligation

The annual review and testing cycle is the minimum. The BCP must also be updated following any material change to the business that affects the continuity scenarios or response procedures. Mandatory update triggers include: key personnel changes (especially BCP roles), changes to primary banking relationships, migration to new custody or exchange infrastructure, expansion into new jurisdictions, and actual BCP activation events. After any real incident that triggered BCP activation, a post-incident review must update the BCP to reflect lessons learned. A BCP that was last updated 18 months ago and names three people who have left the company is non-compliant regardless of when it was formally reviewed.

⚠️
The evidence requirement
Regulators do not take your word for it that you have tested your BCP. They ask for the test report. If you cannot produce a dated test report with named participants and documented findings, your BCP is treated as untested regardless of what the document says. Maintain a BCP testing log with reports from every exercise — tabletop and technical — going back at least three years. This is the audit trail that demonstrates a live compliance programme rather than a paper one.

✅ Section 5

BCP Readiness Checklist — Before Your Next Regulatory Review

Use this checklist before submitting a licence application, before a renewal, or before a supervisory visit. Every item marked as missing is a finding waiting to happen.

VASP BCP Compliance Checklist — 12 Points
Pre-review standard
📋
BCP covers all five crypto-specific scenarios
Cyberattack and system compromise, key person loss, trading halt/exchange failure, banking relationship failure, and custody key compromise. Each scenario has a step-by-step response procedure with named roles and target timeframes. Generic IT recovery procedures are not sufficient on their own.
Check: does your BCP address custody key compromise specifically?

⏱️
RTO and RPO defined with concrete numbers for all critical systems
Recovery Time Objective and Recovery Point Objective are stated as specific timeframes (e.g., “RTO: 4 hours for exchange trading systems; RPO: zero for transaction records”) not as vague commitments. Numbers are based on actual tested capability, not aspirational targets.
Check: have you actually measured your recovery time in a test?

👥
All named BCP roles are current — and each has a documented backup
Every person named in the BCP is still with the company and in the described role. Each critical role has at least one named backup who knows their responsibilities. Contact details are current. Updated within the last 3 months.
Check: when did someone last verify all named contacts are still correct?

🏭
Minimum two banking relationships maintained with different counterparties
The VASP has at least two active banking relationships with different banking counterparties (not two accounts at the same bank). Documented procedures exist for switching fiat operations between banking partners. Minimum operational reserve held outside the primary banking relationship.
Check: could you process client withdrawals today if your primary bank froze your account?

🔐
Custody key management has dual-control and documented recovery procedures
No single individual can unilaterally access, move, or destroy custody keys. Multi-signature or dual-control arrangements are in place and documented. Key recovery procedures exist and have been tested. Key holders are named in the BCP with documented succession.
Check: what happens to client assets if your primary key holder is unavailable?

🧪
BCP tested within the last 12 months — with a dated test report
A tabletop exercise has been conducted within the last 12 months. A written test report exists documenting the scenario, participants, findings, and remediation actions. For critical systems with defined RTO commitments, technical failover testing has also been conducted.
Check: can you produce the test report if a regulator asks for it today?

📡
Pre-drafted client and regulator communication templates exist for each major scenario
Communication templates are drafted and approved in advance for: system outage notification to clients, trading halt notification, regulatory incident notification, and resolution notification. Templates include the required information for each jurisdiction’s regulatory notification requirements (typically: nature of incident, impact on clients, steps taken, estimated resolution time).
Check: does your team know what to send clients within the first hour of an incident?

🏠
Remote working capability is tested and documented
The BCP includes a remote working scenario — what happens if the office is unavailable. Critical staff have remote access to all systems needed to maintain minimum operations. VPN access, authentication, and system access from non-office locations has been tested. Documented in the BCP with specific procedures.
Check: has your team actually tried to operate fully remotely, or only assumed it would work?

🔄
BCP reviewed and updated within the last 12 months — and after any material change
The BCP has a dated review record showing it was reviewed within the last 12 months. A change log records each update with date, reason, and approver. Updates were made following any material change to personnel, systems, banking, or jurisdiction since the last annual review.
Check: is your BCP change log up to date?

📄
BCP approved by board or senior management — not only by compliance
The BCP carries a board or senior management approval signature and date. Approval is not delegated solely to the compliance officer. The board has reviewed the BCP at least annually. Board minutes reference BCP review. This demonstrates that operational resilience is a board-level concern, not a compliance department exercise.
Check: when did your board last formally approve the BCP?

🌎
BCP addresses jurisdiction-specific regulatory notification requirements
For each jurisdiction in which you hold a licence or registration, the BCP identifies: which incidents trigger mandatory regulatory notification, the notification timeframe (typically 24–72 hours), the notification contact at the regulator, and the required content of the notification. For VASPs licensed in multiple jurisdictions, notification requirements vary — the BCP must address each separately. See our compliance services for jurisdiction-specific notification frameworks.
Check: do you know the notification timeframe for your primary jurisdiction?

🛡️
Orderly wind-down procedures are documented alongside recovery procedures
Not every BCP event ends in recovery. If the business cannot be restored to minimum operating capability within the MTPD, the BCP must include orderly wind-down procedures: how client assets are returned, how regulatory notification of wind-down is handled, and how outstanding obligations are managed. Regulators — particularly VARA and MAS — specifically require wind-down planning as part of operational resilience documentation. A BCP that only covers recovery and not wind-down is incomplete.
Check: does your BCP include client asset return procedures in a wind-down scenario?

Building or Reviewing Your VASP BCP?

WCR Legal advises on BCP drafting and review for regulated VASPs — from initial document preparation for licence applications through annual review, testing facilitation, and regulatory submission across VARA, FSC, MAS, FCA, and MiCA jurisdictions.

No commitment required · Confidential initial consultation · Response within 1 business day

Oleg Prosin is the Managing Partner at WCR Legal, focusing on international business structuring, regulatory frameworks for FinTech companies, digital assets, and licensing regimes across various jurisdictions. Works with founders and investment firms on compliance, operating models, and cross-border expansion strategies.

Post Comment