How to Trace a CASP Control from Policy to Production Evidence

CASP control traceability for MiCA, DORA and production evidence

Evidence completeness and production release gates

Make evidence part of the production release gate

Treat evidence generation as a release acceptance condition, not a post-release reporting task. A control-affecting change should not enter production until the team can demonstrate the active control ID, policy and rule versions, deployment reference, evidence schema, test result, rollback path and monitoring owner. The gate should fail when the evidence writer is disabled, the correlation ID is missing, the expected reject path cannot be reconstructed, or retention and access classifications are absent.

After deployment, run a canary transaction or controlled replay and verify that the evidence object is searchable through the same route used for audit retrieval. Record the release decision and any temporary exception against the control version. This turns CASP compliance evidence into a delivery artifact and prevents a common failure: shipping the business behavior first, then building proof under supervisory or audit time pressure.

Define the evidence population

A traceable control needs a denominator. Before sampling records, define the full population of in-scope events for the review period and document how it is produced. The population query should identify the legal entity, service, event type, control version and time boundary. Preserve the query or report version, execution time, result count and operator. Without that record, a clean sample proves only that selected events look correct; it does not show that every event capable of triggering the control entered the evidence pipeline.

Reconcile business events to evidence events

Run a completeness reconciliation between the authoritative business source and the evidence store. Compare event counts and stable identifiers, then investigate missing, duplicated, late or orphaned records. For asynchronous workflows, define the permitted delivery delay and keep late-arrival metrics. For batch controls, reconcile the expected schedule, execution record, processed population and output. A difference should create a governed exception or incident, not disappear through a manual spreadsheet adjustment.

Make the reconciliation reproducible. Record the source snapshots or immutable query references, transformation version, matching rules, tolerances and result. If privacy restrictions prevent a reviewer from seeing raw identifiers, use consistent protected identifiers that still allow both sides of the population to be matched.

Sample by risk and include edge cases

Where full-population testing is not practical, document why the sample is appropriate. Combine random selection with risk-based items such as high-value transactions, overrides, rejected attempts, privileged actions, vendor timeouts and events near a rule or policy change. Keep the random seed or selection logic when a tool generates the sample. A reviewer should be able to reproduce which items were chosen and confirm that unfavorable outcomes were not filtered out.

Test the trace in both directions. Start with an obligation and retrieve the active control, release and production records. Then start with a production event and reconstruct the applicable obligation, policy, rule, operator or service identity, decision and evidence-retention state. Record retrieval time because evidence that exists but cannot be produced within the review window is an operational weakness.

Govern exceptions and emergency changes

An exception record should state the affected control and events, business rationale, risk acceptance, approving authority, compensating control, start time, expiry, monitoring condition and required remediation. Emergency changes need the same trace after the immediate risk is contained: deployment identity, approver, control impact, evidence-schema impact, validation result and retrospective review. Expired exceptions should alert an owner and block silent renewal.

Use evidence quality indicators

Track a small set of indicators that reveal whether the chain remains usable: evidence-write success rate, reconciliation breaks, late records, missing control or rule versions, unauthorized overrides, failed retrieval tests, open exceptions past expiry and overdue remediation. Define owners and thresholds, but keep the underlying event-level proof. A green dashboard is a navigation aid; it is not a substitute for the records that support the status.

A CASP control is traceable only when a reviewer can move in both directions: from a regulatory obligation to the policy, procedure, system behavior and retained evidence that implement it, and from a production event back to the approved obligation and control version that governed it. This guide gives compliance, engineering, risk and internal-audit teams a repeatable way to build that chain without treating screenshots or policy PDFs as proof on their own.

For: CASP CTOs, Heads of Compliance, MLROs, risk owners, security teams, product owners and internal audit.

 Outcome: one control record that can be tested, replayed, exported and explained.

 Scope note: engineering guidance, not legal advice. Confirm applicability and interpretation with qualified counsel and the relevant national competent authority.

