GDPR compliance guide

How EuroRAG helps you, the controller, meet GDPR obligations: data-subject rights as endpoints, deletion cascades, the 11 live compliance checks, and EU provider hierarchy.

GDPR compliance guide

EuroRAG is designed with GDPR compliance as a core principle. This guide explains how the application handles GDPR requirements and what you need to consider when deploying.

Disclaimer: This guide provides technical information about GDPR compliance features. It does not constitute legal advice. Consult with legal counsel for specific GDPR compliance requirements.

GDPR principles implemented

1. Lawfulness, fairness, and transparency

• Consent on registration: Users must explicitly consent to data processing during registration
• Clear privacy policy: Document what data is collected and how it's used
• Transparent data usage: Users can view all data stored about them

Implementation: - Registration requires consent_given checkbox - User profile shows consent date - Data export endpoint provides full transparency

2. Purpose limitation

• Specific use cases: Data is collected only for RAG chat functionality
• No secondary use: User data is not used for marketing or sold to third parties

Implementation: - All data serves the core RAG functionality - No analytics or tracking beyond what's necessary

3. Data minimization

• Only necessary data: Only email, name (optional), and chat history stored
• Automatic cleanup: Old data is automatically deleted based on retention policy

Implementation: - DATA_RETENTION_DAYS setting controls automatic cleanup - Compliance service deletes old chat sessions and documents - Users can customize their retention period

4. Accuracy

• User control: Users can edit their profile and delete their account
• Data export: Users can export all their data in JSON or ZIP format

Implementation: - Profile update endpoint - Account deletion with cascade delete - Data export endpoints (/api/users/me/export)

5. Storage limitation

• Configurable retention: Data is not stored indefinitely
• User control: Users can set their own retention period (30–3650 days)

Implementation: - data_retention_days field in User model - Compliance service enforces retention - Admin can configure system-wide default

6. Integrity and confidentiality

• Encryption: Passwords are hashed with bcrypt
• Secure sessions: Server-side session tokens with secure cookies
• HTTPS: Production deployment uses SSL/TLS

Implementation: - bcrypt for password hashing - Session-based authentication with SECRET_KEY for cookie signing - HttpOnly, Secure cookie flags in production - SSL recommended for production - SINGLE_SESSION_MODE revokes all existing sessions on new login

7. Accountability

• Audit logging: All data access is logged with timestamps
• User actions: User actions (upload, chat, delete) are tracked
• Admin actions: Admin actions are logged

Implementation: - AuditLog model tracks all operations including: user.register, user.login, user.logout, user.delete, user.password_change, document.upload, document.delete, chat.query, admin.create_user, admin.update_user, admin.delete_user, admin.update_settings, admin.update_retention, source.create, source.update, source.delete, source.sync - Chat queries are audited via BackgroundTask after streaming completes; only metadata is logged (query length, session id, model), never the query text - Admin dashboard shows audit history - Configurable AUDIT_LOG_RETENTION_DAYS

Data subject rights

Right to access (Article 15)

Users can request a copy of all personal data stored about them.

API Endpoint: GET /api/users/me/export

Response Format:

{
  "export_date": "2024-01-26T17:00:00Z",
  "user": {
    "id": "...",
    "email": "...",
    "full_name": "...",
    ...
  },
  "chat_sessions": [...],
  "documents": [...],
  "data_sources": [...]
}

Export Options: - JSON: GET /api/users/me/export/json - ZIP (with documents): GET /api/users/me/export/zip

Right to rectification (Article 16)

Users can correct inaccurate personal data.

API Endpoint: PUT /api/users/me

Editable Fields: - full_name: Display name - data_retention_days: Personal retention preference

Consent withdrawal (Article 7.3)

Users can withdraw consent via PUT /api/users/me with {"consent_given": false}. This:

1. Sets consent_given = false on the user record
2. Deactivates the account (is_active = false)
3. Logs the change in the audit trail

Re-granting consent (consent_given: true) reactivates the account. Both operations are audited.

Right to erasure (Article 17)

Users can request deletion of all personal data.

API Endpoint: DELETE /api/users/me

Behavior: - Cascade delete: Removes user, chats, documents, data sources - Vector data: Removed from ChromaDB - BM25 index: User entries removed - Disk: Physical files deleted - Audit log: Deletion is logged

