Leo · 2026-09

EU Data Sovereignty Storage Appliance: What to Verify

An EU data sovereignty storage appliance is a system that keeps the data set physically and administratively inside the organisation that owns it, so no third party holds a copy it could be required to disclose. For a European buyer the practical work is evidence rather than slogans: which records prove where the data sits, what the processing agreement must say, and how much capacity it takes to keep the whole estate on-premises.

What Does Data Sovereignty Mean for a Storage Appliance?

Data sovereignty means that the organisation generating the data remains the only party able to access, move or delete it, and can demonstrate that position on request. For a storage appliance it resolves into four verifiable properties: the disks are administered by the organisation itself, the access log is written where the organisation can export it, retention and deletion follow a written policy, and no mandatory cloud dependency sits in the data path.

That definition matters because it moves the discussion away from features and towards administration. A device can be encrypted, racked and locally installed and still fail the test if its management plane belongs to a vendor that can reach the data set remotely. The question to ask is not "is it encrypted" but "who holds the administrator account, and can that party reach the disks without us". A private-cloud appliance built for on-premises operation, such as woCyber’s on-premises NAS range, is designed around the second answer rather than the first.

Where Does the CLOUD Act Reach, and Where Does It Stop?

The US CLOUD Act is the reason European buyers ask this question at all, and the common misunderstanding runs in both directions. The Act does not depend on where data is stored. It operates on the provider: a company subject to US jurisdiction that can technically reach a data set can be compelled to disclose it, even when the disks sit in Frankfurt, Dublin or Stockholm.

The corresponding limit is technical rather than legal. Where the equipment is administered solely by the organisation itself, inside its own building, there is no provider in the path to serve an order on, because no third party holds the keys or the network route. That is the structural distinction worth writing into a procurement note: cloud dependency versus locally administered infrastructure. It is also why the CLOUD Act is answered by architecture rather than by a compliance statement — a supplier that offers a badge instead of an administration model has answered a different question.

Which Records Prove That Your Data Stayed Under Your Control?

Four artefacts carry the argument in an audit, and each one should be exportable rather than viewable only inside a vendor portal.

• Access log. Who signed in, from which account, and when — written locally and exportable in a format your data protection record can hold.
• Account separation. Evidence that each department, practice group or client team has its own space, so that access to one data set does not imply access to every data set on the appliance. On S1, the surveillance-oriented AiNAS security appliance, this is implemented as physically isolated storage per member rather than a permission layer on top of one pool.
• Retention schedule. The written rule for how long each class of record lives — a site running surveillance storage typically chooses from 7, 14 or 30-day retention windows, while a document estate follows a statutory period instead.
• Deletion record. What happened when the retention period ended: which data set was removed, by whose instruction, and what remains in snapshots. A deletion policy without a snapshot policy is incomplete.

If those four exist and can be produced on a Tuesday afternoon without vendor involvement, the sovereignty claim is doing real work. If they exist only as screenshots in a supplier’s presentation, it is marketing.

How Do You Write Data Location into a Processing Agreement?

Under Article 28 of the GDPR, a controller must use processors that provide sufficient guarantees, and must set the processing terms in a written contract — the DPA in English, AVV in German practice, contrat de sous-traitance in French. The regulation itself is the reference text for how far those terms reach.

Three clauses carry the location argument in practice, and they are the ones to negotiate line by line:

• Storage location and any onward transfer. Name the premises and the equipment class, and state whether any subset of data leaves them, including for support, telemetry or update checks.
• Assistance and access. How the processor responds to an access request from the controller’s clients, and what evidence it can supply about access that took place without the controller’s knowledge.
• Deletion at termination. What is removed at the end of the contract, in what period, and what the controller receives as confirmation.

Where the appliance is self-administered, the processor’s role becomes narrow — supply, warranty and spare parts — and that narrowness is the point. The supervisory authorities publish guidance and practical security material for exactly this kind of assessment; France’s CNIL data security pages and the European Commission’s data protection overview are useful starting points for wording, because they describe the responsibilities in the same terms an auditor will use.

How Much Capacity Do You Need to Keep the Whole Estate On-Site?

Choosing an EU data sovereignty storage appliance has a capacity cost attached, and that number is straightforward to model. Take a working data set, apply annual growth, add headroom for versions and temporary files, then work back from RAID efficiency to the raw disks you have to buy.

Worked example: a document estate of 10 TB growing at a factor of 1.2 per year. After three years the working set is 10 × 1.2 × 1.2 × 1.2 = 17.28 TB. Add headroom of 1.25 for versions, exports and temporary files: 17.28 × 1.25 = 21.6 TB of usable capacity. On the woCyber X4 enterprise NAS server, usable capacity in RAID 5 is (disks − 1) × single-disk capacity, so four 8 TB drives give (4 − 1) × 8 = 24 TB — enough. Moving to RAID 6 for double parity changes the arithmetic: (4 − 2) × 8 = 16 TB is not enough, and the platform needs four 12 TB drives instead, giving (4 − 2) × 12 = 24 TB. The platform ceiling of 120 TB leaves room for the estate to keep growing without a second appliance.

