NIS2 and Data Sovereignty: What the Directive Says About Controlling Your Data

What NIS2 has to do with controlling your data

The NIS2 Directive is described in most articles as a cybersecurity regulation — and it is. But anyone who only thinks about firewalls, patch management, and incident response overlooks a significant aspect: NIS2 places indirect but far-reaching requirements on controlling your data and the security of your supply chain — including the question of where and with whom your compliance data resides.

This article shows you where NIS2 touches on data sovereignty, what the directive concretely means for your tool selection, and why the data residency of your ISMS itself should be part of your risk assessment.

Art. 21: The foundation of NIS2 security requirements

Article 21 of the NIS2 Directive defines the risk management measures that affected entities must implement. The list in paragraph 2 reads like a best-of in information security:

• Risk analysis and security concepts
• Incident handling
• Business continuity and crisis management
• Supply chain security (lit. d)
• Security in acquisition, development, and maintenance of systems
• Assessment of the effectiveness of measures
• Cyber hygiene and training
• Cryptography and encryption
• Personnel security and access controls
• Multi-factor authentication

For data sovereignty, lit. d is particularly relevant: the security of the supply chain, including security-related aspects of the relationships between individual entities and their direct providers or service providers.

What "supply chain" means in the context of ISMS software

If you use a cloud-based ISMS solution, that provider is part of your supply chain. They process and store data that is directly related to your cybersecurity. From a NIS2 perspective, this is not just any service provider — it is one whose compromise can have immediate impact on your security posture.

Art. 21(2)(d) requires you to consider the risks in your supply chain. Concretely, this means:

• You must assess what risks emanate from your service providers.
• You must set security requirements for your service providers and monitor their compliance.
• You must estimate the impact of a compromise of the service provider on your own security.

For a SaaS provider hosting your risk register, control status, and incident data, these requirements are particularly relevant. The supplier assessment for this provider should be significantly more thorough than for a typical cloud service.

Data residency as part of the risk assessment

NIS2 requires in Art. 21(1) a "multi-hazard approach" to risk analysis. This means: you must consider not only technical threats (malware, DDoS, phishing), but all factors that can affect the security of your network and information systems.

Data residency is one such factor. Where your data resides determines:

• Which legal jurisdiction applies: Data on servers of a US company may be subject to the CLOUD Act, regardless of the physical server location.
• Who has technical access: The hosting provider, the SaaS vendor, and their subcontractors potentially have access to your data.
• How quickly you can respond to an incident: If the SaaS provider is compromised, your ability to respond depends on how transparently and quickly the provider communicates.
• Whether you can migrate the data in an emergency: Vendor lock-in with an ISMS solution is an operational risk that belongs in the risk assessment.

Practical risk assessment of data residency

For the risk assessment of your ISMS data residency, you can use the following questions as a starting point:

This assessment belongs in the risk register and should be updated regularly — especially when the provider changes their infrastructure, terms of service, or subcontractors.

Reporting obligations: What if the SaaS provider is hacked?

One of the most underestimated aspects of NIS2 is the reporting obligation for incidents that occur through service providers. The NIS2 reporting deadlines apply not only to direct attacks on your own systems, but also to incidents that have significant impact on the delivery of your services.

The scenario: Your ISMS provider is compromised

Let us assume the cloud provider of your ISMS software is hacked. Attackers exfiltrate data from multiple customers, including your risk registers, action plans, and incident reports. What happens now?

Step 1: The provider must inform you. Depending on the contractual agreement and applicable data protection laws, the provider must inform their customers about the incident. But how quickly? Many terms of service contain no specific timelines. Experience shows that days to weeks often pass between discovery and customer notification.

Step 2: You must assess whether the incident is reportable. Under NIS2, you must submit an early warning within 24 hours and a more detailed report within 72 hours to the competent authority if the incident has "significant impact" on the delivery of your services.

And here it gets complicated: the 24-hour deadline starts from the moment you become aware of the incident. If the provider informs you three days later, you have 24 hours from that point. But you have no control over when you are informed.

Step 3: You must assess the incident internally. Which of your data is affected? What is the impact of the disclosure of your risk register? Do you additionally need to report a DSGVO (GDPR) data breach because personal data is affected? Did the incident reports contain information about third parties?

Step 4: You must take action. Change passwords, review access, possibly switch ISMS software. And you must document what you did.

The fundamental problem

In a SaaS incident, you depend on the provider's communication and cooperation. You cannot forensically investigate what happened yourself. You cannot determine which data is affected yourself. You must trust the provider — precisely at the moment when their trust capital is at its lowest.

With a self-hosted ISMS, this dependency is eliminated. You have complete control over forensics, assessment, and communication. Of course, your own infrastructure can also be attacked, but then you control the process yourself instead of waiting for a third party's email.

In ISMS Lite, the reporting process for security incidents is mapped as a workflow — from initial assessment through early warning to the final report. Because the data resides locally, you can act immediately in an emergency without depending on external notifications.

BSI recommendations on data sovereignty

The BSI (Federal Office for Information Security) has addressed data sovereignty in several publications, even though it does not always use the term explicitly.

BSI C5: Cloud Computing Compliance Criteria Catalogue

The BSI C5 criteria catalogue defines requirements for cloud providers regarding:

• Transparency about data location: The provider must disclose in which countries and data centers customer data is processed and stored.
• Control over subcontractors: The provider must document which subcontractors are used and where they are located.
• Data portability: Customers must be able to export their data in a standardized format.
• Deletion after contract end: Data must be verifiably deleted after the contract ends.

When evaluating a cloud ISMS provider, a C5 attestation — or at least answering the C5 criteria — should be part of your requirements.

BSI IT-Grundschutz and data sovereignty

The BSI IT-Grundschutz Compendium contains relevant building blocks:

