The uncomfortable fact about your telemetry

Security teams tend to think of their data as technical: log lines, hashes, IP addresses, indicators. Not personal, not sensitive, just noise from machines.

The law disagrees. Under Regulation (EU) 2016/679 (GDPR), personal data is any information relating to an identifiable person. That definition catches a lot of what flows through a SOC:

  • IP addresses are personal data. The Court of Justice of the EU settled this in the Breyer case (C-582/14): a dynamic IP is personal data in the hands of someone who can link it to a person.
  • Email addresses in a phishing sample or a breach dump.
  • Usernames in authentication logs.
  • Device identifiers, cookies, and session tokens.

So when you paste an indicator into an online analysis service, or pipe your alerts to a cloud enrichment API, you are processing personal data. And if that service runs outside the EU, you may be carrying out an international data transfer.


Why the transfer question matters

GDPR lets personal data move freely inside the EU and the European Economic Area. Sending it outside that zone (a "third country") is only lawful under specific conditions in Chapter V of the regulation. You need one of:

  • An adequacy decision: the Commission has declared the destination country offers protection essentially equivalent to the EU.
  • Appropriate safeguards, most commonly Standard Contractual Clauses (SCCs) or Binding Corporate Rules.
  • A narrow derogation for specific situations.

The awkward part is that a large share of security tooling is hosted in the United States, and US transfers have been legally turbulent for years.


Schrems II and why it still shapes decisions

In July 2020 the CJEU issued the Schrems II ruling (case C-311/18). It struck down the EU-US Privacy Shield, the framework thousands of companies relied on for transatlantic transfers. The court's reasoning: US surveillance law (notably FISA Section 702) gave public authorities access to data in ways that were not proportionate by EU standards, and EU individuals had no effective redress.

The ruling kept SCCs alive but added a condition. You cannot just sign the clauses and move on. You must run a transfer impact assessment, judging whether the laws of the destination country undermine the protection the clauses promise, and add supplementary measures (such as strong encryption where the provider cannot access the keys) when they do.

In 2023 the EU-US Data Privacy Framework arrived as a new adequacy decision, restoring a lawful route for transfers to certified US organisations. That helps, but it is narrower than it sounds: it covers only participating companies, it has already been challenged, and the underlying surveillance concerns that drove Schrems II have not disappeared. Building your compliance posture on a framework that could be litigated again is a risk many EU teams would rather not carry.

The pragmatic conclusion a lot of European security teams have reached: if the data never leaves the EU, the whole transfer analysis simply does not apply. That is the appeal of data sovereignty. It removes an entire category of legal uncertainty.


The specific risk with security tools

Enrichment and analysis tools are worth singling out because of what you feed them and how much you feed them.

  • Volume: automated enrichment can send thousands of indicators a day, each potentially carrying personal data.
  • Sensitivity: incident data often relates to victims, employees or suspects. A phishing report can contain a colleague's real name and mailbox.
  • Retention: many services keep submitted samples indefinitely and may share them with a wider community. Public malware sandboxes are notorious for exposing documents that internal analysts uploaded without thinking, sometimes with confidential content inside.

That last point is worth dwelling on. When you upload a suspicious document to a shared analysis platform, you may be publishing it. Analysts have leaked internal invoices, contracts and credentials this way. The convenience of "just submit it" hides a disclosure decision.


Questions to ask a security vendor

Before you route telemetry through any third-party tool, get clear answers to these:

Question Why it matters
Where is the data physically stored and processed? Determines whether a transfer occurs at all.
Are sub-processors listed, and where are they located? A US sub-processor reintroduces the transfer question.
How long is submitted data retained, and can retention be configured? Controls your exposure window and supports data minimisation.
Is submitted data shared with third parties or a community? Prevents accidental disclosure of internal material.
Who can access the data, and is it encrypted at rest and in transit? A Schrems II supplementary measure and a baseline control.
Can you sign a Data Processing Agreement, and does it include SCCs if needed? Required under GDPR Article 28.
Is there an option to delete data on request? Supports data-subject rights and cleanup after investigations.

If a vendor cannot answer where your data lives, that is your answer.


Data minimisation is still your job

Hosting location is not a free pass. GDPR's principles apply wherever the data sits. Two habits reduce your exposure regardless of provider:

  • Do local analysis when you can. Some tasks never need to leave your machine. Decoding a token, testing a regex, or extracting indicators from a log can happen client-side. mlab.sh runs several free tools this way, including a JWT decoder and a regex tester, where the input is processed in your browser rather than shipped to a server. If a tool does the work locally, there is no transfer to assess.
  • Minimise before you send. Strip fields you do not need. Redact victim names from a sample before submitting it to an external service. Send the hash, not the whole document, when the hash is enough.

Where mlab.sh sits

mlab.sh runs on EU-hosted infrastructure with GDPR-compliant, controlled data retention. For teams that would rather not run a transfer impact assessment every time they enrich an indicator, keeping the data inside the EU removes that step. Submitted data is retained on a defined, controlled basis rather than indefinitely, which supports the data minimisation and storage limitation principles.

This is not a claim that US-hosted tools are unusable. Plenty of organisations run them lawfully with SCCs, adequacy under the Data Privacy Framework, and supplementary measures. The point is narrower: hosting location is a real variable in your compliance calculation, not a marketing detail. For regulated sectors under NIS2 and DORA, where supply chain and third-party risk are explicit obligations, it is a variable auditors will ask about.


The takeaway

Security data is personal data more often than teams assume. Sending it abroad is a transfer with legal conditions attached, and Schrems II made those conditions demanding. You have three levers: analyse locally where possible, minimise what you send, and choose where your data lives with open eyes.

Data sovereignty is not about distrust of any one country. It is about removing uncertainty from a process you repeat thousands of times a day.

Know where your indicators go before you paste them. The cheapest transfer to assess is the one that never happens.