- Pseudonymisation and encryption of personal data
- Content is encrypted on the client device with XChaCha20-Poly1305 authenticated encryption before transmission. Per-file keys are sealed to the recipient with X25519. The master key is derived from the user passphrase with Argon2id (3 iterations, 64 MiB memory) and is never transmitted. TLS 1.3 protects all data in transit. Server-side storage holds ciphertext only.
- Ability to ensure ongoing confidentiality
- Row-level security on every database table, enforced by identity-anchored policies and immutability triggers. Least-privilege service roles. Mandatory multi-factor authentication for administrative access. No operator role can decrypt customer content.
- Ability to ensure ongoing integrity
- Authenticated encryption rejects any tampered ciphertext. SHA-256 verification on backup and restore paths. Append-only, tamper-evident audit logging of security-relevant events.
- Ability to ensure availability and resilience
- Multi-region edge delivery, automated provider failover checks, and encrypted off-site snapshots held under immutable object lock for a rolling window.
- Restoring availability after an incident
- Documented disaster-recovery procedure with a standby deployment and regularly exercised restore path from encrypted snapshots.
- Regular testing and evaluation
- Automated security regression and isolation test suite executed on every build, including randomised fuzzing of access-control predicates and a network gate that fails the build if any plaintext secret would leave the browser. Dependency vulnerability scanning. Public vulnerability disclosure programme.
- User identification and authorisation
- Passphrase authentication with WebAuthn passkeys and TOTP step-up. Session inventory with instant revocation. Geo-anomaly detection on new sessions. Rate limiting and lockout on authentication and recovery endpoints.
- Protection of data during transmission
- TLS 1.3 with HSTS preload; strict Content Security Policy; subresource integrity on third-party scripts. Payload confidentiality does not depend on transport security, since payloads are already encrypted.
- Protection of data during storage
- Ciphertext at rest, additionally covered by provider-level disk encryption. Keys required to read content exist only on customer devices.
- Physical security of processing locations
- Processing takes place in the certified data centres of the infrastructure sub-processors listed in Annex III; DRIVUNO operates no physical facility that holds customer data.
- Events logging
- Authentication, key operations, sharing, administrative actions and deletions are recorded with actor, timestamp and source, in an append-only store with a defined retention period.
- System configuration and governance
- Infrastructure and schema changes are version-controlled and peer-reviewed. Security headers and access policies are asserted by automated tests. Published security changelog and release transparency records.
- Data minimisation
- No advertising identifiers, no behavioural profiling, no content scanning, no AI training on customer data. Analytics is cookieless and does not collect personal data.
- Accountability
- Named privacy contact and data protection officer, maintained record of processing activities, and a published subprocessor register with advance-notice commitment.
- Measures for sub-processors
- Written data-protection terms no less protective than this Addendum, transfer mechanisms in place, and ciphertext-only exposure for storage and transport providers.