CLAVITORBlack-box credential issuance
Sign in Get free forever Get started

Legal

Data Processing Agreement

Standard contractual clauses for GDPR and Swiss FADP compliance. Automatically applies to all paid subscriptions.

01
Definitions

"Controller" means the natural person who creates and owns the data within their Clavitor vault. You are always the Controller of your own credentials and personal data.

"Processor" means Clavitor.ai, the entity that provides hosting infrastructure, encryption orchestration, and data storage services on behalf of the Controller.

"Data Subject" means the natural person whose personal data is processed — this may be you (the Controller) or others whose data you store in your vault (family members, employees, clients).

"Personal Data" means any information relating to an identified or identifiable natural person stored in your vault, including but not limited to: credentials, passwords, API keys, payment card data, identity documents, and contact information.

"Processing" means any operation performed on Personal Data, including collection, storage, encryption, transmission, backup, and deletion.

02
Processing details
ItemDetail
Subject matterEncrypted credential vault hosting and related services
DurationFor the term of your subscription, plus 30 days for compliance backups (not restorable)
Nature and purposeStorage of encrypted data; authentication orchestration; backup and disaster recovery; technical support (with zero-knowledge limitations)
Type of Personal DataUser credentials, authentication tokens, payment card data, identity documents, secure notes, TOTP seeds, metadata
Categories of Data SubjectsController (account holder) and third parties whose data Controller chooses to store
03
Obligations of the Processor

3.1 Process only on documented instructions. Clavitor processes Personal Data only to provide the vault service as described in our Terms of Service. We do not use data for our own purposes, train AI models, derive insights, or monetize beyond subscription fees.

3.2 Ensure confidentiality. All Clavitor personnel with potential access to infrastructure are bound by confidentiality agreements. Access is granted on principle of least privilege and logged.

3.3 Implement security measures. We implement:

  • End-to-end encryption: Data encrypted at rest and in transit
  • Tiered encryption (L2/L3): Identity fields encrypted with keys derived from your device (WebAuthn PRF) — not decryptable by us
  • Zero-knowledge architecture: We cannot decrypt vault contents; only metadata (entry IDs, types, timestamps) is readable
  • Device-based authentication (WebAuthn): No passwords stored server-side
  • Geographic distribution: 21 POPs with encrypted replication
  • Incident response: 24/7 monitoring, automated alerts, documented breach procedures

3.4 Subprocessor transparency. We use only the subprocessors listed in our Subprocessor List. We notify subscribers 30 days before adding any new subprocessor.

3.5 Assist with Data Subject rights. Upon your request, we will assist you in responding to requests from Data Subjects exercising rights under GDPR/FADP (access, rectification, erasure, portability, restriction, objection). Note: Due to encryption architecture, we cannot access or modify encrypted vault contents; assistance is limited to account-level operations.

3.6 Assist with security obligations. We provide security documentation, penetration test summaries (NDA required for details), and audit logs on request.

3.7 Delete or return data. Upon subscription termination, we delete all active data immediately per our Cancellation Policy. Compliance backups are retained for 30 days only and then destroyed. Data cannot be returned in decrypted form (we don't have keys).

3.8 Audit and inspection. Upon 30 days written notice, you may audit our compliance with this DPA. Audits are conducted at our Zurich headquarters or virtually. We provide relevant documentation; direct infrastructure access requires security clearance.

3.9 Notify of breaches. We notify you within 24 hours of discovering any breach affecting your Personal Data. We will never delay notification for investigation or legal review.

3.10 Document processing activities. We maintain records of processing activities and make summaries available upon request.

04
Obligations of the Controller

You warrant that:

  • You have lawful basis to process Personal Data in your vault
  • You have provided appropriate privacy notices to Data Subjects whose data you store
  • You will not store data in violation of applicable laws
  • You will promptly notify us of any Data Subject requests or regulatory inquiries
05
Data location and transfer

Your vault data is stored encrypted at the Point of Presence (POP) geographically nearest to your access pattern. Primary and backup POPs are in different regions for resilience. The complete list of 21 POPs with cities, providers, and compliance certifications is maintained in our POP database.

Infrastructure providers used for POPs include: Amazon Web Services (17 POPs, primary provider for most regions), ISHosting (Istanbul, Almaty, Bogotá), and HostAfrica (Lagos). Zürich HQ operations (billing, administrative) use Hostkey.

All POPs are either:

  • In jurisdictions with adequacy decisions (EU, EEA, Switzerland, UK, Canada, etc.)
  • Bound by Standard Contractual Clauses (SCCs) where no adequacy decision exists

Due to our encryption architecture (zero-knowledge), even data stored in non-adequate jurisdictions is technically protected. We cannot decrypt it; neither can local authorities. DNS resolution is handled by Cloudflare; no vault data ever passes through their network.

06
Encryption and technical measures

No data is decryptable by us at rest. The vault file is encrypted and the encryption key is not stored on the server. When an agent or user connects, they carry the L1 key with them — we could technically intercept it in transit (though we do not, and TLS prevents third parties from doing so). Even with L1, only metadata is visible. Credential and identity fields remain sealed.

  • L1 (Vault encryption): The vault is encrypted at rest with AES-256-GCM. The 8-byte L1 key is carried by the agent or user on each request — it is not stored on the server. With L1, entry titles, types, and timestamps are visible. This is the operational minimum required to serve requests.
  • L2 (Credential fields): Passwords, API keys, TOTP seeds, OAuth tokens — encrypted per-field with a 16-byte key that never exists on the server. L2 is held only by the user's browser and their registered agents. We cannot decrypt credential fields, and no server-side process ever has access to L2.
  • L3 (Identity fields): Credit cards, CVV, passport numbers, SSNs, recovery codes — encrypted with a 32-byte key of pure random entropy, generated at vault creation. The user does not know this key. We do not have it. L3 never exists on any server. It is protected by wrapping it with the 32-byte output of your hardware key's PRF (fingerprint, face, or security key via WebAuthn PRF). Without the physical device, L3 cannot be unwrapped. We mathematically cannot decrypt identity fields, and we cannot be compelled to produce a key we do not have.
07
Contact

For DPA-related inquiries:

Data Protection Officer (DPO) Clavitor LLC c/o Johan Jongsma

08
Effective date and changes

This DPA is effective as of your subscription start date and remains in effect until termination. Changes are notified 30 days in advance. Continued use constitutes acceptance.

Last updated: May 2026 · Version 1.1