How to Choose Recovery Evidence for a CASP Continuity Review

Engineering guide · 7 October 2026 · Fictional recovery exercise

A backup job can finish while a crypto-asset service remains unsafe to reopen. The restored ledger may be behind the custody provider, an old screening hold may disappear, or an accepted transfer may enter the replay queue again. A CASP continuity review needs evidence of the business function that recovered, including the conditions under which it can operate.

Choose recovery evidence by the claim it supports. A backup manifest establishes what was captured. A restore log establishes what was attempted. Application checks establish which functions worked with the recovered state. Reconciliation establishes where systems agree or disagree. A release decision establishes who accepted the remaining limits. None of those records substitutes for the others.

This guide provides a worked recovery dossier and a selection method for engineering leads, operational risk teams and control owners. Every record in the R-42 example is fictional. Its calculations are reproducible, but no real restore or production transaction was executed. The example deliberately ends with an unresolved transfer and a rejected recovery claim.

Define the recovery claim before requesting files

Start with one service boundary. For an outbound crypto-asset transfer, that might include the client instruction, ledger reservation, screening decision, custody submission and client-visible status. A database being available covers only part of that function. If the review concerns custody administration instead, the acceptance boundary must describe the corresponding business activity.

Write the target state in operational terms: authorized staff can identify outstanding transfers, preserve holds, reconcile accepted submissions and process permitted new instructions. Identify any degraded operation separately. Read-only account access may be useful during disruption without supporting a claim that normal withdrawals have resumed. The evidence request should name which of these states is being assessed.

Set the start and stop events before measuring recovery time. An organization may choose disruption, detection or plan activation for a particular measurement. The choice must be explicit and consistent with its approved objective. Keep those timestamps separately. If the exercise starts after staff have already prepared the recovery environment, that preparation cannot silently disappear from an end-to-end continuity conclusion.

The recovery time objective, or RTO, is the target duration for the defined function. The recovery point objective, or RPO, expresses the tolerated data-loss window. They are targets, not measurements.

Retain the business impact analysis, approved objective and service version alongside the exercise evidence. A result from an older architecture may need reassessment after a material dependency change.

Read the fictional R-42 dossier

Assume an isolated exercise for outbound transfers, with disruption and plan activation both at 10:00 UTC on 1 October 2026. For this example only, the approved service RTO is 30 minutes and the RPO is five minutes. The last acknowledged ledger sequence before the stipulated disruption is 1042. These numbers are illustrative choices, not regulatory thresholds or recommended objectives for every CASP.

Select the following nine records for the review. The identifiers bind the records to this exercise and prevent a successful retry from replacing the history of a failed attempt.

1. Scope R42-S: the service definition, target objectives, activation boundary and acceptance checks. It states that restored balances alone do not authorize transfer processing.

2. Snapshot R42-B: a snapshot exported at 09:58, whose consistent data point is 09:42 and whose ledger watermark is 1038. The export time describes packaging. It does not advance the recovered ledger.

3. Attempt R42-A1: a restore started at 10:02 and failed at 10:06 because the exercise identity could not access the required decryption key. No usable restored resource resulted from this attempt.

4. Attempt R42-A2: a retry with a separately recorded, approved access correction. Its restore job completed at 10:18. The log identifies the same snapshot and the new target resource.

5. Validation R42-V: application checks completed at 10:32. They found readable balances and a preserved screening hold, but transfer T-1042 remained absent from the recovered local ledger.

6. Replay R42-L: recovery applied ledger sequences 1039 through 1041. Its manifest records each source identity and disposition. It does not claim that sequence 1042 was recovered.

7. Provider R42-P: the custody provider's exercise record confirms acceptance of transfer T-1042. Provider acceptance is not evidence of blockchain settlement, and this record makes no settlement claim.

8. Reconciliation R42-X: the comparison identifies T-1042 as externally accepted and locally unresolved. It retains the provider reference, comparison boundary and outstanding exception rather than adjusting a total to hide the difference.

9. Decision R42-D: the exercise reviewer rejects normal outbound transfer release. The record assigns an owner to the unresolved transfer and requires a new validation result before reconsideration.

