ISMS Without Cloud Dependency: Why Offline Capability Is Not a Relic

TL;DR

Cloud ISMS systems are a single point of failure: no internet means no access to risk assessments, controls, and documentation.
Audits frequently take place on-site — in production halls, server rooms, or meeting rooms without stable Wi-Fi. Not being able to access your data in those moments makes a poor impression.
Critical infrastructure operators, companies with OT environments, and organizations with classified information requirements often need air-gapped systems that run offline by design.
During a security incident, the internet may go down or be deliberately severed. The ISMS must be available precisely when it is needed most.
Self-hosted ISMS solutions run on the internal network and are available independently of external services.

The problem nobody talks about

Cloud software is the standard today. For most use cases, it works well. But there is one category of software where "works most of the time" is not good enough: systems that must be available during emergencies and under stress. Your ISMS is one of them.

An ISMS is not a project management tool that can tolerate a few hours of downtime. It contains your incident response plans, your emergency contacts, your risk assessments, your documentation. It is the system you open when something goes wrong. And when it is unreachable at exactly that moment — because the internet connection has failed, the cloud provider is experiencing an outage, or you deliberately severed internet access — you are left empty-handed.

This is not a theoretical risk. It is an availability problem, and availability is one of the three pillars of information security.

Scenario 1: On-site audit without a stable network

External audits do not take place in perfectly equipped conference rooms. They take place where the processes run: in the server room, on the production floor, in the ISM's office who may be at a branch location. And not everywhere is there stable Wi-Fi or cellular reception sufficient for a cloud application.

A typical audit scenario: the external auditor wants to review the risk assessment for the OT systems. You open your cloud ISMS, and the page loads. And loads. The Wi-Fi in the production hall is designed for IoT sensors, not for browser applications with hundreds of records. After 30 seconds, the browser gives up. You apologize, walk back to the office, export a PDF, and walk back to the hall.

That is not catastrophic. But it costs time, looks unprofessional, and shows the auditor something they will note: the ISMS availability depends on an external internet connection. And when they then ask whether this dependency appears in the risk assessment, things get uncomfortable.

With a self-hosted system running on the local network, you open the browser and the data is there. In the server room, at the branch office, on the production floor — as long as the internal network works.

Scenario 2: The incident where internet goes down

Friday evening, 6 PM. The IT department notices unusual network traffic. A ransomware attack is suspected. The first action: isolate network segments, cut external connections. The security expert severs the internet connection to prevent further spread.

And now you need your ISMS. You need the incident response plan. You need the escalation contacts. You need the documentation on the affected systems to assess what data is at risk. You need the protection needs assessment to evaluate reporting obligations. Do you need to report to the BSI within 24 hours?

If your ISMS is in the cloud, you cannot access any of it. You just cut the internet — the very line through which you access your ISMS. The documentation you created for the emergency is not available during the emergency.

"Then we print out the most important documents," some say. Yes, you can do that. But then you have an ISMS system that costs money and a binder that does the actual work. That is not a solution — it is a workaround that shows the actual solution has an availability problem.

A self-hosted system on the local network is independent of the internet. You can cut internet access and still access your ISMS, because it runs on your own infrastructure.

Scenario 3: Production environments without internet

In many manufacturing companies, the production environment is deliberately isolated from the internet. OT security demands strict separation between IT and OT networks. The Purdue Model defines network zones where systems at the lower levels have no direct internet access — and should not have.

When you conduct risk assessments in these environments, capture assets, or document controls, you need a system that is reachable on the internal network. A cloud ISMS requires you to either export the data beforehand and manually enter it later, or bring a separate device with internet access — which in a restricted environment is a security issue.

For companies in the manufacturing industry subject to NIS2 for machinery manufacturers, this is not a fringe topic. They must operate an ISMS that also covers the OT environment. And they must be able to access this ISMS where the OT environment is.

Air-gapped environments: When offline is the requirement

There are environments where offline capability is not an option but a requirement. Air-gapped systems are physically disconnected from the internet — no cable, no Wi-Fi, no cellular. They are found at:

