ISMS for MSPs: Why Self-Hosted Per Customer Is the Better Architecture

The multi-tenancy problem with ISMS platforms

When you offer ISMS-as-a-Service as an MSP, you manage the most sensitive data of your customers: risk assessments, documented vulnerabilities, audit results, action plans. This data is a map of each individual customer company's vulnerabilities. Where and how you store this data is not a technical detail — it is a fundamental architectural decision.

Most ISMS SaaS platforms on the market use multi-tenant architectures. This means: all customers share the same infrastructure, the same database, often the same application instance. Separation happens at the software level, typically through a tenant_id in the database that ensures customer A only sees their own records. This is technically common and perfectly acceptable for CRM systems or project management tools. For ISMS data, the situation is different.

Why multi-tenancy is riskier for ISMS data

An ISMS tool does not simply contain business data. It contains a systematic documentation of all known security gaps, all identified risks, and all not-yet-implemented controls of a company. For an attacker, this is exactly the information needed to attack in a targeted manner. The protection needs assessment for this data almost always yields the highest confidentiality level.

In a multi-tenant architecture, a single error in tenant separation is enough to expose this data. And this is not a hypothetical scenario. The list of real multi-tenancy breaches in recent years is long:

IDOR vulnerabilities (Insecure Direct Object References): An attacker changes an ID in the URL or API request and gains access to another tenant's data. This vulnerability class regularly appears in bug bounty programs and affects established SaaS platforms as well.

SQL injection with tenant escape: If tenant separation at the database level relies on WHERE clauses, a SQL injection can bypass these filters and access all tenants. Even with parameterized queries, a bug in the ORM layer or a custom query can break isolation.

Shared infrastructure compromise: If the underlying infrastructure is compromised — whether through a vulnerability in the hypervisor, in the container runtime, or at the cloud provider — potentially all tenants are affected. Supply chain attacks in recent years have demonstrated how a single attack vector can hit thousands of end customers.

Backup and log leaks: In multi-tenant systems, backups contain the data of all customers. A compromised backup means a data leak for every single tenant. The same applies to log files that, with insufficient filtering, can contain data from multiple tenants.

The core problem is the blast radius. When something goes wrong with a self-hosted single instance, exactly one customer is affected. With a multi-tenant platform, it is potentially all of them. For an MSP with 50 customers, a multi-tenant breach means not one crisis communication — but 50 simultaneously.

The customer's perspective

Consider the situation from your customer's point of view. They commission you to operate their ISMS, document their risks, and manage their vulnerabilities. Now imagine explaining to them in the initial meeting: "Your risk analyses and vulnerability data reside in the same database as the data of all our other customers. The separation is through software."

Compare that with: "Your ISMS data runs on a dedicated instance, on a server that only you and we use. Your data is physically separated from all other customers."

Which statement creates more trust? Which is easier to explain in an audit? Which reduces your own liability risk as an MSP?

One instance per customer: The isolation principle

The alternative to multi-tenancy is conceptually simple: each customer gets their own ISMS instance. Own server or container, own database, own configuration, own backups. No shared infrastructure, no software separation that can fail. Physical isolation instead of logical separation.

What physical isolation concretely means

When you operate a separate instance for each customer, several properties emerge that are not given with multi-tenancy:

Data isolation. The database of customer A and the database of customer B reside on different systems. There is no technical path through which a bug in the software of instance A could lead to accessing data in instance B. A SQL injection in instance A exclusively affects the data of customer A.

Independent updates. You can update instances independently of each other. If an update causes a problem, you roll back the affected instance without other customers being affected. With multi-tenant platforms, a faulty update affects all tenants simultaneously.

Individual configuration. Each customer can have their own security configuration: their own password policies, their own session timeouts, their own backup frequencies. With multi-tenancy, these settings are either global or require additional complexity in the code.

Independent backups. Each instance has its own backup. If you need to restore a backup of customer A, it does not touch customer B's data. With multi-tenancy, a restore must be carefully filtered to avoid accidentally overwriting other tenants' data.

