> ## Documentation Index
> Fetch the complete documentation index at: https://docs.emergence.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# GDPR Compliance
> How CRAFT supports GDPR compliance with data handling, Right to Be Forgotten, audit logging, and data residency controls.
# 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
When audit log entries are created, PII fields (`actor` identity, `ip_address`) are encrypted using a per-principal encryption key.
An administrator or the data subject initiates an RTBF request via the Governance API.
The principal's encryption key is permanently deleted. Without the key, encrypted fields become unrecoverable.
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.
## Consent and Access Controls
| 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:
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.
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.
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.
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
See how the platform maps to SOC 2 Trust Service Criteria.
Review HIPAA compliance considerations for healthcare deployments.
Understand data classification levels and encryption requirements.
Configure backup retention to align with GDPR requirements.