Polish cloud computing: what does "data in Poland" really mean?

WebDisk Blog · category: Cloud · reading time: ~8 minutes

In brief:- Behind the phrase "data in Poland" there are three separate questions: where the data physically sits, whose law the provider is subject to, and who – across the entire chain of subprocessors – has access to the data.- Hosting within the European Economic Area simplifies GDPR compliance (the whole question of transfers outside the EEA shrinks to a review of the subprocessor list), shortens the path packets travel and makes everyday life easier: contract, invoice and support in one language and one currency.- Location is one of the factors in choosing a cloud – not a talisman. It will not replace encryption, backups or a good data processing agreement.

In the security questionnaires our clients receive from their own customers, one question now appears almost every time: "Where is the data physically stored and whose law is the provider subject to?". These used to come mainly from banks and public administration – today they land on the desk of a mid-sized wholesaler, a law firm and a software house.

In this article we take the phrase "Polish cloud" apart into its component pieces: what data location really implies – legally and technically – what is a practical convenience, and what is marketing shorthand. We write from an interested position, because WebDisk is a Polish cloud provider, so we separate the facts from the slogans all the more carefully. The text is for people who choose or audit a provider: business owners, IT administrators and data protection leads.

"Data in Poland" is three questions, not one

Marketing readily glues three different layers into a single phrase, and in a risk analysis they have to be kept apart:

1. Physical location of the servers. Where the machines holding the data stand – and where their backups and replicas sit. This is a question of geography: the country, the data centre, the route the packets travel.
2. The provider's jurisdiction. Which country's law governs the company providing the service – because that law decides which authorities may demand access to the data, and on what grounds. A server in Europe belonging to a non-EU company is legally a different situation from a server in Europe belonging to a European company.
3. The chain of subprocessors. Who actually "touches" the data: where the support team works, where logs and telemetry flow, which subcontractors the provider relies on. GDPR requires the provider to disclose that chain to the customer and to obtain their consent for changes – you will find the list of subprocessors in the data processing agreement.

Only the answers to all three questions tell you what "data in Poland" really means – and that is exactly the order in which to put them to any provider. Ours included.

GDPR: locating data in the EEA is not an obligation, just a simplification

Let us start by dispelling a myth: GDPR does not require data to be stored in Poland. It does not even require it to be stored in the Union. The regulation says something different: personal data may leave the European Economic Area (EEA – the EU countries plus Iceland, Liechtenstein and Norway) only where there is a legal basis for it – for example a European Commission decision finding an adequate level of protection in the country concerned, or standard contractual clauses signed with the recipient of the data.

In practice this means that a cloud outside the EEA is lawful, but requires additional work: you have to identify the transfers, choose a mechanism, assess the risk and follow changes in case law. The past decade has shown this to be shifting ground – two successive frameworks for data transfers to the USA (Safe Harbour and Privacy Shield) were annulled by the Court of Justice of the EU, and the current one, the Data Privacy Framework, remains in force, although it is the subject of legal disputes – nobody guarantees how long it will last. Companies that had built their documentation on those frameworks had to rebuild it every time.

Data stored in the EEA narrows the whole matter down to a review of the subprocessor list in the data processing agreement – the transfer rules do not apply to storage itself. Fewer analyses, shorter documentation, a simpler conversation with the auditor and with the client who sent the questionnaire.

In fairness, two things need to be added. First, location does not exempt you from the remaining obligations: the data processing agreement (DPA), the record of processing activities, technical and organisational safeguards – all of that applies regardless of where the server stands. Second, from the GDPR's point of view "in the EEA" is enough; the requirement of "specifically in Poland" comes rather from public tenders, sector regulations and internal policies than from the regulation itself.

CLOUD Act: jurisdiction counts just as much as geography

The second thread that returns in every discussion about data sovereignty is the American CLOUD Act of 2018. The act allows US authorities to demand data from providers subject to American jurisdiction regardless of where that data physically sits. A server in Frankfurt or in Warsaw changes nothing here if the operator is subject to the law of the United States.

