Home · ISO 27701 compliance

Privacy controls

The technical controls of ISO/IEC 27701:2025, automated.

Trinito is a runtime implementation of the technical privacy controls a PII processor needs to satisfy ISO/IEC 27701:2025. Plug it in and the controls run. Policies, training, role assignment, and customer agreements remain your responsibility — the code does the rest.

Published October 2025, ISO/IEC 27701 is now a stand-alone Privacy Information Management System standard, certifiable independently of ISO/IEC 27001. It is the recognised international answer to the question "how do you evidence GDPR Article 25?"

What Trinito automates

Every row below maps a 27701:2025 control to the technical implementation in the appliance.

27701:2025 control What the standard requires What Trinito does at runtime
A.7.4.5
PII minimisation
Process only the PII necessary for the specified purpose. Redaction-by-default strips identifying fields before any external call. No code path exists that sends an unredacted prompt without explicit per-prompt user authorisation against a visible preview.
A.7.4.7
De-identification & deletion
Apply de-identification when PII can be removed without compromising purpose. Regex + checksum + proximity + spaCy NER + per-organisation learned patterns + optional paranoid mode. Placeholders replace identifiers; the LLM never sees the original values; responses are rehydrated locally.
A.7.4.8
Temporary files
Manage temporary files containing PII securely. Attachment extraction (Tika + Tesseract OCR for files) runs on the appliance; extracted text is sanitised in memory; no PII transits external networks; encrypted at rest with libsodium.
A.7.4.10
PII disposal
Dispose of PII when no longer required. Per-conversation deletion controls; audit log preserves cryptographic hashes of redacted values, not the values themselves, so retention of audit evidence does not retain the underlying PII.
A.7.5.3
Records of PII transfers
Maintain records when PII is transferred, including to processors. Hash-chained, append-only audit log records every prompt, every redaction decision, every external send, with provider name and timestamp. Database-level trigger enforces append-only; even root cannot silently rewrite history.
A.7.5.4
Records of PII disclosure to third parties
Record disclosures to processors and sub-processors. Same audit log; sub-processor (LLM provider) recorded per call; exportable as part of the Evidence Pack.
B.8.2
Processor's purposes
Process PII only for documented purposes. The appliance has no code path that retains or repurposes prompt content beyond the customer's documented use. Trinito-operated infrastructure never receives prompt content; daily check-in to the licensing server contains the appliance ID only.
B.8.6
Records of processing
Maintain records of processing activities under the controller's instructions. The same audit log doubles as the processor's GDPR Article 30 record of processing activities. Exportable in human-readable PDF and machine-readable CSV/JSON via the Evidence Pack.
B.9.2
Disclosures to third parties
Record each disclosure of PII to a third party. Audit log entry per external LLM call, including provider, model, and the hash of the sanitised prompt (so the record can be produced even though the content is not retained).
B.10.2
Return, transfer or disposal at end of processing
Return or delete PII at the end of the processing relationship. Appliance-side disposal; nothing is centrally retained by Trinito; on customer termination the device's data is the customer's to take or destroy.
B.10.3
PII transmission controls
Implement appropriate controls on PII transmission to third parties. This control is the entire product. Redaction + Pre-Send Preview + audit trail before any external transmission. Of all the 27701 controls, this is the one Trinito is, not just satisfies.
B.11.1, B.11.2
Subcontractor management
Inform the customer of subcontractors; obtain authorisation. Maintained sub-processor list at /security; customer chooses LLM provider per-prompt; bring-your-own keys mean Trinito is not a sub-processor on those routes.

What stays your responsibility

27701 is a management system standard. Some of it can be automated. Most of it cannot. The following obligations remain yours:

  • Management system clauses (5–10) — leadership, planning, support, performance evaluation, improvement. Policies, role assignments, training, internal audit.
  • A.7.2.1 Purpose & lawful basis identification — you decide why you are processing PII; Trinito records processing against that purpose.
  • A.7.3.x Subject rights handling — we provide the audit log and erasure tooling; you handle subject access requests and data-subject rights workflows.
  • B.8.1 Customer (data subject) agreement — contracts and consent capture are yours; we can ship a DPA template, but the signatures are not ours.
  • Risk assessment and DPIA — you do the assessment; we provide a DPIA template covering Trinito's data flows that you can use as a starting point.

Most enterprise customers will need a Data Protection Officer (internal or fractional) to run the management system. Trinito automates the technical evidence the DPO needs to do that job.

The Evidence Pack — one-click audit preparation

When your external ISO/IEC 27701:2025 auditor visits, Trinito will generate a signed ZIP from the appliance admin — typically covering a 90-day audit window — containing everything they ask for. The bundle is signed with the appliance's audit-log signing key so verification works offline, without Trinito's central infrastructure.

Contents of the pack:

  • README.pdf — appliance identity, audit window, software version, pack version, regeneration notes for the auditor
  • control-mapping.pdf — every 27701:2025 control we claim, mapped to Trinito controls and the evidence file that supports it
  • audit-log.csv and audit-log.jsonl — full hash-chained log for the window (timestamp, user, action, provider, model, chain hashes)
  • audit-log.sig — detached signature over the JSONL; public key in verification/
  • detection-accuracy-report.pdf — true-positive and false-negative rates per category from our adversarial fixture
  • sub-processors.pdf — sub-processor list pinned to the audit window with effective dates
  • cryptographic-posture.pdf — cipher suites, key sizes, TLS renewal log, rotation evidence
  • configuration-manifest.json — rule pack version, paranoid mode, per-org pattern counts (hashed, not values)
  • verification/ — README, public key, and a POSIX shell script to re-walk the hash chain without external dependencies

