Security & compliance
Security & compliance
The data-protection and GDPR machinery built into the platform — how personal data is protected, how subject rights are served, and how every privileged action is recorded.
- Regulation
- GDPR · EU 2016/679
- Encryption
- Per-tenant AES-256-GCM
- Status
- Built & demoable
Foundations
What everything is built on
Seven commitments that hold across every screen that follows. The features are how they’re kept.
- P1
PII never leaves in cleartext
Personal data is tokenized before any external model sees it, and restored on the way back. Nothing sensitive crosses the tenant boundary in the clear.
- P2
Encryption is per-tenant
AES-256-GCM with keys derived per tenant and per purpose. One tenant’s key cannot read another’s data — enforced by the cipher, not by policy.
- P3
Actions are on an immutable trail
The audit log is append-only at the database level. Entries can be added, never edited or quietly removed.
- P4
Trust-boundary writes re-check the role
Admin actions re-read the actor’s role from the database at the moment of the write, never from a cached session.
- P5
Erasure means the data is gone
Right-to-erasure deletes the subject’s records and PII mappings, drops key material where it applies, and leaves a dated proof certificate.
- P6
Retention is enforced, not aspirational
Windows are applied by scheduled jobs that purge aged data automatically — and every auto-deletion is itself audited.
- P7
Data isolation is the default
Each tenant’s data lives in its own directory. Access, export and erasure are scoped to that boundary by construction.
Data minimisation
PII protection & detection
Before a message reaches any external language model, sensitive entities are detected and swapped for stable tokens; the real values are restored in the reply.
Instance → PII protection · master switch, regex + NLP layers, backend health, confidence threshold, allowlist, per-entity control.
- Art 5(1)(c)
- Art 25
- Art 32
Data minimisation, protection by design, and security of third-party disclosure.
- Reversible tokenization — the same entity maps to the same token within a conversation, preserving context without exposing the value.
- Two detection layers — a built-in regex pass (emails, phones, cards, IBANs) plus an NLP pass for names, places and organisations.
- Pluggable backend — Microsoft Presidio ships as default; an alternative detector swaps in without touching the pipeline.
- Fails safe — if NLP is unreachable, detection degrades to regex-only and records that it did.
- Audited without exposure — operations log entity counts and types, never the values.
Accountability
Audit log
A complete, filterable, append-only record of every privileged action — who did what, to which resource, and when. Exportable for reporting and tamper-evident on the way out.
Instance → Audit log · filter by actor, action, resource and date range; paginated; export to signed CSV / JSON.
- Art 5(2)
- Art 30
- Art 33(5)
Accountability, records of processing, and breach-investigation documentation.
- Append-only by construction — enforced in the database; entries cannot be updated or deleted in place.
- Filter & paginate — by actor (name, email or id), action, resource type and date range.
- Tamper-evident export — CSV / JSON behind a signed, time-limited URL that can be verified after the fact.
- No PII in the trail — the log and its export carry metadata only.
- System actions included — retention purges, key rotations and breach signals sit alongside human actions.
Access control
Roles & permissions
Access is governed by a role-to-permission matrix, split between instance-wide and per-workspace powers, with per-user overrides. The admin role can’t lock itself out.
Instance → RBAC · instance- and workspace-scoped matrices; the admin RBAC-config cell is locked; every edit is audited.
- Art 5(1)(f)
- Art 32(1)(b)
Integrity and confidentiality through access control proportionate to risk.
- Least privilege by role — four roles over a fixed catalogue of permissions.
- Instance vs workspace split — tenant-wide and per-workspace powers are separate partitions; an edit to one can’t leak into the other.
- Per-user overrides — grant or revoke a single permission for one person on top of their role.
- Lockout protection — RBAC-config cannot be removed from the admin role; the server rejects the attempt.
- Live re-authorisation — every change re-reads the editor’s role and writes a before→after audit row.
Data subject rights
Access, portability, erasure & rectification
The full data-subject-rights suite, end to end — each request carries its statutory due date, erasure is approval-gated and irreversible, and a completed erasure leaves a signed proof certificate.
Compliance → Data subject rights · Article 12 due dates, approval-gated erasure, and the erasure proof certificate.
- Art 12
- Art 15
- Art 16
- Art 17
- Art 20
Transparent, timely handling of access, rectification, erasure and portability.
- Access vs portability, kept distinct — Art 15 returns everything held; Art 20 returns the machine-readable, subject-provided subset.
- The one-month clock is visible — each request shows its Art 12(3) due date; a complex-case extension is recorded and audited.
- Secure delivery — exports ride a signed URL that expires; request, generation and download are audited.
- Erasure with proof — request → approval → execution deletes records, mappings and key material, and emits a dated certificate.
- Rectification — correct a subject’s fields with a full before→after trail.
Retention & records
Retention, consent & processing records
Retention windows purge aged data on a schedule, consent is recorded with its legal basis and a withdrawal path, and the Article 30 register of activities and sub-processors is kept on the record.
Compliance → Retention & records · per-category windows, consent with legal basis, sub-processor register, and the ROPA table.
- Art 5(1)(e)
- Art 6
- Art 7
- Art 30
- Art 28
- Art 35
Storage limitation, lawful basis, records of processing, processor governance, DPIA.
- Scheduled auto-purge — per-category windows enforced by durable jobs; default audit retention is one year.
- Audited deletion — even policy deletion of the append-only log goes through one guarded, audited path; un-guarded deletes are still rejected.
- Consent with legal basis — purpose, Art 6 basis and timestamp per activity, plus a withdrawal flow and audit trail.
- Records of processing — an Art 30 register and an approved sub-processor list (LLM, observability, shared services), with a DPIA hook.
Encryption & breach
Encryption keys & breach response
Per-tenant encryption keys rotate as a durable job, rate-limit posture is shown for the record, and a confirmed breach starts the Article 33 72-hour notification clock with a tracked response checklist.
Instance → Security · per-purpose key rotation with live status, read-only rate-limit posture, and the Art 33 breach countdown.
- Art 32
- Art 33
- Art 34
Security of processing, breach notification, and communication to affected subjects.
- Key rotation on demand — per-tenant, per-purpose keys; rotation is durable, resumable and version-stamped, so old and new coexist during transition.
- Crypto-shredding — dropping key material can render an artifact unrecoverable; the mechanism behind erasure of encrypted data.
- Breach detection — anomaly signals (repeated auth failures, rate-limit spikes, unusual access) raise a candidate.
- The 72-hour clock — a confirmed breach stamps a deadline; the surface shows time remaining and flags a breach, recording any late-notice reason.
- Response workflow — assess → contain → notify, each transition dated and audited; admin alerted in-app and, where configured, by email.
Coverage
GDPR coverage at a glance
How the built features map to the obligations. “Built” means shipped and demoable; the one open item is listed honestly.
| Obligation | Articles | How it’s met | Status |
|---|---|---|---|
| Data minimisation & protection by design | 5(1)(c) · 25 | Reversible PII tokenization before external-model disclosure | Built |
| Security of processing | 32 | Per-tenant AES-256-GCM, rotation, RBAC, rate limiting | Built |
| Accountability & records | 5(2) · 30 | Append-only audit log + processing-activity register | Built |
| Right of access & portability | 15 · 20 | Portable export, access/portability split, signed delivery | Built |
| Rectification & erasure | 16 · 17 | Approval-gated erasure with proof certificate + crypto-shred | Built |
| Timely response | 12(3) | One-month due date on every request, audited extension | Built |
| Storage limitation | 5(1)(e) | Per-category retention windows with audited auto-purge | Built |
| Lawful basis & consent | 6 · 7 | Consent records with legal basis + withdrawal flow | Built |
| Processor governance & DPIA | 28 · 35 | Sub-processor register with approval; DPIA record hook | Built |
| Breach notification | 33 · 34 | Candidate detection, 72-hour clock, response workflow | Built |