How to Choose a CASP Evidence Store for Audit Reconstruction

By Dmytro Nasyrov · September 18, 2026 · Engineering selection guide

Scope: proposed engineering checks for an approved record-keeping policy. Synthetic examples; no product certification or legal opinion.

Choose a CASP evidence store by asking a reviewer to reconstruct a disputed decision from retained records. The reviewer should recover what the service knew when it acted, identify later corrections and explain any missing evidence. A searchable dashboard or an immutable bucket alone cannot answer those questions. This guide supplies a decision matrix and a worked correction case for selecting the storage, indexing and access arrangements behind that reconstruction.

The practical acceptance rule is simple: reject any proposal that loses original records, hides corrections, cannot establish the expected event population or depends on an unavailable provider to explain the result. Compare operating cost and convenience only after those gates pass. The examples below are synthetic engineering exercises, with proposed acceptance criteria rather than reported customer results or regulatory certification.

Define the reconstruction job before the product shortlist

A crypto-asset service provider, or CASP, may need to explain an order decision, a withdrawal hold, a customer complaint or a privileged configuration change. Each requires a different evidence population. Start with one named workflow and the questions its reviewer must answer. A store suitable for monthly policy approvals might be inadequate for reconstructing the sequence of an interrupted transfer.

Write the request as a concrete deliverable: retrieve the records for a disputed withdrawal, identify the applicable rule and produce an account of the decision that another reviewer can independently check. Specify the requesting role, permitted data, relevant period and delivery deadline. Set the deadline from the actual review process; a convenient demonstration timeout is not a supervisory requirement.

Separate the authoritative evidence from its search index. The preserved record carries the original observation and its provenance. The index helps locate it and can be rebuilt. A case report interprets several records and may need revision when new evidence arrives. If a proposal uses one mutable row for all these jobs, ask how it will preserve yesterday's explanation after today's correction.

The existing guide on tracing a CASP control from policy to production evidence establishes the control chain. This selection guide starts where that chain reaches persistence: which information survives, who can retrieve it and how a correction changes the reconstructed account.

Translate the regulatory outcome into selection criteria

Commission Delegated Regulation (EU) 2025/1140, Article 2, connects retention to ready access and reconstruction of key processing stages. It also addresses ascertainable corrections and previous contents, protection against manipulation, efficient analysis and technology-independent record-keeping obligations. These outcomes make a latest-state report an insufficient demonstration of historical reconstruction. They do not name a preferred database or turn a particular storage feature into an approval.

For ICT logs, Commission Delegated Regulation (EU) 2024/1774, Article 12, addresses documented logging arrangements, event selection, retention, protection, logging failures and synchronized clocks. Confirm which provisions apply to the entity and records under review. Business evidence and operational logs can share infrastructure while retaining different purposes and access rules.

ESMA describes one purpose of its supervisory guidance as helping readers “operationalise MiCA and RTS obligations into concrete controls and checks.” The quotation comes from ESMA provides guidance on MiCA best practices, published by ESMA on January 31, 2025. Applied here, that means translating an abstract requirement into a retrieval exercise with observable results. ESMA's statement does not endorse this matrix or any supplier.

Have the legal and compliance owners approve the record classes, retention bases and disclosure rules before configuring irreversible retention controls. The remaining recommendations describe a proposed engineering implementation. They should be tested against the CASP's approved interpretation and applicable national requirements.

Use a decision matrix with explicit rejection gates

The following matrix compares three storage roles, not named products. A deployment may combine them. Read each role against the same fields: provenance, access, correction and reconstruction failure. No numerical score compensates for a failed mandatory condition.

Protected object archive with a separate index

Provenance: Preserve original payloads with source identifiers, schema versions and an integrity manifest. Retain the mapping between indexed fields and archived object versions.

Access: Suitable for controlled retrieval of bounded evidence bundles. The design must demonstrate authorization on both index lookup and object download, including temporary links.

Correction: Store a new correction record that identifies its predecessor. Rebuild the searchable interpretation without replacing the protected original.

Reject when: The team can retrieve a file but cannot explain its relationship to the business event, or cannot restore the index from retained material. Low storage cost does not repair missing lineage.