Let us weigh this up without scaremongering, though. The CLOUD Act concerns demands in specific proceedings (criminal ones above all), carried out through a legal procedure – it is not a mechanism for mass access to other people's files, and providers are able to challenge such demands by legal means. For many companies the practical risk is small. The crux lies elsewhere: in the requirements your own company has to meet. A law firm, a healthcare entity or a public-sector contractor increasingly receives an outright condition that the data must not be subject to the law of third countries – and then the mere possibility of such access, regardless of how likely it is, rules the provider out of the shortlist.

A provider that is a European company, not subject to US jurisdiction, remains outside that regime – it is subject to Polish and EU law. And here, symmetrical honesty: this does not mean the data becomes "inaccessible to any state". A Polish provider has obligations towards Polish authorities acting on the basis of Polish law and under the supervision of Polish courts. The difference is that you know whose law applies – and that it is the same law your company and your lawyer work with every day.

Why does the location of the data centre affect application speed?

There is also an argument that no regulation will change, because it follows from physics. A signal in an optical fibre travels at roughly two thirds of the speed of light; it is generally assumed that every ~100 km of route adds about a millisecond of round-trip delay – and cable routes rarely run in a straight line. On top of that, network protocols exchange many rounds of messages (establishing an encrypted connection, negotiating the session, acknowledgements), so every round multiplies the distance.

For a nightly backup this makes no difference. But there are workloads where distance is visible to the naked eye: remote desktops and VDI, interactive business applications, file synchronisation, databases queried by an application from the office. A data centre on the other side of the continent can turn smooth work into an irritating "stuttering" interface.

We deliberately do not give a table of milliseconds "at our place" here, because the result depends on your location and your network operator. We encourage something better than declarations: measure it. A plain ping and traceroute from your office to the provider's endpoint will tell you more than any marketing slide.

A contract you can actually read, an invoice in euro: the mundane details that make the difference

Part of the benefit of a local provider has nothing to do with servers:

• Support in your language and time zone. An outage at 9 a.m. on a Monday is not the moment to translate the problem into English in a global helpdesk form. A conversation with an engineer who works in the same time zone and knows the realities of Polish companies shortens the path from ticket to resolution.
• Billing in euro. A price list in PLN and an ordinary Polish VAT invoice mean no currency risk, no conversion fees and accounting without acrobatics. With clouds billed in dollars, the cost can grow without any change in usage – purely on the exchange rate. We write more about cost predictability in the article on public cloud at a reasonable price.
• Documents written for the Polish legal system. The data processing agreement, the contact point for data protection matters, GDPR documentation – in Polish and for Polish and EU realities, rather than translated from a template drawn up under a different jurisdiction.

These are prosaic arguments – and that is exactly why they matter: you work with the invoice and the contract every month, with the auditor's questions every year, and with a serious outage (hopefully) once every few years.

What does data location NOT guarantee?

If "data in Poland" were a guarantee of security, this article would be shorter. It is not – and that is worth saying outright:

• It will not replace encryption and access control. A leak through a stolen password or wrongly granted permissions works the same in Warsaw as in Frankfurt. We describe how server-side encryption works in our object storage in the article on encryption in S3.
• It will not replace backups. Ransomware, human error and hardware failure do not check the address of the data centre. The 3-2-1 rule and a regular restore test apply at every provider – we wrote about this in the piece on cloud backup.
• It does not guarantee operational quality. A Polish provider may operate excellently or poorly – exactly like a global one. Judge the practice: transparency of service status, communication during outages, quality of the documentation, real contact with engineers.
• It is not always the only right answer. If your application serves users on three continents, or runs on the specialised managed services of a particular global provider, a global cloud may be the better choice – and a hybrid architecture lets you combine the two.