Complete erasure (soft-delete purge)

Documents are soft-deleted immediately (hidden from users). After a 30-day grace period, a scheduled job permanently erases them from all storage layers:

• Database records (hard delete)
• ChromaDB vectors
• BM25 search index entries
• Files on disk

The purge runs daily at 4:00 AM. The 30-day grace period allows recovery from accidental deletion.

Right to restrict processing (Article 18)

Users can object to processing of their personal data.

Implementation: - Users can deactivate their account - Admin can deactivate users - Deactivated users cannot access the system

Right to data portability (Article 20)

Users can receive their data in a structured format.

Implementation: - JSON export provides machine-readable format - Can be imported into other systems - Includes all related data (chats, documents, sources)

Right to object (Article 21)

Users can object to automated processing.

Implementation: - Users can disable RAG and use direct LLM queries - Users can delete specific chat sessions - Users can delete specific documents

Password reset

Password reset tokens are delivered via email when SMTP is configured. Without SMTP (development environments), the token is returned in the API response. Configure SMTP settings in .env for production deployments.

Data controller responsibilities

Security measures

Breach notification

Your responsibility: - Admin dashboard provides system status and audit log export - You must implement your own breach notification procedures - Configure monitoring and alerting for your deployment

Live compliance verification

The admin dashboard (/admin/compliance) runs 11 real-time checks against your deployment:

1. Consent Enforcement: no active users without consent
2. Consent Withdrawal: withdrawn users are deactivated
3. Right to Access: data export endpoint operational
4. Right to Rectification: profile update endpoint operational
5. Right to Erasure: deletion cascade functional
6. Data Portability: JSON/ZIP export endpoints operational
7. Audit Logging: enabled and recording recent entries
8. EU Data Residency: Strict EU Mode + provider compliance
9. Data Retention: enforcement scheduler running on schedule
10. Complete Erasure: soft-delete purge running on schedule
11. Data Source Compliance: all active sources GDPR-compliant

Each check returns evidence (e.g., "Last audit entry: 3m ago, 847 total entries") and a verified timestamp. The compliance score is calculated from live results, not a static badge.

Data Protection Impact Assessment (DPIA)

For Production: - Document your DPIA - Consider: - Scale of processing - Nature of data - Likelihood of breach - Impact on individuals - Mitigation measures

EU data residency

Provider hierarchy

EuroRAG prioritizes EU-compliant providers. STRICT_EU_MODE=true (default) allows only providers in the "Allowed" tier.

Providers 1–5 are EU-headquartered and not subject to the US CLOUD Act. With STRICT_EU_MODE=true (the default), non-EU providers are blocked at startup: the app validates provider configuration when it boots and refuses to start with a non-compliant provider. Custom OpenAI-compatible endpoints are blocked unless you explicitly declare them EU-compliant with CUSTOM_PROVIDER_GDPR_COMPLIANT=true.

Custom providers

When using API_PROVIDER=custom, you must explicitly declare GDPR compliance:

API_PROVIDER=custom
API_BASE_URL=https://oai.endpoints.kepler.ai.cloud.ovh.net/v1
CUSTOM_PROVIDER_GDPR_COMPLIANT=true
CUSTOM_PROVIDER_NAME=OVHcloud
CUSTOM_PROVIDER_REGION=EU (France)

STRICT_EU_MODE=true blocks custom providers unless CUSTOM_PROVIDER_GDPR_COMPLIANT=true is set. The compliance dashboard shows custom providers as "Operator-verified."

Data source compliance

Configuration checklist

Required settings

# Security
SECRET_KEY=<generate-random-32-char-key>
SESSION_EXPIRE_HOURS=24

# GDPR
STRICT_EU_MODE=true
DATA_RETENTION_DAYS=365
AUDIT_LOG_ENABLED=true
AUDIT_LOG_RETENTION_DAYS=90

# Database
DATABASE_URL=sqlite+aiosqlite:////data/app.db
# PostgreSQL: postgresql+asyncpg://user:pass@db:5432/eurorag

Optional settings

# File Storage
UPLOAD_DIR=/data/uploads
MAX_FILE_SIZE_MB=50