Under the stipulated boundary, restore-job completion took 18 minutes, while application validation took 32. The latter exceeds the 30-minute target. Even that 32-minute endpoint does not establish full service recovery because the transfer exception remains open. Record the duration to validation as a measured exercise interval, with the failed acceptance result beside it.

The snapshot's data point is 18 minutes before disruption, although its export file is only two minutes old. Snapshot evidence alone therefore exceeds the five-minute loss allowance. Replay narrows the gap, but sequence 1042 remains unresolved. The packet cannot substantiate an RPO pass from the export timestamp or from the existence of a replay process.

Select records with a claim-to-evidence checklist

Use a checklist whose rows are assertions, not document categories. Each row names the claim, its minimum evidence and the result that would defeat it. This changes a request for more screenshots into a request for the specific missing fact. Keep a status for each row: supported, contradicted or unverified.

For recoverable data, request the selected recovery point, its consistency boundary, integrity checks and demonstrated access to the restored contents. Reject an inference based solely on a successful backup schedule. A file may exist without containing the state needed for the service, and a checksum comparison can establish matching bytes without establishing correct application behavior. For usable restoration, request the attempt log and target resource identity, followed by checks performed against that exact resource. Bind the application build and schema version to the result. An application test against an existing staging database says little about a newly restored database unless the relationship between them is established.

For acceptable loss, request an authoritative pre-disruption cutoff and evidence of the state actually recovered through that cutoff. Specify the event types included. Restoring a ledger sequence does not automatically restore a provider callback, a screening decision or an approval audit entry. Their recovery points may differ even when they share a storage system. For safe operation, request control-state verification, reconciliation exceptions and an authorized disposition. The strongest packet explains what could not be proven. If the evidence does not cover a required transition, keep it unverified. Evidence demonstrating failure belongs in a failed result. Neither state becomes supported because an executive summary is green.

Keep failed restores in the evidence set

R42-A1 is valuable because it shows a recovery dependency that the successful retry could conceal. The exercise identity lacked key access. Preserve the error, identity reference, affected artifact and attempted procedure, with secrets removed. The failure belongs to the continuity finding even though R42-A2 later produced a restored resource.

The access correction needs its own record. State who authorized it, which permission changed and whether the correction is available under the intended disruption scenario. Access granted by an administrator during an exercise may not be obtainable when that administrator's identity service is unavailable.

A one-off workaround is a finding to resolve, not evidence of a repeatable procedure.

Link attempts without blending their clocks. A2 may have a short restore-job duration while the service has already spent additional time in A1 and escalation. Retain the overall service interval as well as attempt-level durations. This supports diagnosis without allowing the fastest attempt to stand in for the continuity outcome.

Amazon Web Services states in its recovery-testing guidance:

Do a test restore using currently established processes used in production for data restoration.

That instruction provides a useful boundary for evidence selection. Identify which procedure the exercise actually followed and every departure from it. A later runbook revision does not retroactively turn an improvised attempt into execution of the revised procedure. Retain both versions and show which attempt, if any, validates the correction.

Distinguish snapshot age from packaging age

The 09:58 export label in R42-B is plausible enough to create a false positive. A reviewer checking only the file timestamp could infer a two-minute data-loss window. The consistent data point is 09:42. Select evidence that states the snapshot's included state, how that state was established and what changed before the disruption cutoff.

A recovery point can require several coordinates. An internal ledger may use a sequence. A queue may use partition offsets, while a provider may use an export cursor. Keep each coordinate with its domain and extraction method.

A timestamp that happens to be shared across these systems is not proof of a consistent joint snapshot.

Ask whether the snapshot captured partially completed work. A reservation may be durable while the external submission result arrived after capture. Conversely, the provider may have accepted a submission whose local acknowledgment was lost. The evidence selection must preserve that possibility instead of classifying every absent local row as an instruction that never happened.

If replay fills part of the loss window, retain the combined recovery claim and its proof. Show the base snapshot, replay source, covered identities and unresolved remainder. Do not report the original snapshot age as the final data-loss result when later records restored state. Equally, do not claim complete recovery merely because replay was configured.

Verify replay without issuing a second transfer

R42-L recovers 1039 through 1041, leaving one missing sequence relative to the known cutoff. Sequence continuity is a useful first check, but the business identity matters more than a repaired counter. T-1042 has a provider acceptance record. Treat it as an exception requiring reconciliation before any decision to resubmit.