A MANIFEST.sha256 inside the ZIP lets an auditor verify individual files without re-extracting the whole bundle. Time-to-prepare for a 27701 audit drops from weeks to minutes — repeatable across audit cycles.

Available in the v1 release (Q3 2026). The control mapping on this page and hash-chained audit log export on the appliance are available today; the one-click Evidence Pack ZIP is in active development.

Where Trinito fits in a 27701 implementation

Implementing 27701 typically follows three phases. Trinito addresses Phase 2 almost entirely and provides evidence for Phase 3. Phase 1 remains yours and your DPO's.

  1. Phase 1 — Establish the management system (months 1–3). Policies, roles, training, risk assessment, Statement of Applicability for the controls you have selected.
  2. Phase 2 — Implement controls (months 3–6). Trinito addresses every technical control listed in the table above on day one. Other technical controls (encryption at rest, transmission, logging) you would otherwise procure separately come bundled.
  3. Phase 3 — Evidence and audit (months 6–12). The Evidence Pack produces the artefacts your external auditor will ask for in a format they can verify.

Total implementation time for a small PII processor typically drops from 9–12 months to 4–6 months when Trinito is in scope from the start.

Why the sanitiser stays in the path, even with a local LLM

The Sovereign tier runs LLMs locally on the appliance — sometimes inside a fully air-gapped network. A reasonable question follows: if the prompt never leaves the building, what is the sanitiser doing?

The short answer: local is not the same as inaccessible. Every prompt — local or remote — must enter the model's context window during inference. The context window is process memory in the inference engine. Inference engines (Ollama, llama.cpp, vLLM and the rest) additionally persist KV caches and conversation history to disk for performance. Anyone with appropriate access on the appliance — an administrative shell, a backup tape, another user account on a shared box — can read what was processed. Running the LLM locally reduces the LLM provider's access to zero. It does not reduce the appliance-side access surface.

The ISO/IEC 27701:2025 controls that govern internal access, records of processing, de-identification, and disposal therefore apply identically whether the model runs on the appliance or in a public cloud. Trinito's sanitiser is doing four pieces of work that the air-gap does not address:

Multi-user access governance

Sovereign appliances rarely ship to a single user. A practice, a chambers, or a regional office puts ten, twenty, fifty people on the same box. Not every user is authorised to see every other user's clients. Without the sanitiser, the prompt cache and the inference engine's conversation history become a shared exposure surface for all users with shell access. The sanitiser, paired with the hash-chained audit log, gives you per-user, per-prompt access governance — material for the SRA, GMC, ICO, and any client who asks "what data of mine did you handle?"

Records of processing for GDPR and 27701

A local LLM does not change the customer's legal position. UK GDPR Article 30 still requires records of processing. ISO/IEC 27701:2025 controls A.7.5.3, A.7.5.4, B.8.6 and B.9.2 still require evidence of every disclosure to a processor — the LLM is the processor, regardless of where it sits. The sanitiser pipeline generates the structured audit-log entries that satisfy these obligations. A local LLM with no sanitiser is a black hole for compliance evidence.

Protection of local model fine-tuning

A meaningful share of Sovereign customers want to fine-tune the local model on their own corpus. Fine-tuning without sanitisation bakes the customer's PII into the model weights. Documented training-data extraction attacks make this risk concrete, not hypothetical. Once an exported .gguf file leaves the appliance — backup, warranty return, share with another office — the PII goes with it permanently. Sanitising the fine-tuning corpus before training means placeholders enter the weights, not customer identifiers.

Defence against air-gap drift

Air-gapped deployments rarely stay air-gapped for the lifetime of the appliance. A temporary management network enabled for an OS upgrade and left on. A USB stick bridging the air-gapped network to the office network. A printer with WiFi enabled by default. The sanitiser is a second control that limits blast radius when the air-gap holds less perfectly than planned.

When the case is weaker — and what we offer

In a true single-user, never-fine-tuned, never-shared, never-backed-up, fully-verified-air-gapped deployment, the redaction value of the sanitiser is reduced. The audit-log and records-of-processing value remain. For these specific deployments we offer Audit-only mode (available from the Q4 2026 release): the sanitiser still runs to detect PII for the audit log, but the prompt continues to the local LLM unchanged. The mode requires explicit documented risk acceptance and is configured at deployment time.

The honest sales conversation for Sovereign starts with five questions:

  • Will more than one user share this appliance?
  • Will you fine-tune the local model on your own data?
  • Do you need to evidence GDPR Article 30 or ISO/IEC 27701:2025 records of processing?
  • Will you back up the appliance — or restore it — ever?
  • Is the air-gap permanent, monitored, and verified end-to-end?

If any answer is "yes" to the first four, or "no" to the last, the sanitiser is doing work that the air-gap alone cannot.

Summary version on the FAQ →

ISO/IEC 27701:2025 is how auditors verify GDPR Article 25

GDPR Article 25 requires "data protection by design and by default." The article tells you the obligation; it does not tell you what evidence satisfies it. The recognised answer is ISO/IEC 27701:2025: a stand-alone privacy management standard whose controls (Annex A and Annex B) are the auditable form of the abstract obligation Article 25 imposes.

Buy Trinito and you have implemented the technical controls. Implement the surrounding management system and you have evidence that will survive an ICO inspection.