Supervisory context. ESMA describes the practical goal as helping teams “operationalise MiCA and RTS obligations into concrete controls and checks.” Source: ESMA guidance on MiCA best practices.

The control traceability chain

Use one stable chain for every material control:

1. Authoritative source - the exact MiCA, DORA, TFR, AML/CFT or national requirement.

2. Applicability decision - why the provision applies to this legal entity, service, product and jurisdiction.

3. Approved obligation - the organization's controlled interpretation of what must happen.

4. Policy and procedure - ownership, scope, decision rules, frequency, escalation and exceptions.

5. Control design - the actor, trigger, input, rule, output, failure state and expected evidence.

6. System enforcement point - the service, workflow, configuration, vendor or manual step that applies the rule.

7. Production event - the timestamped record showing what the control actually did.

8. Evidence object - the protected, queryable artifact retained for review.

9. Acceptance test - the method and result used to decide whether the control operated effectively.

10. Review and remediation - deficiencies, decisions, changes, retests and management-body oversight.

The chain fails if any link is only implied. A policy without an enforcement point is intent. A log without a control identifier is telemetry. A test without a version and evidence reference cannot prove which production behavior was assessed.

Start with applicability, not the policy document

Identify the regulated service and legal entity

Begin with the authorized or proposed crypto-asset services, the contracting entity and the systems that perform those services. A custody control, an execution control and a complaints control may share infrastructure, but they do not share the same legal basis, risk or evidence.

Record:

• CASP legal entity and home-state NCA.

• MiCA service category and product boundary.

• client type and relevant jurisdiction.

• systems, vendors and outsourced processes in scope.

• accountable management-body member.

• interpretation owner and date of legal review.

Pin the obligation to an exact source

Store the regulation, article, paragraph and applicable technical standard. For example, MiCA Article 68(9) requires records of CASP services, activities, orders and transactions that are sufficient for supervisory and enforcement work. Commission Delegated Regulation (EU) 2025/1140 further specifies records for policies, procedures, services, activities, orders and transactions. DORA and Commission Delegated Regulation (EU) 2024/1774 add ICT-risk and logging requirements, including event selection, log retention, protection against tampering and clock synchronisation.

Do not map a control to "MiCA compliance" as a generic label. That is too broad to test and too vague to survive a regulatory change.

Record the interpretation boundary

Separate three things:

• legal requirement - what the primary source states.

• control interpretation - how the CASP decides to satisfy it.

• engineering implementation - how the current system enforces that decision.

This prevents an implementation choice from being presented as if the law prescribed it. It also lets the system change without silently changing the obligation.

Write a testable control statement

Use actor, trigger, rule, result and evidence

A control statement should be executable as a review question. Use this form:

When [trigger] occurs, [actor or system] must evaluate [inputs] against [rule and version], produce [permitted result], block or escalate [failure condition], and retain [evidence] for [retention basis].

Weak statement: "High-risk withdrawals are reviewed."

Testable statement: "Before a withdrawal above the approved risk threshold is released, the withdrawal service must obtain the current customer-risk state and screening result, require an authorized reviewer decision when the configured escalation rule fires, block release while the decision is absent, and retain the inputs, rule version, reviewer identity, decision, timestamps and final outcome."

Define the control objective separately

The objective explains the risk the control reduces. The statement defines observable behavior. Keep both:

• Objective: prevent a withdrawal from bypassing the approved risk decision.

• Control: enforce the escalation rule before release and retain the complete decision record.

Combining them into one sentence usually produces language that sounds authoritative but cannot be tested.

Name the acceptance criteria

Every control needs explicit pass conditions. Typical criteria include:

• the control fires for every in-scope event.

• the correct rule version is used.

• missing inputs fail closed where the approved design requires it.

• overrides require an authorized identity and reason.

• evidence is written even when the transaction is rejected.

• timestamps come from synchronized system clocks.

• the record can be retrieved by client, transaction, control and time range.

• the evidence survives the retention and access-control checks.

