Which ISO 27001 controls ClickHouse helps you meet
A ClickHouse cluster inside an ISO 27001 scope mainly helps with the technological controls in Annex A, which cover access to information, logging and monitoring, backup, cryptography and secure configuration. The four Annex A themes are organizational, people, physical and technological, and the database touches the last one most directly. Before you map anything, remember that ISO does not certify organizations. Accredited certification bodies do, and DeployOpen prepares systems, configuration and evidence for that assessment without issuing audit reports or attestations.
Within the technological theme, the ClickHouse features that matter most are the access model and the logs it produces. Access control uses users, roles, row policies, settings profiles and quotas, and external authenticators such as LDAP, Kerberos, X.509 certificates and JWT can tie database sign-in to your identity provider. Restricting the default user is a first step to confirm in your environment, since it starts with all permissions. Backups are covered by BACKUP and RESTORE, but the documentation is explicit that replication alone does not protect against human error or corruption, so your restore tests are the evidence an auditor will ask for. Encryption, secure configuration and monitoring settings should be checked against the version you actually run, using the ClickHouse security policy to confirm supported releases.
Several requirements sit outside the database and need your own organizational and people processes. Policies, risk assessment, supplier management, awareness training, joiner and leaver procedures and management review are not produced by ClickHouse. Physical controls such as data center access, equipment disposal and secure hardware placement belong to your facilities or hosting provider. Ask your certification body early which evidence it expects from each side, so the database team and the governance team do not assume the other one owns a control.
Mapping Annex A controls to ClickHouse capabilities and configuration
This table maps the Annex A control areas most relevant to a self-managed ClickHouse cluster to the ClickHouse capabilities that support them and the configuration you need to set. Use it as a starting point for your own control design, and confirm each control ID and title against your copy of ISO/IEC 27001:2022 before you rely on it.
| Annex A control area | What the requirement asks for | ClickHouse capability | Configuration needed |
|---|---|---|---|
| Access control (5.15, 5.18, 8.2, 8.5) | Limit access to information to what each role needs, review and remove access, and use strong authentication for privileged access. | Users, roles, row policies, settings profiles and quotas; external authenticators such as LDAP, Kerberos, SSL X.509 certificates and JWT. | Create users and roles with SQL, grant least privilege, restrict or disable the default user, and connect a central directory where your identity policy requires it. |
| Logging and monitoring (8.15, 8.16) | Record events that show who did what, protect those records, and watch systems for anomalous behavior. | System tables such as query and session logs record queries and logins; Prometheus metrics expose server state. | Enable and retain query and session logging, export logs to your central log platform, and confirm the retention period against your own policy. |
| Information backup (8.13) | Keep backups of information and test that they can be restored. | BACKUP and RESTORE for full and incremental backups to local disk, S3-compatible storage or Azure Blob Storage. | Schedule backups to a separate location, protect backup credentials, and run restore tests on a spare cluster, since the vendor warns an untested backup will probably not restore. |
| Redundancy of information processing facilities (8.14) | Design processing so that a component failure does not stop the service unacceptably. | ReplicatedMergeTree tables coordinated by ClickHouse Keeper; a recovered replica syncs missing data automatically. | Run at least three Keeper nodes on dedicated hosts in production, and do not treat replication as a backup because it does not protect against human error or corruption. |
| Cryptography (8.24) | Define and apply rules for cryptographic use, including protection of data in transit and key management. | SSL X.509 certificates for client and server connections; TLS support in the server configuration. | Enable TLS for client and inter-node traffic, define certificate issuance and rotation, and confirm how encryption at rest is provided in your storage layer. |
| Secure configuration (8.9) | Establish, document and maintain secure configurations for software and infrastructure. | Configuration files and the SQL-driven access model let you keep settings under version control. | Store server and user configuration in version control, remove the default user's full permissions, and review changes before they reach production. |
| Management of technical vulnerabilities (8.8) and change management (8.32) | Identify vulnerabilities, obtain fixes in time, and control changes to systems. | Security policy lists supported versions with security updates; stable releases ship roughly monthly; LTS releases are supported for a year. | Run only supported versions, test upgrades in a pre-production environment with representative data, and read the changelog for backward-incompatible changes before upgrading. |
| Network security (8.20, 8.22) | Secure networks and segregate network services so that only intended traffic reaches them. | Listener and interface settings control which networks reach the server and Keeper nodes. | Restrict listening addresses and firewall rules to application, Keeper and backup networks, and confirm exact settings in your deployment and version documentation. |
What evidence a ClickHouse cluster produces for an ISO 27001 auditor
An auditor testing ClickHouse controls will ask for records, not explanations. The items below are the ones a self-managed cluster naturally produces, and each needs a storage location, an owner and a version history so it can be pulled during an audit cycle. Keep them in one evidence repository that is reviewed on a schedule, not assembled the week before fieldwork.
Access control configuration exports
Export users, roles, grants, row policies, settings profiles and quotas on a schedule, and store each export as a versioned text file. Because access is driven by SQL, the grant statements themselves are the evidence, so the export should be diffable from one review period to the next. Check that the default user has been restricted and that the export shows no unexpected grants. Keep the export alongside the approval record for each change, so an auditor can match a grant to the request that justified it.
External authenticator settings
Where ClickHouse delegates sign-in to LDAP, Kerberos, X.509 certificates, an HTTP authenticator or JWT, the configuration file that defines each authenticator is evidence of how identity is verified. Store it in version control with the change history, and record who approved each change. Review the file against the identity provider's own records, since an auditor will ask whether a departed employee could still authenticate. Note which authenticators are enabled for each cluster and environment.
Server and query logs under retention
Query and session logs show who connected, what they ran and when, which supports the logging and monitoring controls in Annex A. Define a retention period for these logs in writing, forward them to a central store with restricted access, and confirm that the retention rule is actually enforced. Test a sample retrieval during the review period. Mask sensitive literals before logs leave the cluster, because the log store becomes a new place where personal or confidential data can sit.
Backup runs and restore test records
Keep the schedule of BACKUP runs, the success or failure output of each run, and the storage location of each backup set. The more important record is the restore test: the date, the backup restored, the spare cluster used, the time taken and the result of the data checks. The ClickHouse documentation warns that a backup never test-restored will probably not restore properly when needed, so an auditor will look for these test records first. Record failed tests and the corrective action too.
Upgrade records against supported versions
Each upgrade should produce a change record that names the source and target versions, the changelog reviewed, the test run on a pre-production environment with representative data, the approval and the rollback plan. Compare the running version against the list of versions the ClickHouse security policy currently supports, and record any period in which a cluster ran an unsupported release. These records connect vulnerability management to the change process, so keep them in the same repository as the configuration exports.
Replica recovery observations
When a replica fails and rejoins, ClickHouse syncs missing data from a healthy replica automatically, but that behavior is only useful evidence if someone observed it. Record each failover or replica restart, the time it was detected, the time the replica caught up and any data discrepancies found. Include Keeper health during the event, since coordination loss is a common cause of replication stalls. These observations support the availability and incident management controls, and they show the auditor how the cluster behaves under failure.
How access, logging and backup controls depend on each other
The access, logging and backup controls in a self-managed ClickHouse cluster reinforce one another, and an auditor will test them as a set. Restricting the default user is the first link in that chain. ClickHouse's default user starts with all permissions, so the cluster should be configured so that the default account is locked down and day-to-day work runs under named users who are granted roles through SQL. When roles are the only path to privilege, the question "who could change this table or this backup job?" has an answer that can be read from the access control tables and matched against the access review. Without that restriction, query logging still records activity, but the record has little value because the actor behind a high-privilege session may be an unnamed shared account.
Backups depend on the same discipline. The backup documentation is explicit that replication alone does not protect against human error or corruption: a DROP TABLE or a bad ALTER runs on every replica, and a recovered replica will faithfully resync the damage. The backup is therefore a separate control, with its own owner, its own storage location and its own evidence. Confirm which roles can run BACKUP and RESTORE, where the backup target is written, and whether the account that writes backups can also delete them. If one administrator can alter the data, disable the job and remove the copies, the control does not hold for ISO 27001 purposes. The ClickHouse backup documentation also warns that a backup never test-restored will probably not restore properly, so a documented restore test on a spare cluster belongs in the same evidence set as the access review.
The ISMS owner should own the evidence trail across these three areas, because no single technical team sees all of it. The access model, the query and session logs, and the backup records each live in a different place and are usually maintained by a different person. Agree in advance which records prove each control, how long they are retained, where they are exported, and who signs off the periodic review. Map each record to the Annex A control it supports, so that during certification the ISMS owner can show how an access change, a logged query and a successful restore test connect to a single policy. Ask your certification body early which evidence it expects for each control, because the answer determines how the logs and tests must be configured.
Where ClickHouse does not satisfy ISO 27001 on its own
ClickHouse can support several Annex A technological controls, but it does not operate an information security management system, and it cannot make your organization certifiable. The gaps below sit around the database: the management system that governs it, the people and premises that run it, the suppliers behind it, and the certification scope that decides what an auditor examines.
The ISMS itself
ISO/IEC 27001 requires an information security management system with a defined scope, a documented risk assessment and treatment process, a statement of applicability, policies, internal audit and management review. ClickHouse provides none of these. Your team must decide which services, environments and backups sit inside the ISMS, record how risks to the cluster are assessed, and show that management reviews the results. Confirm who owns the ISMS before the cluster design is locked.
Organizational and people controls
Many Annex A organizational controls, such as roles and responsibilities, segregation of duties, and screening and training of people, apply to the staff who administer ClickHouse. The database can enforce that a user has only the grants assigned to them, but it cannot decide who should be a database administrator, who approves a schema change, or how leavers lose access. Write those responsibilities into your own procedures and keep records of them.
Physical controls for the hosting environment
Physical controls cover the data center or cloud account that hosts the cluster: facility access, equipment disposal, secure siting and environmental protection. If you run ClickHouse in your own racks, these controls are yours. If you run it in a cloud account, the provider's physical controls are relevant, but you must still document how your account, network and storage locations are governed. Ask your hosting provider for its own ISO 27001 certificate and the scope it covers.
Supplier and vendor management
ClickHouse server is open source, but your cluster also depends on the operating system, Keeper nodes, object storage, identity providers, monitoring tools and the consultants who build it. Annex A supplier controls expect you to assess these suppliers, agree security terms, monitor their service and plan for exit. Keep a register of each component, its license, its support route and the version you run, and confirm which security update channel covers each one.
Certification scope decisions
The certification scope defines which business units, systems and locations an auditor tests. A ClickHouse cluster that holds customer data may sit inside the scope or outside it, depending on how the data flows and which controls protect it. Narrow scopes are cheaper to maintain but must still cover every process that creates, moves or deletes the data. Agree the scope with your certification body before you design logging, backups and access, because those choices fix what evidence exists.
No attestation from the vendor
ClickHouse, DeployOpen and any open-source project do not issue audit reports, attestations or certificates for your environment. Accredited certification bodies assess your ISMS, and they will ask for evidence produced by your own processes. Features such as log masking, encryption at rest or specific audit fields must be confirmed in the exact version you deploy, using its documentation and your own tests, before you cite them in a control description.
Configuring ClickHouse for ISO 27001 evidence
This sequence turns a self-managed ClickHouse cluster into one whose access, logging, backup and change records can be shown to an auditor against the relevant Annex A controls. It is a working order of operations, and the client's ISMS scope decides which steps apply and how far each one reaches.
Fix the supported version line
Confirm which ClickHouse release line the cluster will run, using the security policy's list of versions that receive security updates, and record the choice with the reason for it. Pick a stable or LTS line that is on that list, and note the planned review point for moving to a newer line. This step supports the technological controls on secure configuration and vulnerability management, since an unsupported version cannot receive security fixes. The output is a signed-off version record that the change log can refer to later.
Restrict the default user
Lock down the default user, which starts with all permissions, so that it cannot be used for routine work. Create named administrative accounts through SQL, remove or disable the default account's network access and password, and confirm that application users have only the rights they need. This step supports the technological controls on identity management and privileged access rights. The check is a query against the user and grant system tables showing that no shared or unrestricted account remains in use.
Define roles and row policies
Build roles that match the job functions in the ISMS scope, grant each role the minimum privileges, and use row policies where a team should see only part of a table. Add settings profiles and quotas so that resource use is bounded per role. This step supports the controls on access rights and least privilege. The output is a role matrix that the access review can check against, along with the SQL used to create it, kept under version control.
Connect external authentication
Connect ClickHouse to the identity source the organization already governs, such as an LDAP directory, Kerberos, X.509 client certificates, an HTTP authenticator or JWT, depending on what the ISMS relies on. Remove local passwords where the external source is the authority, and test that disabling a person in the directory blocks their ClickHouse access. This step supports the controls on authentication information and secure log-on. The evidence is a test record showing a successful login, a refused login after the account is disabled, and the configuration file.
Enable and retain query and session logs
Turn on the system logs that record log-ins and queries, decide how long they are kept, and set a storage location that the cluster's own administrators cannot quietly alter. Confirm which fields are captured and whether sensitive values appear in query text, and apply masking where they do. Forward the logs to the monitoring or SIEM platform the organization uses. This step supports the controls on logging, monitoring and protection of log information. The output is a logging standard that states the retention period set by the client and a sample export that proves events are arriving.
Set up backups and test restores on spare clusters
Configure BACKUP jobs to a storage target separate from the cluster, cover the full and incremental cycle the recovery objectives require, and protect the backup credentials. Then run restore tests on a spare cluster at the frequency the client sets, because a backup that has never been restored may not work when it is needed. Replication alone is not treated as a backup, since it does not protect against human error or corruption. This step supports the controls on information backup, redundancy and continuity. The evidence is the backup schedule, the job logs and a dated restore test record with the outcome.
Set Keeper and replica topology
Deploy ClickHouse Keeper on the number of nodes the replication guide recommends for production, on dedicated hosts, and place replicas so that a single node or site failure does not remove the data. Test a replica failure and confirm that the recovered replica syncs its missing data without manual steps. This step supports the controls on redundancy of information processing facilities and resilience. The output is a topology diagram, the Keeper configuration and a failover test record that the operations team keeps.
Document each change and retain the record
Keep a change record for every configuration, role, version and topology change made in the steps above, with the reason, the approver and the test that confirmed it. Store the SQL and configuration files in version control and link each change to the risk treatment or control it supports in the ISMS. This step supports the controls on change management and documented operating procedures. The check is a sample of recent changes traced end to end from the request to the test evidence, confirmed with the client's auditor expectations before the first assessment.
Questions buyers ask about ISO 27001 and ClickHouse
Is ClickHouse ISO 27001 certified?
No. ISO 27001 certifies an organization's information security management system, not a software product. ClickHouse server is open source under the Apache License 2.0, and ClickHouse Inc. sells a managed service separately. Your organization, operating its own ClickHouse cluster, is the party that can be certified. Accredited certification bodies assess your ISMS, and ISO itself does not certify organizations. DeployOpen prepares systems, configurations and evidence for that assessment, but does not issue certificates or audit reports. Ask any partner who claims product-level certification to explain what they mean by it.
How much does an ISO 27001 readiness engagement cost?
DeployOpen does not publish a price list, and a quote follows from a written scope. The main cost drivers are the number of ClickHouse clusters and environments in scope, how many systems feed them (identity providers, log pipelines, SIEM, backup storage), how many Annex A controls you already evidence elsewhere, and how much policy and procedure work is missing. Costs are mostly one-time for readiness work, while certification audits and ongoing evidence collection recur on the certification cycle. Ask for a quote that separates technical hardening, documentation, evidence preparation and any retained support, and that states which items are excluded.
How long does ISO 27001 preparation take for a ClickHouse environment?
Duration depends on scope more than on ClickHouse itself. A single production cluster with existing identity, logging and backup processes takes far less work than a multi-cluster estate with undocumented access and no restore tests. The certification body's own cycle also shapes your plan: under ISO/IEC 17021-1, a management system certification cycle lasts three years, with at least one audit in every calendar year. Ask a partner to show the work packages, the dependencies on your own teams and the points where your certification body must be engaged. No duration should be accepted without that breakdown.
What does our team need to provide before the work starts?
Before work starts, your team needs to supply four things in writing:
- Named owners for each ClickHouse cluster, its Keeper nodes, its identity integration and its backup targets.
- Current user, role and access lists, including who holds administrative rights and whether the default user is still active.
- Log retention rules for query and session logs, and the SIEM or archive where they must be exported.
- Backup targets, retention periods and the restore test cadence you expect, including any spare cluster available for restore tests.
Missing answers on these points usually add scope, so confirm them before the quote is final.
Can our own team do ISO 27001 work on ClickHouse without a partner?
Yes, many organizations do. Your team can configure access control, logging, backups and secure settings if it has the ClickHouse operations skills and the time to document them. The usual gaps are not technical. They are consistent evidence, a clear mapping from Annex A controls to real settings, and tested restores that leave a record. The ClickHouse backup documentation warns that a backup never test-restored will probably not restore when needed, so restore evidence matters as much as the backup job. A partner adds value when your team lacks capacity, needs an independent review before the certification audit, or wants a fixed-scope delivery with written deliverables.
Which ClickHouse versions should we run to keep security updates in scope?
Run a version that still receives security updates. The ClickHouse security policy lists versions 26.9, 26.8, 26.7 and 26.3 as currently supported, and all other versions as unsupported. Auditors will ask how you track this, so record the version in use, the date you checked the policy, and your upgrade plan. The production FAQ recommends stable releases for most production use, a pre-production environment with representative data, and reading the changelog before upgrading. Confirm the current list on the security policy page at the time of your assessment, because it changes.
What evidence will an auditor ask for from our ClickHouse cluster?
Expect requests tied to the Annex A controls in your statement of applicability. Typical items include the list of accounts and roles with their review dates, authentication settings for LDAP, Kerberos, X.509 or JWT where used, query and session logs with their retention settings, backup job records, and restore test reports from a spare cluster. Replication alone does not count as backup, and the ClickHouse documentation says so directly. Ask your partner which evidence they will produce, in what format, and who signs off on it.
Why the 2022 edition and version support both matter for the audit
Auditors will assess your ISMS against ISO/IEC 27001:2022, the third edition, which replaced the 2013 edition. Under IAF MD 26:2023, all certificates to the 2013 edition had to expire or be withdrawn by 31 October 2025, the end of the 36-month transition period. Accredited certification bodies now apply ISO/IEC 17021-1 together with ISO/IEC 27006-1, which IAF MD 29:2024 required them to apply to all clients by 31 March 2026. If your ClickHouse controls still map to the 2013 control numbering, the evidence will not line up with what the auditor asks for. Confirm with your certification body which edition and transition dates apply to your scope, using the IAF MD 26 transition document as the starting reference.
Version support is the technical side of the same question. ClickHouse's security policy lists versions 26.9, 26.8, 26.7 and 26.3 as supported with security updates, and all other versions as unsupported. A cluster running an unsupported line cannot show that its technological controls around patching and vulnerability handling are operating. Record which ClickHouse version runs on each node, and map that version to the supported list at every assessment point, including the replicas and Keeper nodes that often lag behind the primary.
Upgrades are where the two requirements meet. Keep a change record for each ClickHouse upgrade that names the source and target versions, the changelog review, the pre-production test on representative data, the rollback plan and the restore test that followed. The production FAQ recommends reading the changelog because minor backward-incompatible changes can occur, and an auditor will expect to see that review. Ask your team to define who approves each upgrade and which release channel (stable or LTS) you follow before the first audit cycle starts.
How DeployOpen prepares ClickHouse controls and evidence
DeployOpen plans, builds and documents ClickHouse controls inside your own infrastructure, so the configuration and records an auditor reviews come from your environment. We prepare systems, controls and evidence for an ISO/IEC 27001 assessment, but the certification decision rests with an accredited certification body.
How we scope
- Engagements are fixed-scope, with the ClickHouse clusters, environments and Annex A controls agreed in writing before work starts.
- The written scope names which access, logging, backup, cryptography and configuration controls are in scope and who owns each one.
- We confirm your ISMS documentation, statement of applicability entries and existing evidence sources before any build begins.
How we build
- We configure users, roles, row policies and external authentication, and restrict the default user before any workload loads.
- We set up query and session logging, retention and export to your log platform, with masking rules agreed with your security team.
- We design backup schedules and restore tests against replicated clusters, then run restore tests on spare hardware and record results.
How we hand over
- You receive configuration documentation, runbooks and a control-to-evidence map that links each Annex A control to its artifacts.
- Restore test records, access review templates and upgrade change records are delivered in formats your auditors can sample.
- We walk your team through the evidence routines so they can keep producing records after the engagement ends.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial build.
- Retainers can cover version tracking against the ClickHouse support policy, patch planning and periodic restore tests.
- Ask for a written quote that lists which controls, environments and recurring evidence routines the retainer includes.