Select the original client instruction identifier, local operation identifier and provider reference for every replayed transfer. Preserve the relationship between them. Deduplication based on a new recovery-run identifier can miss an operation previously accepted under its original identity. A repeated callback should also remain distinguishable from a new instruction with a similar amount.

The review needs evidence of replay dispositions: applied locally, already represented, rejected or held for investigation. Describe the checks that produced each disposition. A manifest containing only successful applications hides the records that recovery could not safely classify. Retain rejected and unresolved identities with their owners and source references.

For this fictional example, the appropriate next action is to investigate T-1042 and rebuild its local state from verified evidence. No additional external transfer is authorized by the worksheet.

A proposed duplicate-prevention test belongs in the next exercise scope. It must not appear in the current results as though it had already run.

Test the controls restored with the data

A CASP can restore a balance and lose the control that restricts its use. Select evidence that the recovered service preserves relevant permissions, outstanding approvals and holds. Test an allowed operation and a deliberately forbidden operation under the restored state. A successful login verifies neither the full authorization model nor the preservation of transaction controls.

R42-V includes a screening hold that remains active after restoration. Its record should identify the held instruction, the decision version and the check performed. If the validation merely displays a hold in an interface, it does not prove that the submission path enforces it. Record interface visibility and enforcement as separate assertions.

Custody introduces another boundary: recovered application state may be correct while the signing or approval service is unavailable. Evidence can identify accessible key handles, required approvals and the observed dependency outcome without containing private keys or seed material.

A continuity packet should never become a repository of secrets collected for convenience.

Where ledger recovery exposes gaps between internal controls and external services, Pharos Production's MiCA compliance software development covers custody integration, client asset segregation and audit-trail workflows. That service scope is relevant to implementing missing evidence paths. It does not establish that a particular client's recovery procedure has passed or that the fictional exercise represents a delivered client result.

Include dependency evidence at the same boundary

Provider availability is often recorded as a general status page. Select evidence of the interaction the service actually needed: authentication, read access to outstanding operations, acceptance lookup or permitted submission. A provider being operational somewhere does not establish that the recovering CASP can reach it with the intended identity and network path.

Separate unavailable dependencies from degraded functions that can safely continue. Client account viewing might remain available while outbound transfers are held. Name the restriction, its enforcement point and its owner.

A degraded-state record helps the continuity reviewer understand the usable service boundary without overstating normal operation.

Google Cloud's guidance on recovery from data loss calls for testing the application stack and critical infrastructure services with restored data. Apply that principle to your dependency map: identity, configuration, event delivery and provider interfaces need relevant checks. The map should reflect your actual service, rather than a generic list of cloud products. Confirm that dependency evidence belongs to the same exercise window. An old provider integration test may support a design assumption but cannot demonstrate availability during this restore. Label inherited evidence and explain why it remains applicable. If the exercise excludes a dependency, retain that exclusion beside the conclusion it limits.

Reconcile operational identities before totals

A balance total can match while individual transfer states remain wrong. Two compensating errors may cancel numerically. Select both aggregate comparisons and identity-level exception checks where the service requires them. Record currency or asset, account scope, cutoff and the treatment of pending operations so the comparisons answer the same question.

R42-X begins with T-1042, whose external acceptance and missing local state are incompatible with a claim of complete recovery. The finding is not settled by making the ledger total equal a custody balance. Identify whether the operation was reserved, submitted, accepted, settled or reversed. Attach the source that is authoritative for each transition. Use source authority per assertion. The internal ledger can establish its recorded balance. A custody provider can establish its acceptance record, while chain observations may establish a transaction's inclusion under a stated observation policy. One source does not become authoritative for the entire workflow simply because its export is easier to obtain.

Document unresolved differences without forcing a single success percentage. The review needs their business consequences and release constraints. If T-1042 remains uncertain, say which processing path is held and what evidence could resolve it. Retain the original mismatch when subsequent evidence changes the finding, with a versioned explanation of the change.

Check what the exercise environment can actually demonstrate

A recovery demonstration can use a smaller isolated dataset to verify procedure and control behavior. Record that scale explicitly. If production has substantially more ledger history or a larger backlog, a short demonstration cannot establish the production service RTO without a justified relationship between the environments. Preserve the environmental differences beside the timing claim, rather than hiding them in a setup appendix.