Append-only event history with versioned projections

Provenance: Preserve event identity, producer identity and causal references. Document partition and sequence boundaries so readers do not infer a global order that the system never recorded.

Access: Suitable when investigators need event-level transitions. Require a scoped review interface rather than broad access to an operational message stream.

Correction: Represent corrections as additional events. Version the projection logic and preserve the original decision inputs, including external responses.

Reject when: Retention expires before the required review window, or replay requires obsolete code and inaccessible dependencies. An append-only event stream is useful only for as long as its meaning remains recoverable.

Analytical warehouse backed by retained source versions

Provenance: Keep extraction checkpoints and transformation versions linked to preserved inputs. A table's refresh timestamp alone does not establish the origin of every row.

Access: Suitable for large populations and cross-system investigation. Test row-level restrictions, exports and administrator access independently.

Correction: Keep change history and point-in-time query semantics. Mark recalculated fields as derived, with the transformation that produced them.

Reject when: A refresh silently replaces history, or an analyst cannot trace a result back to the original input. Fast queries over an incomplete population merely return incomplete answers faster.

Choose the combination that your team can operate and test. An archive plus index often provides a useful separation of preservation and retrieval, but it also creates two components to reconcile. Event history can reduce ambiguity about transitions while increasing replay maintenance. A warehouse can make population checks practical while requiring careful transformation governance.

Specify provenance as a record contract

For each evidence class, define a stable identifier, legal-entity scope, business-object reference and producing system. Add the schema version and the rule or configuration version used by the decision. Record the original source reference and the transformation that created any normalized representation. Preserve enough context to explain the meaning of a field after its source system is retired.

Time needs more than one column. Distinguish when the source says the event occurred from when the evidence service received it. Where a decision depends on an effective policy period, retain that period separately. A timestamp copied from a provider is a provider assertion; ingestion time is your observation of arrival. Neither alone proves a total order across independent systems.

Integrity also needs a defined boundary. A checksum can detect a change relative to a trusted reference, but does not establish that the source was truthful or that every event was captured. Record how manifests are protected, who can replace them and how signing keys are managed if signatures are used. Keep verification possible after key rotation without exporting private signing material into a review bundle.

Define capture failure behavior at the business boundary. If a withdrawal decision is persisted while its evidence write fails, the system must expose that divergence. Depending on the approved workflow, it may block release, use a durable retry path or raise an exception for controlled recovery. The store selection must include this integration behavior; a storage durability claim begins too late to cover an event never submitted.

Work through a late correction before buying

Consider a fictional withdrawal W-204. The identifiers and times are illustrative. At 09:00 UTC, the local service receives provider assessment A-17 and places the withdrawal on hold under rule R-7. At 09:06, an authorized reviewer records a release decision. At 09:12, the provider supplies correction A-18, stating that its earlier assessment contained an incorrect classification. The corrected assessment has an effective time of 08:58.

A latest-state query may now show only the corrected classification and make the original hold look inexplicable. Conversely, a frozen export containing only A-17 can conceal information the organization later received. Neither view alone is a complete reconstruction. The demonstration must preserve both the historical decision and the later discovery.

Use this compact record sequence as the selection fixture:

E-501, received 09:00: assessment A-17, withdrawal W-204, rule R-7, result HOLD, source payload reference and integrity value.
E-502, recorded 09:06: reviewer release, authorized role, reason, references to E-501 and the approval record, downstream action reference.
E-503, received 09:12: assessment A-18, effective 08:58, correction-of E-501, correction reason and original provider reference.
E-504, recorded after review: reassessment of the correction's consequences, accountable reviewer and a reference to any required operational response.

Ask for the explanation using a knowledge cutoff of 09:07. E-503 must not be presented as information available to the original reviewer. Ask again using a cutoff of 09:13. The result must disclose the correction while retaining E-501 and the reason the hold occurred. The earlier effective time of A-18 must not move its arrival into the past.

The later correction does not automatically reverse an executed withdrawal. The operational consequence requires a separate decision under the approved process. Keep the evidence about that decision distinct from the mechanism that stores revised facts. This distinction prevents a reconstruction tool from accidentally acting as a transaction engine.

