Data Sovereignty in Your ISMS: Why Your Risk Register Doesn't Belong in the Cloud

Your ISMS Knows More About You Than Any Other System

Your ERP knows your revenue. Your CRM knows your customers. But your ISMS knows your weaknesses. It documents every vulnerability you have found, every risk you have accepted, every incident that has occurred, and every control you have not yet implemented. It contains the complete map of your attack surface.

If someone wants to know where your company is vulnerable, they don't need to scan your network. They just need to read your risk register.

Yet many organizations entrust exactly this data to a SaaS platform running on servers they don't control, operated by a provider whose terms of service can change at any time, in a jurisdiction that may not meet their data protection requirements.

This article explains why data sovereignty in ISMS software is not a side issue but a strategic decision with implications for compliance, security, and long-term costs.

What Does Data Sovereignty Mean?

Data sovereignty describes the ability to maintain full control over your own data: where it is stored, who has access, which laws govern it, and how it is processed. It is not about rejecting cloud technology in principle. It is about consciously deciding which data you entrust to which third party and which data you keep under your own control.

For most business applications, cloud hosting is a sensible choice. Email, project management, collaboration — all of this works excellently in the cloud. But there is a category of data where loss of control is not just annoying but potentially business-damaging. And ISMS data falls into this category.

The DSGVO (GDPR) states in Recital 7 the right of natural persons to maintain control over their data. Data sovereignty extends this principle to corporate data: you decide, not the provider.

The Crown Jewels: What Your ISMS Actually Contains

To understand why ISMS data is particularly sensitive, it helps to look at the specific contents. A fully operational ISMS according to ISO 27001 contains, among other things:

Risk registers and risk assessments. Every identified risk with its probability of occurrence, potential damage, and current treatment status. Anyone who reads this register knows every weak point in your organization — including the risks you have consciously accepted because of budget or resource constraints.

Vulnerabilities and control status. Your vulnerability management documents open vulnerabilities, prioritized by criticality, together with the planned remediation date. A list of open vulnerabilities in the wrong hands is an invitation.

Incident details. Every security incident is documented: what happened, which systems were affected, which data was exposed, how the response was handled. Incident reports contain technical details that go far beyond what is externally communicated.

Audit reports and findings. Internal audits and external assessment reports document where your ISMS does not yet meet requirements. Audit findings are essentially a prioritized to-do list of your security gaps.

Access control concepts and network diagrams. Your access control concept shows who has access to which systems. Combined with network diagrams, this provides a detailed picture of your infrastructure.

Action plans and implementation status. What is planned but not yet implemented. This information is particularly sensitive because it shows where you know you are vulnerable but have not yet taken action.

In summary: your ISMS contains the complete security profile of your organization. Strengths and weaknesses, including the timeline. There is no single system that provides a more comprehensive overview of your attack surface.

The Paradox: Security Data in Insecure Hands

This creates a contradiction that is often overlooked in daily operations. You build an ISMS to systematically improve your organization's information security. You document your vulnerabilities, your risks, and your controls. And then you upload all of this to a cloud tool that itself represents a potential vulnerability.

This is not a theoretical scenario. Compliance platforms are attractive targets because they aggregate security information from many organizations in one place. A successful attack on a SaaS ISMS platform does not yield the data of one organization but the security profiles of hundreds or thousands of organizations in a single breach.

The question is not: is the cloud provider insecure? Most major providers operate professional infrastructure with high security standards. The question is: do you want to bear the risk that a third party — regardless of how good they are — has access to your most sensitive security data?

During an audit, this question becomes concrete. The auditor asks: where is the ISMS data processed? Who has access? Which legal framework applies? Do you have a data processing agreement? How do you ensure that the provider's technical and organizational measures meet your protection level? With self-hosting, the answers are: with us, we do, German law, not necessary, we control them ourselves.

CLOUD Act and Schrems II: The Jurisdiction Problem

The CLOUD Act (Clarifying Lawful Overseas Use of Data Act) is a US federal law from 2018. It obligates US companies to hand over stored data upon order from American authorities — regardless of where in the world these data are physically stored. A European server location does not protect against a CLOUD Act access request as long as the operator is a US company or a subsidiary of a US corporation.