Individual performance. If customer A runs a resource-intensive report, it does not slow down customer B's instance. With multi-tenancy, a "noisy neighbor" can impact performance for all tenants.

The objection: "That does not scale"

The most common objection to single instances is scaling. 50 customers mean 50 servers, 50 databases, 50 update processes. It sounds like a nightmare for operations.

In practice, the opposite is true — if you use the right tools. Containerization with Docker has made running many isolated instances trivial. An ISMS tool like ISMS Lite has no extreme resource requirements. A typical instance needs 512 MB RAM and minimal CPU. On a single server with 32 GB RAM, you can comfortably run 30-40 customer instances. For 50+ customers, you need two servers.

The real question is not whether single instances scale, but how you automate deployment and management. And with modern DevOps tools, that is a solved problem.

Deployment automation: Docker Compose per customer in 5 minutes

Let us look at how the deployment of a new customer instance works in practice. The goal: a new customer signs up, and within 5 minutes their own ISMS instance is running.

The architecture

Each customer instance consists of a minimal stack:

The reverse proxy (Nginx, Traefik, or Caddy) is the only shared component. It receives HTTPS connections and routes them to the correct customer instance. Traefik is particularly well suited because it automatically detects Docker containers and provisions TLS certificates via Let's Encrypt.

The deployment process

At its core, deploying a new instance is a single command. You copy a template, adjust the configuration, and start the containers. The entire procedure can be wrapped in a shell script that accepts three parameters: customer name, subdomain, and admin email.

Step 1: Generate configuration. The script creates a Docker Compose file from a template, sets the customer-specific variables (domain, database password, admin credentials), and creates the directory structure for persistent data.

Step 2: Start containers. A docker compose up -d starts the instance. Traefik automatically detects the new container via labels and routes traffic. The Let's Encrypt certificate is issued within seconds.

Step 3: Initialization. The application automatically runs setup on first start: database migration, admin account creation, default configuration.

Step 4: Verification. The script checks whether the instance is reachable and login works. Then it sends a welcome email to the customer administrator.

From step 1 to a working login, it takes under 5 minutes. With a well-established process, often less than 3.

Scaling to 50+ customers

If you support more than a handful of customers, you do not want to manage each instance individually. Here are the tools that make operating many instances manageable:

Portainer or Rancher for container management: A central interface where you can see, start, stop, and monitor all customer instances. Portainer runs as a container itself and needs minimal resources.

Watchtower or your own CI/CD pipeline for updates: Watchtower regularly checks whether a new image is available and updates containers automatically. For more control, set up a CI/CD pipeline that rolls out updates in stages — first to a test instance, then to a few customers, then to all.

Uptime Kuma or Grafana for monitoring: Centralized monitoring that tracks the reachability and performance of all instances. Uptime Kuma is particularly suitable for MSPs because it is lightweight and can generate status pages per customer.

Restic or BorgBackup for backups: Automated, encrypted backups of all customer instances to a central backup server or S3-compatible storage. Each instance is backed up independently, so a restore of individual customers is possible without affecting others. Backup encryption is not optional here — it is mandatory.

Example: Resource planning for 50 customers

What does the actual infrastructure requirement look like? Let us calculate conservatively:

That corresponds to two dedicated servers with 32 GB RAM and 8 cores each. At Hetzner, Netcup, or a comparable German hosting provider, that costs between 80 and 150 euros per month. For 50 customer ISMS instances.

Compare that with typical SaaS costs: a multi-tenant ISMS platform charges per tenant and user. With 50 customers averaging 5 users at 30 euros per user per month, you are at 7,500 euros monthly. The self-hosted variant costs you approximately 150 euros per month for infrastructure plus the one-time license.

Pricing model: ISMS Lite MSP package

Most ISMS tools on the market are designed for individual customers. They sell seat licenses, and every additional user costs extra. For an MSP managing 50 customers with 3-10 users each, that quickly adds up to five-figure monthly amounts.

ISMS Lite offers an MSP package tailored to the needs of IT service providers:

10,000 euros one-time. Unlimited instances. No seat licenses.

That means: you pay once and can deploy as many customer instances as you need — whether 10 or 200. No ongoing license costs per customer, no fee per user. The only recurring costs are your infrastructure (servers, hosting) and your staff.

