Network Infrastructure complete

• No asset inventory. The organisation has no central record of which DNS registrars, nameserver providers, CDN services, or ISPs it depends on. Different teams may use different providers without coordination, and no one holds a complete picture of the network dependency chain.
• Individual account ownership. Domain registrations, CDN dashboards, and ISP management portals are logged in under personal employee email addresses. If that employee leaves, the organisation may lose the ability to manage its own domains or network configuration.
• No change management. Firewall rules, DNS records, and CDN configurations are modified directly in provider consoles without review, approval, or documentation. There is no audit trail of who changed what and when.
• Reactive incident discovery. Network problems are discovered when users or customers report them, not through monitoring. The organisation has no alerting for DNS resolution failures, routing changes, or latency degradation.

Network infrastructure is the foundation on which every other digital capability rests. Without visibility into DNS, routing, and connectivity dependencies, the organisation is unable to assess its own attack surface, plan for provider failures, or respond to incidents with any confidence.

DNS hijacking, for instance, can redirect all traffic intended for the organisation to an attacker-controlled server. If the organisation does not even know which nameservers it uses, it cannot detect such an attack, let alone respond to it. Similarly, BGP route leaks can silently redirect traffic through unintended jurisdictions, a risk the organisation cannot evaluate without a documented network topology.

The regulatory exposure is equally severe. Under GDPR, IP addresses constitute personal data (as confirmed by the CJEU in the Breyer ruling). Network logs that contain IP addresses are therefore subject to data protection requirements, yet at Level 0, the organisation has no awareness of where such logs exist or who processes them. NIS2 Art 21 requires essential and important entities to implement baseline cybersecurity measures including risk analysis and incident handling, none of which are possible without basic network awareness.

At this level, network sovereignty is not a meaningful concept. The organisation lacks the foundational visibility required to reason about where its traffic flows, which jurisdictions it transits, or which providers could disrupt its connectivity. Establishing basic inventory and documentation is the prerequisite for any sovereignty consideration.

• Single-provider dependency. All DNS resolution, CDN distribution, DDoS protection, and often firewall management are handled by one provider. The organisation's entire internet presence depends on this single relationship continuing without disruption.
• No self-service capability. DNS record changes, firewall rule modifications, and CDN cache purges require submitting a support request to the provider. Response times depend on the provider's support tier, and the organisation cannot act independently during incidents.
• Opaque traffic routing. The organisation has no insight into where its traffic is routed geographically. User requests may transit through data centres in jurisdictions the organisation has not evaluated, including countries with expansive surveillance powers.
• Provider-dependent monitoring. Any visibility into network health comes exclusively through the provider's own dashboards. The organisation cannot independently verify uptime claims, latency metrics, or the provider's incident response accuracy.

Network infrastructure at Level 1 functions as a black box. The provider decides which nameservers resolve the organisation's domains, which edge locations serve its content, and which upstream networks carry its traffic. These decisions have direct sovereignty implications that the organisation cannot evaluate, let alone control.

When the network provider is a US-headquartered company, the CLOUD Act grants American law enforcement the authority to compel disclosure of data held by that provider, regardless of where the data is stored or where the traffic flows. For CDN providers specifically, this is significant because CDN edge nodes terminate TLS connections and can inspect traffic in cleartext. A US CDN provider serving European user traffic can, in principle, be compelled to provide access to that traffic content.

FISA Section 702 extends this further by authorising warrantless surveillance of non-US persons' communications for foreign intelligence purposes. If the organisation's CDN or DNS provider is subject to FISA obligations, European user data passing through that provider's infrastructure is within scope.

• "Our data is in Europe, so it is safe." Data residency for storage does not address network transit. If DNS queries resolve through US nameservers or traffic flows through a US CDN's edge nodes, the data is subject to US jurisdiction during transit regardless of where it is stored at rest.
• "The provider guarantees 99.9% uptime." Uptime guarantees in standard terms of service are typically backed by service credits, not by any obligation to maintain connectivity. A provider can meet its SLA obligations financially while the organisation suffers an outage it cannot resolve independently.
• "We can switch providers if needed." Without documented configurations, API access, or portable DNS zone files, migrating away from a single provider is far more disruptive and time-consuming than organisations typically anticipate.

