Traceability · Evidence · Data
Data, evidence and traceability: the foundation of a credible system
A control system is only as good as its ability to demonstrate. Claiming that a control has been carried out, that a decision has been approved or that a recommendation has been followed is not enough: you must be able to prove it, sometimes years later. This is where many systems, despite being soundly designed, prove to be fragile.
The best test of a mechanism comes down to a simple exercise: choose a decision made two years ago — onboarding a sensitive client, accepting a residual risk, closing an audit recommendation — and try to reconstruct it in its entirety. Who decided? Based on what information? Who authorised it? What supporting documents were there?
Demonstrate
Assertion is not enough when dealing with the supervisor
Audit trail
Who did what, when, on what basis
The reconstruction test
In a fragmented setup, the exercise ties up several people for days: the elements exist, but are scattered across messaging apps, shared servers, spreadsheets and business tools. Some disappeared when an employee left. The decision may have been excellent; it can no longer be demonstrated.
What an audit trail is
The audit trail (audit trail) is the continuous, time-stamped record of what has happened: actions carried out, approvals granted, comments exchanged, documents uploaded, statuses changed. It answers four questions — who, what, when, on what basis — and it builds up automatically as activity takes place.
This latter feature is essential. Retroactively reconstructed traceability is fragile and costly; traceability produced by the very workflow itself is reliable and free. This is one of the clearest differences between a paper-based (or file-based) system and a digital tool-based system.
When the trace is formed directly during the execution of the work, evidence ceases to be an exercise in reconstruction. Documents, comments, authorisations and status changes can remain linked to the relevant file and gradually build up its history.
Data quality, the prerequisite for everything else
The most polished reporting is only worth as much as its sources. Four requirements condition the reliability of the whole:
- A single source of truth per data point. When the same information exists in three systems with three values, none of them is reliable. Designating the reference is a prerequisite.
- Shared definitions. An «incident», a «late recommendation», and a «high-risk client» must cover the same reality across all functions and entities.
- Continuous updates. Data updated solely for the purpose of a committee reflects the committee, not reality.
- An identified responsibility. Each structuring data point must have an owner, responsible for its quality.
Keep without hoarding
Traceability raises a symmetrical question: what should be kept, and for how long? Two requirements apparently conflict. On the one hand, retention obligations — particularly regarding AML/CFT — mandate specific periods. On the other hand, the protection of personal data prohibits indefinite retention and requires a specific purpose.
Reconciliation involves an explicit retention policy: which data categories, for how long, and what happens to them when that period expires. This policy is part of the compliance framework just like controls—and it is regularly reviewed during audits.
What traceability brings to the organisation
Reducing traceability to a control constraint would be a mistake: its internal benefits are substantial.
- Continuity. The departure of an employee no longer makes the history of a file disappear.
- Learning. Analysing past decisions and their effects presupposes being able to find them.
- Effective monitoring. Recommendations and open items stop getting lost between committee meetings.
- Serenity. A request from the supervisor or an auditor becomes an extraction, not a general mobilisation.
- Time taken for analysis. Time spent searching for information is time taken away from interpreting it.
Common pitfalls
- Confusing document volume with traceability: accumulating unstructured documents does not make it possible to reconstruct a pathway.
- Leave the validations in the inboxes, away from any viewable system.
- Reconstitute the evidence on demand, as an audit approaches.
- Neglecting the retention policy, between sectoral obligations and data protection.
- Treating data quality as a technical issue, with no business owner.
The ARCAD approach
ARCAD examines the demonstrability of the system as well as its design: are decisions traceable, are proofs linked to controls, are data responsibilities identified, and is the retention policy consistent with applicable obligations? This assessment is a useful precursor to any tooling project.
Make your device demonstrable.
ARCAD evaluates the traceability of your decisions, controls and evidence, and identifies weak points.