Compliance

What the architecture makes structural, what remains procedural, and what is missing.

Some compliance objectives are satisfied by how a system is shaped; others need an organisational programme on top. This page separates the two, and says plainly where the gaps are.

Structural

Own-infrastructure deployment turns several objectives from procedural commitments into architectural facts:

Objective	Why it becomes structural
Data residency	Data never leaves your chosen server, region or cloud account. Residency is inherent, not a configuration toggle
Data minimisation	The vendor processes only what it needs to operate and bill, and retains no content
Processor scope	Because content stays with you, the vendor's role is narrowly scoped — which simplifies the data-processing agreement
Encryption in transit and at rest	Tunnel plus mutual TLS in transit; disk plus box-held key at rest, with keys the vendor does not hold
Auditability	Every privileged action logged, credential-free

GDPR compliance is part shape, part programme. Chordian's architecture makes the shape strong; the programme — data-processing agreement, records of processing, subprocessor list — is an organisational commitment layered on top.

Area	Posture
Data residency (Chapter V)	On Secure Dedicated and own-infrastructure, content stays in the region you choose; a region-pinned deployment avoids an international transfer entirely
Inference locality	On the GDPR tiers, extraction, embeddings and chat are pinned to EU or self-hosted models — content is never sent to a non-EU provider
Data minimisation	The core platform processes only identity, billing and metadata; content lives in the memory tier you choose
Right of access / portability	Content and audit are retrievable through the API
Right to erasure	Whole-tenant purge is live, and on a dedicated or box tier erasure can be as concrete as deleting the box. Selective per-record erasure is not built yet
DPA & subprocessors	Provided as controlled documents through your account contact

The core platform meets a GDPR baseline for identity, billing and metadata. Secure Dedicated and own-infrastructure add regional residency, EU or self-hosted inference, and a narrower processor scope on top — the tiers to choose when a regulated workload needs residency by shape rather than by policy. GDPR is a per-memory choice: a customer who needs it runs that memory on a GDPR tier without forcing every workload onto regional infrastructure.

Post-quantum cryptography (PQC)

Transport is being hardened with hybrid post-quantum key exchange — TLS 1.3 negotiating X25519MLKEM768, combining classical X25519 with ML-KEM-768 (NIST FIPS 203). The hybrid construction stays safe even if one of the two algorithms is later broken, and it defends against "harvest-now, decrypt-later" — traffic captured today for decryption once a quantum computer exists. This is part of a phased cryptographic-resilience programme (FIPS 203 / 204).

Leg	PQC status
Client ↔ edge — key exchange	Verified — hybrid X25519MLKEM768 at the edge
Certificate signatures	Classical (ECDSA / RSA)
Edge ↔ origin (in-cluster)	Classical TLS; PQC roadmap
Secure Dedicated / box transport	PQC key exchange to the box — roadmap

PQC here means key exchange at the edge — not "post-quantum encryption at rest", not certificate signatures, and not the in-cluster or box legs. Claim the edge key-exchange leg only — never "end-to-end" or "quantum-safe everywhere".

Control mapping

Criterion	Posture	Notes
Security	Strong	Encryption, tenant isolation, RBAC, audit, gateway
Confidentiality	Strong	Encryption at rest and in transit, perimeter, sovereignty
Availability	Partial	Health probes and orchestration in place; formal SLO and disaster-recovery documentation outstanding
Processing integrity	Partial	Idempotency, audit and reconciliation in place; formal documentation partial
Privacy	Partial	Selective erasure not built

Gaps, stated plainly

Do not build a compliance programme around these until they land.

No SOC 2 Type 2 attestation. The control mapping exists and the controls are real. The audit is an organisational programme that has not been completed. SOC 2 is not something code can produce.
No HIPAA BAA.
No selective right-to-erasure. Whole-tenant purge exists; per-record erasure does not. This is the most commonly requested missing control, and the honest answer is that it is on the roadmap.
No formal DR/RPO/RTO documentation or published backup-restore evidence.
Backup and restore for a memory box is not built. For an own-infrastructure deployment, backup is currently your responsibility. This matters and is called out here rather than buried.

Subprocessors

Model inference, email delivery, payments and cloud infrastructure involve third parties. Request the current subprocessor list through your account contact — it is maintained as a controlled document rather than published here, so that it cannot drift out of date on a docs page.

In bring-your-own-model mode, inference does not touch a Chordian subprocessor: content reaches only the provider you already have a relationship with.

Claim guardrails

For anyone writing about Chordian externally:

Claim	Permitted for
"Data never leaves your infrastructure"	Own-server and own-cloud deployments only
"Air-gapped install"	Own-infrastructure, validated
"Air-gapped processing"	Own-infrastructure in bring-your-own or in-box model mode only
"Encrypted at rest and in transit"	All tiers
"Tenant isolation enforced on every query"	All tiers
"Hybrid post-quantum key exchange at the edge"	Verified at the TLS edge — key exchange only
"GDPR regional data residency"	Secure Dedicated and own-infrastructure only
"End-to-end post-quantum transport" / "quantum-safe everywhere"	Nobody. In-cluster, box and signature legs are roadmap
"SOC 2 certified"	Nobody. Not yet true
"GDPR right to erasure supported"	Nobody. Not yet built