This affects all major cloud providers: AWS, Azure, Google Cloud. And it affects every SaaS platform running on the infrastructure of these providers. If your ISMS tool is hosted on AWS in Frankfurt but the provider is headquartered in the US, the CLOUD Act applies.

The Schrems II ruling by the CJEU in 2020 further tightened the situation. The European Court of Justice declared the EU-US Privacy Shield invalid because US surveillance laws do not provide an adequate level of protection for personal data of EU citizens. Its successor, the EU-US Data Privacy Framework of 2023, is viewed critically by data protection experts and could be struck down again.

What does this mean for your ISMS? The data in your risk register is not necessarily personal data, but it is highly sensitive. The GDPR logic shows the direction: if even personal data should not easily fall within the scope of US law, how do you justify storing your complete security architecture within exactly that scope?

This is not about paranoia. It is about a sober risk analysis. The probability that a US authority will request specifically your risk register may be low. But the possibility exists, and the mere existence of this possibility creates a compliance problem. Your auditor will ask: have you assessed this risk? What is your risk treatment? And "it probably won't happen" is not an acceptable answer in an ISMS based on systematic risk management.

European regulatory authorities are also becoming more attentive. The French data protection authority CNIL has already ruled several times against the use of US cloud services in sensitive areas. The German Data Protection Conference recommends preferring European providers without US parent companies for particularly sensitive data. ISMS data clearly falls into the "particularly sensitive" category.

For NIS2-regulated companies, there is an additional aspect. The NIS2 directive requires in Article 21 appropriate risk management measures, including supply chain security. A cloud-based ISMS tool is part of your supply chain. You must be able to demonstrate that this service provider does not compromise your security level. With a self-hosted system, this obligation to provide evidence is eliminated.

Vendor Lock-in: The Creeping Dependency

Vendor lock-in is often underestimated when selecting compliance software because it builds up slowly. At the beginning, SaaS seems uncomplicated: create an account, enter data, get started. But with every month that you document risks, track controls, and create audit reports, the dependency grows.

After two years, hundreds of hours of work are invested in the system. Your entire risk register, your protection needs assessment, your control history, your audit reports, your training records. Switching means not just setting up a new tool but migrating this entire history.

And this is precisely where it becomes problematic. Most SaaS providers do not offer a complete data export. You might get a CSV with the risk titles, but not the linked controls, not the audit history, not the document versions. The data legally belongs to you, but practically you cannot access it.

What happens in these scenarios?

The provider raises prices. SaaS prices increase regularly, typically 5 to 15 percent per year. After five years, you pay significantly more than at the start, and switching is costly because you need to migrate years of data. You are effectively trapped.

The provider gets acquired. Startups in the compliance space are frequently acquired by larger providers. The product strategy changes, features get discontinued or moved into more expensive packages. Your workflows suddenly no longer work.

The provider shuts down. Not every SaaS company survives. If your ISMS provider ceases operations, you need an alternative quickly — in the middle of ongoing ISMS operations, possibly shortly before an audit.

The provider changes terms of service. New privacy policies, changed storage locations, expanded analytics of your data. You agree or you lose access.

Self-hosting does not completely eliminate these risks — even with on-premise software there are licensing models and update cycles. But you retain control over your data, your pace, and your infrastructure. If you are dissatisfied, you export your data and switch, without a provider being able to cut off your access.

TCO Comparison: SaaS vs. Self-Hosted Over 5 Years

The argument for SaaS often goes: lower initial investment, no dedicated server, no IT overhead. This is true for the first few months. Over a five-year period, the calculation looks different.

Let's take a concrete example: a company with 150 employees, one ISM (Information Security Manager) and four additional ISMS users (IT manager, CISO, quality manager, data protection officer).

Scenario A: Typical SaaS ISMS Tool

This does not include external consulting costs for data migration in case of a switch. Nor does it account for the risk that the provider bills user licenses on a per-seat basis and costs double when ten users are needed instead of five.

Scenario B: Self-Hosted with ISMS Lite

