What audit logs need to become before a court will treat them as evidence

*The opening scenario below is a composite, drawn from production-grade evidentiary requirements observed across South African financial-services and legal-discovery workflows. It does not describe a single named customer.*

Consider how a Section 205 subpoena typically lands at a South African financial services firm. The investigation needs twenty-three months of email history for four custodians, with a forensic chain showing exactly when each message had been received, scanned, classified, retained, and — for messages that had aged out — destroyed. The legal team has ninety-six hours to produce it.

The non-evidence-grade response is what most firms produce: a folder of EML files and a CSV of audit log entries. The CSV is a sequence of timestamped database rows. The rows could have been edited at any point between creation and export. There is no cryptographic proof that the export reflects the historical state of the system. Opposing counsel's expert challenges the export inside a week. The court orders a second production with chain-of-custody documentation. The firm has to redo the work under tighter scrutiny, with less goodwill, and at a higher legal cost than the original deadline.

That is the gap between an audit log and evidence. This article explains what it takes to close it, and what the platform actually ships to do so.

The difference between an audit log and evidence

An audit log is a sequence of records describing things that happened. It is useful operationally — it lets administrators investigate incidents, troubleshoot integrations, and demonstrate operational diligence. It is what most platforms ship and most customers ask for.

Evidence is something else. Evidence has to function as a witness in a proceeding where its veracity is being challenged. The party producing the evidence has to be able to show three things: that the record is what it claims to be (authentication), that it has not been altered between the event and the production (integrity), and that the path it took from system to courtroom can be accounted for (chain of custody). Each of these has technical requirements that a generic audit log does not satisfy.

A regular audit log is mutable by anyone with database access. It has no proof of completeness — a row that was deleted leaves no trace. It has no proof of order — a record's createdAt field is whatever the system wrote, not what an external observer can verify. And it has no proof of authorship — a row attributing an action to a user is only as trustworthy as the system that wrote it.

The shift from audit log to evidence is therefore not a labelling exercise. It is a series of architectural decisions that have to be made before the data is captured.

What a court actually requires

Different jurisdictions phrase the requirements differently, but the underlying tests converge. The convergence below cuts across South African (POPIA, ECT Act), EU (GDPR), and US (FRE, FRCP) regimes — not because all three apply to every customer, but because their evidentiary tests converge in practice.

In the United States, Federal Rule of Evidence 902(13) was added in 2017 and provides that records "generated by an electronic process or system that produces an accurate result" are self-authenticating if accompanied by a certification from a qualified person. The accompanying note discusses hash values among the accepted means of demonstrating that an electronic process produces an accurate result.

In South Africa, the Electronic Communications and Transactions Act 25 of 2002 governs the admissibility and evidential weight of data messages. Section 14 sets out the "original" form requirement. Section 15(1) provides that the rules of evidence shall not be applied to deny the admissibility of a data message on the grounds that it is in electronic form. Section 15(3) lists the factors that a court considers when assessing the evidential weight of a data message: the reliability of the manner in which the data message was generated, stored, or communicated; the reliability of the manner in which the integrity of the data message was maintained; the manner in which its originator was identified; and any other relevant factor. A platform that cannot demonstrate cryptographic continuity between event and export has a harder route to weight under this test.

POPIA Section 19 — the security measures duty on integrity and confidentiality — and Section 22 — the security compromise notification duty — both presuppose that a responsible party can prove what data existed at what time and in what state. POPIA does not specify a cryptographic mechanism, but it makes the responsible party liable for proving the integrity claim if challenged. POPIA Section 14, separately, governs the retention and restriction of records — relevant to destruction events but distinct from the integrity duty.

GDPR Article 30 imposes a similar evidentiary burden through its records-of-processing requirement. GDPR Article 5(1)(e) — the storage limitation principle — engages on retention.

The convergence across these regimes is that "we kept logs" is not a defence. The party producing the records has to demonstrate that the production is faithful to the original.

The cryptographic primitive

The mechanism that closes the gap is a hash-chained audit ledger.

Every time the platform records an event — a backup ran, a restore was approved, a retention policy was applied, a legal hold was placed, an object was purged — it captures the event payload in a canonical form, computes the SHA-256 hash of prevHash + the canonical JSON serialisation of the payload, and writes both the hash and the previous hash into the new row. The result is a singly-linked cryptographic chain. Any tampering with a single row will produce a hash that no longer matches what the next row expects. A rebuild of the chain from the head will detect the discrepancy.

There are several details that matter for this construction to actually function as evidence.

The serialisation of the payload must be stable. JavaScript object key ordering is not guaranteed, so we use a deterministic JSON serialiser that sorts keys recursively across nested objects. Timestamps are converted to ISO-8601 strings before hashing. The same payload produces the same hash, regardless of which process serialised it.

