GDPR Compliance

CRAFT is designed to support organizations in meeting their obligations under the General Data Protection Regulation (GDPR). This page covers data handling, Right to Be Forgotten (RTBF) implementation, audit logging, and data residency controls.

CRAFT provides the technical mechanisms for GDPR compliance. Organizations are responsible for configuring and operating the platform in accordance with their specific GDPR obligations, Data Protection Impact Assessments (DPIAs), and legal counsel.

Data Processing Principles

The platform implements GDPR’s data processing principles at the architecture level:

Principle	Implementation
Lawfulness	Platform enforces authenticated access controls; deploying organizations must establish and document their Article 6 lawful basis (e.g., legitimate interests, contract performance, consent) for each processing activity in their Records of Processing Activities (RoPA)
Purpose limitation	Data connections are scoped to specific projects with defined purposes
Data minimization	Agent Cards apply data minimization to provider contact information
Accuracy	Audit logs record all data modifications with timestamps
Storage limitation	Configurable retention policies per tenant and data type
Integrity and confidentiality	Encryption at rest (AES-256) and in transit (TLS 1.2 minimum)
Accountability	Immutable audit logs with full traceability

Personal Data Inventory

The platform processes the following categories of personal data:

Category	Location	Sensitivity	Purpose	Suggested Lawful Basis
User identity (email, name)	Keycloak realms	Restricted	Authentication	Contract performance or legitimate interests
User IP address	Audit logs	Restricted	Security monitoring	Legitimate interests
User agent string	Audit logs	Internal	Debugging	Legitimate interests
Agent Card provider contact	Assets database	Confidential	Agent registration	Contract performance
Session data	Redis, PostgreSQL	Confidential	Multi-turn conversations	Contract performance
Query results	Solution databases	Confidential	Data analytics	Determined by organization based on data source

The “Suggested Lawful Basis” column provides guidance only. Organizations must confirm the lawful basis for each processing activity in their specific deployment context and document it in their Records of Processing Activities (RoPA).

Right to Be Forgotten (RTBF)

The platform implements RTBF using crypto-shredding — destroying the encryption key rather than locating and deleting every instance of the data.

How Crypto-Shredding Works

PII fields are encrypted per principal

When audit log entries are created, PII fields (actor identity, ip_address) are encrypted using a per-principal encryption key.

RTBF request is received

An administrator or the data subject initiates an RTBF request via the Governance API.

Encryption key is destroyed

The principal’s encryption key is permanently deleted. Without the key, encrypted fields become unrecoverable.

Audit trail is preserved

The audit log entry structure is preserved (action, resource_type, resource_id, timestamp, trace_id), but the actor field displays [REDACTED].

Data Deletion Matrix

When an RTBF request is processed, data is deleted across all storage systems:

Storage	Action	Timing
PostgreSQL	Hard-delete rows from all tables	Immediate
OpenFGA	Delete authorization relationship tuples	Immediate
Object storage	Delete skill package artifacts	Immediate
Redis	Invalidate cached entries	Immediate
Event bus (Redis Streams)	Events are ephemeral (7-day retention)	No action needed beyond retention expiry
WAL/PITR backups	Backup retention must not exceed RTBF compliance deadline	Per backup retention policy
Operational logs	PII limited to tenant_id and actor; 90-day max retention	Retention-based expiry

WAL and PITR backups may contain personal data. GDPR controllers have one month to respond to RTBF requests (extendable by two months for complex cases under Art. 12(3)). Recommended maximum backup retention is 30-90 days to stay within RTBF response obligations. The default infrastructure configuration retains 7 daily backups with 7-day transaction log retention. Long-term backups containing personal data require either crypto-shredding capability or documented justification under Art. 17(3) exemptions.

Audit Logging

Every state-changing operation produces an immutable audit entry:

Field	Type	Description
`id`	ULID	Unique entry identifier
`tenant_id`	string	Tenant scope
`action`	string	e.g., `agent.register`, `agent.approve`, `policy.update`
`actor`	string	Authenticated principal (encrypted with per-principal key)
`actor_type`	enum	USER, SERVICE_ACCOUNT, SYSTEM
`resource_type`	string	Target resource type
`resource_id`	string	Target resource identifier
`timestamp`	timestamp	When the action occurred
`details`	JSONB	Old/new values, approval comments, policy violations
`ip_address`	string	Client IP (encrypted with per-principal key)
`trace_id`	string	OpenTelemetry trace ID for end-to-end correlation

Audit Log Properties

Append-only: No updates or deletes in normal operation
Retention: Configurable per tenant (default 1 year; extended retention only where required by specific regulation, e.g., financial record-keeping)
Export: GET /governance/admin/audit-logs?format=csv for compliance reporting
SIEM integration: Forward to Splunk, Datadog, or SIEM via OpenTelemetry Collector (customer-configurable exporters)
Filterable: By actor, action, date range, and resource

Breach Notification