The difference is substantial: a factor of 5 to 7 over five years. And ISMS Lite is not limited to a specific number of users. Whether five or fifteen people work in the system, the price stays the same.

Of course, self-hosting has requirements: you need someone who can start a Docker container and configure a backup. For a company with 150 employees and an IT department, this is everyday business, not a special service.

On-Premise as a Compliance Advantage in Audits

In audits, data storage is regularly scrutinized. And here, self-hosting turns from a perceived disadvantage into a tangible advantage.

Evidence in ISO 27001 Audits

An ISO 27001 auditor checks, among other things, compliance with Annex A.5.23 (cloud services). If your ISMS tool itself is a cloud service, you must demonstrate that you have evaluated the provider, that a data processing agreement exists, that the technical and organizational measures are documented, and that an exit plan is in place. These are four additional evidence points that are completely eliminated with self-hosting.

Instead, you document: the ISMS tool runs on server X in our data center (or with our German hosting provider Y), data is stored encrypted, backups reside on a separate system, and access is restricted to ISMS roles. Done. No third-party management, no supplier assessment questionnaire, no additional risk assessment.

Evidence in NIS2 Audits

NIS2 requires in Article 21 paragraph 2d the security of the supply chain. Every cloud service you use is part of this supply chain and must be evaluated. A self-hosted tool is under your own control and is therefore not a supply chain link but an internal system.

Data Protection and GDPR

If your ISMS processes personal data — and it does at the latest when incident reports contain employee names — you need a data processing agreement, a data protection impact assessment, and an assessment of international data transfers with a cloud provider. With self-hosting in your own facility, you process the data as the controller yourself, without a data processor.

Backup and Data Sovereignty

You determine the backup strategy. You know where the backups are stored, how often they are created, and how quickly a restore is possible. With a SaaS provider, you must trust that their backup strategy meets your requirements. Typically, you cannot test this yourself.

What Self-Hosting Is Not: A Rejection of Modern Technology

A common misconception: self-hosting means running servers in the basement and forgoing updates. That may have been true in 2010. Today, self-hosting means deploying a Docker container on a VPS or within your own infrastructure. This takes less than an hour and requires no specialized skills beyond what every IT department in a mid-market company brings to the table.

Modern self-hosted software is no less convenient than SaaS. You get a web interface, automatic updates (which you can apply in a controlled manner), backups at the push of a button, and an API for integrations. The only difference: the data stays with you.

Self-hosting and cloud are not mutually exclusive. You can run your ISMS tool on a VPS with a German hosting provider. The infrastructure is then "in the cloud" in the technical sense, but under your control. The critical point is not whether the server physically resides in your building, but whether you have administrative control over the system and data.

It helps to think of the distinction this way: with SaaS, you rent a finished apartment — the landlord has a spare key and can change the house rules. With self-hosting on a VPS, you rent a shell and finish it yourself. The hoster provides the infrastructure, but they have no access to your application and your data. You decide who gets in.

Checklist: Data Sovereignty When Choosing an ISMS Tool

When evaluating an ISMS tool, check these data sovereignty points:

• Data location: Where is the data physically stored? Which legal framework applies?
• Third-party access: Can the provider access your data? Under what conditions?
• CLOUD Act: Is the provider or its infrastructure provider subject to the US CLOUD Act?
• Data export: Can you export all data completely at any time? In what format?
• Data portability: Is the exported data in an open format that can be imported into another system?
• Vendor lock-in: What happens when you want to switch providers? What effort is involved?
• Price commitment: Is there a contractual price guarantee? How often has the price been raised in the past?
• Exit strategy: What happens if the provider ceases operations? How quickly can you migrate?
• DPA and TOMs: Is there a data processing agreement? Are the provider's technical and organizational measures documented and reviewed?
• Backup control: Can you determine the backup frequency and storage location yourself?
• Encryption: Who holds the keys? Can the provider decrypt the data?
• Audit rights: Do you have the right to audit the provider or review audit reports?

Common Objections to Self-Hosting — And the Answers

"We don't have capacity for server operations"

