Logs your auditor can read with you in the room.

By Gil Salu, Cyaxios

Compliance frameworks ask for one thing from a log: that you can prove it has not changed. TN signs every record at the source and links each one to the last, so tampering, deletion, and gaps are detectable at verification time. The same record stays sealed to the readers you choose.

What makes an audit log tamper-evident?

A plain log file is a list of lines. Anyone with write access can edit a line, delete a row, or insert one after the fact, and nothing in the file betrays the change. Provider-managed encryption at rest does not help here: it protects the bytes from an outside reader, not from a privileged insider who can rewrite history.

A tamper-evident log is different. It does not try to prevent edits. It makes every edit detectable. TN does this with two mechanisms working together on each entry.

• A per-record signature. Every entry is signed at the moment it is written, by the credential of the DID that issued it. The signature covers the record's contents. Change a byte and the signature no longer verifies against the issuer's public key.
• A hash link to the previous entry. Each record carries the hash of the one before it. The records form a chain. Remove an entry, reorder two, or splice one in, and the link no longer matches the neighbour it claims.

Together these make the log append-only in evidence, not just in policy. The history is fixed the instant it is written, and any later departure from that history shows up when the chain is verified.

How the chain is built

TN models a log as an ordered sequence of records. Each record carries a header: the issuing device identity, an event type, a sequence number, the hash of the previous record, a hash over the record's own contents, and a signature over that hash. The sensitive fields inside the record are sealed per reader; the header and the integrity material are public, so anyone can verify the chain without being able to read the payload.

This is the same construction certificate-transparency logs use to make a public, append-only record of issued certificates: entries bound into a hash structure so that the log cannot be altered after the fact without detection (RFC 6962). TN points the construction at your application's own audit records instead of at certificates, and keeps the field contents encrypted.

The verifier walks the entries in order. For each one it recomputes the content hash, checks the signature against the issuer's public key, and confirms the previous-hash link matches the prior entry. If every check passes for every record, the segment is intact. If one fails, the verifier reports the index of the first invalid entry, so you learn not just that the log changed but where.

The threat model

An audit log is only as good as the attacks it survives. TN's chain is built against four specific failures, each one a thing a regulator or a forensic reviewer will ask about.

One boundary is worth stating plainly, because auditors ask. The chain proves that the records you hold have not changed since they were written. It does not, on its own, prove that no record was ever withheld before the chain was published. Anchoring the chain head to an external witness on a schedule closes that gap; the hash links close the rest.

Verifying a chain segment

Verification is mechanical. tn verify reads the public envelope records as newline-delimited JSON on standard input and prints one result line per record. You feed it the public envelopes for the segment you want to check:

# verify the public envelopes for a log
$ cat order.placed.ndjson | tn verify

# one result line per input record
order.placed  seq=0  ok
order.placed  seq=1  ok
refund.issued seq=2  ok
order.placed  seq=3  ok

If a record were edited after the fact, its content would no longer match its signed hash, and that record's line would report the failure instead of ok:

$ cat order.placed.ndjson | tn verify
order.placed  seq=0  ok
order.placed  seq=1  ok
refund.issued seq=2  FAIL  signature does not match content
order.placed  seq=3  ok

What each line attests to is the same three checks, applied to every record: the content hash is recomputed and compared, the signature is checked against the issuer's public key, and the previous-hash link is confirmed to match the prior entry. A record that passes all three is intact and in place; a record that fails any one of them is reported, so you learn not just that the log changed but which record changed.

The same logic runs in the auditor's browser, on their own machine, against the records you hand them. They do not need access to your keys to check integrity. The public header and the signature are enough. They need a grant only to read the sealed fields.

Mapping TN to compliance frameworks

The frameworks below all require durable, attributable, integrity- protected logging. None of them name a vendor; each names a property. TN's chain is a way to satisfy the property and to show the satisfaction to an assessor.

• GDPR Article 30 (records of processing). Every record TN seals is typed and every grant is an explicit, logged act, so the system produces a verifiable account of what it did. That contributes to a records-of-processing exercise; the full ROPA still needs controller identity, purposes, retention periods, recipients, and transfers that live outside the log. (Art. 30)
• GDPR Article 32 (security of processing). Article 32 asks for integrity, confidentiality, and the ability to demonstrate effectiveness on an ongoing basis. Per-record signatures support integrity, per-reader encryption supports confidentiality, and the verifiable chain provides standing evidence toward demonstrating the measures are working. (Art. 32)
• PCI DSS v4.0 Requirement 10 (logging and monitoring). Requirement 10 calls for audit trails that are protected from modification, attribute each event to an actor, and can be shown intact to a QSA. Source signing attributes each entry to an issuing DID and the hash chain protects the trail from undetected change, which contributes to Requirement 10; the requirement also covers time synchronisation, retention, log review, and access logging that the chain does not provide on its own. (PCI DSS library)
• SOC 2 audit logging. The Trust Services Criteria expect a log that supports detection of unauthorised change and provides evidence to an examiner. A chain whose breaks are detectable and whose origin is signed is evidence an examiner can test rather than take on trust, and so supports those controls. (Trust Services Criteria)
• NIST SP 800-92 (log management). The guide treats log integrity and the protection of log data as core objectives of a sound logging program. Signing and hash-linking at the source support both directly. (SP 800-92)

Industry packs and per-field grants

Tamper-evidence governs the whole record. The sealing model governs what is inside it. TN ships industry packs: pre-built classifications for common regulated data types, covering standards such as PCI DSS, HIPAA Safe Harbor, OIDC, FHIR, ISO 20022, and FIX. Each pack maps named fields from its source standard to encryption groups, so an auditor can check the classification against the specification. Run tn show profiles to list the profile catalog available in your install and see which packs ship.

An audit then begins with a grant. You grant the auditor's DID access to the groups in scope for the engagement, and only those groups. They read records on their own machine: fields inside the granted groups decrypt, fields outside them stay sealed. When the engagement ends, rotating the affected groups revokes their read access for every subsequent entry. The grant is forward-looking, the same way an expired rental stops opening new content.

For the per-field model in detail, see field-level encryption, the DRM-for-logs primer on how sealing and granting work on a single record, and where TN fits in a DPIA for the GDPR mapping in full.