ROI calculation for an MSP

Let us take an MSP with 30 ISMS customers as a calculation example:

One-time costs:

Recurring costs per month:

Revenue per month:

If you offer the ISMS service in the base package at 1,000 euros per month per customer (which is at the lower end of typical pricing models for ISMS services), you generate 30,000 euros in recurring revenue with 30 customers. Your tool and infrastructure costs are 200 euros per month. The ISMS Lite license pays for itself after the first half customer.

The actual costs lie in personnel, not in tooling. You need ISMS consultants to support the customers. But that is exactly your business model as an MSP: selling expertise, not reselling software.

Comparison with SaaS alternatives

Customer data never mixed: Why this is more than a technical detail

The physical separation of customer data is not just a technical architecture decision. It has concrete implications for contracts, liability, and customer relationships.

Contractual simplification

When you have to explain to your customers how tenant separation in a multi-tenant platform works, the data processing agreement becomes complex. You must document technical measures for tenant separation, list the SaaS provider's sub-processors, and explain why logical separation is sufficient.

With a dedicated instance, the explanation is simple: "Your data runs on its own server. No other customer has access to this server. Period." The DPA becomes shorter, the risk assessment simpler, and the approval from the customer's data protection officer faster.

Liability reduction

As an MSP, you bear responsibility for the security of customer data you process as part of the ISMS service. If a security incident at a multi-tenant system affects all tenants, you simultaneously have 30 or 50 data breaches. Each individual customer can assert claims. NIS2 fines do not multiply, but reputational damage and remediation costs do.

With isolated instances, the worst case is limited to one customer. That is still bad, but it is a manageable incident rather than a catastrophe.

Customer communication

In regulated industries, the question "Where does my data reside?" is a standard question in the procurement process. Customers in critical infrastructure, healthcare, or the defense industry often have explicit requirements for data isolation. With a dedicated instance, you meet this requirement by design — without discussion.

And even customers without explicit requirements react positively when you explain that their ISMS data runs on its own instance. It signals professionalism and shows that you understand the sensitivity of the data.

The audit advantage: Each customer has their own server

When your customers are audited — whether internally, by an ISO 27001 auditor, or by a supervisory authority under NIS2 — the security of the tools used is questioned. And with an ISMS tool, they look particularly closely because it contains the core documentation of security management.

What auditors ask

A typical questionnaire about ISMS tooling covers:

• Where is the data stored?
• Who has access to the data?
• How is tenant separation implemented?
• How is the data encrypted (at rest and in transit)?
• What does the backup concept look like?
• Which sub-processors are involved?
• What happens in a security incident at the tool provider?

With a multi-tenant SaaS solution, you must refer to the SaaS provider's documentation for each of these questions. You depend on the provider delivering current and complete evidence. If they have an ISO 27001 certification, that is helpful, but the auditor can still ask detailed questions that the provider does not or cannot promptly answer.

The advantage of dedicated instances

With a self-hosted instance, you can answer each of these questions directly:

These answers are concrete, verifiable, and produce no "We need to check with the provider." The auditor gets clear statements and you save yourself follow-up questions and wait times.

Audit documentation per customer

Another practical advantage: you can create an individual security documentation of their ISMS instance for each customer. This documentation contains the specific server configuration, access rights, backup concept, and encryption parameters for exactly their instance. In ISMS Lite, this technical documentation can be linked directly as evidence for the internal audit, so the auditor finds configuration and compliance status in one place.

With a multi-tenant system, this documentation is generic because all customers use the same infrastructure. That is not wrong, but it is less convincing than a document that says: "Your server is isms-customer-a.msp-domain.com, runs at Hetzner in Falkenstein, has IP address X, and was last patched on Y."

Common objections and honest answers

"We do not have the capacity to administer 50 servers"

Understandable objection, but it is based on the image of traditional server management: configure each server individually, update each individually, monitor each individually. With container orchestration, reality looks different. A docker compose pull && docker compose up -d updates an instance. A bash script that runs this command for all instances updates 50 instances in a loop. Central monitoring shows you all 50 instances on one dashboard. The additional effort compared to a single multi-tenant instance is real, but it is measured in hours per month, not days.