GDPR Article 33 requires that in the event of a personal data breach, the controller must notify the competent supervisory authority without undue delay and, where feasible, no later than 72 hours after becoming aware of it. Article 34 requires notification to affected data subjects where the breach is likely to result in a high risk to their rights and freedoms. The platform supports breach detection and timely reporting through:

SIEM integration: Real-time forwarding of security events via OpenTelemetry Collector for anomaly detection
Audit log analysis: Identify unauthorized access patterns via audit log queries and export
OpenTelemetry alerting: Configure alerts for unusual access patterns (high volume queries, off-hours access, privilege escalation)
Trace correlation: trace_id in audit logs enables end-to-end investigation of suspected breaches

Organizations must establish their own breach notification procedures, including designated contacts for supervisory authority notification, internal escalation chains, and data subject communication templates. The platform provides detection and evidence tools, not the notification process itself.

Data Residency

For GDPR Article 44-49 compliance (international data transfers):

Region labels: Each tenant is tagged with a data residency region (EU, US, APAC, custom)
Geo-fenced storage: Database partitioning by region ensures EU data stays in EU
Regional API endpoints: Optional per-region API gateway routing (e.g., eu.platform.example.com)
Cross-region search: Federated queries can span regions only with explicit opt-in
Data location attestation: API endpoint returns storage location metadata per entity

Legal Transfer Mechanisms

Technical geo-fencing alone does not constitute GDPR-compliant transfer controls. Cross-border data flows require a valid legal transfer mechanism under GDPR Chapter V:

Standard Contractual Clauses (SCCs) (Art. 46(2)(c)) — the most common mechanism for international transfers
Adequacy decisions (Art. 45) — transfers to countries with an adequate level of data protection
Binding Corporate Rules (Art. 47) — for intra-group international transfers

Organizations should review their Data Processing Agreements (DPAs) with cloud providers to ensure EU-standard protections for transferred data, including appropriate SCCs.

GDPR Right	Platform Mechanism
Right of access (Art. 15)	Audit logs and data export APIs. Organizations must respond to DSARs within one month of receipt (Art. 12(3)), extendable by two months for complex requests
Right to rectification (Art. 16)	Standard CRUD APIs for data correction
Right to erasure (Art. 17)	Crypto-shredding + data deletion matrix
Right to restrict processing (Art. 18)	Tenant-level freeze / per-resource access controls
Right to data portability (Art. 20)	JSON/CSV export APIs
Right to object (Art. 21)	Organizations must implement a process to receive and act on individual objection requests. Platform supports per-user processing restrictions via access controls. Tenant-level processing settings provide additional scope controls

Data Protection Impact Assessment (DPIA)

When deploying the platform for processing personal data, consider the following for your DPIA:

Data flows

Map the flow of personal data through the platform: authentication tokens, audit logs, data connections, query results, and agent interactions. Identify which components process personal data and the legal basis for each.

Data minimization

Configure the platform to collect only the data necessary for your use case. Disable anonymous access logging if not needed. Configure audit log retention to the minimum required period.

Third-party processors

If using cloud-managed services (Cloud SQL, RDS, Azure Database), ensure your Data Processing Agreement (DPA) with the cloud provider covers the data being processed. If using cloud-based LLM APIs, a DPA with the LLM provider is required.

High-risk processing scenarios

A formal DPIA is mandatory under Art. 35 for processing likely to result in high risk, including: systematic profiling, large-scale processing of sensitive data (e.g., healthcare via Data Insights), and automated decision-making. Engage your Data Protection Officer (DPO) per Art. 37 in reviewing the DPIA, and consult your supervisory authority under Art. 36 if residual risk remains high after mitigation.

Compliance Reporting

The platform provides compliance reports via the admin API:

Report	Content
Data processing inventory	All data connections, their purposes, and access patterns
Access review	All users and their permissions per tenant
Audit trail export	Full audit log for a specified date range
RTBF confirmation	Confirmation of data deletion across all storage systems

Next Steps

SOC 2 Controls

See how the platform maps to SOC 2 Trust Service Criteria.

HIPAA Compliance

Review HIPAA compliance considerations for healthcare deployments.

Data Classification

Understand data classification levels and encryption requirements.

Backup & Restore

Configure backup retention to align with GDPR requirements.

​GDPR Compliance

​Data Processing Principles

​Personal Data Inventory

​Right to Be Forgotten (RTBF)

​How Crypto-Shredding Works

​Data Deletion Matrix

​Audit Logging

​Audit Log Properties

​Breach Notification

​Data Residency

​Legal Transfer Mechanisms

​Consent and Access Controls

​Data Protection Impact Assessment (DPIA)

​Compliance Reporting

​Next Steps

SOC 2 Controls

HIPAA Compliance

Data Classification

Backup & Restore

Data Processing Principles

Personal Data Inventory

Right to Be Forgotten (RTBF)

How Crypto-Shredding Works

Data Deletion Matrix

Audit Logging

Audit Log Properties

Breach Notification

Data Residency

Legal Transfer Mechanisms

Consent and Access Controls

Data Protection Impact Assessment (DPIA)

Compliance Reporting

Next Steps