+ Security & Compliance
Built to be
verifiable.
Compliance claims should be checkable, not trusted. This page documents every mechanism behind our promises — the crypto boundary, every vendor in your data path, how we handle GDPR's hardest tension (erasure vs. immutability), how to report a vulnerability, and what we commit to when something goes wrong.
+ Crypto boundary
Envelope encryption with a
hard key boundary.
Objects are encrypted with per-object data encryption keys (DEKs). Each DEK is envelope-wrapped by a per-tenant key encryption key (KEK) that never leaves OpenBao. The gateway holds unwrapped DEKs in process memory only — never on disk, never in Redis, never in logs.
KEKs live in OpenBao
Key encryption keys are generated and stored in OpenBao (Linux Foundation fork of Vault, MPL 2.0). Unwrap is the only operation that exposes a usable DEK, and every unwrap is audited. No Recover engineer holds a key that can decrypt your data at rest.
DEKs are memory-only
Data encryption keys live in the gateway's process memory for the request lifetime. Cache key format is dek:{tenantId}:{bucketId} — tenant always first, making cross-tenant bleed structurally impossible at the cache layer.
Structured logs redact keys
All services log as structured JSON with enforced scrubbing of fields matching DEK, KEK, or token patterns. A CI test asserts the build fails if a log entry containing key material is ever introduced.
+ Sub-processors
Every vendor in your
data path.
The complete list of third parties who could technically touch customer data, metadata, or authentication. Any change is announced 30 days in advance via our sub-processor change log.
| Vendor | Purpose | Location | Data it sees |
|---|---|---|---|
| Atlas (runatlas.is) | Object storage, managed Postgres, Kubernetes | Iceland | Encrypted customer objects and metadata |
| Authentik | OIDC + SAML authentication (self-hosted) | Iceland (in our Atlas tenancy) | Email, org ID — never object data |
| OpenBao | Key management (self-hosted) | Iceland (in our Atlas tenancy) | KEKs. Never leave OpenBao. |
| Resend | Transactional email | US | Email address, message body — never objects |
| Comet Backup | Backup engine (Recover Total only) | Software vendor (New Zealand). Engine runs in our Atlas tenancy in Iceland. | License check-ins only. Vendor never accesses customer data or metadata. |
To subscribe to sub-processor changes, email security@recover.is.
+ GDPR Article 17 deep-dive
Erasure vs.
immutability.
GDPR Article 17 grants data subjects the right to erasure. WORM (Write Once Read Many) storage, by design, prevents deletion. These two requirements are fundamentally in tension. This is an industry-wide challenge with no single perfect solution — here is how Recover handles it across each product tier.
Natural Propagation
Continuous replication means once a user is deleted from the production database, the next sync cycle propagates that deletion automatically. Older point-in-time snapshots rotate out within the configured RPO window (typically minutes to hours).
Erasure latency: minutes to hours
Multi-Strategy Approach
True byte-level deletion is impossible on WORM storage. Recover employs two complementary strategies:
- 1.Crypto-shredding — Each backup generation is encrypted with a unique key. Destroying the key renders the ciphertext unrecoverable. Per GDPR Recital 26, data that cannot be attributed to a person is no longer personal data.
- 2.Restore-filter-rebackup — Backup is restored to an isolated environment, the subject's data is deleted, a new clean backup is created and stored. The old backup's key is then shredded.
Erasure latency: up to WORM retention period (30–90 days)
Air-Gap + Crypto-Shred
Air-gapped infrastructure cannot be modified remotely. Crypto-shredding is applied at the next scheduled sync window. Physical isolation means the restore-filter-rebackup pipeline requires coordination with the Vault operations team.
Erasure latency: next sync cycle (typically 24–72h)
Regulatory Basis & Honest Limitations
Why regulators accept this
- +GDPR Recital 26 — Data rendered irreversibly unattributable is no longer personal data.
- +Art. 17(3)(b) — Right to erasure does not apply where processing is necessary for legal obligation compliance.
- +ICO Guidance — UK ICO explicitly allows reasonable delay for backup systems, provided the retention period is documented and communicated to the data subject.
Honest limitations
- —Crypto-shredding requires per-generation or per-subject key management. A single shared key makes selective erasure impossible without destroying all data.
- —Restore-filter-rebackup is operationally expensive for large datasets. Processing time scales with backup size.
- —Unencrypted metadata (filenames, subject identifiers) on WORM storage may still constitute personal data. Zero-knowledge mode is required to fully mitigate this.
- —There is no court precedent definitively confirming crypto-shredding satisfies Art. 17. Regulatory guidance is favorable but not binding case law.
Erasure Pipeline — Per Request
Request Received
DSR validated & logged in immutable audit trail
Production Erasure
Data deleted from live systems. Resilience tier propagates automatically
Archive Processing
Crypto-shred or restore-filter-rebackup initiated for WORM tier
Proof of Erasure
Cryptographic attestation generated. Data subject notified
+ Standards we follow
Open standards,
not marketing.
We implement well-documented standards and publish the evidence so you can verify. Where we're working toward a standard, we say so plainly.
GDPR
CompliantIcelandic jurisdiction, 72-hour breach notification, Article 17 erasure pipeline.
DORA
ReadyResilience testing framework, tamper-evident recovery evidence.
S3 Object Lock (Compliance mode)
EnforcedWORM retention cannot be bypassed — even by Recover staff.
ISO 27001
SoA in progressStatement of applicability drafted; formal certification post-funding.
SOC 2 Type I
PlannedAudit window opens after first signed customer; ETA 2026 Q4.
Iceland / CLOUD Act legal opinion
Commissioned at GAPublished in the trust repo before the first enterprise contract signs.
+ Responsible disclosure
Found a
vulnerability?
We welcome reports from the security research community. We acknowledge within 72 hours and follow coordinated disclosure timelines consistent with ISO 29147.
We do not currently offer monetary rewards. A bounty program is planned post-GA. Researchers who surface meaningful issues before GA will be named on our Hall of Thanks.
Report to
security@recover.isPGP fingerprint
Key publication pending ahead of GA. Email first — we will coordinate an encrypted channel if needed.
In scope
- +recover.is and all subdomains
- +Production S3 gateway endpoints
- +Dashboard and admin console
- +Node SDK (once published)
Out of scope
- —Marketing site quirks (thanks — we know)
- —Social engineering of our staff
- —DoS / resource exhaustion (ask first if you need to test)
- —Third parties (Atlas, Resend) — report to them directly
+ Incident response
When something
goes wrong.
We commit to transparency on both regulatory and service-level incidents. For availability and integrity events, our status page is the source of truth.
Notification to affected customers and the Icelandic Data Protection Authority (Persónuvernd) for personal-data breaches — GDPR Article 33.
Customer notification for any confirmed availability or integrity incident affecting production service.
Public post-mortem for any P1 or P2 incident — root cause, timeline, and preventive actions, published on our status page.