GDPR-Compliant ISMS Hosting: Requirements for Storing Your Compliance Data

TL;DR

An ISMS tool processes personal data (names, roles, emails of risk owners, auditors, training participants) and therefore falls under the DSGVO (GDPR).
When the ISMS tool is operated as a cloud solution, data processing on behalf of the controller under Art. 28 GDPR applies. You need a DPA with the provider and must verify their TOMs.
Third-country transfer under Art. 44ff is relevant with US-based cloud providers, even if the servers are in the EU, because the CLOUD Act creates access possibilities.
A Data Protection Impact Assessment for the ISMS tool is not always mandatory but recommended, because the tool contains sensitive information about the organization's entire security posture.
On-premise hosting eliminates data processing by third parties, third-country transfers, and the sub-processor chain. It is the shortest path to GDPR-compliant ISMS operations.

Your ISMS Tool Falls Under the GDPR

When you build an ISMS, you think about risks, controls, and audits. You might think about the DSGVO (GDPR) in the context of processing customer data or employee data. But there is a point where data protection and information security directly intersect: your ISMS tool itself.

An ISMS tool processes personal data. Not in massive quantities, but systematically and throughout the entire period of use. As soon as you process personal data, the rules of the GDPR apply. And with an ISMS tool running in the cloud, it gets particularly interesting because additional requirements for data processing agreements, third-country transfers, and technical protection measures arise.

What Personal Data Does an ISMS Contain?

A look at a typical ISMS tool quickly reveals that personal data is processed in many places:

Data Field	Where in the ISMS	Personal Reference
Name, email, role	User management	Direct
Risk owner	Risk register	Direct (name + responsibility)
Control owner	Action plan	Direct (name + task)
Auditor names	Audit reports	Direct
Training participants	Training records	Direct (name + date + result)
Incident reporter	Incident reports	Direct (name + description)
Comments and notes	Various modules	Potential (if names or details are included)
Login logs	Audit trail	Direct (user + timestamp + action)

These are not abstract categories. This is real data about real employees. The name of the ISM who created a risk assessment. The email address of the department head listed as risk owner. The timestamp of when the IT administrator marked the last control as completed.

Art. 32 GDPR: Technical and Organizational Measures

Art. 32 GDPR requires that you implement appropriate technical and organizational measures "taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons."

For an ISMS tool, this means concretely:

Encryption (Art. 32(1)(a))

Encryption in transit. Every connection to the ISMS tool must be encrypted via TLS. This applies both to browser access and API connections. With a self-hosted setup, you configure this through the reverse proxy with a valid certificate. With cloud solutions, this is usually standard, but check whether internal connections between the provider's services are also encrypted.

Encryption at rest. Data on disk should be encrypted. For self-hosted, LUKS (Linux) or BitLocker (Windows) on the server is sufficient. For cloud solutions, ask whether the database is encrypted and who manages the keys. If the cloud provider controls the keys, they technically have the ability to decrypt the data.

Access and Authorization Control (Art. 32(1)(b))

MFA for all user accounts
Role-based access control concept (ISM sees everything, department heads only their own risks)
Automatic session timeouts
Logging of all access and changes
User lifecycle management: deactivate access when employees leave the company

Availability and Resilience (Art. 32(1)(b))

Regular, tested backups
Documented restore procedures
Monitoring of system availability

Regular Review (Art. 32(1)(d))

Art. 32 requires a "process for regularly testing, assessing and evaluating the effectiveness of technical and organizational measures." For an ISMS tool, this means: the TOMs must not only exist — they must be regularly reviewed. Are the password policies still current? Does MFA work? Was the last backup restore tested?

Art. 28 GDPR: Data Processing

This is where it becomes relevant for cloud-based ISMS tools. If you use an ISMS tool as SaaS, the provider processes personal data on your behalf. This constitutes data processing within the meaning of Art. 28 GDPR, and you need a Data Processing Agreement (DPA).

What the DPA Must Contain

Art. 28(3) GDPR lists the mandatory contents of a DPA:

Subject and duration of processing
Nature and purpose of processing
Types of personal data and categories of data subjects
Obligations and rights of the controller
Instruction-bound nature of the processor
Confidentiality obligation of the processor's employees
TOMs of the processor (Art. 32)
Conditions for engaging further processors (sub-processors)
Assistance with data subject rights (access, deletion, rectification)
Assistance with DPIAs and notification obligations
Deletion or return of data after termination
Verification options and inspections (audit rights)

DPA Review in Practice

Most SaaS providers include a standard DPA that you accept at contract signing. The problem: these standard DPAs are frequently worded in the provider's favor and contain gaps you need to identify.

Typical weaknesses in standard DPAs:

Restricted audit rights. The DPA grants you the right to "inspections" but defines that the provider may instead present a SOC 2 report or an ISO 27001 certificate. This is not the same as your own audit right, and supplier assessment becomes more difficult.

Blanket approval for sub-processors. The DPA allows the provider to add sub-processors, and you are merely informed. You have a right to object, but if you object, the provider can terminate the contract. In practice, you have no real choice.