Build the control record before building the dashboard

Give every control a stable identity

Use an immutable control ID such as CASP-WD-004. Do not encode a team name, vendor or policy version into the ID. Those change. The ID should remain stable while versions describe the change history.

Minimum control metadata:

• control ID and title.

• objective and risk.

• authoritative source references.

• applicability statement.

• policy, procedure and rule versions.

• control owner, operator, reviewer and approver.

• frequency or event trigger.

• systems and third parties in scope.

• evidence types and storage locations.

• retention basis and access class.

• acceptance criteria and test frequency.

• exception and remediation workflow.

• effective date, review date and status.

Separate design evidence from operating evidence

Design evidence shows that the control was specified and approved: policy versions, architecture decisions, rule definitions, approvals, data-flow diagrams and test plans.

Operating evidence shows that the control ran: decision events, access records, alerts, case histories, reconciliations, test results, incident records and remediation closure.

A supervisor may need both. A configuration screenshot can help explain design, but it rarely proves continuous operation. A production log can prove an event occurred, but without the approved rule and applicability record it may not prove compliance.

Preserve rejected outcomes

Controls often retain successful transactions and lose blocked, timed-out or malformed attempts. That removes the events most likely to reveal a control failure. The evidence model should record permit, deny, escalate, error and incomplete outcomes with a reason code.

Map the control to the production path

Find the real enforcement point

Locate the component that can actually prevent or change the outcome. It may be:

• an API gateway or policy engine.

• a KYC, sanctions or blockchain-analytics decision service.

• an order-management rule.

• a custody approval workflow.

• an IAM or privileged-access policy.

• a reconciliation job.

• a case-management queue.

• a manual review step with system-enforced completion.

• a third-party service whose response is validated locally.

If the mapped component only observes the event after it completes, it is a detective control, not a preventive one. Record that distinction.

Trace every handoff

For each boundary between systems, capture:

• source and destination.

• message or API schema version.

• correlation and causation identifiers.

• authentication and service identity.

• retry and idempotency behavior.

• timeout and fallback behavior.

• ownership when delivery fails.

• evidence written on both sides of the boundary.

The control should still be explainable when a vendor dashboard is unavailable. Retain the vendor decision reference, the input fingerprint needed to reconcile it, the local action and the contractual or technical boundary around third-party evidence.

Treat configuration as code or controlled data

Rules that live only in an administrator console are hard to review and compare. Where possible, version thresholds, lists, workflow states and policy mappings in a controlled repository or configuration service. Record who approved the change, when it became effective, which deployment introduced it and which control IDs it affects.

Design the evidence event

Capture enough context to replay the decision

A useful event schema normally includes:

• event ID, control ID and control version.

• correlation ID and business-object ID.

• legal entity and service context.

• actor or service identity.

• event time and processing time.

• input references or privacy-safe fingerprints.

• rule, model or configuration version.

• decision and reason code.

• override identity and justification, if any.

• downstream action and final state.

• evidence location, integrity value and retention class.

Do not place secrets, private keys or unnecessary personal data in evidence logs. Store references or protected values according to the data-classification and minimization design.

Make chronology defensible

Commission Delegated Regulation (EU) 2024/1774 requires documented logging procedures and includes clock synchronisation among the logging controls. In practice, preserve event time, ingestion time and processing time rather than collapsing them into one timestamp. This exposes delayed delivery, replay and clock drift.

Protect evidence from silent alteration

Evidence should be access-controlled, monitored and protected against tampering, deletion and unauthorized access. The implementation may use append-only storage, immutability controls, write separation, cryptographic integrity checks or another risk-appropriate design. The regulation sets the outcome; the architecture should document why its mechanism is proportionate.

Link policy versions to system versions

Use an effective-version matrix

For each production period, a reviewer should be able to identify:

• the approved policy and procedure version.

• the active control version.

• the rule or configuration version.

• the application deployment or release.

• the evidence schema version.

• the test result that accepted that combination.