At Level 1, the organisation has delegated its network sovereignty entirely to a third party. It cannot choose where its traffic flows, cannot verify the provider's security posture independently, and cannot respond to network incidents without the provider's cooperation. The organisation has no independent capability to operate, reconfigure, or recover its network presence.

• Negotiated SLAs. The organisation has moved beyond default terms of service to negotiate specific availability targets, latency guarantees, and incident response commitments. Financial penalties or termination rights are defined for SLA breaches.
• Self-service DNS and CDN management. The organisation can create, modify, and delete DNS records and CDN configurations through an API or management console without requiring provider support tickets. This enables faster incident response and routine operational agility.
• Data Processing Agreements for network metadata. DPAs with DNS, CDN, and ISP providers explicitly address the processing of network metadata. IP addresses, DNS query logs, and CDN access logs are recognised as personal data (per CJEU C-582/14), and the DPAs specify jurisdictional restrictions on where this data is processed.
• Independent log retention. Network access logs and DNS query logs are exported to an organisation-controlled system. This ensures that the organisation retains visibility into network events independently of the provider's retention policies and access controls.

The core limitation of Level 2 is the same across all dimensions: contractual obligations are only as strong as the enforcement mechanisms behind them. For network infrastructure, this gap manifests in several specific ways:

• Jurisdictional override. The CLOUD Act explicitly allows US authorities to compel US-headquartered providers to disclose data regardless of contractual data-residency restrictions. A DPA that specifies EU-only processing does not prevent a US provider from complying with a lawful US government order. The provider faces conflicting legal obligations, and US law typically prevails for US-incorporated entities.
• Traffic interception capability. CDN providers terminate TLS connections at their edge nodes, meaning they can inspect traffic in cleartext. A contractual promise not to inspect traffic does not eliminate the technical capability to do so, nor does it prevent compelled inspection under a court order.
• DNS resolution transparency. Even with API-based DNS management, the authoritative nameservers themselves are operated by the provider. The organisation controls the content of DNS records but not the resolution infrastructure that serves them. A provider-side compromise or government order affecting the nameserver infrastructure is outside the organisation's contractual reach.
• SLA enforcement asymmetry. When a network provider breaches its SLA, the organisation's recourse is typically limited to service credits or contract termination. Neither remedy addresses the immediate operational impact of a network outage. For organisations that depend on continuous connectivity, the financial remedy is far less valuable than the connectivity that was lost.

Level 2 is a reasonable posture for organisations that:

• Operate in regulatory environments where contractual safeguards are accepted as valid risk mitigation (noting that this acceptance may be challenged by future regulatory guidance or court rulings)
• Do not process highly sensitive data through their CDN or DNS infrastructure
• Have the operational capacity to monitor provider compliance but not yet the capability to operate self-managed network infrastructure
• Are actively evaluating the path to Level 3, with a credible migration plan that can be triggered if the risk posture changes

At Level 2, the organisation has established a contractual framework for network sovereignty but lacks technical enforcement. It controls what DNS records exist and how CDN caching behaves, but it does not control the infrastructure that serves those records or delivers that content. The provider remains a trusted intermediary whose cooperation is assumed, not verified.

• Self-managed authoritative DNS. The organisation runs its own authoritative nameservers (PowerDNS, Knot DNS, BIND, or equivalent) with DNSSEC signing enabled on all domains. A secondary DNS provider is configured for automated failover, ensuring that a single nameserver failure does not disrupt resolution. DNS zone files are managed as code, enabling audit trails and rollback.
• Infrastructure-as-code governance. Firewall rules, reverse proxy configurations, and CDN caching policies are defined declaratively in version-controlled repositories. Changes are deployed through CI/CD pipelines with mandatory peer review. This eliminates ad-hoc configuration changes and provides a complete audit trail of network infrastructure modifications.
• Independent network monitoring. The organisation operates its own monitoring stack (Prometheus, Grafana, Zabbix, or equivalent) that independently verifies DNS resolution, measures latency, detects routing anomalies, and monitors certificate transparency logs. Alerts trigger defined incident response procedures with on-call rotations.
• European CDN and DDoS mitigation. Content delivery and DDoS protection are provided by European-headquartered companies (such as Myra Security, Bunny.net, KeyCDN, or Gcore) or through self-managed edge infrastructure. This eliminates the CLOUD Act and FISA Section 702 exposure inherent in US-headquartered CDN providers.

