Compliance alignment

This page maps CDC’s platform mechanisms onto the obligations a compliance, security, or due-diligence function is accountable for, principally GDPR and NIS2, and the kinds of questions a procurement or vendor-risk review asks. It is written for an evaluator who has to demonstrate, not just assert, that the controls exist. It restates the guarantees developed in the governance and audit model and the security posture and shows which obligation each one answers.

A framing note: CDC is a platform that provides the mechanisms for compliance. It does not make an organisation compliant on its own; that depends on how the organisation configures ownership, classification, regions, and access. What CDC offers is that the mechanisms are built into the runtime rather than bolted on, so the controls a regulator expects correspond to real, enforced behaviour rather than to policy documents.

GDPR alignment

Obligation	How CDC provides it
Accountable processing (Art. 5)	Every governed operation resolves to a real principal, captured immutably when a process instance starts and written into the audit trail alongside the process that ran. There is no “the platform did it”: always a who.
Data minimisation (Art. 5)	Egress is a decision, not a read: ownership, masking, and projection materialise into exactly the permitted view, so a consumer receives the minimum a policy allows rather than a raw store dump.
Security of processing (Art. 32)	Default-deny authorisation, mandatory authentication that fails closed, a write-only secret store, sensitive-field masking, and encryption of properties marked encrypted: the controls are covered in the security posture.
Right of access / portability (Art. 15, 20)	Governed data is a queryable catalogue of typed entities with full history; the governed read boundary is the controlled path for producing a subject’s data in a structured form.
Right to erasure (Art. 17)	The model lifecycle supports archiving and deleting governed data, with a referrer sweep that establishes what still depends on a model before it is removed, so erasure is a governed, dependency-aware operation rather than an ad-hoc delete.
Records of processing (Art. 30)	Lineage is a property of the runtime: for any governed record the platform can answer what happened, when, at whose request, under which decision, against which model version.
International transfer / localisation	Data sovereignty is enforced with defence in depth: each engine declares its region, and both the Master’s distribution gate and the engine’s own check fail closed, so regulated data cannot be processed outside its allowed region by a single misconfiguration.

NIS2 alignment

NIS2 raises the bar on risk management, accountability, and resilience for essential and important entities. CDC’s mechanisms map onto its core themes:

• Access control and least privilege. Authorisation is default-deny over a flat, closed, group-granted scope vocabulary; users hold access only through group membership and machine callers through service accounts held to least privilege. Access can be brokered to the corporate directory so joiner/mover/ leaver governance stays where it already lives (see the identity and authentication page).
• Logging and traceability. The two-phase audit keeps authorised and actually committed as distinct facts joined by a correlation identity, so the audit trail cannot silently diverge from reality: a decision with no matching outcome is itself a first-class, queryable signal. The trail is designed to be tamper-evident at record level, so alteration or reordering is detectable rather than assumed-away.
• Supply-chain and integration security. Source systems are reached only through isolated, versioned plugins whose credentials live in the secret store, never in configuration or process definitions; every governed movement crosses a standardised, audited boundary rather than an ungoverned side channel (see the integration story).
• Business continuity and resilience. Engine loss is handled automatically (reassignment and self-recovery of in-flight instances with no lost history), and Master loss queues and parks governed work rather than dropping it, with rejected ingest dead-lettered for replay. The resilience characteristics an incident-response plan needs to reference are in the deployment topology and scaling and production-operations runbook pages.
• Incident detection. Standards-based OpenTelemetry, anonymous health probes, broker-depth and dead-letter signals, and engine-heartbeat monitoring give the operational visibility detection and reporting obligations depend on (see the observability posture).

What a due-diligence review will find

The questions a vendor-risk or procurement review asks most often, and where the answer sits:

• “Can you prove who accessed what, and when?” Yes: every governed operation is attributable to an immutable principal with a correlation identity that ties the decision, the outcome, and the audit record together (governance and audit model).
• “Can the audit trail be tampered with?” It is designed to be tamper-evident at the granularity of a single record, so alteration, deletion, or reordering breaks the chain at that record.
• “What happens on uncertainty?” The platform fails closed: an unknown asset the Master cannot resolve is denied, and a misconfigured region contains data rather than leaking it. Uncertainty never resolves to allow.
• “How is sensitive data protected?” Classification is a model fact enforced everywhere the data moves: sensitive fields masked, encrypted fields protected in transit and at rest, exposure decided at the egress boundary (security posture).
• “How do you handle identity?” Standards-based OIDC/OAuth, brokered to the corporate directory so identity governance stays authoritative there (identity and authentication).
• “What is your recovery story?” Small, standard stateful surface (a PostgreSQL database as the single source of truth), stateless disposable workers, automatic engine recovery, and durable queuing on Master downtime (production-operations runbook).

What to take into an evaluation

• CDC provides the mechanisms for GDPR and NIS2 obligations built into the runtime; the organisation supplies the configuration (ownership, classification, regions, access design) that makes them effective.
• Accountability, minimisation, tamper-evident logging, sovereignty containment, and resilience each map onto a concrete, enforced platform behaviour rather than a policy statement.
• A due-diligence review’s hardest questions (attributable access, tamper- evidence, fail-closed behaviour, data protection, identity, and recovery) each have a specific mechanism behind them, cross-referenced above.