# Store user files no provider can open.

> Files your users upload, encrypted inside your process before they leave it, unreadable by every provider that stores them.

Source: https://dataprism.co/use-cases/user-data

## The problem

Every product that stores user data carries the same debt: the team can read it, the cloud can read it, and one bad day makes it public. You pay it in reviews, in deals that wait on them, and in the disclosure you would have to write.

## No readable copies at rest, anywhere your data lands.

Integrate the client-side encryption SDK and user data is encrypted before upload, fragmented, and dispersed. Your users notice nothing: same signup, same product, no cryptography in their way. What changes is the answer you give afterwards, and it stays the same answer whoever is asking: a breached bucket yields ciphertext, not user data.

If the mechanism has to survive a security review, the product page explains how encryption before upload works.

## What changes

- Deletion enumerates every fragment a file left behind, removes each one at its provider, and reports what failed.
- No readable copies at rest: what each provider holds is encrypted fragments.
- A security questionnaire you answer with architecture instead of promises.
