Data Sovereignty / Source date:

Sweden's FRA Law and the Transit Data Problem

Surveillance of traffic crossing borders showed residency alone cannot address interception risk.

Engineer reviews a cable path at an illustrative fiber junction, not Swedish surveillance infrastructure.

Most data protection debate assumes data has a destination. It is collected here, stored there, occasionally transferred somewhere else, and the law attaches to those points. Sweden's signals intelligence legislation — the FRA law, passed in 2008 and in force from 1 January 2009 — raised a different question, one that almost no corporate compliance framework of the period had an answer for. What happens to data that is merely passing through?

Geography Made Sweden a Junction

The legislation authorised Sweden's National Defence Radio Establishment to intercept communications crossing the country's borders by cable. The significance was not the legal power itself — comparable powers existed elsewhere — but Sweden's position in the physical topology of the internet. A substantial share of traffic between Russia, the Baltic states, Finland and the rest of Europe crossed Swedish cable. Traffic between parties who had no relationship with Sweden, were not Swedish, and had never chosen to route through it, nonetheless transited Swedish territory because that is where the fibre ran. The law therefore reached communications belonging to organizations that had no Swedish presence, no Swedish customers and no Swedish data centre. Routing is determined by network engineering and commercial peering arrangements, not by corporate policy, and it changes without notice. The framework was eventually tested at the European Court of Human Rights. In Centrum för rättvisa v. Sweden, decided by the Grand Chamber in May 2021, the court examined the bulk interception regime and found deficiencies in the safeguards — notably around the handling of intercepted material and oversight of onward transmission to foreign partners — while accepting that bulk interception itself was not inherently incompatible with the Convention.

Why Corporate Compliance Missed It

Data protection programmes of 2009 mapped storage and transfer as discrete events with identifiable parties. That model has no slot for transit. Routing is invisible to the data controller. An organization can specify where data is stored and processed. It cannot specify the path a packet takes between two endpoints, which is chosen dynamically by carriers optimising for cost and capacity. Transit was not treated as a transfer. Legal analysis focused on where data came to rest. Data in motion across a third country was a technical detail, not a compliance event. Nobody had visibility. Very few organizations could describe the physical path of their international traffic, and fewer still monitored it for change. Encryption was inconsistent. Much corporate traffic of the period crossed the public internet unencrypted or weakly encrypted, on the assumption that the network was a neutral pipe.

The Question Generalised

Sweden was not exceptional. It was simply an early, legible example of a structural condition: internet traffic crosses jurisdictions that have legal powers over it, and the organizations generating that traffic have neither knowledge of nor control over the path. Subsequent disclosures about cable-tapping programmes in other countries confirmed the general case, and cross-border surveillance moved from a specialist concern to a mainstream one — particularly for European organizations reassessing transfers to jurisdictions with broad intelligence powers. The practical consequence is that data residency, as usually implemented, addresses only part of the exposure. Storing data in an approved country says nothing about the countries its traffic crosses on the way there, or about who is positioned along that route.

Map the journey and the destinationQualitative article summary, not geographic evidence, legal advice or a jurisdictional-risk guarantee.
LayerQuestion
StorageWhere does data rest?
ProcessingWhere can application, support and inference handle data?
TransitWhich paths carry traffic and how is content protected?
ReviewWhat can change routing and when are assumptions rechecked?

Qualitative summary of this article's source text, not a measured outcome or performance estimate.

Managing Transit Risk

  • Encrypt everything in transit, end to end. This is the only control that works without knowledge of the route. Strong TLS with modern cipher suites, certificate validation, and no exceptions for internal traffic crossing public networks.
  • Understand your actual network paths. Ask carriers and cloud providers which routes carry your inter-region traffic. The answer is often available and almost never requested.
  • Prefer private interconnects for sensitive flows. Dedicated circuits and provider backbone routing reduce exposure compared with the public internet, though they do not eliminate jurisdictional questions.
  • Keep regional traffic regional. Architect so that data processed in one region does not transit others unnecessarily. Many designs route through a central hub by habit rather than requirement.
  • Protect metadata too. Traffic analysis reveals who communicates with whom, when and how much, even when content is encrypted. That pattern is sensitive in itself for legal, financial and health-related communications.
  • Assess transit in transfer impact assessments. Where a transfer assessment is required, consider the route as well as the destination, and document the mitigations.
  • Re-check periodically. Routing changes with peering agreements, cable construction and outages. A path documented two years ago may not be the path in use today.

What It Means Now

The transit problem has grown rather than shrunk. Cloud architectures generate large volumes of inter-region traffic that customers never see. Content delivery networks distribute data to edge locations chosen algorithmically. AI services send prompts to inference infrastructure whose location is frequently undocumented and may differ from the storage region named in the contract. For organizations in the GCC, where regulated sectors carry explicit residency requirements, this is the gap most compliance programmes still have. A hosting contract that names a local region is necessary and insufficient: if the traffic reaching that region crosses jurisdictions with interception powers, the residency guarantee describes the endpoint and not the journey. Sweden's law was a useful early warning precisely because it was public, debated and specific. Most transit exposure is none of those things. The only control that holds regardless is the one available since 2009 and still inconsistently applied: encrypt it properly, everywhere, and assume the network belongs to someone else.

Common Questions

What was Sweden's FRA law?

Legislation passed in 2008, effective from January 2009, authorising Sweden's signals intelligence agency to intercept cross-border communications carried by cable — significant because large volumes of European internet traffic transit Swedish territory.

Why does data transit matter if data is stored in an approved country?

Residency describes where data rests. Traffic reaching that location may cross multiple jurisdictions with legal powers of interception, and routing is determined by carriers rather than by the data controller.

Can organizations control their network routing?

Only partially. Private interconnects, regional architecture and provider backbone routing reduce exposure, but public internet paths are chosen dynamically. Strong end-to-end encryption is the control that works without route knowledge.

Does encryption fully solve transit risk?

It protects content, which is the main exposure. Metadata — who communicates with whom, when and how often — remains visible and can be sensitive on its own.


Network Data Risk Briefing — Outpace traces where your traffic actually travels, not just where it lands, and closes the encryption and routing gaps that residency clauses never cover.

Continue reading

Talk to OPS

Start with the operating problem.