The Amsterdam Server Seizure: What European Hosting Actually Protects

On 13 October, Dutch police seized a server belonging to Italian internet provider Autistici/Inventati at a data centre in Amsterdam. The action followed a request from US authorities, according to ANP's initial report, published by NL Times. For a European business considering where to host its applications, the obvious question is what protection a European address actually provides.

Our view is that location still matters, but it needs a more precise explanation than a promise that data will never leave Europe. This case brings three separate questions into focus: where information sits, who can require access to it, and how a business continues operating when infrastructure becomes unavailable. Each needs its own answer.

What is established, and what remains disputed

The initial report said police were making a digital copy of the server's data for US authorities. It did not identify the specific data to be transferred. A planned transfer and a completed transfer are different events, so that early account should not be read as confirmation that information had already reached the US. ANP, 14 October.

On 17 October, Amsterdam's Public Prosecutor's Office told ANP that the seizure used the Netherlands-US mutual legal assistance treaty and that it had found no ground for refusal. It also said the data had not yet been shared with the US. That is a dated account of the prosecutor's position, rather than confirmation of the transfer's status today. ANP, 17 October.

The same report describes concerns from the Dutch Cloud Community, the industry association, about whether an independent Dutch legal review took place. Separately, MPs Barbara Kathmann and Sarah El Boujdaini submitted written parliamentary questions on 16 October about facilitating the American seizure request. Neither an industry objection nor parliamentary questions establish a court finding that the action was unlawful.

The public sources reviewed for this article do not establish the final transfer outcome or resolve the contested handling of the request. A responsible business analysis has to preserve that uncertainty. We can examine the legal route described without pretending to have reviewed the underlying case file.

A treaty request and a CLOUD Act demand take different routes

A mutual legal assistance treaty lets authorities in one country ask their counterparts in another to obtain evidence. Under this route, the receiving country's authorities handle the request through the applicable legal process. The US Department of Justice describes that government-to-government mechanism in its explanation of international evidence gathering.

The Netherlands-US treaty itself contains rules for search and seizure, grounds on which assistance may be denied, and provisions on executing requests under domestic law. Its existence therefore establishes a framework for cooperation, rather than answering whether officials correctly applied every requirement in a particular case. The relevant provisions appear in Articles 6, 10 and 12 of the published treaty text incorporating the bilateral amendments.

The CLOUD Act raises a different issue for cloud buyers. Its amendment to US law addresses disclosure by covered providers subject to US jurisdiction of responsive data in their possession or control, wherever it is stored. The Justice Department's explanation also makes clear that jurisdiction is not determined solely by whether a company is American-owned.

Those distinctions matter when assessing a migration. Changing the provider's corporate and operational arrangements may change exposure to direct demands; it does not abolish cooperation between governments. On the prosecutor's reported account, Amsterdam is a case about treaty-based assistance, so describing it simply as a CLOUD Act seizure would obscure the mechanism that needs scrutiny.

GDPR is relevant, but the legal route still matters

European data-protection rules do not treat a foreign authority's demand as sufficient permission for a company to disclose personal data. The European Data Protection Board's final Article 48 guidelines explain that an EU company's response needs both a lawful basis for processing and compliance with the rules for international transfers. Receiving an official-looking request does not, by itself, satisfy those requirements.

There is a crucial limit to that guidance: it focuses on direct cooperation between foreign authorities and private entities in the EU. It distinguishes exchanges between public authorities, including those under mutual legal assistance treaties. Applying its conclusions wholesale to the Dutch police action would skip that difference.

For a management team, the practical implication is to identify who received the demand and under which procedure before drawing conclusions about safeguards. A foreign order sent to a supplier and a domestic measure carried out by local police require different legal analysis. A data-centre address alone cannot explain either process.

European hosting needs a specific promise

The Amsterdam case should make buyers more demanding about the language used to sell sovereignty. "Hosted in Europe" describes a location; the useful follow-up is what that location means for the particular service, contract and operating model. Ask a supplier to connect its claims to identifiable entities, people and procedures.

For example, a business moving its customer portal might want its live database, backups and support access confined to agreed European locations. It might also want a clear account of which company operates the service, which subcontractors can access information, and who makes decisions about disclosure. These are separate requirements to document and verify during procurement.

Our recommendation is to express the intended benefit in terms your organisation can check. "We know who operates the system and which process applies to an access request" gives a board something concrete to assess. A broad assurance that nobody outside Europe could ever obtain information leaves too much unexplained.

This also makes comparisons between providers more useful. Ask how a request reaches the legal team, how its scope is assessed, and what the customer can be told when disclosure is permitted. Seek an explanation of the process and its limits, rather than a guarantee about every possible future investigation.

For an existing migration project, this is a reason to refine the acceptance criteria. Record which risks the move is meant to reduce and what evidence would demonstrate that reduction. If the project depends on an assumption of complete immunity from foreign investigations, that assumption needs correcting before the business relies on it.

A physical server also raises a continuity question

The news concerns the seizure of hardware, which makes availability worth considering alongside confidentiality. These are distinct security objectives: preventing someone from reading information and keeping a service usable. The UK's National Cyber Security Centre includes physical seizure, applicable legislation and resilience in its cloud security principles.

Consider a hypothetical manufacturer whose order-management application depends on one hosting location. Its continuity exercise should establish how it would recover if that location became unavailable, who would authorise the recovery, and how staff would reach the replacement system. That exercise is useful without predicting that the company will face a seizure.

Make the recovery evidence specific. A recent test should show which records were restored, how long the application took to become usable, and whether staff could actually sign in and complete essential work. A backup inventory alone cannot demonstrate that the business can resume taking orders.

Encryption deserves the same precision. The NCSC's cloud platform guidance treats encryption, provider access, workload separation and storage location as separate considerations. For procurement, that means asking who can decrypt information and under what circumstances, alongside where encrypted files are stored.

These are planning questions, not findings about Autistici/Inventati's technical arrangements. The reporting cited here does not establish its key management, recovery capability or the readability of the seized data. We should not fill those gaps with assumptions about what encryption or a different architecture would have achieved.

The next useful question is about accountability

For the Amsterdam case, further scrutiny should clarify how the request was assessed, what information was within scope and what happened to it afterwards. A fuller explanation would help customers judge the safeguards operating in practice. The prosecutor's statement and the industry association's concerns leave that discussion open.

For your own organisation, start with one important application and ask the hosting partner to explain the chain of responsibility in plain language. Identify the operator, the people authorised to access information, the legal escalation process and the tested recovery arrangement. Involve the person responsible for privacy or legal matters where the answers depend on jurisdiction or disclosure obligations.

That is a manageable next step for a smaller European company. It produces evidence for a hosting decision without requiring management to settle a disputed criminal-procedure case. It also gives the technical team requirements they can investigate, document and test.

European hosting should come with a clear account of the protections it provides and the limits it retains. The lesson we draw from Amsterdam is to make those promises specific enough to scrutinise before an incident forces the discussion.

Thinking about migration? Book a free consultation to discuss your situation.