Critical infrastructure operators: Energy utilities, water utilities, hospitals with critical control systems
Defense industry: Suppliers with classified information requirements who must not process data outside controlled environments
Research institutions: Laboratories with sensitive research data or patents
OT environments: Production controls, SCADA systems, process control technology

In all these environments, a cloud ISMS is excluded from the start. The data must not leave the internal network, and a browser that connects to an external server is not permitted.

Self-hosted systems run by design in this environment. They need no external connection, no license server reachability, no telemetry. ISMS Lite runs on a local server, requires no internet connection at all for operation, and validates the license offline. In air-gapped environments, the system is installed and updated via USB media, with the appropriate security clearances for media transport.

SaaS dependency as a single point of failure

Let us look at the problem systematically. A single point of failure (SPOF) is a component whose failure takes down the entire system. With a cloud ISMS, there are several potential SPOFs:

Dependency	Reason for failure	Likelihood	Impact
Internet connection	Line failure, DDoS, provider outage	Medium	No ISMS access
DNS	DNS provider outage	Low	No ISMS access
SaaS provider	Server failure, maintenance, overload	Low to medium	No ISMS access
Authentication	IdP outage (e.g., Entra ID)	Low	No login possible
Payment failure	Credit card expired, account suspended	Rare but real	Account locked

Each of these dependencies can independently cause an outage. Total availability is the product of individual availabilities. If each component has 99.9% availability, five components yield a total availability of 99.5% — that is over 40 hours of downtime per year.

With a self-hosted system, the dependencies reduce to: the server is running and the internal network is working. Two components instead of five, both under your control, both securable with local redundancy.

"But our internet is stable"

Yes, most of the time. And you usually do not urgently need your ISMS either. The problem is "most of the time." You need your ISMS urgently exactly when things go wrong. And when things go wrong, the internet connection is frequently part of the problem.

A DDoS attack takes down your internet connection. A compromised router is shut down by the provider. A construction accident cuts the fiber optic cable. The cloud provider has a global outage. The scenarios are varied, and they rarely occur in isolation. A security incident frequently correlates with network problems, because attackers target exactly this infrastructure or because responding to the incident requires network measures.

An ISMS that is unavailable precisely when it is needed has a fundamental design problem. And this problem cannot be solved through the cloud provider's SLAs, because the SLA only covers the availability of the cloud service — not the availability of your internet connection.

Offline capability and NIS2

The NIS2 Directive requires affected companies, among other things, to maintain business continuity and functional incident management. Both presuppose that the relevant systems and documentation are available even during a crisis.

If your ISMS is the central place where incident response plans, emergency handbooks, and reporting processes are documented, and this system is unreachable during an internet outage, you have a compliance problem. Not because NIS2 prescribes self-hosted (it does not), but because NIS2 demands availability of your security processes. And that availability is tied to internet availability with a cloud ISMS.

You can treat this risk: through redundant internet connections, through local copies of critical documents, through a separate offline emergency handbook. But each of these measures is a workaround for a problem that a self-hosted system does not have in the first place.

Scenario 4: Branch offices with unstable internet

Not every location has fiber optic. A construction company with job sites in rural areas, a machinery manufacturer with a production hall in an industrial park on the edge of town, a logistics company with warehouse locations along the highway. In Germany, there are plenty of places where the internet connection is neither fast nor stable.

When the ISM conducts an on-site inspection at such a location, captures assets, or discusses a risk assessment, they need access to the ISMS. With a cloud solution, that means: set up a mobile hotspot, hope for sufficient reception, and pray that the web application is still usable at 2 Mbit/s. With a self-hosted system on the company network, a VPN to the main location suffices — or, if the branch has its own local network, a local instance.

This becomes particularly relevant for companies that must include multiple locations in the scope of their ISMS under NIS2. An ISMS that only works with limitations at three out of five locations is not a complete ISMS.

The risk assessment that is missing

Here lies the actual problem: most companies have never assessed the dependency of their ISMS on the internet connection as a risk. They have assessed risks for their servers, for their applications, for their databases. But the ISMS itself — the tool where all those risks are documented — is not on the list.

That is a blind spot. If you operate your ISMS as a cloud service, "failure of the ISMS cloud service" should appear as its own risk in your risk assessment — with likelihood, impact, and defined controls.

