The data never has to leave an account you control
For a regulated buyer the question is rarely whether the data is encrypted. It is whose account it sits in and who could be compelled to produce it. Those are custody questions, and encryption alone does not answer them.
Two things we do not have
If either of these is a hard requirement, stop here. We would rather you find out on this page than three calls into an evaluation.
No audit
No SOC 2, and none in progress
We hold no SOC 2, ISO 27001 or equivalent report, and none is being pursued today. If your process requires an audited vendor we are not yet approvable, and no amount of architecture on this page changes that.
The hold is ours
Enforced in code, not at the storage layer
Our hold binds every path through our API and our own sweep. It does not bind someone holding our storage credentials, so a full compromise of us is still a route to deletion. A storage-layer lock would close that; we have not turned one on.
Your bucket, your account, our orchestration
Point a workspace at storage you own and artifacts land there. What you are buying is the scheduling, the encryption boundary, the retention policy and the verified run history, which is the part that is actually hard.
Our incentives, stated rather than implied
This is the highest-margin thing we can sell, because it removes our largest recurring cost. We are telling you that because it is the reason to believe the offer rather than a reason to doubt it: a storage-backed vendor who wants your bytes on their infrastructure is the one whose incentives point the other way.
We hold the half that cannot open anything
You upload a public key and keep the private half. There is no escrow, which has a real cost worth naming: lose the private half and the artifacts encrypted to it are unrecoverable, by you and by us. That is the price of there being nothing here worth stealing.
Four layers, and one of them is not ours to give up
Six answers you can forward
The questions a security review actually asks, answered in the form you will need to give them.
Where is our data stored?
In a bucket you own, in your account, if you choose. We orchestrate, verify and record every run against it and store nothing ourselves. On our storage instead, it is a provider and region we name per workspace.
Can the vendor read our data?
No. Encryption is applied on the machine that produced the data using a public key you upload. We hold public keys only and there is no configuration in which we receive plaintext.
Can the vendor be compelled to produce it?
We can be compelled to produce what we hold, which is ciphertext, sizes, checksums and timestamps. We cannot produce plaintext because we never have it.
Who can delete our backups?
Inside a hold, nobody through our API: not you, not an attacker with your credentials, not us answering a support ticket. The hold can be lengthened and never shortened. See the limit below.
How do we prove a backup ran?
Every run records what it produced, its size, its checksum, its duration and which worker executed it. It is a query rather than an archaeology project.
What happens if we leave?
If the artifacts are in your bucket they are already yours, in a standard format, with the procedure to open them documented. There is no export to negotiate and no window to beat.
The largest line leaves our invoice
Storage in your own bucket is billed by your provider, not by us. We meter the orchestration and the transfer, so what is normally the biggest number on a backup bill simply is not on ours.
What you take on
- The bucket: its lifecycle policy, access controls, region and bill
- Key management, including the consequence of losing the private half
- A view on whether an application-level hold satisfies your auditor
A misconfiguration in your bucket is not something we can see or fix for you. That is the actual cost of custody, and anyone telling you custody is free is selling something.