Define the failure before choosing the recovery action
Select a specific scenario: loss of a hosting environment, loss of a data source or inability to access an essential configuration. Identify the services and records affected. Do not combine every possible failure into one drill; the team needs to understand which dependency triggered the exercise.
Agree the acceptable recovery objectives with the business and the providers involved. Record which data can be reconstructed, which data must be restored and which external services require separate cooperation. A backup schedule is not evidence that the required operating state can be recovered.
Build an exercise record
| Exercise item | Record | Pass condition |
|---|---|---|
| Recoverable contents | Data, configuration and external dependencies | The selected restore set can be located and accessed |
| Restoration | Ordered actions and responsible operators | An isolated environment reaches the expected state |
| Validation | Account, instrument and integration checks | The restored workflow matches the approved evidence |
| Decision authority | Who can declare recovery or pause it | The team knows who approves the next step |
The table is an illustrative test framework. Actual objectives, permitted restoration methods and production decisions must be agreed for the environment being operated.
Rehearse without confusing a test with production
- Prepare a controlled destination with clearly separated access and communications.
- Restore the agreed materials and record missing dependencies.
- Validate representative account, pricing and reporting workflows without affecting live clients.
- Document how the production cutover decision would be made and who would reconcile state.
A drill should produce a usable exception list. Missing credentials, unavailable exports and unclear ownership are findings to resolve before a real incident, not reasons to hide the test result.
Keep recovery aligned with change
Review the exercise after a material configuration, provider or integration change. Update the runbook and repeat only the checks affected by the change, with a wider rehearsal when the operating model changed substantially.
For MT4 White Label and MT5 White Label, confirm which parts of recovery are controlled by the brokerage and which require the platform provider. The useful outcome is a documented, rehearsed recovery path with explicit remaining limitations.