Free download · A4 PDF · CISO / CTO grade
Encryption Control
Schrems II isn't a policy choice. It's a design requirement, and most backup vendors fail it.
One email. Confirmation by mail. Unsubscribe with one click.
What's inside
Inside: what it protects against and how it works. Which rules it helps meet. The proof an auditor will want. About 10 to 14 dense pages.
- What the real threat is, in plain terms
- How the system works, and why an attacker can't beat it
- What it stops, with real-world examples
- Which rules apply: fines, deadlines, exact wording
- The cost math, grounded in published numbers
- How we stack up against other vendors on the tech, not the price tag
- What setup looks like, and what we don't cover
- The evidence an auditor will ask for
Related solution pages
The same approach, framed for the questions that come up:
Migrate without risking the data
Switching servers, clouds, or providers? Backups stay locked the whole way. No data exposed. None lost.
Read moreOwn the keys. Own the encryption. No exceptions.
Every backup is encrypted with locally owned keys. Not the vendor's keys. Not shared keys. One owner only.
Read moreEvery action logged. Nothing hidden.
See who did what, when, and why. Every action lands in a record nobody can fake.
Read moreSovereign by design, not by certificate.
It runs on local servers. The only keys stay local. A US-owned provider can't hand over data it never had.
Read moreQuestions readers asked
Who is this brief written for?
A CISO, CTO, or senior infrastructure engineer reviewing the design. It assumes working knowledge of backups, storage, and the rules the stack already has to follow.
Is there a non-technical version?
Yes. After the email is submitted, the same page links to a five-minute executive PDF, ready to forward to a CFO, IT director, or board member.
What happens to my email?
One confirmation email, plus our newsletter (one short post per month, all-product). Unsubscribe with one click. Email addresses live in the EU by default per Rediacc's data-residency policy.
Why btrfs?
The brief covers this in depth. Short version: btrfs puts write-once copies and instant clones into the storage layer itself. Not into an app on top. The send/receive feature ships those copies off-machine. So an attacker holding the top admin password can't change or delete them.
Does this apply to managed services like AWS RDS?
Not directly. The design covers self-hosted servers running databases in Docker on btrfs storage. When critical data lives in RDS or Aurora, the brief flags that. It then shows where the model fits and where it doesn't.
About this brief
Rediacc is a Tallinn-based company. We build backup and disaster recovery on btrfs and commodity Linux. Our engineering team wrote this brief. We edited it against an anti-slop style guide. Then we checked every claim before publishing.
Have a question we should add to this page? Tell us at hello@rediacc.com.
Download short brief (PDF)