Technical and Organizational Measures

Annex 1 to the Data Processing Agreement — Technical and Organizational Measures pursuant to Art. 32 GDPR (Technische und organisatorische Maßnahmen gem. Art. 32 DSGVO)

The following measures describe how Jakob Bennemann protects personal data processed on behalf of its customers. These measures are regularly reviewed and updated as necessary to maintain an appropriate level of security.

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

1.1 Physical Access Control

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

• All infrastructure is hosted at Hetzner Cloud data centers in Germany and Finland
• Hetzner data centers are ISO 27001 certified
• Data centers employ 24/7 security personnel, CCTV surveillance, and biometric access controls
• Hoppla staff have no physical access to data center hardware; all management is via encrypted remote access

1.2 Logical Access Control

Measures to prevent unauthorized access to data processing systems:

• All system access requires SSH key-based authentication (no password-based SSH)
• Administrative access is restricted to a minimal number of authorized personnel
• Principle of least privilege applied to all internal access roles
• Multi-factor authentication (MFA) enforced for all infrastructure management consoles
• Internal management interfaces (database administration, cluster console) are protected by HTTP basic authentication on the ingress and by personal, MFA-protected accounts
• Automated session timeout after periods of inactivity

1.3 Data Access Control

Measures to ensure that authorized users can only access data within their authorized scope:

• PostgreSQL Row-Level Security (RLS) enforces tenant isolation at the database level
• Application-level middleware sets tenant context (SET app.tenant_id) for every request
• Role-based access control (RBAC) within teams (owner, admin, member)
• API token scoping limits access to authorized operations
• Separate database credentials for application, migration, and read-only operations
• Tenant isolation is enforced by the database, not only by the application, and fails closed. Defined administrative paths exist and are audit-logged: platform support access, and reseller access to the tenants that reseller manages

1.4 Separation Control

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

• Multi-tenant architecture with strict logical separation via RLS
• Each tenant (team) has a unique UUID that is enforced on every database query
• Separate databases for production and testing/staging environments
• Monitoring data, account data, and billing data are stored in separate logical domains
• Check result data is stored in a dedicated TimescaleDB hypertable with time-based partitioning

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

2.1 Transfer Control

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

• All data in transit is encrypted using TLS 1.3 on Hoppla domains (TLS 1.2 minimum for custom domains)
• HTTP Strict Transport Security (HSTS) enforced on all endpoints
• API authentication via bearer tokens for all programmatic access
• Webhook deliveries use HMAC signatures for payload verification
• Internal cluster traffic runs on a private overlay network that is not reachable from the internet and is restricted by network policies. It is not additionally encrypted between pods.
• Email notifications sent via TLS-encrypted SMTP connections

2.2 Input Control

Measures to ensure that it can be verified whether and by whom personal data has been entered, modified, or removed:

• Comprehensive audit logging of all user actions (create, update, delete operations)
• Audit logs include: timestamp, acting user, action type, affected resource, IP address
• Audit logs are retained for 365 days and are tamper-resistant (append-only)
• Database-level change tracking for critical entities
• Git-based version control for all infrastructure and application code changes

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

3.1 Availability Control

Measures to ensure that personal data is protected against accidental destruction or loss:

• Automated daily database dump (03:00 UTC), retained for 14 days
• Backups stored in Hetzner Object Storage in the EU, separately from the database volume
• Backups encrypted at rest by the storage provider; transport secured with TLS
• Backup completion is monitored; a failed or missing backup raises an alert
• Multiple application and worker instances with pod disruption budgets
• Automated health monitoring and restart of failed services
• DDoS protection via Cloudflare

3.2 Rapid Recovery

Measures to ensure rapid restoration of availability and access to personal data in the event of a physical or technical incident:

• Documented incident response procedures
• Documented breach notification procedures
• Recovery Point Objective (RPO): up to 24 hours, following the daily backup cycle
• Recovery Time Objective (RTO): target of 8 hours for full service restoration. This is a planning target derived from the documented procedure; it has not yet been established by a full restore exercise.
• Kubernetes-based orchestration: stateless components (API, dashboard, workers) are rescheduled automatically on node or pod failure. The database tier does not fail over automatically; it is restored from the daily backup, per the RPO above.
• Infrastructure as Code (Helm charts) for reproducible deployments

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

4.1 Data Protection Management

• Designated data protection contact reachable at [email protected]
• Regular review and update of data protection policies and documentation
• Records of processing activities under Art. 30 GDPR and, where required, data protection impact assessments under Art. 35 GDPR are being compiled. They are not yet complete and are not currently available for disclosure.

4.2 Security Testing

• Automated vulnerability scanning of application dependencies
• Regular security reviews of application code
• Automated dynamic application security scanning (OWASP ZAP) against the API and the public status pages, run by Hoppla. No independent third-party penetration test has been commissioned to date.
• Automated linting in the CI/CD pipeline

4.3 Employee Measures

• Hoppla is operated by its sole proprietor. There are currently no employees, and no third party holds access to production personal data.
• Should staff or contractors be engaged, access will be granted only against a written confidentiality undertaking (Art. 28(3)(b), Art. 32(4) GDPR) and revoked on departure.
• Administrative access is personal, MFA-protected and logged in the audit log.

4.4 Incident Response

• Defined incident response process with escalation procedures
• Data breach notification process aligned with Art. 33 GDPR (72-hour notification to authorities)
• Post-incident review and lessons-learned process
• Communication templates for data subject notification per Art. 34 GDPR

5. Encryption (Art. 32(1)(a) GDPR)

5.1 Encryption at Rest

• Particularly sensitive fields are encrypted in the database at application level with AES-256 (audit-log diffs and metadata, two-factor secrets and recovery codes, notification channel credentials, tenant SMTP configuration, imported vendor API credentials)
• Database volumes and backup objects are encrypted at rest by the infrastructure provider (Hetzner) under the provider's keys. Hoppla does not operate its own volume-level encryption.
• Passwords stored using bcrypt with appropriate cost factor (never stored in plaintext)

5.2 Encryption in Transit

• TLS 1.3 enforced on all Hoppla domains (API, dashboard, status pages)
• TLS 1.2 minimum for custom status page domains; older protocols disabled
• HSTS headers with long max-age
• Certificate management via automated renewal (Let's Encrypt / Cloudflare)

6. Pseudonymization (Art. 32(1)(a) GDPR)

• Internal identifiers use UUIDs rather than sequential IDs
• API tokens are hashed before storage
• Monitoring check results reference monitors by UUID, not by user-identifiable information
• Audit log entries can be processed independently of account data for analytics purposes

7. Sub-Processor Security

All sub-processors (see Sub-Processor List) are contractually bound to maintain equivalent technical and organizational measures. Sub-processor compliance is verified:

• During initial vendor assessment before engagement
• Through review of certifications and audit reports (ISO 27001, SOC 2)
• Through contractual DPA obligations
• Periodically, as part of ongoing vendor management

8. Review and Updates

These technical and organizational measures are reviewed at least annually and updated as necessary to reflect changes in the risk landscape, technology, or regulatory requirements. Material changes will be communicated to customers via the DPA change notification process.

Contact

Questions about our security measures?
Security: [email protected]
Privacy: [email protected]