Unclear deletion deadlines. The DPA promises deletion of data after contract end but defines no concrete timeframe and no obligation to provide evidence. "Within a reasonable period" can mean anything from one week to one year.

Missing TOM documentation. The DPA references the provider's TOMs, but the TOMs are either not attached or consist of generic descriptions without concrete technical details.

When reviewing a DPA, watch for these points. A bad DPA is worse than none because it creates a false sense of security.

On-Prem Eliminates Data Processing

This is the fundamental advantage of on-premise hosting: if you run the ISMS tool on your own infrastructure, there is no data processor. You process the data yourself, on your own servers, under your own control. There is no DPA, no sub-processor chain, and no dependence on a third party's data protection practices. In ISMS Lite, all personal data stays on your server, and you are both the controller and the operator of the infrastructure.

This does not mean you don't need TOMs. You need those for your own infrastructure just as well. But you control them yourself and don't have to trust that a third party adheres to them.

Art. 44ff GDPR: Third-Country Transfer

Articles 44 to 49 of the GDPR regulate the transfer of personal data to third countries — that is, countries outside the European Economic Area (EEA). For ISMS tools, this is relevant when the cloud provider or its sub-processors process data in third countries or access it from there.

The US Problem

Most major cloud infrastructures (AWS, Azure, GCP) belong to US companies. Even if the data resides in an EU data center, US companies are subject to the CLOUD Act (Clarifying Lawful Overseas Use of Data Act). The CLOUD Act enables US authorities to demand data from US companies, even when that data is physically stored in the EU.

The EU-US Data Privacy Framework (DPF), which has served as an adequacy decision under Art. 45 GDPR since 2023, provides a legal basis for data transfers to certified US companies. But the stability of this framework is uncertain. The European Court of Justice has already invalidated two predecessor arrangements (Safe Harbor and Privacy Shield). Whether the DPF will endure is an open question.

For an ISMS tool that contains the most sensitive security information in your organization, this is a relevant risk. Not a theoretical risk of the "a US intelligence agency might be interested in our risk assessment" variety, but a practical compliance risk: if the DPF is struck down, you need an alternative legal basis for the international data transfer on short notice or must repatriate the data.

Standard Contractual Clauses (SCCs) as a Safeguard

Independent of the DPF, many companies rely on Standard Contractual Clauses (SCCs) as additional protection. SCCs are contractual agreements intended to ensure that the recipient in the third country provides an adequate level of data protection.

But SCCs alone are not sufficient after the Schrems II ruling by the CJEU. You must additionally conduct a Transfer Impact Assessment (TIA) — a documented evaluation of whether the law of the third country can undermine the contractually guaranteed protection in practice. For the US and the CLOUD Act, the answer is: yes, potentially.

On-Prem Eliminates Third-Country Transfer

If you run your ISMS tool on your own infrastructure in the EU, there is no third-country transfer. No SCCs, no TIA, no dependence on adequacy decisions that the CJEU might invalidate in five years. The data resides in the EU, is processed in the EU, and is subject exclusively to EU law.

DPIA for ISMS Tools: Mandatory or Optional?

The Data Protection Impact Assessment (DPIA) under Art. 35 GDPR is mandatory when processing is "likely to result in a high risk to the rights and freedoms of natural persons." The supervisory authorities have published positive lists naming certain types of processing for which a DPIA must be conducted.

When a DPIA for the ISMS Tool May Be Required

An ISMS tool does not automatically fall under the DPIA obligation. The processed data is predominantly professional contact data (name, role, email) in a limited context. There is no profiling, no automated decision-making, and no systematic monitoring.

However, there are borderline cases:

Extensive audit trail data. If the ISMS tool logs every action of every user to the minute, a detailed behavioral profile emerges. Who edited what and when, how long the person was logged in, which documents they viewed. This goes beyond simple access logs and can be interpreted as systematic monitoring.

Sensitive supplementary data in incident reports. If incident reports contain details about individual employees' misconduct ("Employee X clicked the phishing link"), the data becomes significantly more sensitive than mere contact data.

Large organizations. If the ISMS tool stores data from several thousand employees over years, the scope of processing increases.

Recommendation: DPIA as a Safeguard

Even when a DPIA is not formally mandatory, a brief analysis documenting why the processing does not pose a high risk — or, if risks are identified, what measures were taken — is recommended. This costs half a day of effort and provides clean documentation in case the supervisory authority inquires.

The Records of Processing Activities for Your ISMS Tool

Every company must maintain records of processing activities (ROPA) under Art. 30 GDPR. Your ISMS tool is a processing activity that must be listed there.

ROPA Entry for Cloud Hosting

Name: Information Security Management System (ISMS)
Controller: [Company name], represented by [CEO]
Purpose: ISMS management, risk assessment, control tracking,
         audit management, training records, incident management
Legal basis: Art. 6(1)(c) (legal obligation),
             Art. 6(1)(f) (legitimate interest)