Two decisions follow from the calculation rather than from the price list. Parity level is a risk decision, not a capacity decision, and it should be taken together with the backup window. And growth factor is the assumption that most often turns out to be wrong — a practice that scans every incoming file will grow closer to 1.4 per year, which changes the drive choice on the same platform. Modelling both columns before ordering is cheaper than adding a second appliance eighteen months later. Buyers who want the wider platform comparison, including the two-bay and single-bay options for smaller sites, will find it on the product pages.

A Worked Scenario: A 40-Person Accountancy Practice Consolidates Client Files

Consider a hypothetical 40-person accountancy practice with three offices, consolidating client bookkeeping files that currently sit in a mix of desktop folders and a consumer cloud drive. The driver is not cost: a client audit has asked where the working papers physically sit, and the practice cannot answer with a consumer account it does not administer.

The realistic options are three. Staying on the consumer cloud means accepting that the provider is in the data path and that the access record belongs to the provider. Moving to a business cloud tenant in an EU region keeps the storage inside the union but does not change who administers it, so the audit question survives. Consolidating onto an on-premises appliance in the practice’s own office answers the question directly: the disks are theirs, the administrator account is theirs, the access log is local, and the retention schedule for working papers can follow professional rules instead of a plan tier.

The trade-off is operational and should be stated plainly: the practice becomes responsible for backups, for drive replacement and for the security of the room the appliance stands in. That is why the deployment normally pairs the appliance with an off-site copy and a written restore procedure — sovereignty over the primary copy, resilience for the rest. Practices that take this route usually keep a narrow cloud function for client file exchange and leave the record copy on-premises.

Which Storage Model Fits Which Data Location?

The fourth row is the one that catches buyers out: hardware on your floor does not by itself mean sovereignty, because remote administration keeps a provider inside the data path. Location and administration are two separate conditions, and both have to be satisfied.

What Should You Ask Before You Sign?

A short list settles most of it in one meeting. Who is the administrator of record, and can that be changed without vendor involvement? Where is the access log written, and in what format can it be exported? Is any outbound connection required for the appliance to keep working, and can it be disabled? What is the deletion procedure at end of retention and at end of contract? Which spare parts are guaranteed for the life of the project, and on what terms? And if the appliance fails, what is the documented path to recover the data set without sending it to a third party?

Answers to those six questions, in writing before the order, do more for a data sovereignty position than any badge. The remaining decisions are hardware ones: parity level, drive count and the growth assumption behind them. A capacity and deployment review before purchase usually costs a fortnight and saves a second appliance — the same calculation is used for archive and tiering decisions in cold data storage planning, and the hardware side is set out in AI-ready NAS requirements. Where the alternative is still a metered cloud service, the recurring side of that comparison is covered in the cost of data egress from cloud.

Questions EU Buyers Ask About Data Sovereignty

Does an on-premises appliance make an organisation GDPR compliant? No, and no product can. Compliance is an organisational and contractual position held by the controller. What local infrastructure changes is the architecture: data can be processed inside the organisation’s own environment with a local access log, which supports the position instead of replacing it.

Is a cloud tenant in an EU region equivalent to on-premises storage? Not for administration. The data may be stored inside the union, but the provider still administers the platform and can be required to disclose what it can reach. Whether that is acceptable depends on the sensitivity of the data set and on what the processing agreement says.

What has to change in our processing agreement? Name the storage location and the equipment class, state whether any data leaves those premises — including for support or update checks — set out how access requests are handled and evidenced, and define deletion at termination. Article 28 of the GDPR is the reference text for that wording.

How long should we retain records, and what does retention cost? Retention periods follow your professional or statutory rules; the storage cost follows directly from the schedule. Model the working set, apply an annual growth factor, add version headroom, then work back through RAID parity to the raw drives, as in the 10 TB example above.

What happens to our data if the supplier relationship ends? The appliance should keep operating with its administrator accounts, and the data set should be recoverable without routing through a vendor service. Ask for the export format, the deletion procedure and the spare-part commitment for the life of the project before the order is placed.

Which Signals Should Send a Procurement Team Back to the Specification?

Three patterns tend to appear in supplier claims that do not survive an audit. The first is a compliance badge where an architecture description should be — if the answer to a data location question is a certificate, the administration model has not been explained. The second is remote-only administration on hardware marketed as fully local: check whether the management plane can be reached without your network, and whether it can be turned off. The third is a deletion claim without a snapshot policy, which in practice means data that was deleted from the file system is still present in a snapshot months later. Each of the three is testable in a single technical call, and each one is easier to test before the order than after it.