Now remove E-502 from the supplied fixture. The expected answer is an explicit evidence gap, with the missing approval or release record named. The tool must not infer authorization from the fact that a downstream system shows completion. A persuasive narrative unsupported by the retained record should fail the exercise.

Finally, duplicate delivery of E-503. The system should recognize the same source event while preserving ingestion observations where needed. A duplicate correction must not become a second business correction merely because a retry generated another transport identifier. Record the identity rule used to make that distinction.

Test permissions at retrieval and export

An auditor may need the control decision and pseudonymous client reference without unrestricted access to identity documents. An operator may need ingestion health without the ability to alter retention. A service administrator may require maintenance access without authority to approve their own exceptional export. Define these roles before the demonstration so the supplier cannot prove access control using one all-powerful account.

Test the same evidence request under an authorized reviewer and an unrelated business unit. Check the search results, result counts, downloaded objects and export metadata. Restricting visible rows while allowing direct object access leaves a second disclosure path. Also inspect denied access attempts and changes to the permissions themselves as reviewable events.

Redaction creates a derived artifact. Preserve a protected mapping from the redacted export to its originals, the redaction policy version and the approving role. The receiving reviewer should know which fields were withheld and why, without learning the withheld values. A cryptographic digest of a predictable personal identifier can still expose information through guessing; do not describe hashing alone as anonymization.

The GDPR establishes data minimization and storage limitation, while recognizing circumstances in which processing is necessary for a legal obligation. Those principles require a reasoned lifecycle for personal data. They do not justify indiscriminate copying of customer records into an indefinitely retained audit archive. Have the privacy owner assess the actual purposes, lawful bases and rights handling.

If a supplier hosts the evidence, include support access, subprocessors, regional dependencies and exit access in the review. Record the approved arrangement and its contractual boundaries. A diagram showing a selected storage region does not describe every support or administrative access path.

Treat retention, correction and deletion as different operations

Assign retention by record class with an approved basis, starting event and expiration rule. Keep extensions or legal holds explicit and attributable. A single global duration can retain irrelevant payloads too long while deleting records whose period starts later. Review the policy against the applicable MiCA record-keeping provisions and other obligations instead of treating a vendor's default as a legal schedule.

Correction preserves the ability to distinguish the original observation from a later amendment. Deletion follows the approved lifecycle and any applicable restriction or hold. A store that supports one does not automatically support the other. Ask what happens to primary copies, replicas, indexes, exported bundles and backups when the lifecycle advances.

Irreversible retention settings deserve a rehearsal with non-sensitive fixtures. Confirm who can set or extend a protected period and what recovery is available after a configuration mistake. Do not put unnecessary identity data under a permanent lock merely to demonstrate immutability. Separate payload classes so an error in one class does not make the entire archive impossible to govern.

Include keys in the lifecycle. Retaining encrypted objects while losing the required decryption capability leaves unreadable evidence. Conversely, destroying a key is not automatically a legally sufficient erasure procedure in every context. Record the dependency and have the relevant owners approve the preservation and disposal design.

Make completeness and recovery part of acceptance

A store cannot prove its own completeness merely by counting what it contains. Reconcile it to an independent business population, such as the authoritative set of withdrawal decisions for the period. Preserve the population query and its version, scope, execution time and identifiers. Compare identities as well as counts: one missing record and one duplicate can leave a total unchanged.

Classify mismatches as missing, duplicate, late, orphaned or intentionally excluded with a documented basis. Distinguish late arrival from permanent loss. A reviewer should see the cutoff used by the check and whether the result is provisional while permitted deliveries remain outstanding. Any excluded category needs an owner who can explain why it is outside the population.

Run a cold retrieval exercise after disabling access to the source application's normal review interface. Recover the originals, rebuild the relevant index and produce the same bounded explanation. Include the schemas, reference data and transformation definitions needed to interpret the objects. Record actual recovery duration and unresolved dependencies rather than extrapolating from a successful small-file restore.

For vendor exit, request a bounded export and validate it in an independently controlled environment. Check record identity, correction links, usable formats and retained metadata. Include the contractual right and practical ability to obtain the data after termination. An export that opens only with the departing supplier's active account has not demonstrated an independent exit path.