This matrix resolves a common audit failure: a current policy is compared with historical evidence generated under an older rule.

Define change triggers

Reassessment should not wait for the annual review when a material change occurs. Triggers may include:

• a new CASP service or jurisdiction.

• a regulatory or supervisory change.

• a new vendor or outsourcing arrangement.

• a material workflow or architecture change.

• an incident, recurring alert or control deficiency.

• a model, threshold or rule-set change.

• an evidence-schema or retention change.

Each trigger should identify the controls affected, the required approval and whether regression or effectiveness testing is mandatory before release.

Test design and operating effectiveness

Test the design before production

Design testing asks whether the control, if operated as documented, could meet its objective. Review the applicability logic, segregation of duties, failure behavior, data dependencies, evidence completeness, privacy constraints and third-party boundaries.

Test operation with representative evidence

Operating-effectiveness testing asks whether the control actually ran during a defined period. Use a documented population and sampling method, or an automated completeness check where every event can be evaluated.

For each test retain:

• test ID, control ID and period.

• population definition and count.

• sample method and selected items.

• expected result and test procedure.

• evidence references.

• observed result.

• exceptions and severity.

• reviewer and approval.

• remediation owner, due date and retest result.

Test negative and degraded paths

Include missing vendor responses, stale data, duplicate messages, unauthorized overrides, clock drift, evidence-write failure and recovery after outage. A happy-path sample cannot show how the control behaves when the evidence system itself fails.

Manage exceptions without breaking the chain

Distinguish control exception from control failure

An approved exception is a governed decision with scope, rationale, owner, expiry, compensating controls and approval. A control failure is an unapproved departure from expected behavior. Mixing the two allows operational defects to disappear inside a waiver process.

Keep the remediation record connected

The deficiency record should link to the control, affected events, risk assessment, temporary action, permanent fix, release, retest and closure approval. Commission Delegated Regulation (EU) 2025/1140 requires records of management-body assessment and periodic review of policy effectiveness, including identified deficiencies and measures taken to address them.

Escalate evidence gaps as control gaps

If required evidence was not produced, do not mark the control effective solely because the business outcome looks correct. Missing proof may indicate a logging failure, an unmapped path or an operation outside the controlled workflow.

Retain, retrieve and export

Apply the correct retention basis

MiCA Article 68(9) establishes a five-year period for the records it covers and allows extension up to seven years when requested by the competent authority before the initial period ends. Other records may follow different MiCA, DORA, AML/CFT, TFR, privacy, employment or national-law rules. Assign retention by record class and legal basis rather than using one global duration.

Prove retrieval, not just storage

Run periodic retrieval tests. A reviewer should be able to request a control ID, time range, client or business object and receive a complete export with an index, provenance and integrity information. Test retrieval from archives and after the source application or vendor account is unavailable.

Produce a supervisor-readable evidence pack

A compact control pack should contain:

1. control summary and applicability.

2. regulatory-source references.

3. policy and procedure references.

4. ownership and segregation of duties.

5. architecture and enforcement-point description.

6. event and evidence schema.

7. evidence index for the review period.

8. test plan and results.

9. exceptions, deficiencies and remediation.

10. version history and management review.

The pack should point to protected evidence rather than duplicating sensitive data into an uncontrolled document.

Worked example: complaints handling

Obligation and control objective

MiCA Article 71 requires CASPs to make a complaint template available, keep a record of complaints and record measures taken in response. The objective is to ensure every complaint enters the governed process, receives traceable action and remains retrievable.

System behavior

When a complaint arrives through an approved channel, the case service creates a complaint ID, records the client and channel, assigns the current handling procedure, starts the applicable service clock, restricts access, records each action and preserves the final response. If classification is uncertain, the case is escalated rather than silently treated as ordinary support.

Production evidence

Evidence includes the intake event, complaint template version, classification, owner, action history, communications references, decision, response time, closure approval and any remediation link. The control test reconciles approved-channel intake against created cases, checks required fields and samples the action history and final response.