The createdAt field has to be captured once and written into the canonical payload — not generated at write time by the database. If the application stamps a timestamp for hashing but lets PostgreSQL set the stored value via DEFAULT now(), the chain will fail to verify even on untampered data, because the two timestamps will differ by milliseconds. We capture the timestamp once, hash it, and write it explicitly.

The chain must be verifiable end-to-end, not just by pointer linkage. Some implementations only check that each row's prevHash field matches the prior row's hash field. That is necessary but insufficient. An attacker who modifies a row's content while also updating both hash and prevHash to match will pass a pointer check. The verification has to recompute the SHA-256 from scratch and compare it byte-for-byte against the stored hash. That is what verify-chain does.

Note: POPIA does not yet have published cryptographic-evidence guidelines from the Information Regulator, so the architectural standard derives from the ECT Act's reliability factors plus common-law evidentiary principles plus jurisdiction-specific equivalents (FRE 902, GDPR Art 30 as anchors).

The four properties that survive challenge

A hash-chained ledger has to satisfy four properties to function as evidence under adversarial review.

It must be **append-only**. Once a row is written, it cannot be modified. Update operations on the audit table are blocked at the application layer and at the database role level. The only operation other than INSERT is a controlled soft-delete used for retention purges, which we describe below.

It must be **tamper-evident**. Modification of any row breaks the chain in a way that any chain-walk will detect. The verification can run continuously in the background, on demand from an administrator, or as part of an export bundle. We verify the chain on every export to make sure the export carries proof of integrity at the moment of production.

It must be **verifiable on demand**. The cryptographic test is computable from the row contents alone. No external service, no proprietary verifier, no vendor cooperation is required. A regulator or opposing counsel can take the export, run the SHA-256 recomputation themselves, and reach the same answer. This independence is what gives the chain evidentiary weight — if the verifier had to trust the producer, the producer's incentives could be questioned.

It must support **retention without loss of integrity**. This is the property most implementations get wrong. A naïve audit ledger uses hard delete for retention purges. The deletion removes the row, but the next row's prevHash still references the deleted row's hash — a hash that no longer exists in the database. Any subsequent verification will report a broken chain even though no tampering occurred. We use a purgedAt soft-delete field instead. The row's hash linkage is preserved; the row's content fields are nulled out. The chain remains verifiable across the gap, and the audit history of the deletion itself is captured as its own event.

Legal holds: where the chain meets the law

A legal hold is a directive that suspends the platform's normal retention schedule for a defined set of data, usually in connection with anticipated or pending litigation, regulatory investigation, or audit. The hold is placed by an authorised user — typically an MSP-side legal officer or a tenant-side compliance officer — and it must remain effective until the matter closes.

The mechanics of a legal hold sound simple. They are not. A defensible hold has to do five things.

It has to identify the scope precisely — which custodians, which date ranges, which data types. Vague holds invite challenges that the producing party did not preserve enough; over-broad holds produce an unnecessary fishing expedition for opposing counsel. The platform supports custodian-level, date-range, and data-type granularity at the moment the hold is placed.

It has to notify the custodians. A hold that is placed in the system but never communicated to the affected employees is not legally operative. The custodian must acknowledge the notice. We send notices via the platform's email integration with an HMAC-signed acknowledgment URL — a click-once token that registers the acknowledgment in the audit chain with the custodian's identity, the timestamp of acknowledgment, and the cryptographic proof that the click came from the URL we sent.

It has to escalate when custodians do not respond. We run a daily reminder cron that re-notifies non-acknowledging custodians and, after three reminders, escalates to the matter owner with a non-acknowledgment alert. Escalation thresholds are configurable per matter. The escalation events are themselves audit-chained.

It has to suspend retention reliably. When a hold is in force on an object, the retention engine cannot purge it. This is enforced at the service layer — every retention action checks for active holds against the object before any destructive operation. Holds also block restore operations that would write to a held mailbox without explicit override.

It has to release cleanly when the matter closes. Release is itself an event in the chain. Custodians receive release notices, which they acknowledge through the same HMAC mechanism. Once released, the held objects re-enter normal retention. The release notice is an audit row. So is the acknowledgment.

Pre-purge SHA-256: the moment before destruction

Retention is the other side of the hold lifecycle. Data subject to a retention policy will eventually be destroyed. POPIA Section 14(1) requires that personal information not be retained longer than is necessary. GDPR Article 5(1)(e) requires the same. Whichever framework applies, the destruction event is the moment most likely to be challenged later — by a regulator asking "did you actually destroy what you said you destroyed?", by opposing counsel asking "what evidence existed before destruction that we no longer have access to?".

The 2015-amended Federal Rule of Civil Procedure 37(e) addresses this directly. The rule turns on whether the producing party took reasonable steps to preserve electronically stored information that should have been preserved in anticipation of litigation. Sanctions for the loss of ESI require a finding that the loss caused prejudice; the most severe sanctions require a finding of intent to deprive. The defence to a 37(e) challenge is built from two things: a documented retention policy applied through reasonable preservation steps, and proof that the destruction was actually executed as the policy described.