"What if a security patch needs to go on all instances immediately?"

That is exactly what the automation is for. A rolling update that sequentially updates each instance and briefly checks whether it still works is rolled out across all customers in a few minutes. And you have the option to patch the most critical customers first and stop if there are problems — before everyone is affected. With multi-tenancy, you do not have this granularity: it is updated for everyone simultaneously, or for nobody.

"Our customers want a central platform, not individual instances"

Your customers do not want an architecture concept. They want a functioning ISMS that is secure and passes the audit. Whether one or fifty instances run behind the scenes is transparent to the customer. They log in to their URL, see their data, and work with it. That a dedicated instance runs in the background is a quality feature for them, not a disadvantage.

For you as an MSP, you need a central overview of all customer instances. You solve that through a dashboard or monitoring tool, not through a shared database.

"Multi-tenancy is the industry standard"

Yes, for office software, CRM, and project management. Meaning everywhere a data leak is annoying but not existential. For security software, different standards apply. Your penetration testing provider does not store results in a shared database with all other customers' results either. Why should your ISMS tool?

Checklist: Self-hosted ISMS for MSPs

If you want to take the step to self-hosted single instances, you need the following building blocks:

• Infrastructure: At least two dedicated servers at a German hosting provider (redundancy)
• Reverse proxy: Traefik or Caddy with automatic Let's Encrypt certification
• Deployment script: Automated onboarding of new customers in under 5 minutes
• Update process: Rolling update script for all instances with health check
• Monitoring: Central monitoring of all instances (uptime, performance, disk usage)
• Backup: Automated, encrypted backups of all instances to separate storage
• Documentation: Per-customer security documentation (server configuration, access rights, backup concept)
• DPA: Data processing agreement per customer, adapted to the self-hosted model
• Incident response: Process for security incidents that accounts for the isolation of individual instances
• ISMS license: ISMS Lite MSP package (10,000 € one-time, unlimited instances)

Common implementation mistakes

All instances on one server without redundancy. If the one server fails, all customers are offline. Distribute instances across at least two servers and plan a failover mechanism.

Not encrypting backups. Every backup must be encrypted — with a key that does not reside on the same server. Unencrypted backups make the entire isolation worthless if an attacker reaches the backup storage.

Deferring updates. Just because you now run 50 individual instances does not mean you can postpone updates. Automate the update process and apply security updates promptly. A patch management process is mandatory for your own infrastructure as well.

Not documenting access rights. Who on your team has SSH access to which customer instances? Document this and regularly check whether the rights are still current. A former employee who still has access to 50 customer instances is a significant risk.

No central logging. Even with isolated instances, you need central log management to detect anomalies across all customers. An attacker who systematically probes instances is only noticeable if you correlate the logs of all instances.

Conclusion: Isolation is not a luxury — it is the right architecture for ISMS data

Multi-tenancy has its place. For a project management tool, a CRM, or a ticketing system, shared infrastructure is a reasonable compromise between efficiency and security. For an ISMS tool that contains the documented vulnerabilities, risks, and security gaps of your customers, this balance shifts.

For MSPs offering ISMS as a service, the single instance per customer is not the more effort-intensive path. It is the more professional one. The additional operational effort is manageable with modern container technology. The advantages in security, audit readiness, contract design, and customer trust are significant. And the costs with the ISMS Lite MSP package are well below any comparable SaaS alternative.

The next step: evaluate your current infrastructure, plan the deployment setup, and talk to your customers about the benefits of dedicated instances. Most will not ask why you are doing this. They will ask why you did not do it sooner.

Further reading

• NIS2 for IT Service Providers and MSPs: The Dual Role as Affected Party and Advisor
• Self-Hosted vs. Cloud: Data Sovereignty for Compliance Software
• Encryption in the Enterprise: What, Where, and How to Encrypt
• Supplier Assessment with Security Questionnaire: Template and Approach
• Container Security: Securing Docker and Kubernetes for SMEs