• OPS.1.2.4 Teleworking and OPS.1.2.5 Remote Maintenance: Rules for data access from outside the corporate network.
• OPS.2.2 Cloud Usage: Requirements for the selection and use of cloud services, including aspects of data sovereignty.
• CON.1 Cryptographic Concept: Requirements for encryption that directly address the question of who controls the keys.

The BSI explicitly recommends considering "digital sovereignty" as a criterion when selecting cloud services. This does not mean that cloud services should be fundamentally rejected, but that risks must be consciously assessed and managed.

Gaia-X and the European perspective

At the European level, the Gaia-X initiative pursues the goal of building a sovereign data infrastructure in Europe. For practical purposes in SMEs, Gaia-X is not yet very relevant, but the political direction is clear: Europe wants to reduce dependence on non-European cloud providers. NIS2 is one building block of this strategy.

Self-hosted as risk mitigation under NIS2

Self-hosted solutions do not solve all problems, but they significantly simplify compliance with several NIS2 requirements.

Minimizing supply chain risk

Every external service provider is a potential risk in the supply chain. With a self-hosted ISMS solution, you reduce this risk to the software vendor themselves (who delivers the software but has no access to your data) and your own hosting provider (which you select and control yourself).

This is a significant difference from a SaaS solution, where the vendor is simultaneously software manufacturer, operator, and data processor. With a self-hosted solution, these roles are separated, making risk management easier.

Concretely, this means for NIS2 documentation: instead of evaluating a complex service provider with multiple roles, you have two clearly delineated supplier relationships. The software vendor delivers updates and support but has no access to your production data. The hosting provider provides infrastructure but does not know the application. This separation makes the risk assessment under Art. 21 more precise and the documentation more traceable for the auditor.

And if you run the ISMS on your own hardware in your own server room, the hosting provider as a supplier is eliminated entirely. The entire chain is in your hands.

Simplifying reporting obligations

If your ISMS runs on your own infrastructure, you have full control over assessment and reporting in the event of an incident. You do not have to wait for notification from a third party but can immediately begin the initial report to the BSI. Forensics is in your hands, as is data analysis.

Fulfilling documentation obligations

NIS2 requires you to be able to demonstrate the effectiveness of your measures. For data residency, this means: you must be able to document where your data resides, who has access, and what protective measures are in place.

With a self-hosted solution, you can provide this evidence yourself. You show the auditor your server, your firewall rules, your backup concept, and your access logs. With a SaaS solution, you reference the certifications and assurances of the provider — which the auditor may or may not accept, depending on the depth of their review.

A concrete example: the auditor asks how encryption of ISMS data is implemented. With self-hosted, you show the disk encryption (LUKS), the TLS configuration of the web server, and the backup encryption (AES-256). You control every key. With a SaaS solution, you reference the provider's cryptography policy and hope it is current and reflects reality. The difference in evidence depth is significant.

Practical implementation

The decision for self-hosted does not mean you have to build everything yourself. Ready-made self-hosted ISMS solutions like ISMS Lite offer the same functionality as cloud solutions but run on your infrastructure. Installation effort is typically a few hours; ongoing operation requires the usual administration tasks: applying updates, configuring backups, setting up monitoring.

For a company with a functioning IT department, this is not a significant additional effort compared to managing another internal system. The gain in data sovereignty and the simplification of NIS2 documentation obligations outweigh it in most cases.

Checklist: Data sovereignty under NIS2

Common mistakes in NIS2 implementation regarding data sovereignty

Mistake 1: Treating data sovereignty only as a data protection topic. NIS2 and GDPR are different regulations with different requirements. Even if your cloud provider is GDPR-compliant, that does not automatically meet NIS2 requirements for supply chain security and risk assessment of data residency.

Mistake 2: Equating "EU data center" with data sovereignty. A data center in Frankfurt operated by a US company is still subject to the US CLOUD Act. The physical location alone says little about actual data sovereignty. What matters is the operator's headquarters, the applicable legal jurisdiction, and the technical access capability.

Mistake 3: Not classifying the ISMS provider as a critical service provider. Many companies carefully evaluate their IT service providers but forget the compliance software. Yet the ISMS contains the company's most sensitive security information. The ISMS provider belongs in the highest criticality tier of the supplier assessment.

Mistake 4: Not agreeing on contractual reporting obligations. If your SaaS ISMS provider is compromised, you need a contractual commitment on the timeframe within which you will be informed. Without such a clause, you risk missing NIS2 reporting deadlines because you learn of the incident too late.

Mistake 5: Underestimating your own infrastructure. Self-hosted is not a set-and-forget solution. If you run your ISMS on an unpatched server, you have traded supply chain risk for operational risk. Self-hosted only works if you master the fundamental security measures for operating your own systems: patch management, backup, monitoring, access control.

What this means for your NIS2 implementation

Data sovereignty is not a buzzword or a marketing argument. NIS2 makes controlling your data a concrete compliance topic. When you implement the directive, review not only your firewalls and password policies, but also where your compliance data resides and who can access it.

The choice between cloud and self-hosted is not black and white. There are cloud providers with high transparency and strong security commitments, and there are self-hosted installations on poorly maintained servers. The key lies in making a conscious, documented decision based on a risk assessment — not in blind trust in a provider's marketing promises. NIS2 expects exactly this: that you know, assess, and manage the risks. For your ISMS data, this applies especially.

Further reading

• Your Company's Crown Jewels: Why ISMS Data Needs Special Protection
• Self-Hosted vs. Cloud: Data Sovereignty for Compliance Software
• Securing ISMS Data: Backup Strategy for Self-Hosted Compliance Systems
• NIS2 Checklist: All Requirements at a Glance
• NIS2 Reporting Deadlines: 24h, 72h, 1 Month