SECURITY
Technical and Organisational Measures
Annex to the Data Processing Agreement. Article 32 GDPR security measures applied to PersoHR.
This page is the Technical and Organisational Measures ("TOMs") annex referenced in section 7 of the Data Processing Agreement at /legal/dpa. The measures below are those currently in force; they may be updated from time to time, provided that any update does not materially reduce the overall level of security.
1. Hosting and EU data residency
Primary application data is hosted on Hetzner Online GmbH (Germany) for the PostgreSQL database, on Hetzner Object Storage (Germany) for document files, on Brevo (France) for transactional email and on Mistral AI (Paris, France) for runtime AI inference. No primary processing of customer HR data takes place outside the European Union. The only routine onward transfer outside the EU is to Stripe Payments Europe Limited (Ireland), with onward transfer to Stripe Inc. (United States) for billing/subscription processing under the European Commission's Standard Contractual Clauses (Decision 2021/914/EU) supplemented by Stripe's own technical and organisational measures.
2. Access control and authentication
El acceso de los clientes a la plataforma requiere inicio de sesión sin contraseña mediante un magic link por correo. El token del magic link es de un solo uso, se hashea con SHA-256 antes de almacenarse y caduca a los 15 minutos. La autenticación de dos factores mediante TOTP se ofrece a todos los propietarios de cuenta y se recomienda a los administradores de RR. HH.; los códigos de recuperación se generan, se muestran una sola vez y se almacenan hasheados. Los tokens de sesión son de corta duración (tokens de acceso de 15 minutos, tokens de actualización de 7 días entregados como cookies HttpOnly Secure SameSite=Strict que JavaScript no puede leer). Las sesiones autenticadas cierran sesión automáticamente tras 30 minutos de inactividad. El acceso operativo privilegiado a la infraestructura de producción se limita a personas concretas, exige autenticación con clave SSH respaldada por hardware y se registra. El control de acceso basado en roles dentro de la aplicación aplica el principio de mínimo privilegio en los cuatro roles (OWNER, HR_ADMIN, MANAGER, EMPLOYEE) más el aislamiento de datos por tenant.
3. Tenant isolation
Each customer organisation operates within an isolated tenant scope. Every personal-data record is tagged with a tenant identifier on creation and every database query is automatically constrained to the current tenant via a Hibernate row-filter activated by the authenticated session's JWT claim. A leaked or guessed identifier from one tenant cannot be used to access another tenant's data because the query layer enforces the constraint independently of the application code.
4. Encryption
Personal data in transit is protected by TLS 1.2 or higher across all customer-facing endpoints, the database connection (sslmode=require in production) and traffic to all sub-processors. Personal data at rest is encrypted at the storage layer (LUKS for the PostgreSQL volume; AES-256 server-side encryption for Hetzner Object Storage). TOTP secrets are additionally encrypted at the application layer using AES-256-GCM with a key supplied via the ENCRYPTION_KEY environment variable rotated through the deployment pipeline. Passwords are not stored; authentication is passwordless.
5. Logging, monitoring and audit
All create, update, delete, export and erasure actions on personal data are recorded in an immutable audit log table that includes the actor, the action, the entity type, the entity identifier and the timestamp. The audit log is retained for 24 months for accountability under Article 5(2) GDPR. Application logs are routed to a centralised log store and retained for 90 days; logs do not contain PII (no email addresses, phone numbers, names or token values — only identifiers). Operational alerts cover authentication failures, rate-limit hits, webhook failures, schedule mismatches and infrastructure health.
6. Backups and disaster recovery
The PostgreSQL database is backed up at least daily to an EU-located object storage bucket with point-in-time recovery within the last 7 days and full snapshots retained for 30 days. Backups are encrypted at rest. Restoration is tested at least once per quarter. The Recovery Point Objective is 24 hours and the Recovery Time Objective is 24 hours for a complete platform rebuild from backup.
7. Incident response
We operate a written incident-response procedure with defined severity levels, escalation paths and on-call coverage. Personal data breaches are reported to the Controller's account owner without undue delay and in any event within 72 hours of becoming aware of them, including the categories and approximate number of data subjects affected, the likely consequences and the measures taken or proposed to mitigate the breach. Post-incident reviews are documented and feed into corrective measures.
8. Vulnerability management and secure development
All application dependencies are scanned for known vulnerabilities on each build; high or critical vulnerabilities block merge until resolved or formally accepted. Static analysis runs on every change. We perform threat modelling for every new domain feature that touches personal data. We engage external penetration testing on a regular cadence appropriate to product scale.
9. Deletion, retention and portability
On controlled erasure, personal data identifiable as belonging to a specific data subject is either anonymised in place (where related records must be retained for legal reasons) or hard-deleted (for free-standing records such as documents). Backups are subject to the documented backup-retention schedule above and are overwritten in due course; until then, restored data remains subject to the DPA. Data portability is supported through an in-app self-service GDPR export (Profile → Download my data) and an admin tenant export.
10. Sub-processor due diligence
The current sub-processor list, with role, location, transfer mechanism and links to each vendor's data-processing agreement, is published at /legal/sub-processors. Each sub-processor is bound by a written DPA equivalent to the obligations PersoHR commits to in its own DPA. We notify the account owner at least 30 days in advance of any intended change to the sub-processor list and offer the right to object on reasonable data-protection grounds.
11. Personnel
All personnel with access to personal data are bound by written confidentiality obligations that survive termination of their engagement. Access is granted on a need-to-know basis and reviewed when role or scope changes. Personnel receive security and data-protection training and acknowledge the acceptable-use and data-handling policy at onboarding and annually thereafter.