ISMS Audit and Data Storage: Why the Auditor Wants to Know Where Your Data Resides

The Question Every Auditor Asks

It usually happens on the second day of the certification audit. The auditor has worked through the information security policy, reviewed the risk assessment, and discussed the controls in the Statement of Applicability. Then comes a question that sounds harmless: "Where does your risk register actually reside?"

The question is not about the format. Whether you maintain your risk register in Excel, a specialized tool, or a custom-built application is initially irrelevant to the auditor. What interests them is the physical and legal storage location. Is the risk register on a server in your server room? On a German cloud server? With a US provider? In a SaaS solution whose infrastructure is distributed across three continents?

The answer to this question has direct implications for several ISO 27001 controls. And the way you respond tells the auditor more about the maturity of your ISMS than any policy could.

Why the Storage Location of Your ISMS Tool Matters

An ISMS tool is not an ordinary piece of software. It contains a concentrated collection of the most sensitive information in your organization:

Risk register. A complete inventory of all identified risks, their assessment, and planned treatment. For an attacker, this is a shopping list: which vulnerabilities does the company know about, and which remain untreated?

Audit findings. Documented deviations, weaknesses, and open actions. Anyone with access to this data knows exactly where the defense is thin.

Incident reports. Detailed descriptions of past security incidents, their causes, and the measures taken. Combined with the risk register, a complete picture of the security posture emerges.

Control status. Which controls are implemented, which are planned, which have deficits? This information is invaluable for anyone specifically looking for attack vectors.

Personal data. Names of risk owners, control owners, training participants, and auditors. This means ISMS data also falls under the DSGVO (GDPR).

The auditor knows this. That is why they treat your ISMS tool not as neutral software but as a critical information asset subject to the same protection requirements as any other asset with high protection needs.

What the Auditor Specifically Examines

The question about the storage location is just the beginning. An experienced auditor works systematically through several layers:

A.5.23 Cloud Services

If your ISMS tool is a cloud solution, Control A.5.23 of ISO 27001:2022 applies. This control requires you to establish processes for the procurement, use, management, and exit from cloud services. The auditor wants to see that you consciously selected the cloud service and are aware of the associated risks.

Typical audit questions:

• Have you conducted a risk assessment for the use of this cloud service?
• What data classification do the information stored in the cloud service have?
• Is there an exit strategy in case the provider discontinues the service or changes the terms?
• How do you ensure that encryption of the data meets your requirements?

A.5.21 Information Security in the Supply Chain

Every cloud provider is a link in your supply chain. Control A.5.21 requires you to identify and treat the risks in the supply chain. This means: you must know who hosts your ISMS tool, who operates the infrastructure, and which additional service providers are involved.

A.8.10 Deletion of Information

When you switch ISMS providers or decommission the tool, you must ensure that your data is completely deleted. With a self-hosted solution, you format the hard drive. With a SaaS solution, you trust that the provider removes the data from all backups and replicas. The auditor wants to know how you verify this.

A.5.31 Legal and Regulatory Requirements

Where your data resides determines which law applies. Data in the EU is subject to the GDPR. Data with a US company may be subject to the CLOUD Act, even if physically stored in Europe. The auditor checks whether you have assessed these legal implications and included them in your risk assessment.

The Problem of Sub-Processor Chains

This is where it gets complicated with cloud-based ISMS tools. No SaaS provider operates its solution entirely on its own. Behind the user interface lies a chain of sub-processors, each with their own access, jurisdictions, and security levels.

A typical scenario for a cloud ISMS tool:

That is seven companies with potential access to parts of your ISMS data. Each of these companies has its own sub-processors. The chain can extend to 20 to 30 companies before you reach the end.

The auditor will ask: "Can you show me the complete sub-processor list of your ISMS tool?" If you cannot answer this question, that is a finding. If you can answer it but have not conducted a risk assessment for the critical sub-processors, that is also a finding.

The Notification Trap

Most SaaS providers reserve the right to change sub-processors and inform their customers via email or a website. You are contractually obligated to monitor and assess these changes. In practice, this email gets buried in the inbox, and the risk assessment is never updated. The auditor then finds a sub-processor list from the time of contract signing two years ago and a current list with three new entries for which no assessment exists.

Auditability: SaaS vs. On-Prem

A fundamental difference between cloud and self-hosted solutions shows in the question of auditability. As a user of a SaaS solution, your verification options are significantly limited.