The consistency proof is in the retention engine — every object's destruction is decided by a policy that is itself an audit-chained record. The execution proof is what we hash before we destroy.

Before any retention action removes an object from the storage tier, we compute a SHA-256 fingerprint of the object's identity record — its protected-object id, external Microsoft 365 id, display name, workload type, and tenant. That fingerprint is written into the destruction event. The fingerprint, the policy that triggered the destruction, the retention rule version, the actor (always SYSTEM for cron-driven retention), and the timestamp are all part of the chain. The object itself is then removed from the storage tier. What remains is a cryptographic anchor that says: at this moment, this object existed, this is its identity, and this is the policy under which it was destroyed.

If the policy is later challenged, the fingerprint is the proof that the destruction was actual and not selective. If the matter is later challenged, the fingerprint distinguishes objects that were destroyed routinely from objects that should have been held. A regulator asking "what records existed in May 2024 that have now aged out?" gets a list of identity fingerprints, the policy that retired them, and the audit trail proving the policy ran on every eligible object on schedule.

Destruction records: closing the loop

The destruction event is the chain entry. The destruction record — what we call a destruction certificate in the product — is the customer-facing artefact that summarises the destruction and references the chain entry.

A destruction certificate is a database record produced for every retention-driven purge. It captures: which objects were destroyed, when, under which policy, by which retention rule version, the SHA-256 fingerprint of the object's identity record, the actor (SYSTEM for cron-driven retention), and a SHA-256 hash of the certificate payload itself. The certificate is then itself audit-chained — a destruction.certificate.created event lands in the tamper-evident ledger alongside the preceding OBJECT_PURGED event.

Verification is straightforward and customer-runnable. A regulator or counsel pulls the certificate, recomputes the SHA-256 of its payload, and compares against the stored certificateHash. If the hashes match, the certificate has not been altered since issue. Because the certificate is also referenced in the audit chain, any tampering with the certificate row would cascade into a chain break detectable by verify-chain.

The legal weight of this is mostly about defensibility rather than enforcement. POPIA does not require a destruction certificate per se — it requires that the responsible party can prove the destruction occurred as described. The certificate is the form that proof takes. GDPR is similar. Where the certificate matters most is when destruction is challenged years later. The chain is still verifiable. The certificate hash is still recomputable. The proof survives the time horizon of the dispute.

What this looks like in a real subpoena response

A subpoena arrives. It asks for "all communications between Custodian A and Custodian B during 2024 relating to Project X, including any messages that were destroyed during that period and the records of their destruction."

Step one: legal counsel places a hold against the four custodians for the relevant time period. The hold is recorded in the chain. Custodians are notified; their acknowledgments are recorded. The retention engine is suspended for the held objects.

Step two: the eDiscovery search runs across the held data. EvidenceVault returns the matching messages. The export bundle is generated. It includes the EML files, a manifest with SHA-256 fingerprints of every file, the audit chain extract for every message in the bundle, and a verification record showing the chain was verified end-to-end at the moment of export.

Step three: for messages that were destroyed during the relevant period, the search also returns the destruction certificates. The certificates show the SHA-256 fingerprints of the destroyed messages' identity records, the policy under which they were destroyed, and the chain reference proving the destruction was routine. The bundle is now complete.

Step four: opposing counsel's expert receives the bundle. They run the verification themselves. The chain checks out. The certificate hashes recompute correctly. The export was produced by an authenticated export operation that is itself in the chain. The expert's assessment is that the production is authentic, complete, and defensible.

The ninety-six-hour deadline is met. The challenge does not arrive a second time.

What evidence-grade is not

It is not "we have logs". Almost every platform has logs.

It is not "logs are immutable". Object Lock on storage is necessary but not sufficient; immutability of the storage tier does not prove anything about the content of what was stored or the order in which it was written.

It is not "logs are encrypted". Encryption protects confidentiality. Evidence is about integrity and provenance, which are different properties.

It is not "we keep logs for seven years". Retention is a separate question from integrity. A seven-year-old log that was edited last Tuesday is no more useful than a one-day-old log with the same problem.

Evidence-grade is a specific architectural commitment. The chain has to be cryptographic. The verification has to be independent and customer-runnable. The chain has to survive retention. The hold workflow has to be legally operative — notices, acknowledgments, escalation, release. The destruction has to leave a fingerprint and a certificate that outlives the data itself.

The honest answer to "what does evidence-grade actually mean" is that it is a label that gets used loosely, and the difference between the loose use and the strict use is a series of architectural decisions made before any data is captured. SHA-256-chained audit, HMAC-signed custodian acknowledgments, pre-purge identity fingerprints, audit-chained destruction certificates with customer-runnable hash verification — these are not features. They are properties of the platform's data layer that have to be true on day one. We built VaultFuzion that way because the alternative is to discover, on the day the subpoena arrives, that the audit log is not what the law needs.