Where evidence capture spans customer identity, monitoring and custody systems, integration ownership becomes part of storage selection. Pharos Production's MiCA compliance software development covers these workflow areas. A relevant engineering scope should connect their evidence contracts and retrieval tests; the service description supports that scope, not a claim that a particular deployment has passed an audit.

Run one bounded acceptance exercise

Give every shortlisted arrangement the same synthetic fixture and questions. Include the W-204 correction sequence, a missing record, a duplicate and a restricted field. Agree on the expected behavior before the demonstration. The following eight checks form a proposed acceptance sheet; the CASP must approve its thresholds and any additional service-specific tests.

Original preservation: Retrieve the original payload after its correction. Record its identity and the verification result against the protected reference.
Historical explanation: Reconstruct the 09:07 and 09:13 knowledge cutoffs without applying later knowledge to the earlier decision.
Completeness: Detect the missing E-502 using an independent expected population. Return an explicit gap rather than an inferred approval.
Duplicate handling: Explain how repeated E-503 delivery is identified and whether any derived count changes.
Access boundary: Refuse the unrelated role's request across both search and download paths. Preserve the access decision for review.
Correction visibility: Show the prior content, amendment reference and effect on the derived explanation. Identify any report that requires regeneration.
Recovery and exit: Produce an interpretable export with the ordinary source interface unavailable. Record the dependencies still required.
Lifecycle: Demonstrate a permitted retention transition and a held record that remains protected, using synthetic data under the approved test policy.

For each check retain the input, expected result, observed result, supporting artifact and reviewer. Mark a check unverified if the demonstration cannot exercise it. Keep sales assurances separate from demonstrated behavior. A deferred test needs an owner and an acceptance condition, not a green cell.

Keep acceptance approval separate from the authority to administer the store. The engineer configuring retention should provide the configuration evidence, while the designated reviewer checks it against the approved policy. Where the team is small, document the compensating review instead of inventing separation that does not exist. Include an emergency access procedure with a bounded purpose and a retrospective check of the records retrieved.

After a failed exercise, preserve the failed result alongside the remediation and retest. Replacing the original report with a successful rerun hides what changed. If the failure affected a previous export, identify its recipients through the existing disclosure register and determine whether a corrected account is required. The store should help locate affected records; the responsible business owner decides the communication and corrective action. This keeps technical correction from silently rewriting an earlier review conclusion.

Record the decision and the cost of keeping it true

Compare cost across ingestion, protected retention, indexing, retrieval, export, key management and operational review. Include engineering effort to maintain schemas and replay dependencies. Model a normal month and a concentrated audit request separately. A low steady-state bill may hide restoration delay or expensive export work when multiple reviewers request overlapping populations.

Estimate with the same workload for every option: event volume, average payload size, growth, retention classes, query patterns and export size. State which values are measured and which are assumptions. Obtain current supplier terms for the configuration under consideration. This article supplies no price comparison or performance benchmark.

The decision record should name the selected storage roles, mandatory checks passed, remaining gaps, accountable owner and conditions that would reopen the choice. Attach the accepted fixture and evidence results. Record why rejected alternatives failed a required condition or imposed an operating burden the team cannot support. Do not average a failed access or reconstruction test into an acceptable score.

Revisit the decision when a service changes, a provider is replaced, a schema breaks compatibility or a retrieval exercise exposes a gap. The useful question remains whether another reviewer can recover a defensible account from the retained evidence. Keep the acceptance artifacts close to that question, and require the next material change to preserve the ability to answer it.

Sources and review

Primary sources and service scope checked September 18, 2026. Regulatory statements are linked beside the relevant passages. The acceptance procedure and W-204 fixture are proposed engineering artifacts, not measured deployment results.

Suggested citation: Dmytro Nasyrov, How to Choose a CASP Evidence Store for Audit Reconstruction, Pharos Production, September 18, 2026. CASP evidence store selection guide.

About the author

Portrait of Dmytro Nasyrov wearing a dark suit and light blue shirt against a dark background.

Dmytro Nasyrov. Photo supplied by 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.

Page updated

Report abuse