Location and jurisdiction bring order to legal risk and shorten the path packets travel. All the rest of security and quality is work to be done regardless of geography.

How this looks at WebDisk

Finally, our own answer – structured around the three questions from the start of the article:

• Geography. The infrastructure on which we provide our services is located on Polish territory – that is what our Privacy Policy states. The data you store in our services stays in Europe. The exceptions – analytical and billing data processed by providers outside the EEA on the basis of standard contractual clauses – are described in the same document.
• Jurisdiction. We are a Polish company and we are subject to Polish and EU law. The contact point for data protection matters (iod@webdisk.io) is given in the Privacy Policy, and we make the data processing agreement (DPA) – together with the list of subprocessors – available to customers on request.
• Chain and exit. We build the platform on open technologies – Apache CloudStack, Ceph and S3-compatible object storage – and you can run Kubernetes clusters with us as a service. Whatever you set up here, you can move with standard tools, without proprietary formats. We explain why this matters in the article on vendor lock-in.

On top of that come the everyday practicalities described above: a public price list in euro, a business model with a monthly invoice for the pool of resources you have purchased – no surprises on the invoice, and in compute services no separate charges for transfer – and direct contact with the team that runs the platform.

Frequently asked questions

Does GDPR require data to be stored in Poland? No. GDPR requires that personal data does not leave the EEA without a legal basis – and Poland is one of the EEA countries, just like Germany or the Netherlands. The requirement of "specifically in Poland" usually comes from public tenders, internal policies or sector regulations, not from the regulation itself.

Does using the cloud of a non-EU provider breach GDPR? Not automatically. It requires a properly documented transfer mechanism and a risk assessment – that is, additional work and sensitivity to changes in the law. Data stored in the EEA with a European provider reduces that work to a minimum – provided the list of subprocessors does not point to third countries.

What is the CLOUD Act and does it apply to data stored in Europe? The CLOUD Act is an American law of 2018 that allows US authorities to demand data from providers subject to American jurisdiction – regardless of where that data physically sits. A server in Warsaw or in Frankfurt changes nothing if the operator is subject to the law of the United States. It concerns demands in specific proceedings, not mass access to files – but if your contracts require that the data must not be subject to the law of third countries, the mere possibility of such access rules the provider out of the shortlist.

Is the Polish cloud not technologically behind the global one? In the basics – compute power, S3 object storage, Kubernetes, backups – there is no difference: these are the same open standards. Global providers do, however, have a broader catalogue of specialised managed services; if your architecture rests on them, take that into account in the calculation – including the calculation of dependency on the provider.

Does the distance to the data centre affect application speed? Yes. Every ~100 km of fibre route adds about a millisecond of round-trip delay, and network protocols exchange many rounds of messages, so every round multiplies the distance. For a nightly backup this makes no difference, but with remote desktops, interactive business applications and file synchronisation the distance is visible to the naked eye. Instead of relying on declarations, measure the latency with a plain ping and traceroute from your own office.

How do I know the provider is telling the truth about data location? Ask for documents, not slogans: the data processing agreement with the list of subprocessors, the processing locations (including backups), the contact details for the data protection officer or for the person responsible for that area. A provider that takes the subject seriously will answer with specifics.

I already have an environment with another provider or on my own VMware. Can it be moved? Yes – migrating virtual machines to a cloud based on open technologies is a well-documented, standard process. We write about where to start in the article on migration from VMware.

Summary

"Data in Poland" is neither a slogan nor a talisman, but three concrete properties of a service: geography, jurisdiction and the chain of subprocessors. They give simpler GDPR compliance, legal predictability and a shorter path for packets – they do not remove the need for encryption, backups and assessing the provider by their everyday practice. Treat location as one important row in the comparison table, not as the whole table.

If you want to check how our answers to these three questions look in detail – or you need arguments for a conversation with an auditor or a client – write to us. The public price list and service descriptions are on webdisk.pl.