Self-managed network infrastructure demands operational maturity comparable to that required for self-managed identity (DSCM-IAM Level 3):

• DNS as a Tier-0 service. If authoritative DNS fails, no one can reach the organisation's services. Clustering, geographic distribution, and tested failover procedures are essential. DNSSEC key rotation must be managed carefully to avoid validation failures.
• Infrastructure-as-code discipline. The value of IaC depends entirely on the discipline to use it consistently. If engineers bypass the pipeline and make changes directly in provider consoles, the code repository drifts from reality, and the audit trail becomes unreliable.
• Monitoring coverage. Network monitoring must cover not only the organisation's own infrastructure but also upstream provider behaviour. BGP route monitoring (through services like RIPE RIS or BGPStream) provides early warning of routing anomalies that could indicate hijacking or route leaks.
• European CDN evaluation. European CDN providers offer strong sovereignty positioning but may have fewer edge locations and lower total capacity than US hyperscalers. The organisation must evaluate whether the performance characteristics of European alternatives meet its requirements for all geographic markets.

The importance of DNS and routing sovereignty is not theoretical. In June 2019, Swiss data centre company SafeHost (AS21217) leaked over 70,000 routes to China Telecom (AS4134), causing European traffic from networks including Swisscom and KPN to be rerouted through China for over two hours. Organisations without independent routing monitoring had no visibility into this incident until it was reported publicly. At Level 3, the organisation's monitoring stack would detect such anomalies, even if it cannot yet prevent them at the BGP level.

At Level 3 the organisation has achieved substantive network sovereignty. It controls its DNS infrastructure, governs its network configuration through code, monitors its connectivity independently, and avoids jurisdictional exposure through US network intermediaries. The primary remaining gap is at the routing layer: without its own AS number and IP address space, the organisation cannot participate directly in BGP routing and remains dependent on upstream transit providers for connectivity.

The distinguishing characteristic of Level 4 is zero single-point-of-failure dependency on any external network provider. This goes beyond self-managing DNS and CDN (Level 3) to encompass the routing layer itself:

• Own Autonomous System. The organisation holds its own ASN and provider-independent IP address space through RIPE NCC. It participates directly in BGP routing, announcing its prefixes to multiple upstream providers and IXP peers. This means the organisation is a recognised, independent participant in global internet routing rather than a customer of someone else's network.
• IXP peering. The organisation peers at multiple European internet exchange points (DE-CIX, SwissIX, AMS-IX, or equivalent). Public peering via route servers provides connectivity to hundreds of networks through a single physical connection, while private peering arrangements with critical partners provide guaranteed bandwidth and lower latency for high-volume traffic relationships.
• Sovereign DNS (authoritative and recursive). Beyond operating authoritative nameservers (Level 3), the organisation also runs its own recursive DNS resolvers for internal use. This eliminates the dependency on external resolvers (Google, Cloudflare, or ISP-provided) that could log queries, inject responses, or be subject to foreign government surveillance.
• Self-managed DDoS mitigation. The organisation can defend against volumetric attacks using BGP-based techniques. Remotely Triggered Black Hole (RTBH) routing drops attack traffic at the network edge, while BGP flowspec rules enable more granular filtering. For application-layer attacks, the organisation operates its own scrubbing infrastructure or contracts with European-operated scrubbing providers as a complement to its own capabilities.

Holding an ASN brings with it the responsibility to secure the organisation's routing announcements. Resource Public Key Infrastructure (RPKI) with Route Origin Authorisations (ROAs) is the primary defence against BGP hijacking, where a malicious or misconfigured network announces the organisation's IP prefixes as its own.