Categories of data subjects: Employees, external auditors,
                              service providers
Categories of personal data: Name, email, role, department,
                               training participation,
                               access logs
Recipients: [SaaS provider as processor],
            [Sub-processors of provider per DPA]
Third-country transfer: [Yes/No, details on SCCs, TIA, DPF]
Deletion periods: User data 3 months after departure,
                  audit data 6 years, incident reports 3 years
TOMs: See DPA with [provider], own access control via MFA,
      role-based concept

ROPA Entry for On-Prem Hosting

Name: Information Security Management System (ISMS)
Controller: [Company name], represented by [CEO]
Purpose: ISMS management, risk assessment, control tracking,
         audit management, training records, incident management
Legal basis: Art. 6(1)(c) (legal obligation),
             Art. 6(1)(f) (legitimate interest)
Categories of data subjects: Employees, external auditors,
                              service providers
Categories of personal data: Name, email, role, department,
                               training participation,
                               access logs
Recipients: None (internal processing on own infrastructure)
Third-country transfer: No
Deletion periods: User data 3 months after departure,
                  audit data 6 years, incident reports 3 years
TOMs: Server-side encryption (LUKS), TLS 1.3,
      MFA for all users, role-based access control,
      daily backup with restore test

The difference is immediately apparent. With on-prem, there are no recipients, no third-country transfer, and no references to external DPAs. The entry is shorter, clearer, and easier to maintain.

Checklist: GDPR Compliance of Your ISMS Tool

Basics

Is the ISMS tool listed as a processing activity in the ROPA?
Is the legal basis for processing documented?
Are deletion periods defined for the various data types?
Is there a deletion concept ensuring implementation of the deletion periods?

Technical Measures (Art. 32)

Is the connection to the ISMS tool encrypted via TLS?
Is data at rest encrypted?
Is MFA activated for all users?
Is there a role-based access control concept?
Are accesses and changes logged?
Are there regular, tested backups?

Additional for Cloud Hosting

Is there a DPA with the provider?
Was the DPA substantively reviewed (not just accepted)?
Is the sub-processor list documented and assessed?
Is there a process for sub-processor changes?
Is the third-country transfer reviewed and documented (DPF, SCCs, TIA)?
Is there an audit right vis-a-vis the provider?
Is an exit strategy with data return and deletion agreed?

Data Subject Rights

Can the company respond to access requests under Art. 15 regarding ISMS data?
Can personal data in the ISMS tool be rectified and deleted?
Is the deletion concept for ISMS data documented?

Common Mistakes in GDPR Compliance for the ISMS

Mistake 1: Not treating the ISMS tool as a processing activity. The ISMS tool often falls through the cracks because it is perceived as an internal tool rather than as data processing. But as soon as personal data is stored there — and it is from the first user account — it is a processing activity that belongs in the ROPA.

Mistake 2: Not reviewing the cloud provider's DPA. Many companies accept the standard DPA at contract signing without substantively reviewing it. This is risky, because a standard DPA that is missing essential mandatory content does not protect you in an emergency. The data protection officer should review the DPA before signing.

Mistake 3: Ignoring third-country transfer. "The servers are in Frankfurt" is not a sufficient analysis. If the SaaS provider is a US company or uses US sub-processors, you must assess the third-country transfer, even if the data is physically located in the EU.

Mistake 4: Not defining deletion periods. ISMS data has different retention requirements. Training records must be retained for the duration of employment plus a reasonable period. Audit reports typically six years. Incident reports three to five years. User data must be deleted when the employee leaves the company and no retention reason remains. Without defined periods, you accumulate data indefinitely — and that is a GDPR violation.

Mistake 5: Excluding the ISMS tool's TOMs from the TOM documentation. The TOMs under Art. 32 apply to all processing activities — including the ISMS tool. When you document TOMs for your main business processes, don't forget to also document the TOMs for the tools with which you operate your ISMS.

The Pragmatic Path: On-Prem as a GDPR Simplifier

This article has shown that the GDPR requirements for an ISMS tool are not trivial. Data processing agreements, third-country transfer, sub-processor management, DPA review, TIA — the list of tasks is long. Each individual point is solvable, but collectively they create significant documentation and review effort.

On-premise hosting eliminates half of this list. No data processing by third parties, no DPA, no third-country transfer, no TIA, no sub-processor assessment. What remains are the baseline requirements you must fulfill anyway: TOMs, access control concept, backup strategy, deletion concept, and the ROPA entry.

This is not an argument against cloud solutions in general. For many applications, the cloud is the right path. But for an ISMS tool that contains the most sensitive information in your organization and whose data storage is scrutinized by both GDPR supervisory authorities and ISO 27001 auditors, on-prem offers the clearest and shortest path to compliance.

ISMS Lite follows exactly this model: a self-hosted solution that runs on your own infrastructure. You install it on your server, the data stays with you, and the GDPR documentation becomes as short as possible. No third-country transfer, no sub-processor lists, no DPA negotiations. Instead, full control and a ROPA entry that fits on half a page.