# Rate Limiting
RATE_LIMIT_ENABLED=true
RATE_LIMIT_PER_MINUTE=60

# CORS
CORS_ORIGINS=https://your-domain.com

# Session Management
SINGLE_SESSION_MODE=false

Deployment considerations

Self-hosted (recommended)

Pros: - Full data control - No third-party data sharing - Complete GDPR compliance control - No subscription costs

Cons: - Requires server management - Need to handle backups - Responsible for security updates

Cloud services

Considerations: - Verify provider's GDPR compliance - Check data center locations - Review data processing agreement - Understand subprocessor relationships

Compliance checklist

Before launch

• [ ] Privacy policy created and published
• [ ] Terms of service created and published
• [ ] Cookie policy (if using cookies)
• [ ] DPIA completed (if required)
• [ ] Data protection officer appointed (if required)
• [ ] Breach notification process documented
• [ ] User consent mechanism tested
• [ ] Data export functionality tested
• [ ] Account deletion tested
• [ ] Audit logging verified
• [ ] Security audit completed

Ongoing

• [ ] Monitor for security vulnerabilities
• [ ] Review and update privacy policy
• [ ] Handle data subject requests promptly (within 1 month)
• [ ] Maintain audit logs for retention period
• [ ] Regular security training
• [ ] Backup testing and verification

Common GDPR scenarios

User requests data export

Process: 1. User authenticates 2. Calls GET /api/users/me/export 3. System compiles all user data 4. Returns JSON or ZIP file 5. Action is logged in audit log

Response time: Within 1 month (Article 12)

User requests account deletion

Process: 1. User authenticates 2. Calls DELETE /api/users/me 3. System performs cascade delete: - User record - Chat sessions and messages - Documents - Data sources - Vector embeddings - BM25 index entries - Physical files on disk 4. Confirmation returned 5. Action logged in audit log

Response time: Without undue delay (Article 12)

User requests data correction

Process: 1. User authenticates 2. Calls PUT /api/users/me with corrections 3. System updates user profile 4. Changes logged in audit log

Response time: Within 1 month (Article 12)

Your responsibilities as data controller

EuroRAG provides the technical infrastructure. These organizational measures are your responsibility:

Required documents

• Privacy Policy: inform users how their data is processed (Articles 13–14)
• Data Processing Agreements (DPAs): with your LLM provider (Mistral, OpenAI, etc.), hosting provider, and any sub-processors
• Data Protection Impact Assessment (DPIA): if processing personal data at scale. See EDPB DPIA guidance
• Record of Processing Activities (Article 30): document what data you process, why, and for how long. A template is provided below.

Required procedures

• Breach notification: you must notify your supervisory authority within 72 hours of discovering a breach (Article 33). EuroRAG provides audit logs and data export to support investigation, but the notification procedure is yours to implement.
• Data subject request handling: EuroRAG provides the API endpoints for access, export, deletion, and rectification. You need a process for receiving and responding to requests within the 1-month deadline (Article 12).
• Sub-processor management: maintain a list of all services that process personal data on your behalf (hosting provider, LLM API provider, etc.).
• DPO appointment: if required by Article 37, designate a Data Protection Officer and publish their contact details.

Encryption

• At rest: Enable disk encryption on your server (LUKS on Linux, BitLocker on Windows). EuroRAG stores documents and database files unencrypted on the filesystem; disk-level encryption covers this.
• In transit: Use a reverse proxy (nginx, Caddy, Traefik) with TLS/HTTPS in production. EuroRAG does not terminate TLS itself.

Article 30: Record of Processing Activities (template)

International transfers

When STRICT_EU_MODE=true (default), EuroRAG blocks non-EU LLM providers at startup (validated at boot). If you disable strict mode to use OpenAI or Groq, you are responsible for establishing appropriate transfer safeguards (Standard Contractual Clauses or an adequacy decision).

Limitations

What EuroRAG does NOT provide:

• Legal advice on GDPR compliance
• Automated DPIA generation
• Breach notification email service
• Data processing agreements
• Cookie consent management (if using cookies)

Resources

• GDPR Official Text
• EDPB Guidelines
• Article 29 Working Party
• ICO Guide

Support

For GDPR-related questions or concerns: - Review the codebase for implementation details - Consult with legal counsel - Contact relevant data protection authority