What You Cannot Do with SaaS

No own penetration tests. The vast majority of SaaS providers prohibit penetration tests against their infrastructure. You can request a pentest report from the provider, but you cannot test yourself or through a service provider you commission. You are dependent on the provider's statements.

No server logs. You see the application logs the SaaS provider makes available to you. The underlying server logs, operating system events, network logs, and infrastructure events remain hidden. If a security incident occurs, you are dependent on the provider's forensics.

No physical inspection. You cannot visit the data center and check whether the physical security meets your requirements. You rely on certificates and audit reports from the data center operator.

No independent backup verification. You cannot verify whether the backups of your data actually work, whether they are encrypted, and whether they are stored where the provider claims. You trust the information in the documentation.

No access to the configuration. You cannot view the database configuration, web server settings, firewall rules, or encryption parameters. The entire infrastructure layer is a black box.

What You Can Do with Self-Hosted

With a self-hosted solution, you reverse the relationship. You have full access to:

• Server logs at all levels (application, operating system, network)
• Database contents and configuration
• Backup files and their verification
• Network configuration and firewall rules
• Encryption configuration and certificate management
• Physical location of the hardware

This does not mean self-hosted is automatically more secure. It means you can take responsibility for security and demonstrate it to the auditor yourself, rather than depending on third-party statements.

Practical Example: Two Companies in the Audit

Two mid-market companies, each with approximately 120 employees, are in the certification audit. Both have built a functioning ISMS. Both have the same auditor. But the data storage of their ISMS tools differs fundamentally.

Company A: Cloud-Based ISMS Tool

The auditor asks: "Where does your risk register reside?"

The ISM responds: "We use a cloud-based ISMS tool. The data is with a German SaaS provider."

The auditor follows up: "Where exactly does the provider host the data?"

"At AWS in Frankfurt."

"Does AWS as a US company potentially have access to the data under the CLOUD Act?"

"I would need to check that."

"Do you have a data processing agreement with the SaaS provider?"

"Yes, it was signed at contract conclusion."

"Have you reviewed the sub-processor list and assessed the risks?"

Silence.

"Have you documented an exit strategy in case the provider discontinues the service?"

"We could export the data as CSV."

"Have you tested that? Is all data exportable, including file attachments, versioning, and relationships between records?"

More silence.

The auditor notes three observations: incomplete risk assessment of the cloud service, missing sub-processor assessment, and untested exit strategy. None of these is a major nonconformity, but collectively they show that the data storage of the ISMS tool was not treated with the same diligence as the other ISMS processes.

Company B: Self-Hosted ISMS Tool

The same question: "Where does your risk register reside?"

The ISM responds: "On our own server in the server room at our Karlsruhe location. The ISMS tool runs as a Docker container on a dedicated server used exclusively for the ISMS."

"Who has access to the server?"

"Three people from the IT department, plus myself as ISM for the application level. Access is secured by SSH keys and MFA. Here is the access matrix."

"What does the backup strategy look like?"

"Daily database backup, encrypted, to a separate server at the secondary location. Monthly restore test — the last one was successful three weeks ago. Here is the protocol."

"Which sub-processors are involved?"

"None. The entire infrastructure is with us. Software updates are downloaded from the vendor and applied after testing in a staging environment."

The auditor notes: full control over data storage, documented access control, tested backup strategy. No findings in this area.

The difference is not that Company A did poor work. The difference is that Company B could answer the questions immediately and completely because it has control over the entire chain. In ISMS Lite, exactly this model works: the tool sits on your own infrastructure, and you can show the auditor every layer yourself, from server to application.

Checklist: Audit Preparation for Data Storage

Regardless of whether you use a cloud or self-hosted ISMS tool, you should be able to answer these questions before the audit:

Location and Jurisdiction

• In which country and data center does the ISMS data reside?
• Which legal framework applies (GDPR, CLOUD Act, other)?
• Is there a risk assessment for the location and jurisdiction?
• Are the TOMs of the data center documented and assessed?

Access Control

• Who has access to the ISMS data (internal and external)?
• Are accesses granted according to the least-privilege principle?
• Is there an access control concept for the ISMS tool?
• Are accesses logged and regularly reviewed?

Sub-Processor Management (for Cloud Solutions)

• Is a current sub-processor list available?
• Has a risk assessment been conducted for each critical sub-processor?
• Is there a process for monitoring sub-processor changes?
• Are the DPAs of sub-processors reviewed and documented?

