---
title: "Compliance"
description: "What we do, and what we do not claim."
url: "https://saved.sh/docs/security/compliance"
---
This 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 [#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](/docs/security/encryption#transport) |
| **Encryption at rest** | OpenPGP to a customer-held key, optional per backup | [Encryption](/docs/security/encryption) |
| **Key custody** | Customer holds the private key. We have no escrow | [Key management](/docs/security/key-management) |
| **Access control** | Permission-based, 27 permissions, custom roles | [Permissions](/docs/security/permissions) |
| **Least privilege for machines** | Human-only families refused on machine keys, at two layers | [API keys](/docs/security/api-keys) |
| **Tenant isolation** | Organization-scoped credentials, per-workspace namespaces and key prefixes | [Data flow](/docs/security/data-flow#tenancy) |
| **Audit trail** | Append-only, no write endpoint, actor on every row | [Audit log](/docs/security/audit-log) |
| **Immutability** | Application-level artifact locks, write-once retention policy | [Retention](/docs/backups/retention) |
| **Identity** | WorkOS as the single trust anchor; MFA configurable at the organization | [Authentication](/docs/security/authentication) |
| **Data minimisation** | Bulk data never routes through our API; only metadata does | [Data flow](/docs/security/data-flow) |
## Where the controls are weaker than they sound [#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](/docs/backups/retention#protection-lockfor).
**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 [#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 [#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-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 [#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 [#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 [#asking-us-things]
For a security review, a questionnaire, or a data processing agreement, write to
**[security@saved.sh](mailto: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.
## Next [#next]