Compliance
What we do, and what we do not claim.
View as MarkdownThis page describes controls that exist and states plainly which formal attestations we do not currently hold. It is written to be useful in a vendor review, including the parts that are inconvenient for us.
We do not currently hold SOC 2, ISO 27001, HIPAA or PCI attestation, and we do not claim otherwise. If your procurement process requires one of those today, we are not yet a fit, and it is better for both of us to establish that in the first conversation.
If certification status changes, this page changes with it. Until then, what follows is the evidence we can actually offer: how the system is built, and what you can verify yourself.
Controls that exist
These are described in detail elsewhere in this section. The table is for the reviewer who needs the map.
| Control area | What exists | Detail |
|---|---|---|
| Encryption in transit | TLS on every hop | Encryption |
| Encryption at rest | OpenPGP to a customer-held key, optional per backup | Encryption |
| Key custody | Customer holds the private key. We have no escrow | Key management |
| Access control | Permission-based, 27 permissions, custom roles | Permissions |
| Least privilege for machines | Human-only families refused on machine keys, at two layers | API keys |
| Tenant isolation | Organization-scoped credentials, per-workspace namespaces and key prefixes | Data flow |
| Audit trail | Append-only, no write endpoint, actor on every row | Audit log |
| Immutability | Application-level artifact locks, write-once retention policy | Retention |
| Identity | WorkOS as the single trust anchor; MFA configurable at the organization | Authentication |
| Data minimisation | Bulk data never routes through our API; only metadata does | Data flow |
Where the controls are weaker than they sound
A vendor review is more useful when the vendor volunteers this. Three items:
Artifact locks are enforced by us, not by storage. lock_for stops our API, our
dashboard, our support tooling and our retention sweep. It is not object-lock enforcement
at the bucket, so it is not a defence against someone holding the archive credentials
directly. If you need storage-layer WORM, deliver to a bucket you control and configure object
lock there. See retention.
Encryption is optional and unenforced. Nothing refuses to run without a key and nothing
warns at run time. A backup configured without one produces plaintext artifacts indefinitely.
Verify with sctl artifact get rather than assuming.
Credential revocation is TTL-bound. Validations are cached for about a minute, so a revoked machine key can continue to work briefly. Treat revocation as effective within a minute rather than instantly.
What a cloud backup means for your data classification
The choice of kind is a compliance-relevant decision, not a convenience one.
local | cloud | |
|---|---|---|
| Source credential held by | You | Us |
| Plaintext processed on | Your infrastructure | Our infrastructure |
| We are a processor of the source data | No | Yes |
For a local backup we hold ciphertext and metadata: we cannot read the contents, and any assessment should reflect that. For a cloud backup we hold the credential and process the plaintext, and your assessment must treat us accordingly.
If your data classification makes the second unacceptable, run local backups. The capability difference is small; the trust difference is not.
What we hold about you
| Category | Examples |
|---|---|
| Account data | Email, name, workspace membership, role |
| Configuration | Backup names, source types, schedules, retention policies |
| Cloud source configuration | Host, port, database, bucket, URL, and the credential in our vault |
| Artifact metadata | Size, checksum, timestamps, key fingerprint, storage locations |
| Operational records | Run history, step names, failure text, audit events |
| Billing | Usage meters, card brand and last four via our payment processor |
| Artifact contents | Ciphertext for encrypted backups, plaintext for unencrypted ones |
Names are metadata we necessarily hold. If a database or bucket name is itself sensitive, that is worth knowing before you schedule it.
Data retention on our side
| Data | Kept |
|---|---|
| Artifacts | Under the backup's retention policy, which is write-once |
| Run history | 30 days |
| Audit events | Retained for the workspace |
| Account and configuration | For the life of the workspace |
An artifact's retention is a promise made when the backup was created and cannot be edited afterwards, which is what makes it worth citing in a policy document.
Deletion
| Action | Effect |
|---|---|
| Delete an artifact | Removes our copy. Copies in your own buckets are left alone |
| Delete an artifact under a lock | Refused until the lock expires |
| Delete a backup | Refused while it still has artifacts |
| Delete a workspace | Removes the workspace and its records |
We remove only our own copies, because we hold write credentials to your buckets rather than a mandate to destroy data in them.
What you can verify yourself
Rather than taking this page's word for it:
| Claim | How to check |
|---|---|
| Encryption happens on your machine | Read the worker source. It is open, and the encrypt step is a few dozen lines |
| We cannot read your local backups | Try gpg --decrypt without the private key |
| The artifact needs nothing of ours | Open one with plain gpg and tar on a machine with no account |
| Downloads are recorded | Check artifact.download_url_issued in the audit log |
| A machine key cannot escalate | Try to create an API key with api-keys:write. It is refused |
The last three take about ten minutes and are worth more than any document we could write.
Asking us things
For a security review, a questionnaire, or a data processing agreement, write to security@saved.sh with what you need and the deadline you are working to. We would rather answer a specific question honestly than return a generic packet.