Backup and Recovery

• How often are backups created and where are they stored?
• Are the backups encrypted?
• Has a restore test been performed and documented?
• What are the RPO and RTO for the ISMS tool?

Exit Strategy

• Can all data be fully exported?
• Has the export been tested and documented?
• Is there a migration plan for switching providers?
• Is the deletion of data at the previous provider contractually regulated?

Encryption

• Is data at rest encrypted?
• Is data in transit encrypted?
• Who manages the encryption keys?
• Is there documented key management?

Common Mistakes in Audit Preparation

Mistake 1: Excluding the ISMS tool from the risk assessment. Many companies carefully assess risks for their business applications but forget that the ISMS tool itself is an information asset with high protection needs. It belongs in asset management and in the risk assessment.

Mistake 2: Treating the provider's certificates as sufficient. The fact that your SaaS provider is ISO 27001 certified does not relieve you of the obligation to conduct your own risk assessment. The provider's certificate is a data point, not a free pass. The auditor will check whether you know the scope of the provider's certification and whether it covers the areas relevant to you.

Mistake 3: Dismissing the exit strategy as theoretical. "We're not going to switch providers" is not an acceptable answer. ISO 27001 requires planning for the case that a service is no longer available. This includes the case that the SaaS provider discontinues the service, triples the prices, or changes the terms in a way that is no longer acceptable to you. In your Business Impact Analysis, the ISMS tool should be considered as a business-critical process.

Mistake 4: Ignoring sub-processor changes. SaaS providers regularly change their sub-processor lists. If you do not actively track and assess the change notifications, a compliance backlog accumulates that the auditor will uncover.

Mistake 5: Assuming backup responsibility lies with the provider. With SaaS solutions, it is often unclear what backup guarantees actually exist. "We do backups" is not sufficient. You need specific information about frequency, retention period, encryption, and restore capability. And you must verify that a restore actually works.

What the Auditor Ultimately Wants to See

At its core, the auditor wants to see one thing: that you treat your ISMS tool with the same diligence as any other critical system. This means:

A documented protection needs assessment for the ISMS data. Typically, the protection needs for confidentiality and integrity are rated as high, because the data reveals the entire security posture of the organization.

A risk assessment that considers the storage location, access control, the sub-processor chain, and the availability of the tool. Not as a one-time exercise at contract signing, but as a regularly updated assessment.

Evidence that identified risks are being treated. If you know that your SaaS provider uses sub-processors in the US, you must also document how you treat the risk of third-country transfer: acceptance with justification, Standard Contractual Clauses, additional technical measures, or switching to a provider without US sub-processors.

A tested plan for the case that the tool is no longer available. This can be a restore from backup on your own infrastructure, an export to an alternative format, or a documented migration path to another tool.

The Loss-of-Control Factor

The audit topic reveals a fundamental pattern: the more control you give up over the data storage of your ISMS tool, the more documentation and evidence effort is required. Not because cloud solutions are inherently insecure, but because for every aspect you do not control yourself, you depend on the statements and evidence of third parties.

With a self-hosted solution, you document what you see and configure yourself. With a cloud solution, you document what the provider tells you. The auditor appreciates the difference.

This does not mean that cloud solutions automatically fail in the audit. It means you must invest more work in documentation and risk assessment with cloud solutions to achieve the same result. In an internal audit, you should include the data storage of the ISMS tool as a separate audit point before the external auditor asks.

For companies that want to minimize effort and give the auditor clear, self-verifiable answers, the self-hosted approach is the shortest path. You point to your server, open the configuration, and say: "The data resides here, this is how it is protected, and here is the evidence." No references to third-party reports, no sub-processor lists, no chains of trust.

ISMS Lite follows exactly this approach: a self-hosted solution that runs on your own infrastructure and gives you full control over your ISMS data. This simplifies not only the audit but also daily operations, because you do not constantly need to check whether something in the supply chain of your tool provider has changed.

Further Reading

• Self-Hosted vs. Cloud: Datensouveränität bei Compliance-Software
• Internes ISMS-Audit durchführen: Planung, Checkliste und Bericht
• Auftragsverarbeitung: AVV prüfen und Dienstleister bewerten
• ISO 27001 A.5.23: Cloud-Dienste sicher nutzen
• Technische und organisatorische Maßnahmen (TOMs) dokumentieren