# A demand served on your provider returns encrypted fragments.

> For teams whose data protection obligations and whose infrastructure sit on opposite sides of a border.

Source: https://dataprism.co/use-cases/cross-border-compliance

## The problem

Cross-border data transfer compliance is where the calendar goes. A reviewer asks who abroad can read the data, the honest answer is a contract clause, and the launch waits while nobody can produce anything more solid than that.

The usual exits are expensive. Migrating to a local provider costs months and the services your teams already know. Adding paperwork costs less and changes nothing about who could read the file: it records a promise, which is what was in question.

## Encrypted fragments cross the border. Files do not.

Files are encrypted on your side before upload, then split into fragments dispersed across the providers you already use, with the key derived on your side and never stored. So the answer changes: an operator served with a request can produce only incomplete fragments of ciphertext, and that is a property of your architecture, not a promise you were given.

Reviewers can check both: the product page shows what each provider actually holds, and the security architecture overview, releasing with launch, sets out what an operator can produce, actor by actor.

## What changes

- Answer "who abroad can read this" with a fact, not a contract clause.
- No migration: the same providers, the same regions, the same contracts.
- Which providers hold your fragments, and in which regions, stays your call.