The organisation publishes ROAs for all announced prefixes through the RIPE NCC portal, cryptographically binding its IP ranges to its ASN. This enables other networks that implement Route Origin Validation (ROV) to reject unauthorised announcements of the organisation's prefixes. While global ROV adoption remains incomplete (approximately 40% of globally routed prefix-AS pairs are covered), the trend is toward universal adoption, and publishing ROAs is a low-cost measure with significant protective value.

BGP hijacking is not a theoretical risk. In June 2019, over 70,000 routes were leaked through China Telecom (AS4134) due to a misconfiguration at Swiss data centre company SafeHost, rerouting European traffic from Swisscom, KPN, and other networks through China for over two hours. In June 2024, Cloudflare's 1.1.1.1 DNS resolver was hijacked by a Brazilian ISP, affecting 300 networks across 70 countries. At Level 4, the organisation's RPKI deployment and direct IXP presence provide both protection and rapid detection capabilities against such incidents.

European internet exchange points are predominantly operated as non-profit associations governed by their member networks. This governance model ensures that internet traffic exchange within Europe remains under European collective governance:

• DE-CIX Frankfurt is the world's largest internet exchange by connected networks, with over 1,100 connected networks and peak traffic exceeding 25 Tbps. It operates as an independent GmbH.
• SwissIX is Switzerland's primary IXP, operating across five sites (Basel, Bern, Glattbrugg, Lupfig, Zurich) with 229 members. Traffic grew 28% in 2025 alone, and the exchange is upgrading core sites to 400G capacity.
• AMS-IX in Amsterdam operates as a non-profit association with over 900 connected networks.

Peering at these exchanges provides the organisation with direct, low-latency connectivity to European networks without routing traffic through US-jurisdictional intermediaries.

Level 4 demands the highest level of internal network engineering capability:

• Dedicated network engineering team. The organisation needs staff with deep expertise in BGP operations, DNSSEC key management, IXP peering, and DDoS mitigation. This is typically a team of 2-4 network engineers for a mid-sized organisation, plus on-call coverage for routing incidents.
• RIPE NCC membership. Holding IP resources and an ASN through RIPE NCC requires maintaining a Local Internet Registry (LIR) membership, paying annual fees, and complying with RIPE policies for resource usage and registration data accuracy.
• Continuous BGP monitoring. The organisation must monitor its own routing announcements and the global routing table for anomalies affecting its prefixes. Tools like RIPE RIS, BGPStream, and MANRS (Mutually Agreed Norms for Routing Security) provide visibility into the global routing ecosystem.
• DNSSEC key lifecycle management. Operating both authoritative and recursive DNS with DNSSEC requires managing key signing keys (KSKs) and zone signing keys (ZSKs), performing regular key rollovers, and monitoring DNSSEC validation across the recursive resolver fleet.
• Network isolation testing. Annual testing confirms that internal services continue to function when external connectivity is severed, similar to the identity isolation test at DSCM-IAM Level 4.

Full network autonomy is appropriate for organisations that:

• Operate critical infrastructure or process sovereignty-sensitive data where any external network dependency is unacceptable
• Serve as network service providers themselves, where BGP autonomy is a business requirement
• Face specific state-level threats to network integrity, such as traffic interception, DNS manipulation, or routing-based censorship
• Have the engineering talent and operational maturity to sustain autonomous network operations at the required level of reliability

For many organisations, Level 3 (Controlled) provides sufficient network sovereignty with substantially lower operational complexity. The cost of maintaining an ASN, managing BGP peering relationships, and operating sovereign recursive DNS resolvers is significant. Organisations should pursue Level 4 only when their threat model and regulatory requirements explicitly demand routing-layer independence, and when they can sustain the required operational investment over the long term.

At Level 4 the organisation has no single external network dependency. It controls its own routing through BGP, resolves DNS through its own servers, and mitigates attacks using its own infrastructure. No foreign government can compel a network intermediary to intercept the organisation's traffic, because the organisation is itself the network operator. Its network sovereignty is limited only by the fundamental architecture of the internet (shared physical cables, root DNS governance) and its own operational competence.