And if you conduct this assessment honestly, you reach an uncomfortable conclusion: the likelihood is not low (internet outages happen), the impact is high (no access to emergency documentation during a crisis), and the most effective control is to eliminate the dependency — meaning to self-host.

What "available" really means in the ISMS context

Availability is one of the three pillars of information security — alongside confidentiality and integrity. The CIA triad appears on slide two of every ISO 27001 training. But when it comes to the ISMS tool itself, availability is often interpreted only as "the provider has 99.9% uptime."

That falls short. Availability in the ISMS context means:

Access when you need it: Not just when everything is running normally, but especially when it is not
Access where you need it: At the branch office, on the production floor, at the customer site — not just at a desk with Wi-Fi
Access for everyone who needs it: The ISM, the risk owner, the auditor, the crisis team — simultaneously, not sequentially through a shared login
Access at acceptable speed: A risk matrix that takes 15 seconds to load is no help during an audit

A self-hosted system on the local network meets all four criteria — regardless of the internet connection. A cloud system meets them only as long as the internet works.

Common mistakes regarding offline capability

1. "We print out the most important documents"

A printed emergency handbook is better than none. But it is no substitute for a functioning ISMS. Printed documents are static. They become outdated immediately after printing. They contain no links between risks, assets, and controls. They are not searchable. And in practice, they are never updated. If you need a printed emergency handbook alongside a digital ISMS, that is a sign that the availability of your digital ISMS is insufficient.

2. "Our cloud provider has an SLA of 99.9%"

99.9% sounds good. That is less than 9 hours of downtime per year. But the SLA only covers the availability of the cloud service. If your internet connection goes down, your DNS provider has an outage, or your identity provider is offline, the SLA does not apply. End-to-end availability is the product of all components along the path.

3. "We have a second internet line"

Redundant internet connectivity is a good measure. But it does not protect against all scenarios: deliberate network isolation during an incident, air-gapped requirements, cloud provider outage. And it generates ongoing costs for a problem that self-hosting solves by design.

4. "That has never happened"

Security incidents are, by definition, events that have never happened before — at least not in your company. The fact that your cloud ISMS has never gone down is not evidence that it will not. Risk management is based on likelihoods and impacts, not on the absence of past incidents.

When offline capability is a must

Not every company needs an ISMS that runs offline. But these constellations make it a hard requirement:

Critical infrastructure operators with availability requirements for critical processes
Companies with OT environments where the ISMS must also cover production
Organizations with classified information requirements (defense, government, research)
Companies with locations without stable internet (rural areas, international sites, construction sites)
Companies with strict data sovereignty requirements that must not store data with external providers
Any company that considers its ISMS part of emergency preparedness, because emergencies do not guarantee a stable internet connection

And if you are honest: every company that takes its ISMS seriously should ask itself what happens when the internet goes down. Not because the cloud is inherently bad, but because availability is a core objective of information security — and your own security documentation should not be exempt from it.

Practical comparison: Availability cloud vs. self-hosted

Criterion	Cloud ISMS	Self-hosted ISMS
Available during internet outage	No	Yes
Available during cloud provider outage	No	Yes (no external provider)
Available in air-gapped environments	No	Yes
Available during DNS outage	No	Yes (access via IP)
Available during network isolation (incident)	No	Yes (internal network suffices)
Backup under own control	Limited	Full
Latency on local network	Depends on internet speed	Milliseconds

A note on maintenance

Self-hosted means self-responsibility. You are responsible for updates, backups, and server maintenance. That is a valid objection, and it must factor into the decision. But maintaining a local server is not rocket science. A monthly update, daily automated backups, and a restore test per quarter are sufficient. The effort is one to two hours per month — significantly less than most people fear.

And this effort is in no proportion to the cost of an ISMS outage at the wrong moment.

Conclusion

Offline capability is not a relic from the pre-cloud era. It is an availability requirement that arises from the nature of an ISMS. A system that contains your emergency plans must be available during an emergency. A system that contains your risk assessments must be available during an audit. A system that contains your OT documentation must be available in the OT environment. Self-hosted is not the only answer to this requirement, but it is the simplest.