The provider that can read your archive

If your archive provider can read what they store for you, the risk was not outsourced. It was duplicated.

That sentence is the whole argument, but it is worth unpacking, because the instinct it contradicts is a reasonable one. Moving a problem to a specialist is normally how engineering risk gets reduced. For document retention it works differently, and the reason is structural rather than a comment on anybody's competence.

What you actually acquire

When a provider holds readable copies of your documents, several of their properties become yours.

Their access control model becomes your exposure. Every role, every service account, every break-glass procedure in their system is now a path to your documents, and you have visibility into approximately none of it.

Their offboarding becomes your problem. An engineer leaving their company with credentials that were not revoked promptly is an incident in your archive, discovered by you at the same time as everyone else, which is to say later.

Their breach becomes your notification. When their storage is compromised, the fact that it happened on someone else's infrastructure will not make it feel like someone else's problem in front of your users, your counterparties, or anybody assessing your platform afterwards.

Their subprocessors become your subprocessors, transitively, and their subprocessors' subprocessors after that. Each link in that chain is a party who can read your documents and whose security posture you are accepting on the basis of a paragraph in a contract.

None of these are exotic failure modes. They are the ordinary ways that systems leak, and they are all downstream of one capability: the provider can read the content.

Why auditing does not close it

The standard response is diligence. Review their certifications. Read their policies. Check the subprocessor list. Ask for the penetration test summary. Put the right clauses in the contract.

All of that is worth doing and none of it changes the underlying situation, for a reason that is easy to state and uncomfortable to sit with.

A certification describes controls that were observed to be operating during an audit window. It is evidence about the past, produced by a sampling process, about an organisation that has changed since. It is genuinely useful information. What it is not is a constraint on what is possible.

A provider who can read your archive can read your archive on the morning their credentials leak, whatever the policy said the night before. The capability persists through every organisational change, every acquisition, every rushed incident response, every new engineer who needs broad access to debug something urgent. Policies govern intent. They do not govern possibility.

This is not an argument against certification. It is an argument about what certification can and cannot do, and the thing it cannot do is remove a capability.

Removing the capability instead

The alternative is not a better policy. It is arranging matters so that the provider never holds anything readable in the first place.

If the document is encrypted on your side, with a key that never transits the provider's systems, then the provider holds ciphertext and whatever metadata you chose to hand over. What they might read stops being a question about their controls and becomes a question about mathematics.

The change in your own risk register is substantial and specific. A breach of their storage exposes bytes that decrypt to nothing. An insider with full administrative access to their infrastructure gets the same bytes. A subprocessor three links down the chain gets the same bytes. A legal order compelling them to produce content gets ciphertext and a truthful statement that they cannot decrypt it.

That last case is worth pausing on, because it is where the property does the most work and where it is least intuitive. A provider who can decrypt is a provider who can be compelled to. A provider who cannot has nothing to be compelled about, and the request goes where it should have gone in the first place, which is to you.

What we do and do not see

For concreteness, here is our own answer, since a general argument is easy to make and harder to live with.

Partners encrypt on their side before calling us. We receive ciphertext and the metadata the partner chooses to send — which regime applies, what content type it is, how many bytes, and whatever partner-supplied identifiers they want back later. We hold that, plus a hash of the ciphertext, plus the receipts and events bound to the deposit.

We do not receive the key. There is no key escrow, no recovery path through us, no support process that ends with us decrypting something for you. This is not a policy we could revise under pressure. It is a property of the interface.

The consequence is that we cannot help with a category of problems that a readable archive provider can help with, and that limitation is real rather than rhetorical.

The cost, stated properly

A provider who cannot read your documents cannot read them for you either.

You hold the key. If you lose it, the documents are gone, and nobody recovers them — not us, not a support ticket, not a court order. Key management becomes your operational responsibility, and it is a genuine responsibility rather than a checkbox: rotation, backup, custody, access control, and a documented procedure for what happens when the person who set it up is unavailable.

For a platform that has never managed keys, that is real work. It is well-understood work, with established practice and good tooling, but it is work, and a vendor who presents it as trivial is not being straight with you.

So the trade is: you take on a solved problem in exchange for removing an unsolved one. Whether that is the right trade depends on what kind of documents you have.

For documents that must not leak — cancellation letters with account details, medical correspondence, tax filings, claim evidence — it is usually the right trade, because the consequence of leakage is severe and the consequence of key loss is recoverable through operational discipline.

For documents where you might genuinely need someone to rescue you, and where exposure would be embarrassing rather than serious, it may not be. There is nothing wrong with a readable archive for material that does not warrant this.

Knowing which kind you have is most of the decision, and it is a decision worth making explicitly rather than inheriting from whichever provider you happened to evaluate first.

The question worth asking a vendor

If you take one thing from this into a procurement conversation, make it this question: what would you be able to produce if you were compelled to, and what would you be able to produce if you were breached?

A provider who answers with policies has told you about their intentions. A provider who answers with a description of what is cryptographically available to them has told you about your actual exposure. The second answer is short, checkable, and does not change when their org chart does.