ISO/IEC 27701:2025 compliance — Trinito automates the technical controls

What Trinito automates

Every row below maps a 27701:2025 control to the technical implementation in the appliance. Control descriptions are on the ISO Online Browsing Platform.

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 + 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 on the appliance (Apache Tika; Tesseract via Tika for images and scanned PDFs); 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 the fact of every prompt processed, every redaction decision, and every external send, with provider name, timestamp, and SHA-256 hashes of prompt and response content (the content itself is not retained in the log). 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 from the appliance admin.
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.5 Classification of PII	Classify PII according to type and sensitivity.	Document uploads carry a four-tier sensitivity label (Public, Internal, Confidential, Restricted). Auto-detection reads existing markings on the document; `detection_counts` from the sanitiser plus the assigned sensitivity give a per-document privacy-impact view. The audit log records what categories of PII each document contains and what sensitivity the customer assigned.
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 — including document upload, sanitiser detection, release decisions, and retrieval into prompts. Exportable in human-readable and machine-readable formats from the appliance.
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. When document chunks are retrieved into a chat sent to an external provider, a `document.retrieved_for_prompt` event records the document IDs and their sensitivities, paired with the `send.completed` event for the provider and model.
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.

Audit evidence on the appliance

The hash-chained audit log on the appliance records every sanitiser run, send authorisation, model routing decision, document upload, classification, and release action. Compliance teams export the log on demand — CSV and JSONL — and verify the chain offline with the appliance's published signing key.

What auditors typically ask for maps directly to what the box already produces:

Records of processing — timestamped events with user, action, provider, and cryptographic hashes of prompt content (not cleartext in the audit store)
Detection evidence — per-category counts on every sanitiser pass; document-library chip review and release decisions logged with admin attribution
Sub-processor traceability — which LLM provider and model handled each authorised send
Configuration posture — rule pack version, security policy settings, and verification tooling bundled with the appliance admin

The control mapping on this page describes how ISO/IEC 27701:2025 controls map to those runtime artefacts. Your external auditor verifies exports from hardware you own — without Trinito's central infrastructure in the path.

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.

Phase 1 — Establish the management system (months 1–3). Policies, roles, training, risk assessment, Statement of Applicability for the controls you have selected.
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.
Phase 3 — Evidence and audit (months 6–12). The hash-chained audit log and exports from the appliance produce 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 Solicitors Regulation Authority, the General Medical Council, the Information Commissioner's Office, 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 is what generates the structured audit-log entries that satisfy these obligations. A local LLM with no sanitiser is a black hole for compliance evidence: prompts go in, responses come out, nothing structured records what was processed for whom.

Protection of local model fine-tuning

A meaningful share of Sovereign customers want to fine-tune the local model on their own corpus — case notes, listings, candidate CVs. Fine-tuning without sanitisation bakes the customer's PII into the model weights. Documented training-data extraction attacks (Carlini et al., 2021 and follow-on work) 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. Inference rehydrates locally using the user's placeholder map at request time.

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. A backup-to-cloud script added by IT because they don't trust local hardware alone. The sanitiser is a second control that limits blast radius when the air-gap holds less perfectly than planned. The same principle that makes Tier-3 data centres encrypt their disks — even though the discs never leave the facility — applies here.

When the case is weaker — and what we offer

In deployments where a local model should receive original text for drafting quality while still recording detections, admins enable detection-only for local in /admin/security: the sanitiser runs on every prompt and writes the redacted copy to the audit trail; only the outbound call to the on-box local model uses the original text. Cloud-routed sends always use the sanitised version.

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.

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