Capacity evidence answers a different question from restoration evidence.

A service might process one permitted instruction while being unable to handle its normal backlog after an outage. If the acceptance criteria include throughput or backlog clearance, select the corresponding observations and their load assumptions. Do not insert a throughput target simply to make the packet look complete. The business impact analysis and approved operating boundary should determine whether that claim is needed.

For an exercise that replaces external services with simulators, identify the simulated interactions individually. A simulator can demonstrate local behavior for a chosen response, including rejection or timeout. It does not demonstrate that the actual provider was reachable, that a custody approval could be completed or that production credentials remained usable. Keep those claims outside the observed result until relevant evidence exists.

Record the exercise's stop conditions too. A restored resource may be intentionally isolated to prevent accidental submissions, or an exception may stop processing before the end-to-end check. That can be a sound exercise boundary. The report should preserve the narrower result and identify the additional controlled validation required, instead of describing a deliberately incomplete path as a fully recovered service.

Connect findings to the applicable continuity requirements

DORA Article 12(6) and (7) connect function-specific recovery objectives with integrity checks and reconciliation, including data reconstructed from external stakeholders. This supports keeping the function, cutoff and cross-system comparison explicit. It does not supply a universal 30-minute recovery target for CASPs. That number belongs only to the fictional worksheet.

Delegated Regulation 2024/1774, Article 25(5) requires documentation of testing results and analysis, remediation and management-body reporting of identified deficiencies. Link the failed key-access attempt and unresolved transfer to that findings workflow. A revised procedure is a remediation artifact. A new test result is evidence about whether the correction worked.

Keep applicability and engineering interpretation separate in the review. Confirm the relevant entity, function and regulatory framework with the responsible compliance team. The checklist organizes technical evidence. It is not a certification or an exhaustive legal assessment. Regulatory citations cannot compensate for missing execution records.

Package evidence so another reviewer can reproduce the finding

Build a manifest containing the service scope, exercise identifier, record identifiers and source locations. Preserve the original exports and describe every transformation used to produce a readable worksheet.

A hash helps detect a changed file, but it does not prove the truth of the source record or the completeness of the collection.

Include extraction timestamps and distinguish them from event and recovery-point times. Document redaction rules and retain a controlled path to the underlying records where appropriate. An external reviewer may need pseudonymous operation identifiers and evidence references, while secret material and unnecessary client data remain outside the packet. Access and retention should follow the organization's applicable policy.

Give the reviewer an explicit route from each conclusion to its inputs. For R-42, that means the activation boundary, 10:18 job completion, 10:32 validation endpoint, 09:42 recovery point, watermark 1038 and cutoff 1042. Preserve the arithmetic and the identity comparison. A reviewer should be able to disagree with the acceptance boundary without losing the ability to reproduce the calculations.

Turn missing evidence into a bounded engineering brief

Close the review with an evidence backlog, not a promise to improve resilience generally. Each task should name the missing assertion, the system responsible for recording it and the acceptance check for the next exercise. The R-42 backlog would address repeatable key access, T-1042 reconciliation and a measured service endpoint after all required checks pass.

Pharos Production's MiCA audit-trail and integration engineering provides a relevant service scope when ledger, custody and control records need to become inspectable together. Bring the service boundary and unresolved evidence rows to that discussion. The commercial brief should ask for a demonstrable recording and validation method, with the CASP retaining ownership of its recovery objectives and release authority.

For the next exercise, agree who can accept degraded operation, which exceptions prevent normal release and what new evidence closes each defect. Keep the current rejected result intact. The next successful attempt becomes a linked result with its own scope and inputs, rather than a replacement for the failed history.

More insights to read

1. What Did the Ledger Know at Cutoff? Build a Reconciliation Snapshot

2. Blockchain Ledger Integration Hub: Contracts and Acceptance Evidence

3. How to Choose a Blockchain Integrator for an Existing FinTech Ledger

4. How to Specify a Blockchain Ledger Integration Contract

5. Choosing a FinTech Blockchain Discovery Partner

About the author

Written by Dmytro Nasyrov PhD, software architect with 24 years of production experience. Dmytro is the founder and CTO of Pharos Production. He works on production software architecture for FinTech, AI, Web3 and blockchain systems.