Compliance

Where TN fits in a DPIA

By Gil Salu, Cyaxios

A Data Protection Impact Assessment documents the measures that protect personal data. TN gives you those measures ready-made: encryption, privacy by design, and an attested audit trail that turns every claim in the assessment into a fact you can show. Here is the value it delivers, how little you do to get it, and the GDPR articles it satisfies.

One line, and the controls are on

TN earns its place in a DPIA with a single call. You write a log line the way you always have, and the record arrives encrypted to the readers you choose, signed at the source, and entered in an attested log.

# one call — encrypted per reader, signed, logged
tn.log("order.placed", order_id=o.id, amount=o.total, email=o.email)

Granting a colleague or a partner access to a field is one line, and withdrawing it is one line. From the moment TN is in place, privacy by design is the default behaviour of the system and data minimisation is simply how records rest. The work a DPIA usually spreads across services and runbooks collapses into the act of logging.

Where it fits

TN suits any service that emits records carrying personal data. A SaaS product that writes customer details into its logs can seal those fields and still hand a partner exactly the columns they are owed. An AI agent that records the actions it takes gains a signed, encrypted account of every decision, ready to show a customer or a regulator on request. A payments or fintech service gains an audit trail it can prove has stayed intact. A team working across regions keeps keys and plaintext wherever its data-residency commitments point, while the vault holds ciphertext alone. In each case the same one-line wrap carries the weight, which is why teams reach for it early and keep it through audit season.

Interactive GDPR Logging Risk Tool

Assess the regulatory exposure of your logging pipeline. Toggle your current data practices below to evaluate your compliance risk level and see how to resolve audit issues.

Data Type Logged

Log Destination

Encryption Model

Static Analysis & Leak Prevention

Calculated compliance risk level: High Risk

Primary Compliance Vulnerabilities:

Envisaged Mitigation Safeguards with TN:

The articles it satisfies

Article 35The measures a DPIA documents

Article 35(7)(d) calls for the measures that address the risks and demonstrate compliance. Sealed-by-default records, per-reader encryption, and an attested access trail are precisely those measures, and because each one is verifiable it carries straight from the written assessment into the audit that follows.

Article 25Privacy by design and by default

TN delivers privacy by design and by default in the literal sense the article describes. A field is sealed to a named reader the instant you grant it, so data minimisation is the resting state of every record and the private setting is the one you get for free. Article 25 asks for exactly this posture, engineered in from the first line.

Article 32Security of processing

TN encrypts in transit and at rest, keeps your keys as material only you can open, and signs every record so its integrity is provable. The attested log gives you continuous evidence that these measures are working, which is the living proof of effectiveness Article 32 invites you to keep.

Article 5Integrity, confidentiality, and accountability

Signing at the source gives you integrity, per-reader encryption gives you confidentiality, and the attested trail gives you accountability (the means to show, to anyone, that data was handled the way you said). Article 5 names these as principles; TN hands you all three as working primitives.

Article 30Records of processing activities

Every record TN seals is typed and every grant is an explicit, logged act, so your records of processing activities are generated from what the system actually does. You keep a current ROPA as a by-product of running the service, which is the standing inventory Article 30 expects.

Article 28Processors under documented control

When you bring on a processor, their access is a cryptographic grant you issue and log, and withdraw in a single act. The instruction and its enforcement become one and the same, giving you the demonstrable controller-to-processor relationship Article 28 is built around.

Articles 33 and 34A strong breach position

Because every record is encrypted and the keys stay in your hands, your stored data meets the Article 34(3)(a) standard for material that is unintelligible to anyone unauthorised, and the attestation trail is the evidence that the keys stayed safe. That is the strongest footing you can carry into any breach assessment under Articles 33 and 34.

DPO Drafting & Boilerplate Toolkit

Are you documenting your logging pipeline in an official Data Protection Impact Assessment? Use these pre-drafted clauses for GDPR Article 35 templates to simplify your compliance documentation.

1. Description (Art. 35(7)(a))

2. Necessity (Art. 35(7)(b))

3. Safeguards (Art. 35(7)(d))

Systematic Description of processing operations

Describe how data is collected, stored, and protected in your logging framework.

The application implements the open-source 'TN' protocol for transactional and event logging. personal data (including [insert fields, e.g., email addresses, IPs, user identifiers]) is encrypted at the application boundary (within the runtime process memory) before being written to disk or transmitted to logging destinations. Encryption policies are defined locally in code or via static configurations ('tn.yaml'). The companion 'tn-agent' performs compile-time static analysis of the source code during CI/CD to identify potential leaks, enforce field schema declarations, and generate signed policy contracts. The hosted vault store only processes encrypted key backups and recipient metadata, ensuring zero custodial access to log cleartext by third-party processors.

Necessity and Proportionality assessment

Document your adherence to the data minimisation and purpose limitation principles.

The collection of logging data is strictly limited to fields required for operational auditing, security monitoring, and debugging. By employing client-side, per-reader field-level encryption, data minimisation (GDPR Article 5(1)(c) and Article 25) is enforced at the source. Unauthorized engineers, third-party log processors, and database administrators cannot view plaintext records, as cleartext never crosses the process boundary. Access to specific fields is granted cryptographically to designated recipient DIDs (Decentralised Identifiers) and can be revoked instantaneously by rotating the corresponding recipient keys without rewriting historical log files.

Measures envisaged to address compliance risks

List the specific technical safeguards implemented to protect user rights.

To address data protection risks, the following technical controls are implemented: 1. Cryptographic Sealing: Event logs are signed at source using public-key cryptography (secp256k1 DIDs) to prevent tampering and ensure non-repudiation (integrity and accountability). 2. Broadcast Encryption: Fields designated as personal data are sealed per-reader using a hybrid cryptosystem, ensuring only holders of approved private keys can access the cleartext. 3. Non-Custodial Vaulting: The storage of cryptographic key backups is federated and decoupled from log routing. Cyaxios acts as a key backup vault, holding only double-wrapped key ciphertext and maintaining no access to the decryption keys or the logs themselves. 4. Pre-Deploy Leak Prevention: Source code is scanned before release via static analysis to prevent accidental PII leakage from unmapped parameters or exception traceback output.

A DPIA that stays current

Article 35(11) invites you to keep the assessment current as the processing evolves. The attested trail makes that effortless: it is a living record that processing still matches what you described, so each review is a quick check against evidence. The same property that helps you pass the first audit keeps the assessment trustworthy between them.

TN and your team, together

Your privacy team brings the judgement a DPIA needs: purpose, necessity, proportionality. TN brings the verifiable controls and the evidence those controls are running, so the assessment rests on facts an auditor can check. The two fit together cleanly.

To go deeper, the DRM-for-logs primer shows how sealing and granting work on a single record, field-level encryption covers the per-field model, and our privacy policy describes what the vault holds.

← Back to the vault