Failure and exception paths

Test duplicate messages, channel outages, missing client identifiers, reclassification, reopened cases and records that reach the retention boundary. A support ticket is not automatically a complaint record; the classification decision and evidence must be explicit.

Common traceability failures

Policy-only compliance

The policy is approved, but no component, workflow or owner is mapped to each rule. Fix: add an enforcement-point and evidence field to every material control.

Screenshot evidence

A screenshot shows a state at one moment without population completeness, provenance or integrity. Fix: retain structured events and use screenshots only as explanatory context.

Logs without business meaning

Technical logs lack legal entity, service, control ID or business-object correlation. Fix: use a controlled evidence envelope around the operational event.

Current-state bias

Reviewers see today's policy and configuration but cannot reconstruct last quarter. Fix: preserve effective versions and link evidence to the versions active at event time.

Vendor-only proof

The CASP depends on a third-party dashboard that cannot be exported or retained after termination. Fix: persist the decision reference, local action, reconciliation data and contractually required access.

Evidence that proves success only

Denied, failed and incomplete events are missing. Fix: require evidence creation before outcome branching and monitor evidence-write failures.

Manual overrides outside the workflow

Urgent decisions happen in chat or email. Fix: require the production workflow to capture the authorized actor, scope, reason, expiry and compensating control before the final action.

A practical implementation sequence

First 30 days: establish the traceability spine

• choose the control taxonomy and stable IDs.

• define the control-record schema.

• map priority obligations and services.

• name owners and enforcement points.

• select one high-risk workflow for an end-to-end pilot.

• define evidence classes, access and retention.

Days 31-60: instrument and test

• add control and version metadata to events.

• implement integrity and evidence-write monitoring.

• link policy, configuration and deployment versions.

• build the evidence index and retrieval query.

• run design, negative-path and recovery tests.

• record deficiencies rather than hiding incomplete evidence.

Days 61-90: operationalize review

• automate population completeness where possible.

• produce the first control evidence pack.

• rehearse a supervisor request.

• close or formally accept deficiencies.

• schedule periodic effectiveness and retrieval tests.

• connect material changes to control reassessment.

How Pharos Production supports the evidence chain

Pharos Production designs and implements MiCA compliance software that connects policy decisions to enforceable workflows, versioned rules, production events and reviewable evidence. The work can cover control mapping, event and evidence schemas, integration boundaries, control testing, retrieval exports and acceptance gates. The legal interpretation remains with the CASP and its counsel; Pharos Production owns the engineering translation agreed in scope.

For a concrete example of evidence planned before a stress event, see the Pharos Production guide to a CASP wind-down plan and asset-return evidence trail. For the broader delivery scope, see MiCA compliance software development.

Sources, review and change control

Primary sources checked on 18 September 2026:

• Regulation (EU) 2023/1114 (MiCA), especially Articles 62, 68, 71 and the service-specific obligations.

• Commission Delegated Regulation (EU) 2025/1140, specifying records to be kept by CASPs.

• Regulation (EU) 2022/2554 (DORA), especially ICT risk management, response, recovery and evidence obligations.

• Commission Delegated Regulation (EU) 2024/1774, especially Article 12 logging and Articles 22-23 incident evidence and detection.

• ESMA Supervisory Briefing on the Authorisation of CASPs under MiCA.

Engineering review: Dmytro Nasyrov, PhD, software architect with 24 years of production experience.

 Publisher: Pharos Production.

 Last substantive review: 18 September 2026.

 Review triggers: amendment or new technical standard affecting the cited provisions; material ESMA or NCA supervisory guidance; change in the service scope or evidence architecture.

More insights to read

1. Blockchain Ledger Integration Hub: Contracts and Acceptance Evidence

2. How to Specify a Blockchain Ledger Integration Contract

3. How to Scope a FinTech Blockchain Discovery Sprint

4. How to Choose a Blockchain Partner for a FinTech Discovery Sprint

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

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.