Which SOC 2 evidence ClickHouse helps you produce
When a ClickHouse cluster sits inside a SOC 2 boundary, the auditor will ask for proof that access, change, backup and monitoring controls operate as described. A self-managed cluster produces system-level records that support those controls, mainly under the common criteria. DeployOpen prepares the systems, controls and evidence for that examination, but it does not issue reports; the independent CPA firm performing the examination does. The AICPA's 2017 Trust Services Criteria contain 61 criteria: 33 common criteria, 3 for availability, 2 for confidentiality, 5 for processing integrity and 18 for privacy. Security, covered by CC1 to CC9, applies to every SOC 2, while the other four categories add criteria only when your scope includes them.
Plan the evidence around the examination type. A Type 1 report describes the system and the suitability of control design as of a single date, so your cluster's configuration, role definitions and runbooks need to be in place then. A Type 2 report adds an opinion on operating effectiveness over a period, so the auditor will sample records across that window: access reviews, upgrade change tickets, backup and restore test results, monitoring alerts and incident logs. Confirm the observation period and the sampling approach with your auditor early, because a control that ran only once during the period will be harder to evidence than one with a recurring record.
Mapping SOC 2 criteria to ClickHouse capabilities and configuration
This table pairs each SOC 2 Common Criteria area with the ClickHouse capability, configuration and record that supports it. Read it as a starting point for planning evidence collection, then confirm the control design and scope with your auditor, who decides what is sufficient.
| Criteria area | ClickHouse capability and configuration needed | Evidence an assessor will likely ask for |
|---|---|---|
| Control environment (CC1 to CC5) | Named owners for the ClickHouse cluster, documented responsibilities, and a change process that covers the database as part of the wider platform | Ownership record, role descriptions, approval history for configuration and upgrade changes |
| Logical access (CC6): users and roles | Create named users and roles through SQL, grant least privilege, and restrict or disable the default user, which starts with all permissions | Current user and grant listing, role membership export, and the SQL or configuration used to set them |
| Logical access (CC6): row policies and profiles | Row policies to limit row visibility per role, plus settings profiles and quotas to bound resource use per user | Policy definitions, profile assignments and dated change records |
| Logical access (CC6): external authentication | Route sign-in through LDAP, Kerberos, X.509 certificates, an HTTP authenticator or JWT, depending on your identity stack | Authenticator configuration, directory group mapping, and a record of who can sign in and how |
| System operations and monitoring (CC7) | Query and session logging through system tables, exported to your log platform with retention set by policy | Sample query and login logs, retention settings, and alert history for failed logins or unusual queries |
| Change management (CC8) | Upgrades tracked against the stable or LTS release line, tested in a pre-production environment, with the changelog reviewed first | Upgrade tickets, test results, changelog review notes and the version running before and after each change |
| Risk mitigation and availability (CC9, with A1 if in scope) | ReplicatedMergeTree tables coordinated by ClickHouse Keeper, with at least three Keeper nodes in production, plus scheduled BACKUP and RESTORE jobs | Replica health history, backup job logs, and restore test results from a spare cluster |
| Restore evidence (CC9) | Regular restore tests on a spare cluster, since a backup that has never been restored may not work when needed | Dated restore test records showing the restored data was checked against expected results |
Which records a ClickHouse cluster produces for auditors
A SOC 2 examination tests whether controls operated over a period, so the cluster has to leave records that show it. The six artifacts below come from ClickHouse system tables, backup logs, the release record and your incident process, and each needs an owner, an export schedule and a retention rule set before the audit window opens.
Access review exports
Export system.users, system.roles, system.grants and system.role_grants on a fixed schedule, then compare each snapshot with the previous one and with your identity provider's group list. Record who approved each change, and remove or disable the default user if it still has its starting permissions. Auditors commonly sample a few quarters of reviews and ask for evidence that terminated staff lost access. Confirm your review cadence and retention with your audit firm before the period starts.
Authentication and session records
Keep login and session history from the server's authentication logs and session tables, and map each external authenticator (LDAP, Kerberos, X.509 or JWT) to the identity source that issued it. Store exports outside the cluster so a compromised node cannot alter them. Auditors typically pick a sample of accounts and ask for logins across the period, along with failed attempts and how they were investigated.
Upgrade change records
For each upgrade, keep a change ticket that names the target release, the changelog entries reviewed, the test run on a pre-production cluster, and the approver. Check the target against the supported versions list in the security policy, since unsupported versions receive no security updates. Auditors usually sample upgrades in the period and compare the version in the ticket with the version the server reports afterward.
Backup job logs and restore tests
Retain BACKUP and RESTORE job output, including timestamps, destination, size and failures, for the full audit period. Pair each backup series with a dated restore test on a spare cluster, recording the row counts or checksums compared and the time taken. The backup documentation warns that a backup never test-restored will probably not restore properly, so auditors usually ask for restore evidence, not only backup logs.
Keeper and replica health history
Keep monitoring history for ClickHouse Keeper quorum, replica lag, readonly replicas and failed fetches. Export alert rules along with the alerts that fired and their acknowledgments. Keeper should run on at least three nodes in production, and a recovered replica should sync missing data on its own, so the history should show those events and their durations. Auditors use this to test the availability and monitoring criteria.
Incident tickets with timelines
Each incident record should carry detection time, the alert or report that triggered it, containment steps, the responders, the recovery time and the root cause review. Link any restore or failover to the backup and replica records above so the chain is traceable. Auditors commonly select incidents from the period and check that the timeline matches the logs, and that corrective actions were tracked to closure.
Why restore tests and upgrade records carry the most weight
The most persuasive SOC 2 evidence for a self-managed ClickHouse cluster is proof that you can get data back and that you change the platform deliberately. The ClickHouse backup documentation warns that a backup never test-restored will probably not restore properly when needed, and it recommends regular restore tests on spare clusters. It also notes that replication alone does not protect against human error or corruption, because a bad DROP TABLE or a corrupted part is copied to every replica. Auditors reviewing availability and change-related criteria will look for the restore test itself, not only for a backup schedule. For each test, record the scope (which database, tables or partitions were restored, and whether BACKUP and RESTORE ran against local disk, S3-compatible storage or Azure Blob Storage), the date, the operator, the result, and the elapsed time. Confirm with your own team how long a restore of your largest tables takes, because that figure is the one your recovery commitments will rest on.
Upgrade records follow the same logic. The ClickHouse production FAQ recommends running stable releases for most production use, testing in a pre-production environment with representative data and queries, and reading the changelog before upgrading because minor backward-incompatible changes can occur. Each of those steps can become a change ticket: the target version, the changelog items reviewed, the pre-production test results, the approver, the rollout order across replicas, and the rollback plan. Before every upgrade decision, check the security policy's list of supported versions, which currently names 26.9, 26.8, 26.7 and 26.3 as receiving security updates, and record that check in the ticket. Confirm the list again on the day of the decision, since it changes over time. A ticket that shows an unsupported version was left running is evidence of a control gap, so the supported-version check belongs in the record.
What ClickHouse and your cluster will not cover for SOC 2
A SOC 2 examination covers the whole service organization, not only the database. The cards below mark the areas that ClickHouse and your cluster cannot supply on their own, and the work your organization and auditor still need to own.
No report or certification from the platform
ClickHouse is open-source software under the Apache License 2.0, and DeployOpen does not issue audit reports or attestations. A SOC 2 report is issued by an independent CPA firm after examining your system. Software and configuration can produce evidence, but no product or implementation partner can make the system SOC 2 compliant on its own. Ask your CPA firm early which Type 1 or Type 2 report you need and what period it must cover.
Policies, risk and vendor management
Written security policies, the annual risk assessment, vendor due diligence and the management description of the system sit outside ClickHouse. The Trust Services Criteria expect management to define objectives and assess risks, and the auditor will test whether those documents exist, are approved and are followed. Your cluster can show that a control operates, but it cannot write the policy that defines it.
HR onboarding and offboarding
Whether a person should have a ClickHouse account is decided in your HR and identity processes, not in the database. Evidence for joiners, movers and leavers comes from tickets, approvals and the identity provider, and must be matched to ClickHouse user and role changes. Check that a departing engineer's ClickHouse access is removed within the window your policy states, and keep the ticket that shows it.
Physical security of hosts
If ClickHouse runs in your data center, the cage, badge logs and visitor records belong to your facilities team. If it runs in a cloud account, the provider's physical controls are covered through its own assurance reports and your vendor review. Either way, the auditor will ask how physical access to the servers that hold the data is controlled, and a ClickHouse configuration file cannot answer that question.
Log retention and SIEM export
The system tables that record queries and logins are useful evidence, but they are not a retention program. Their contents are kept for limited periods that you configure, and they are local to each node unless exported. Design where audit records go, how long they are held, who can read them and how their integrity is protected, then test that a sample event can be traced end to end.
Proposed 2026 attestation changes
The AICPA Auditing Standards Board proposed revisions to its baseline attestation standards in February 2026. If adopted, they would apply to engagements beginning on or after June 15, 2029. Your engagement timing and evidence expectations may change, so ask your CPA firm how the proposal would affect your next examination and whether any evidence you collect now needs a different format.
Configuring the cluster so evidence is collected from day one
This sequence sets up the ClickHouse controls, logs and recurring records that a SOC 2 examiner will sample, so evidence accumulates from the first day of the observation period rather than being reconstructed later. Each step names the artifact it produces and who keeps it.
Agree the system boundary and categories with the CPA firm
Before changing the cluster, the service organization and its CPA firm agree which systems, data stores, people and processes fall inside the SOC 2 system description, and which Trust Services categories beyond the common criteria are in scope. The ClickHouse cluster, its Keeper nodes, backup storage, authentication sources and the upgrade pipeline should all be named explicitly. The output is a written scope that every later step can point back to. Confirm with the firm how the description criteria will be applied, since the system description is management's responsibility.
Restrict the default user and move access into SQL
The ClickHouse access control documentation recommends restricting the default user, which starts with all permissions, and managing users, roles, row policies, settings profiles and quotas through SQL statements rather than hand-edited configuration. Create named administrative accounts, disable or lock down the default user, and keep the grant statements in version-controlled scripts. The check is a query against the access control system tables showing that no unnamed account holds broad privileges, and that every role has a documented owner. Those scripts become the change history an examiner will ask for.
Connect and document the external authenticator
Choose the external authenticator that matches your identity source, such as LDAP, Kerberos, SSL X.509 certificates, an HTTP authenticator or JWT, based on the options in the external authenticators documentation. Configure it, test a successful and a rejected login, and record the configuration, the identity provider owner and the group-to-role mapping in your control documentation. Users authenticated this way should be mapped to roles rather than granted rights directly. The completed step leaves a configuration record and test results that tie logins to your central identity process.
Deploy ClickHouse Keeper on dedicated nodes
ClickHouse Keeper coordinates ReplicatedMergeTree replication and replaces ZooKeeper. The replication guide recommends at least three Keeper nodes on dedicated hosts in production, with about 4 GB of RAM each. Deploy the nodes in separate failure domains where your infrastructure allows, restrict network access to the Keeper ports, and record host inventory, sizing and placement. Verify that the ensemble has a leader and that a test table replicates between replicas. The inventory and the replication test are the evidence for availability controls.
Schedule backups and a recurring restore test
Define a backup schedule with BACKUP statements covering full and incremental runs to your chosen target, whether local disk, S3-compatible storage or Azure Blob Storage. The backup documentation notes that replication does not protect against human error or corruption, so the schedule matters alongside replication. Separately, schedule restores onto a spare cluster at a fixed cadence, since the documentation warns that a backup never test-restored will probably not restore properly. Log each backup job result and each restore test with the date, the operator, the data restored and the row count comparison.
Set up pre-production and a written upgrade change procedure
Maintain a pre-production environment with representative data and queries, as the production FAQ recommends, and use the supported version list in the security policy to decide which release lines the cluster may run. Before each upgrade, read the changelog for backward-incompatible changes, test on pre-production, and record the approval, the test outcome and the rollback plan in a change ticket. Track the release notes and the security policy for updates. The change tickets, approvals and test records form the change management evidence that examiners sample.
Schedule access reviews and export the evidence
Set a recurring access review that exports the current users, roles, grants, row policies and external authenticator mappings, then has a named owner approve or remove each entry. Keep the exported snapshots, the reviewer sign-off and the removal tickets in your evidence repository. Establish a routine that also collects backup logs, restore test records, monitoring alerts and incident tickets for the same period, so nothing has to be rebuilt at audit time. Confirm with your CPA firm which samples and periods they expect.
What SOC 2 evidence work costs and what it needs from your team
What drives the cost of preparing ClickHouse evidence for a SOC 2 audit?
The main drivers are the size of the system scope, the number of environments that produce evidence, how much of identity and logging already exists, and how many restore tests you need to run and document. A single production cluster with existing SSO, a central log store and a tested backup job is a small, bounded task. Several clusters across production, staging and disaster recovery sites, with local users and no central logs, adds design, configuration and collection work on every item. Cost is typically split between a one-time readiness build and recurring evidence collection, such as quarterly access reviews and restore tests. Ask any partner to separate those two lines in a written quote.
Can our in-house team prepare ClickHouse evidence without a partner?
Yes, if your team owns the controls and can show they operate. The work is mostly configuration and record keeping: defining roles and row policies, restricting the default user, routing authentication through your identity provider, keeping upgrade and change records, and running a documented restore test on a spare cluster. The ClickHouse backup documentation warns that a backup never test-restored will probably not restore properly, so the restore test is the item most teams underestimate. A partner adds value when the team lacks ClickHouse operations experience, needs a readiness review before the auditor arrives, or wants the evidence pack assembled in a repeatable form.
How long does ClickHouse SOC 2 evidence preparation take?
The timeline depends on the report type and the starting point. A Type 1 report describes the system and the design of controls at a single date, so preparation mainly covers design and a readiness check. A Type 2 report also tests operating effectiveness over an examination period, so the controls must run for that period before the auditor can test them. The current state of your identity, logging, patching and backup processes sets the length of the readiness phase. DeployOpen does not publish durations, so ask for a timeline in the written scope, tied to the report type and the controls you already operate.
Does a SOC 2 Type 2 report need an observation period for ClickHouse controls?
Yes. A Type 2 report adds an opinion on operating effectiveness over a period, so the controls must have operated throughout that period and left records. For a ClickHouse cluster, that means access reviews, change records for upgrades, backup jobs, restore tests, monitoring alerts and incident tickets should exist for the full window, not only at the end. The length of the period is set by the auditor and the engagement, not by the platform. Start collecting evidence before the period begins, because a control that was not operating cannot be reconstructed afterward.
What does DeployOpen provide for SOC 2 evidence, and what does our team own?
DeployOpen plans, implements and documents the ClickHouse configuration, prepares the controls and evidence for the assessment, and can run security testing as a separate engagement. DeployOpen does not issue SOC 2 reports, attestations or certifications; an independent CPA firm performs the examination. Your team owns the control decisions and the operation of those controls after handover: who approves access, who signs off on upgrades, who responds to alerts and who runs restore tests. Management also provides the written system description and representations the auditor requires. Confirm this split in the scope document before work starts.
What should we ask for in a written quote for ClickHouse SOC 2 evidence work?
Ask for a scope that names each ClickHouse cluster, environment and the report type targeted, and a list of the Trust Services Criteria areas the evidence supports, such as access, change management, system operations and risk mitigation. Request a deliverables list, for example an access review record, upgrade change records, a backup and restore test report, monitoring and incident logs, and a readiness summary. Ask which items are one-time and which recur, what the partner needs from your team and by when, what is excluded, and how change requests to scope are priced. Ask who performs restore tests and where the test cluster lives.
Which ClickHouse evidence do auditors usually ask for first?
Auditors commonly start with who can access the system and how that access is reviewed, so expect requests for the user and role list, authentication configuration and review records. Next are change records for upgrades, which should show the version, the changelog review, pre-production testing and approval. Backup and restore evidence follows, meaning job logs and a dated restore test with its results. Monitoring and incident records close the set. The exact requests depend on the criteria in scope and the auditor, so confirm the evidence list with the CPA firm early.
Working with your CPA firm on the system description
The system description is management's document, and management is responsible for preparing it. For a SOC 2, the description is prepared and evaluated against the AICPA's 2018 description criteria (DC 200), with revised implementation guidance issued in 2022. The examination itself is assertion-based under AT-C section 205 of the AICPA attestation standards, which requires the service auditor to obtain written representations from management. In practice, that means your organization signs off on the description and on the statements behind it, so every ClickHouse claim in the description must be something your team can show with evidence. Agree the evidence list with your CPA firm before the examination period starts, not during fieldwork. Cover the access review exports, the upgrade change records, the backup and restore test reports, the monitoring alerts and the incident log entries described elsewhere on this page, and confirm the format and sampling expectations for each. Ask the firm which points of focus it expects you to address for your chosen categories.
Keep the description accurate about where ClickHouse data, backups and object storage live. For a self-managed cluster, the description must name the regions, data centers or cloud accounts that hold replicas, backup targets (local disk, S3-compatible storage or Azure Blob Storage, per the backup documentation) and Keeper nodes, along with who can reach them. If a backup bucket moves, a replica is added in another region or an operator gains access to a new account, update the description and tell the firm during the period rather than discovering the change at testing. Confirm with your auditor how they want system changes of this kind documented, and whether they expect a Type 1 point-in-time description, a Type 2 operating period, or both.
Decide early who may receive the report and in what form. A SOC 2 report is generally restricted in use, typically to existing customers, regulators and parties with a defined need, while a SOC 3 report covers the same categories in less detail and is a general use report that can be freely distributed. If your sales or marketing team needs a document for prospects, ask the CPA firm whether a SOC 3 report is appropriate and what it would omit about your ClickHouse controls. Confirm the distribution terms in your engagement letter. Finally, check the status of the AICPA Auditing Standards Board's proposed revisions to its baseline attestation standards, which were exposed in February 2026 and, if adopted, would apply to engagements beginning on or after June 15, 2029. Ask your firm how it expects to handle any change to those standards before your next examination.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted ClickHouse inside your own cloud accounts, data centers or restricted networks. For SOC 2 evidence, we shape the cluster, its access model, change records, backup tests and monitoring so the evidence your auditor samples is produced as a normal by-product of operations. DeployOpen prepares these controls and records; the independent CPA firm performs the examination.
How we scope
- We agree in writing which Trust Services Criteria categories and systems sit inside the examination boundary.
- The written scope lists each evidence source: user and role exports, change tickets, restore test logs and alert history.
- Engagements are fixed-scope, with deliverables and timelines agreed before work starts; ongoing support is available as a retainer.
How we build
- We configure named users, roles and external authenticators, restrict the default user, and export the access state for review.
- We set up upgrade records tied to changelog review and a pre-production test on representative data before each change.
- We schedule restore tests on a spare cluster and capture the results, timings and gaps in a repeatable runbook.
How we hand over
- You receive a control-to-evidence map that names each system table, log, ticket type and report that supports a control.
- You receive the runbooks, access review procedure and evidence collection schedule, written so your own staff can repeat them.
- We document the system description inputs your management team needs for the SOC 2 description, without issuing any report ourselves.
How we support
- Retainers cover recurring access reviews, upgrade records, restore test cycles and monitoring checks against the agreed scope.
- We help your team answer auditor requests and prepare samples, while the CPA firm decides what it tests and concludes.
- We review evidence gaps after each audit period and agree in writing any changes to scope, controls or retainer work.