A Docker container is not server operations in the traditional sense. Setup takes under an hour, updates are a single command, backups run automatically. The ongoing effort is a few hours per quarter. If your company can maintain a printer, it can run a Docker container.

"SaaS is more secure because the provider has experts"

The infrastructure security of major cloud providers is indeed at a high level. But infrastructure security is only one aspect. The question of data sovereignty — who has access, which laws apply to the data, what happens in case of a breach at the provider — is not answered by even the best infrastructure.

"Cloud solutions are always up to date"

Self-hosted software can receive security patches just as promptly as SaaS. The difference: you decide when to apply an update after testing it in a staging environment. With SaaS, the update is applied whether you are ready or not.

"We don't want our own data center"

You don't need one. A VPS with a German hosting provider for 5 to 15 euros per month is fully sufficient for an ISMS tool with five to fifteen users. You rent computing power, but you control the system.

How ISMS Lite Implements Data Sovereignty

ISMS Lite was designed from the start as a self-hosted solution because the founders experienced exactly the problems described in this article in practice: customers whose risk registers were stored with US cloud providers. Companies that could not switch after a price increase because no complete export was possible. ISMs who had to explain in audits why their vulnerability documentation was stored with a third-party provider without a data processing agreement.

Docker-based. ISMS Lite runs as a Docker container on any Linux server, Windows server, or within an existing container infrastructure. docker compose up and the system is operational. No complex installation, no dependencies, no database configuration.

Your server, your rules. The data resides where you specify. On your own server in a data center, with a German hosting provider of your choice, or on a VM in your corporate network. You control access, firewall rules, and encryption.

Full JSON export. All data can be exported at any time as structured JSON: risks, controls, assets, audits, documents. No lock-in, no proprietary formats. If you want to switch, you take your data with you.

Unlimited users. Whether three or thirty users work in the system — the price stays the same. No per-seat pricing that drives costs higher with each additional person.

Transparent pricing. ab 500 Euro pro Jahr oder als Einmalkauf für 2.500 Euro. No hidden costs, no add-ons, no "enterprise tier" for features that should be standard.

Common Mistakes Regarding Data Sovereignty in ISMS

Confusing "European server location" with data sovereignty. Many providers advertise "data in Germany" or "EU hosting." This sounds good, but if the provider is a US company or uses US infrastructure, the server location does not protect against the CLOUD Act. What matters is not where the server is located, but who has legal control over the data.

Having no exit plan. Many companies adopt a SaaS ISMS without first checking what an exit would look like. Test the data export before entering productive data, not only when you need to switch.

Forgetting to classify ISMS data. ISMS data is often overlooked in your own classification policy. Risk registers, vulnerability lists, and audit reports belong at least in the "Confidential" category. If your classification policy states that confidential data may not be stored with third parties, you cannot use a cloud ISMS without documenting and justifying an exception.

Not reviewing the SaaS provider's TOMs. A data processing agreement alone is not enough. You must know and evaluate the provider's technical and organizational measures. How do they encrypt the data? Who has internal access? What does their incident management look like? Many companies sign the DPA and file it away without ever reading the TOMs.

Misunderstanding self-hosting as "doing everything yourself." Self-hosting does not mean you run the entire stack yourself. You use a finished application and merely determine where it runs. The development effort lies with the vendor, the operational responsibility for the infrastructure lies with you. This is less effort than many fear.

Conclusion

Data sovereignty in ISMS software is not an ideological question or tech purism. It is a risk management decision. You document your vulnerabilities, your risks, and your control gaps — and you should not give up control over that documentation. Self-hosting gives you that control back: over the storage location, over access, over costs, and over the timing of your departure when something no longer fits.

Further Reading

• Self-Hosted vs. Cloud: Datensouveränität bei Compliance-Software
• Risikobewertung im ISMS: Methodik, Matrix und Praxisbeispiel
• ISMS-Software auswählen: Worauf es bei der Evaluation ankommt
• Was kostet ein ISMS? Budget, Aufwand und ROI realistisch einschätzen
• Build vs. Buy: Eigenentwicklung oder fertige Lösung für ISMS-Prozesse