Why NIS2 makes the hyperscaler question board-level

The conversation about hyperscaler dependency used to happen between architects and security leads. It was a technical preference, weighed against cost and capability. NIS2 has moved it into the boardroom.

What changed with NIS2

The Network and Information Security Directive 2 introduced a materiality threshold that most critical infrastructure operators did not previously have to articulate: where does your cryptographic trust estate reside, and under whose legal jurisdiction?

For organisations relying on hyperscaler-hosted key management, the answer is increasingly uncomfortable. Encryption keys stored in a US-headquartered cloud provider sit within reach of CLOUD Act compulsion. That is not a hypothetical risk — it is a structural one.

The fiduciary question

Directors of entities covered by NIS2 are now personally accountable for cybersecurity governance decisions. When auditors ask "where are your keys," the answer "in the cloud" is no longer sufficient. You need to be able to demonstrate:

• Which legal jurisdiction governs key access
• What compelled-disclosure mechanisms apply to your provider
• How that exposure maps against the sensitivity of what you are protecting

What to do about it

The answer is not to rip out existing infrastructure. A phased approach — beginning with the most sensitive key material and progressively migrating to sovereign HSM environments — is defensible, auditable, and achievable without service disruption.

The first step is a sovereignty audit: mapping where key material lives, what it protects, and what the legal exposure looks like. That mapping is typically where a first conversation with our team begins.