Can ClickHouse stay out of PCI DSS scope?
An analytics team that wants payment-flow events in ClickHouse can keep the cluster outside the cardholder data environment only if no cardholder data and no sensitive authentication data ever reach it, in storage, in processing or in transit. If the cluster does receive those values, it is in scope and must support the controls PCI DSS v4.0.1 expects. The first decision is therefore a data-flow decision: confirm which fields the ingestion path (Kafka topics, application logs, OpenTelemetry pipelines) carries, and block primary account numbers and sensitive authentication data upstream rather than relying on ClickHouse to discard them later. Tokens, truncated values or hashed identifiers are the usual substitutes, but whether a token is out of scope depends on how your tokenization service is assessed, so confirm that with your QSA or acquirer before you design around it.
Scope is not set by the standard's owner. PCI SSC does not enforce compliance or impose penalties. The payment brands decide which entities must validate and run any enforcement programs, so ask your acquirer or payment brand which assessment applies before you size the controls. Validation takes the form of a Report on Compliance completed by a Qualified Security Assessor or a Self-Assessment Questionnaire, each with an Attestation of Compliance. DeployOpen prepares the ClickHouse configuration, network segmentation, access records and evidence that an assessor will ask for, but it does not issue a ROC, an AOC or any other attestation. Those documents come from your assessor and the payment brands, not from the implementation partner.
Mapping PCI DSS requirement areas to ClickHouse capabilities
This table maps the PCI DSS v4.0.1 requirement areas that usually touch a data store to the ClickHouse features that support them, along with the configuration each one needs. Use it to see which controls ClickHouse can carry, which ones sit in your network and operations, and where an assessor will still ask for evidence you must produce yourself.
| Requirement area | ClickHouse capability | Configuration needed | Evidence to keep |
|---|---|---|---|
| Network security | Network exposure of the HTTP and native ports, and Keeper traffic between nodes | Restrict listening interfaces, isolate Keeper on its own network segment, and allow only application subnets to reach the cluster ports | Firewall rules, network diagrams and change records for each rule |
| System hardening | Default user starts with all permissions, so it must be restricted before go-live | Disable or lock down the default user, create named administrative accounts, and remove unused access paths | Configuration files under version control and a dated hardening baseline |
| Strong access control | Users, roles, row policies and settings profiles, with LDAP, Kerberos, X.509 or JWT external authenticators | Use the SQL-driven workflow, grant roles instead of direct privileges, and apply row policies to restrict cardholder-adjacent data by job function | Exported grants, role membership lists and periodic access review sign-offs |
| Logging and monitoring | Query logging through system tables, which records statements and sessions | Keep query and session logging enabled, forward logs to your SIEM, and mask sensitive literals before they are written | Log retention settings, sample audit queries and alert rules tied to privileged access |
| Encryption | TLS for client and inter-node connections, and encryption of data at rest through storage configuration | Configure certificates for all listeners, use encrypted disks or volumes where your platform supports them, and confirm key custody with your team | Certificate inventory, key rotation records and storage encryption settings |
| Data minimization and tokenization | Storage is controlled by your table design, so tokens can be stored in place of primary account numbers | Store tokens from a vault outside the cluster where possible, avoid full card numbers in any table, and set TTL rules for retention | Table schemas, data flow diagrams and TTL definitions |
| Backup and testing | BACKUP and RESTORE for tables, partitions or databases to local disk, S3-compatible or Azure Blob storage | Schedule full and incremental backups, encrypt the backup destination, and run restore tests on a spare cluster | Restore test reports, backup job logs and records of who can read the backup store |
| Resilience of the data store | ReplicatedMergeTree tables coordinated by ClickHouse Keeper, with automatic resync of a recovered replica | Run at least three Keeper nodes on dedicated hosts in production, and remember that replication does not protect against deletion or corruption | Keeper health checks, replica status history and the backup policy that covers those gaps |
How tokenization keeps card numbers out of analytics tables
If ClickHouse only ever holds tokens, the analytics platform should fall outside the cardholder data environment, but only when the design proves that no primary account number (PAN) can reach it. Scope follows the data and the systems that could affect it, so the boundary moves only when three things are separated: the token vault, the tokenization service that calls it, and the analytics schema that ClickHouse serves. The vault holds the PAN-to-token mapping and stays inside the cardholder data environment. The tokenization service is the only component permitted to call the vault. ClickHouse tables receive tokens, masked values and business attributes, and the network, credentials and service accounts should reflect that split. Whether a token-only ClickHouse cluster is out of scope is a judgment for your QSA, so confirm the boundary with them before the data model is frozen.
Define what must never reach ClickHouse, including sensitive authentication data. Full PANs are the obvious case, but the list also covers card verification codes, PIN data and full track data, which PCI DSS prohibits storing after authorization even in encrypted form. Ingestion paths deserve the same scrutiny: Kafka topics, PostgreSQL replication, OpenTelemetry collectors and application logs can each carry card data into ClickHouse without anyone adding a card column on purpose. Write allow-lists for ingested fields, reject unexpected columns at the pipeline boundary, and ask the tokenization provider and your QSA which fields the token format and the masking rules actually produce.
Test for PANs in tables, logs and backups, not just in the schema. Run pattern scans with a Luhn check against system.query_log, server and Keeper logs, exported audit records, and sample rows in every table, then repeat the scan on restored backup data made with BACKUP, because a backup carries whatever the live tables held. Keep the scan results as evidence, and set the scan to run after each schema change and each pipeline release. Design the test with your QSA so that the scope of the scan, the sampling method and the handling of any hit are agreed before the first run.
What evidence a QSA will ask ClickHouse to produce
A Qualified Security Assessor will test ClickHouse controls by asking for records, not descriptions. The cards below list the artifacts to keep current, how to refresh each one, and who should sign them off before an assessment begins.
User and role inventory export
Export the users, roles, row policies and settings profiles from access control on a fixed schedule, and keep the dated files with the change tickets that produced them. A QSA will compare the export against the list of people who need cardholder data access and ask why each account exists. Sign-off belongs to the data owner who approves access and to the security lead who confirms the export matches the running cluster.
Default user restriction record
ClickHouse ships with a default user that starts with all permissions, so the assessor will expect evidence that it was restricted or disabled. Keep the configuration change, the server-side check that shows the restricted state, and the date it was verified after each upgrade. Confirm with the security lead that no application still connects through the default account.
Network and TLS configuration
Keep the listener settings, certificate inventory, cipher and protocol configuration, and firewall rules that limit which networks can reach the cluster and Keeper nodes. Record certificate expiry dates and the owner of each certificate. Review the set after every configuration change, and have the network owner and the security lead approve it together.
Keeper and replica health records
Retain periodic captures of ClickHouse Keeper quorum status and replica sync state, along with the alerts raised when a replica falls behind or a Keeper node drops out. Assessors use these records to judge whether the cardholder data environment stayed available and whether incidents were detected. The platform operations lead should review and sign the monthly summary.
Backup and restore test results
Store each restore test as a dated record that names the backup, the spare cluster used, the tables restored, the row counts compared, and any failures. The ClickHouse documentation warns that a backup never test-restored will probably not restore properly, so an untested backup will not satisfy an assessor. The data owner and the operations lead should both sign each test result.
Query log retention settings
Document the retention period and storage location set for the query log and session log, and show that access to these tables is restricted to the audit role. Assessors will check whether logs that could contain cardholder data are masked and whether the retention matches the policy you have written. The compliance lead should approve the setting, and the security lead should review the log access list each quarter.
Configuring ClickHouse for a PCI DSS review
This sequence turns a self-managed ClickHouse cluster into something a QSA or internal assessor can examine: a documented cardholder data boundary, restricted accounts, encrypted and authenticated connections, a resilient replicated layout, tested backups and a recurring access review. Each step leaves evidence that the assessment can reference.
Map data flows and document the CDE boundary
Before any configuration change, the team lists every source that sends data to ClickHouse, every consumer that reads from it and every system that could reach the cluster's network. The team, with your QSA or internal assessor, decides whether any table will hold primary account number data, sensitive authentication data or anything that could affect the security of the cardholder data environment. The output is a dated data flow diagram and a scope statement that names which ClickHouse hosts, Keeper nodes and backup targets are in scope. If the cluster holds only tokens and no account data, the scope statement must still explain why it is not in scope and what would change that.
Disable or restrict the default user
ClickHouse's default user starts with all permissions, so the platform team creates named administrative accounts through SQL, assigns them roles and then disables or restricts the default user. Confirm the change by logging in with each named account and attempting a privileged action from an unprivileged account, which should fail. Keep the configuration change in version control so the assessor can see when the default access was closed and who approved it.
Define roles, row policies and quotas
Access follows the scope statement. The team creates roles per job function, such as ingestion service, analyst and administrator, grants each role only the tables it needs and adds row policies where a query should see only part of a table. Settings profiles and quotas limit resource use per role. Verify by querying the access grants from the system tables and checking that every in-scope table appears under a named role. Export the grant list as a baseline for the access review in a later step.
Connect an external authenticator for workforce access
Shared local passwords are hard to review and hard to revoke. The identity team connects ClickHouse to an external authenticator that already governs staff accounts, such as LDAP or a directory, Kerberos, SSL X.509 client certificates, an HTTP authenticator or JWT authentication. The choice depends on the directory and the client tooling your teams use, and the vendor documentation should be checked for the exact version you run. Test a joiner and a leaver: a newly enabled account should log in, and a disabled one should fail. The output is a test record showing both results.
Enable TLS on every client and inter-node path
The platform team issues certificates from the organization's approved certificate authority, configures TLS for client connections, for replication between replicas and for Keeper connections, and disables plaintext listeners that are not needed. Cipher and protocol choices should follow your own cryptography policy and the assessor's expectations. Confirm the result with a connection test from an in-scope client and a scan of the open listening ports, and keep the certificate inventory with expiry dates so renewal is tracked.
Deploy a Keeper ensemble on dedicated hosts
Replicated tables depend on ClickHouse Keeper for coordination. The ClickHouse replication guide recommends at least three Keeper nodes, on dedicated hosts in production, with about 4 GB of RAM each. The infrastructure team deploys the ensemble on hosts that do not run ClickHouse data nodes, applies the same TLS and access rules, and checks that a leader is elected and that a single node failure leaves the ensemble working. The output is a documented ensemble layout and a failover test record.
Schedule backups and prove them with a restore test
The team configures BACKUP jobs for in-scope databases and tables to the chosen target, which may be local disk, S3-compatible storage or Azure Blob Storage, and encrypts or access-controls that target according to your policy. Replication alone does not protect against human error or corruption, and the backup documentation warns that a backup never test-restored will probably not restore properly. The team restores the latest backup to a spare cluster and compares row counts and sample checksums against production. Record the date, the operator and the result, and repeat the restore on a set schedule.
Set the access review cadence and retain evidence
The security owner sets a recurring access review that compares the current user, role and row policy lists against the approved roster, removes stale accounts and records each decision. The review also covers Keeper and backup-target access. The first review produces a signed baseline, and later reviews reference it. Ask your QSA which review frequency and evidence format the assessment expects, because the assessor, not DeployOpen or the vendor, decides whether the controls satisfy the requirements.
Questions buyers ask before hiring help for PCI DSS and ClickHouse
Can ClickHouse be kept out of PCI DSS scope?
Sometimes, but only if the cardholder data never reaches the cluster and nothing in the cluster can affect the security of the cardholder data environment. PCI DSS applies to entities that store, process or transmit cardholder data or sensitive authentication data, or that could affect the security of that environment, so the scope decision follows the data flows, not the product name. A design that stores tokens instead of primary account numbers, keeps detokenization and card data in a separate segment, and masks card-like values in logs gives the best chance of a smaller scope. Ask a QSA or your acquirer to confirm the boundary before you rely on it. DeployOpen prepares the evidence for that review but does not issue the assessment.
What drives the cost and effort of a PCI DSS scope analysis?
The main drivers are the number of systems that touch cardholder data, how many data flows cross into ClickHouse, how many teams hold access, and how much existing documentation you can supply. Each extra ingestion path, log source or downstream dashboard adds review and testing work. Cost has one-time parts (scope analysis, configuration, evidence setup) and recurring parts (access reviews, log review, retesting after changes). A written scope should list the systems in each phase, who performs each task, and what is delivered. No public price is given for this work, so request a quote based on that scope.
How long does a ClickHouse PCI DSS configuration project take?
Duration depends mainly on the number of data flows into and out of ClickHouse, not on the cluster size. Each flow needs a documented source, format, owner, retention rule and masking decision, and each must be tested. A small, well-documented environment with one or two flows is far quicker to configure than a cluster fed by many payment and logging sources. No researched duration applies to this work, so ask for a timeline in the written scope that lists flows, environments and review checkpoints. Ask the assessor how much time they need to review the result, since their schedule often sets the end date.
What must our team provide before a PCI DSS engagement starts?
The team needs to provide a current data flow diagram, a named owner for each data flow and each ClickHouse role, and a list of accounts with their access. In practice this means:
- Data flow diagrams showing where card data, tokens and logs enter, move and leave
- Owners for each source system, table and business function that reads the data
- Access lists for operating system, database and application accounts, with the groups they belong to
- Current network diagrams, retention requirements and any existing log masking rules
Missing items usually become open questions in the scope, so collect them before quoting.
Can an internal team configure ClickHouse for PCI DSS alone?
Yes, if the team has ClickHouse operations skills and someone who understands PCI DSS requirements in depth. The configuration tasks are concrete: restricting the default user, defining users and roles, row policies and settings profiles, enabling TLS, and setting up audit trails. The ClickHouse access control documentation recommends the SQL-driven workflow and restricting the default user, which starts with all permissions. The harder part is proving the result, which needs scope documentation, access reviews and an assessor-ready evidence set. An external partner can add capacity and a second review, while the internal team keeps ownership of decisions.
Which PCI DSS version applies to a ClickHouse assessment today?
PCI DSS v4.0.1 is the only active version. The PCI SSC published it on 11 June 2024 as a limited revision of v4.0 with no added or deleted requirements, and v4.0 was retired on 31 December 2024. The 51 future-dated requirements introduced in v4.0 became effective on 31 March 2025. The PCI SSC ran a request for comments from 3 June to 20 July 2026 on the next iteration, but it had announced no release date as of October 2026. Confirm with your acquirer or payment brand whether they accept any other version for your validation cycle.
Why does ClickHouse still need a ROC or SAQ if the controls are in place?
Because only a formal assessment produces the documents that payment brands accept. The PCI SSC does not enforce compliance itself. Payment brands decide who must validate, and validation is documented either as a Report on Compliance completed by a Qualified Security Assessor or as a Self-Assessment Questionnaire, each with an Attestation of Compliance. The PCI SSC states that certificates are not recognized as validation. DeployOpen can prepare systems, configuration and evidence for that review, but the ROC or SAQ and the AOC must come from the assessor or your own validation process.
When a managed or separate ClickHouse changes the scope answer
The first question is not whether ClickHouse is involved, but whether the analytics cluster ever holds, receives or can reach cardholder data. Work through four checks in order: whether any cardholder data or sensitive authentication data lands in its tables, staging buckets or ingestion pipelines (for example, a Kafka topic or PostgreSQL replica feeding MergeTree tables); whether it sits on a network segment that connects to the cardholder data environment (CDE) or shares credentials, DNS, jump hosts or identity services with it; who administers the servers, Keeper nodes and object storage; and whether backups made with BACKUP to local disk, S3-compatible storage or Azure Blob Storage contain card data. A single yes on any of these means the cluster, its backup target and the people who can reach them need to be assessed as part of the CDE or as systems that could affect it.
A separate cluster that receives only tokens, truncated values or aggregated figures can often sit outside the CDE, but that conclusion must be supported by documented segmentation and by evidence that the data really contains no cardholder data. Tokenization is only a scope reducer if the token vault stays in the CDE and the analytics cluster cannot reverse tokens. Treat any managed ClickHouse service the same way: confirm in its own PCI DSS documentation, such as its responsibility matrix and Attestation of Compliance, which requirements the provider covers, which fall to you and whether the service's backups, support access and regions are included. Ask the provider for its current validation and the scope of that validation rather than relying on a general statement about security. The scope decision belongs to your organization and its Qualified Security Assessor or internal assessor, so bring them the data flow diagram and the access list before the cluster is built.
How DeployOpen scopes and evidences ClickHouse for PCI DSS
DeployOpen plans, builds and documents self-managed ClickHouse inside your own infrastructure, starting with a written decision on whether each cluster sits in or out of PCI DSS scope. We agree the boundary, controls and evidence list before build work starts, so the assessor receives a clear record of what was configured and why.
How we scope
- Map every system that stores, processes or transmits cardholder data, including ClickHouse tables, backups and log sinks.
- Record in writing which tables hold tokens, which hold no cardholder data, and which connect to the cardholder data environment.
- Agree with your QSA or internal assessor which requirements apply and whether any customized approach is proposed.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- Design the token-only data model, with masking rules for logs and query results applied before data reaches ClickHouse.
- Configure TLS, external authentication, roles, row policies and a restricted default user against a documented access matrix.
- Set up encryption, retention settings and audit logging from system tables, then test each control against its written objective.
- Run a restore test of ClickHouse backups on a spare cluster and record the results as part of the build.
How we hand over
- Deliver the scope statement, data flow diagrams, configuration baselines and the control-to-evidence mapping for your assessor.
- Provide runbooks for access reviews, upgrade change records, backup and restore tests, and log export to your SIEM.
- Document known gaps, compensating controls and open decisions so your team can close them without DeployOpen present.
- Hand over administration credentials and configuration in your own repositories, with knowledge transfer sessions agreed in the scope.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped to your ClickHouse version and change volume.
- Re-check scope when the cardholder data flow, tables or connected systems change, and update the evidence set accordingly.
- Track supported ClickHouse versions and plan upgrades on the stable or LTS line before support windows close.
- DeployOpen prepares systems and evidence only. Your QSA or the payment brands decide validation and the Attestation of Compliance.
