1. Confidentiality (Art. 32(1)(b) GDPR)

1.1 Physical Access Control

Measures to prevent unauthorized persons from gaining physical access to data processing facilities:

• Physical infrastructure is operated exclusively in ISO 27001 certified data centers in Germany (primary) and Finland (secondary)
• Data centers feature 24/7 security personnel, biometric access controls, and video surveillance
• GraphCapsule employees have no physical access to servers; administration is performed exclusively via encrypted remote connections

1.2 System Access Control

Measures to prevent unauthorized use of data processing systems:

• SSH access to servers exclusively via key-based authentication (password login disabled)
• Network access through OPNsense firewall with strictly defined rule sets (only required ports)
• Mandatory VPN for all administrative access to the production environment
• Encrypted communication (TLS 1.3) for all data transmissions
• Rate limiting on authentication endpoints (max. 10 requests per 5 minutes for login/registration) and automatic temporary account lockout after repeated failed attempts
• JWT-based authentication with short-lived access tokens (15-minute expiry) and session-bound refresh tokens

1.3 Data Access Control

Measures to ensure that only authorized persons can access data:

• Role-based access control (RBAC) with four levels: Owner, Admin, Member, Read-Only
• Over 20 granular permissions (tenant, users, provider, backup, restore, search, billing, audit, compliance)
• Strict tenant isolation at the database level via Prisma extension with automatic filtering by tenant ID (26+ models)
• Cross-tenant data access is prevented by design through automatic database-level tenant filtering on all application queries. System-level administrative access requires explicit override and is restricted to authorized operational processes.
• Scoped Admin Roles (Enterprise): restricted administrator privileges per department/region

1.4 Separation Control

Measures to ensure that data collected for different purposes is processed separately:

• Logical tenant separation at the database level (each record is assigned to a tenant ID)
• Automatic tenant filtering via AsyncLocalStorage-based middleware (no manual filtering required)
• Separate encryption keys per tenant (Vault Transit Engine)
• Separate S3 path structure per tenant in object storage
• Separate OpenSearch indices per tenant

2. Integrity (Art. 32(1)(b) GDPR)

2.1 Transfer Control

Measures to ensure that data cannot be read, copied, modified, or removed without authorization during transmission:

• TLS 1.3 for all external connections (API, Microsoft Graph API, S3 storage)
• TLS-secured internal communication between all services in the Kubernetes cluster
• AES-256-GCM encryption of all backed-up data, applied before it leaves the platform — the storage provider receives ciphertext only
• Per-tenant key encryption key held in the HashiCorp Vault Transit Engine, which it never leaves
• Optional customer-supplied encryption key (Professional and above), replacing the platform-generated one
• Wildcard TLS certificates via cert-manager with Cloudflare DNS-01 challenge

2.2 Input Control

Measures to ensure it can be subsequently verified whether and by whom data was entered, modified, or removed:

• Comprehensive audit logs of all security-relevant access and operations (AuditLog model)
• Logging of all API access with timestamp, user ID, tenant ID, and action performed
• Immutable backup versioning (BackupItemVersion) with timestamps and source references
• WORM compliance (Enterprise): immutable retention for compliance-relevant data
• Task event system with complete logging of all backup and restore operations

3. Availability and Resilience (Art. 32(1)(b) and (c) GDPR)

3.1 Availability Control

Measures to protect against accidental destruction or loss:

• Provider-level triple replication (3x) of object storage data within the primary region
• PostgreSQL cluster via CloudNativePG with automatic failover
• Redis with AOF persistence (Append-Only File) for queue data
• Kubernetes (k3s) with automatic container restart and pod scheduling
• gzip compression of all backed-up data (reduction to approximately 55% of original size)
• Monitoring via Zabbix 7.2 with automatic alerting
• Optional cross-region replication available as an add-on service

3.2 Recoverability

Measures for rapid recovery following an incident:

• Automatic resumption of failed backup jobs via Redis Stream-based queue system with retry logic (exponential backoff strategy)
• Dead-letter queue for undeliverable jobs with manual retry capability
• Abandoned task recovery: automatic detection and resumption of stuck tasks (every 60 seconds)
• Kubernetes-based auto-restart on container failures
• Documented disaster recovery procedures

4. Procedures for Regular Review, Assessment, and Evaluation (Art. 32(1)(d) GDPR)

4.1 Data Protection Management

• Data Processing Agreement (DPA) pursuant to Art. 28 GDPR with all customers
• Documented records of processing activities pursuant to Art. 30 GDPR
• Regular review and updating of the TOM
• Employee awareness training and education in data protection

4.2 Incident Response

• Defined process for detecting, assessing, and reporting data protection breaches
• Notification to the data controller within 48 hours of becoming aware of a breach
• Vulnerability disclosure policy for security researchers

4.3 Sub-Processing

• Careful selection of sub-processors (ISO 27001 certified infrastructure providers)
• Contractual obligation of all sub-processors to maintain at least equivalent data protection standards
• Regular auditing of sub-processors
• Advance notification to the data controller when changing or adding sub-processors (30 days notice)

5. Encryption Concept

5.1 Encryption at Rest (all plans)

Envelope encryption applied inside the platform, before any data reaches object storage. There is one encryption path; it does not depend on the plan.

• Algorithm: AES-256-GCM (authenticated encryption), applied in 1 MiB frames whose authentication covers the object header, the frame position and the end of the object — so truncation or modification of a stored object is detected rather than decrypted
• Three key levels: a per-tenant key encryption key that never leaves the HashiCorp Vault Transit Engine; a versioned tenant object key wrapped by it; and a data key generated separately for every single stored object
• No key material is persisted in readable form. Unwrapped keys exist only in process memory, for minutes at a time
• Server-side encryption by the storage provider is not used and not relied upon: the provider never receives plaintext or key material
• Every object records which key version sealed it, so key rotation takes effect for new data without re-encrypting or invalidating existing backups

5.2 Customer-Supplied Keys (Professional and above)

• The customer can upload their own 256-bit key, which replaces the platform-generated tenant object key for all subsequently stored data
• The uploaded key is wrapped immediately and is never persisted, logged or returned in readable form
• Key versions are never deleted: a version that sealed data is the only thing that can open it again, so earlier backups remain readable after a key change
• Revoking a key version is available as a deliberate, irreversible act and renders all data sealed under it permanently unreadable

6. Deletion Concept

• Automated enforcement of customer-configured retention policies
• Maximum retention periods per plan: Starter 1 year, Professional 7 years, Enterprise up to 10 years
• After contract termination: 30-day data export period, followed by irrevocable deletion
• Deletion covers: S3 object storage, PostgreSQL records, OpenSearch indices, Redis queue data
• Tenant Purge Worker for GDPR-compliant data deletion (tenant purge stream)
• Deletion confirmed in writing upon request

7. Infrastructure Overview

Contact

For questions regarding these technical and organizational measures, please contact: