Running ClickHouse for HIPAA-regulated data: what the platform covers and what it does not
If your organization is a covered entity or a business associate and you put electronic protected health information into ClickHouse, the database is one component inside a Security Rule program, not the program itself. The HIPAA Security Rule in 45 CFR Part 164 Subpart C applies to ePHI wherever it is created, received, maintained or transmitted, so the ClickHouse cluster falls under the technical safeguards in 45 CFR 164.312 (unique user identification, access control, audit controls, integrity, authentication and transmission security) and the access and contingency standards in 164.308. The platform gives you concrete levers for those: local users and roles, row policies, external authenticators such as LDAP, Kerberos and X.509 certificates, TLS for client and replica traffic, and BACKUP and RESTORE for recovery. Physical safeguards under 164.310 mostly sit with your data center or cloud provider, and the policies, workforce training, risk analysis, sanctions and business associate contracts under 164.308, 164.314 and 164.316 remain organizational work that no database setting completes.
Start by deciding which standards the platform touches and which you must document yourself. Confirm in writing with your privacy and security officers which ClickHouse features will hold ePHI, then map each implementation specification to a setting, a runbook or a policy. Several specifications are addressable, which means you must assess whether they are reasonable and appropriate, document the decision, and implement an equivalent measure if you do not adopt them (45 CFR 164.306(d)). For example, the encryption specifications under 164.312(a)(2)(iv) and 164.312(e)(2)(ii) are addressable, so an encryption-at-rest decision needs a recorded rationale in your risk analysis. The Security Rule also requires that business associates, including hosting providers and any firm that operates the cluster for you, sign contracts that flow these obligations down, as set out in 45 CFR 164.314(a).
HIPAA has no certification. HHS states that no Security Rule standard requires certifying compliance and that private certifications do not stop HHS from later finding a violation, so any claim that a ClickHouse deployment is "HIPAA certified" should be rejected. DeployOpen configures the system, documents controls and collects evidence that your assessors and OCR can review, but it does not issue attestations or certifications, and it does not give legal advice on your obligations. Ask your counsel to confirm the penalty exposure and the status of the proposed Security Rule revision before you settle the scope. For the detailed standard-by-standard reading, NIST SP 800-66 Rev. 2 is the natural next resource.
Mapping HIPAA Security Rule requirements to ClickHouse capabilities
This table maps the HIPAA technical safeguards in 45 CFR 164.312 to the ClickHouse features that help meet them, with the configuration each one needs. Required specifications must be implemented, while addressable ones require a documented assessment of whether they are reasonable and appropriate for your environment. Treat ClickHouse features as inputs to your risk analysis, not as proof of compliance.
| Requirement | ClickHouse capability | Configuration needed |
|---|---|---|
| Unique user identification (required, 164.312(a)(2)(i)) | Named users with roles, assigned through SQL-driven access control | Create one account per person or service, disable or restrict the default user, and remove shared logins from applications |
| Emergency access procedure (required, 164.312(a)(2)(ii)) | Separately managed break-glass account with tightly scoped roles | Document who may use it, store its credentials under dual control, and log every use for review |
| Automatic logoff (addressable, 164.312(a)(2)(iii)) | Session and query limits through settings profiles and quotas; session expiry depends on the authenticator and client | Confirm idle timeout behavior for your clients and BI tools, then document either the setting or the equivalent alternative |
| Encryption and decryption (addressable, 164.312(a)(2)(iv)) | Encryption at rest depends on your storage layer or disk encryption; ClickHouse does not provide a single built-in switch for all data | Choose volume or filesystem encryption for data and backup locations, and record the key management decision |
| Audit controls (required, 164.312(b)) | System tables such as query and session logs record activity for the server | Forward logs to a central store with a retention period set by your policy, and test that entries are complete and tamper-resistant |
| Integrity (required, 164.312(c)(1)) | ReplicatedMergeTree replicas coordinated by ClickHouse Keeper, with checksums and automatic resync of recovered replicas | Run at least three Keeper nodes on dedicated hosts in production and monitor replication health for drift |
| Person or entity authentication (required, 164.312(d)) | LDAP, Kerberos, X.509 certificates, HTTP authenticator or JWT as external authenticators | Enable the authenticator that matches your identity provider and disable password-only access where possible |
| Transmission security (addressable, 164.312(e)(1)) | TLS on native and HTTP interfaces using X.509 certificates | Enforce TLS for all client, replica and Keeper traffic, and document any internal network exception as an addressable decision |
| Data backup and contingency (required at the plan level, 164.308(a)(7)) | BACKUP and RESTORE for full and incremental backups to local disk, S3-compatible or Azure Blob storage | Keep backups off the primary cluster, encrypt them, and run restore tests on a spare cluster on a schedule you document |
Evidence an auditor or OCR reviewer will ask for
An OCR reviewer or auditor will ask you to show who could access ePHI, how they proved who they were, what happened in the system, and whether you could recover it. Each item below answers one of those questions, and together they form the evidence set you should keep current before anyone asks. Retention periods and review cadence should follow your own risk analysis and policy, so confirm them with your compliance lead.
Role and grant exports
Export users, roles, grants, row policies and settings profiles on a schedule, and keep each export with its date and the approver who reviewed it. Confirm that the default user has been restricted, because it starts with all permissions and an export that still shows it active is a finding. Compare each export with the access your care and operations teams were approved for, and record every removal. Store exports in write-once storage so the history cannot be quietly rewritten.
Authentication configuration records
Keep the version-controlled configuration for every external authenticator in use, such as LDAP, Kerberos, SSL X.509 certificates, HTTP or JWT, along with its owner and change history. Reviewers will ask how a user proves identity and whether shared or generic accounts exist. Record which mechanism applies to each access path, including administrative and service accounts. Each configuration change should link to a ticket that states the reason and the test performed.
Login and query records from system tables
Retain the session and query records that ClickHouse writes to its system tables, and export them to your log platform before any rotation removes them. These records show who logged in, from where and what they queried, which is the basis for reviewing access to ePHI. Schedule a documented review, sample accesses against approved care relationships, and keep evidence of the review. Confirm that query text containing patient identifiers is masked before it reaches any log store.
Backup job logs
Keep the logs from every scheduled BACKUP job, including the target, the backup type (full or incremental), the start and end times, and the result. Gaps in the schedule and failed jobs with no follow-up are the findings reviewers look for first. Record where each backup is stored and who can read or delete it, because a backup holding ePHI is itself in scope. Link failures to incident or change records that show how they were resolved.
Restore test records on spare clusters
ClickHouse documentation warns that a backup never test-restored will probably not restore properly when needed, so keep dated records of restores performed on spare clusters. Each record should name the backup restored, the target, the row counts or checksums compared, the elapsed time, and the person who signed off. Replication does not protect against human error or corruption, so a record showing you restored a deleted table is stronger evidence than a backup file alone. Retain these records for as long as your policy requires the backups they cover.
Version and patch records
Keep a record of the ClickHouse version running in each environment, the date it was deployed, and the security advisories reviewed against it. Compare each version with the ClickHouse security policy, which lists the versions that currently receive security updates. A version outside that list needs a documented risk decision or an upgrade plan with a date. Retain the change tickets and the pre-production test results for every upgrade.
Risk analysis and addressable decisions
The Security Rule lets you treat an addressable implementation specification as a documented decision, but you must assess whether it is reasonable and appropriate and record why, along with any equivalent alternative. Keep the current risk analysis, the rationale for each addressable item such as encryption or automatic logoff, and the date each decision was last reviewed. Reviewers will check that these decisions match what the cluster actually does. NIST SP 800-66 Rev. 2 can help structure the analysis, but it is informational rather than binding.
Keeping PHI out of logs, query text and backups
PHI in a self-managed ClickHouse cluster rarely sits only in tables. It also appears in SQL text that analysts paste into clients, in the query_log system table, in server logs, and in every backup destination that BACKUP writes to. Each of those copies falls under the same Security Rule duty to protect electronic PHI, so the design question is how to keep identifiers out of them in the first place. The most effective control is schema design: keep direct identifiers such as names, record numbers and dates of birth in a separate, tightly restricted table, and key analytical tables on pseudonymous or tokenized identifiers so that routine queries rarely need to contain raw values.
Where PHI cannot be avoided in query text, the control direction is masking and restricted access. ClickHouse can mask sensitive values in its logs through query masking rules, which replace matched patterns before text is written. Confirm the exact masking settings, their syntax and whether they cover query_log and server logs in the version you run, and test them with a deliberately sensitive query before relying on them. Then decide who may read system.query_log and server log files, since these are operational data that many engineers can reach by default. Restrict them to a named group and record that access in your audit trail.
Backups copy everything, including any PHI that slipped into tables or logs, so the destination needs the same protection as the cluster. Choose an S3-compatible or Azure Blob Storage target that you control, enable server-side encryption and restrict bucket or container access to the backup service identity. Confirm with your storage vendor how keys are managed and whether object-level logging is available. Finally, treat backup retention as a PHI decision: a retention period that outlives your documented need keeps sensitive data in more places. Record the decision, and confirm during each restore test that the restored copy respects the same access and masking rules.
Configuration sequence for a HIPAA-aligned ClickHouse cluster
This sequence turns HIPAA Security Rule safeguards into concrete ClickHouse settings, in an order that keeps scope, access and recovery decisions ahead of data loading. It ends with a documented record of each addressable decision that the covered entity or business associate can show to an assessor.
Scope ePHI data flows and business associate duties
Before any cluster exists, the compliance owner and the data team map every table, ingestion source, query consumer, backup destination and support path that will hold or touch electronic protected health information. Each third party that hosts, processes or can reach that data is identified, and the business associate contract is checked against the requirements in 45 CFR 164.314(a)(2)(i), including flow-down to subcontractors and incident reporting. The step is complete when a data flow inventory is signed off and every party in it has a contract position recorded.
Deploy on a supported ClickHouse version
The platform team selects a version listed as supported in the ClickHouse security policy, preferring a stable or LTS line that receives security updates, and builds a pre-production environment loaded with representative data and queries. The release notes and changelog are read for backward-incompatible changes before the production build is chosen. The step closes when the version, its source and the install method are recorded in the change log, and the pre-production cluster passes a basic query and ingestion test.
Configure authentication, roles and row policies
The security engineer integrates the cluster with the identity source the organization already governs, such as LDAP, Kerberos, X.509 certificates or JWT through ClickHouse external authenticators. Users, roles, settings profiles and row policies are created with SQL so that each role reflects the minimum access needed by a care team, analyst or service account. The step is complete when test accounts can reach only the rows and columns their role permits, and that result is saved as evidence.
Lock down the default user
The default user starts with all permissions, so the administrator disables or restricts it and confirms that no application, script or monitoring agent still depends on it. Named administrative accounts take over operational work, and their use is limited to the people who need it. The step is done when a login attempt with the default account is refused in the pre-production environment and the production configuration matches the tested change.
Build ReplicatedMergeTree with dedicated Keeper nodes
The infrastructure team deploys ClickHouse Keeper on at least three dedicated hosts, each with about 4 GB of RAM as the replication guide recommends, and creates ReplicatedMergeTree tables across replicas. Network paths between servers and Keeper are restricted and encrypted, and a test replica is stopped and restarted to confirm it resynchronizes from a healthy peer. The step closes when the quorum survives a single node failure in testing and the replication status is recorded. Replication is treated as availability protection, not as backup.
Configure BACKUP to encrypted destinations
The operations team configures BACKUP jobs for the databases and tables that hold ePHI, writing to local disk, S3-compatible storage or Azure Blob Storage with encryption enforced at the destination and access limited to the backup service identity. Full and incremental schedules are set, and retention is defined in writing. The step is complete when a backup runs to the encrypted target and the job log and destination settings are stored with the change record.
Schedule and record restore tests
The team restores a recent backup onto a spare cluster on a fixed schedule, verifies row counts and sample records against the source, and confirms that access controls and row policies behave as they did in production. The backup documentation warns that an untested backup will probably not restore when needed, so each test is logged with its date, operator, result and any defect fixed. The step is done when the first restore test passes and the recurring test calendar is approved by the compliance owner.
Document addressable decisions and evidence
For each addressable implementation specification in the Security Rule, the compliance owner records whether the measure is reasonable and appropriate, and if it is not, documents why and the equivalent alternative chosen, as 45 CFR 164.306(d) requires. Policies, configuration baselines, access reviews and restore logs are filed in one controlled location. The step closes when every addressable decision has a dated record and the file set is reviewed by someone outside the build team. The file is evidence for an assessor, not a certification, because HHS does not certify compliance.
What ClickHouse does not cover for HIPAA
ClickHouse can support technical safeguards, but the Security Rule also reaches the people, facilities, contracts and processes around the cluster. These cards cover the obligations that stay with your organization and its partners, and they explain why no platform can certify HIPAA compliance on its own.
Risk analysis and contingency planning
The Security Rule requires covered entities and business associates to assess risks to ePHI and to maintain contingency plans for emergencies and data loss. ClickHouse can hold replicated data and backups, but it cannot decide which threats apply to your environment or how long recovery may take. Check that your risk analysis names the ClickHouse cluster, its Keeper nodes, backup storage and admin paths, and that your contingency plan records restore tests you have actually run.
Workforce training and sanctions
Administrative safeguards require workforce security, security awareness training and a sanctions policy for workforce members who violate security policy. Access to a ClickHouse cluster often sits with a small group of engineers, so training must cover query logging, handling of exported PHI and the consequences of bypassing access controls. Ask who is trained, how often training is repeated, and how sanctions are documented and applied.
Physical safeguards at the hosting facility
The physical standards cover facility access controls, workstation use and device and media controls. If ClickHouse runs in your data center, these controls are yours to design and evidence. If it runs in a cloud account or colocation facility, request the provider's physical security documentation and confirm how disks, backup media and decommissioned hardware are sanitized. Your procedures must cover servers, laptops that reach the admin network and removable media.
Business associate agreements and subcontractors
A business associate contract must require the business associate to comply with the Security Rule and to flow the same terms down to subcontractors that handle ePHI. Your hosting provider, backup storage provider and any consultant with access to the cluster may fall into this category. Confirm in writing which parties can reach ePHI, whether each has signed an agreement, and where backup copies are stored.
Security incident reporting
Business associates must report security incidents, including breaches of unsecured PHI, to the covered entity, and the covered entity must run its own breach assessment. Your incident process should define what the ClickHouse on-call team reports, to whom and within what timeframe set by your agreements. Log sources such as query_log can show suspicious access, but only if someone reviews them and has agreed escalation paths.
Pending Security Rule revision
HHS proposed a major Security Rule revision on 6 January 2025 (90 FR 898), which would change technical and administrative requirements. As of October 2026 no final rule has been published, and the Unified Agenda projects final action for July 2027. Track the rulemaking, map proposed changes against your ClickHouse controls, and budget review time when the final text arrives. Current obligations still apply under the existing rule.
Questions buyers ask before running ClickHouse for PHI
Does HIPAA certify ClickHouse?
No. HIPAA has no certification. HHS states that no Security Rule standard requires an entity to certify compliance, that HHS does not endorse or recognize private certifications, and that such certifications do not prevent HHS from later finding a violation. The Security Rule applies to the covered entity or business associate that handles electronic PHI, so the question is whether your deployment, policies and records meet the standards. ClickHouse is open-source software under the Apache License 2.0, and the configuration you build on top of it is what must be assessed. Any vendor claiming HIPAA certification for a product should be questioned closely.
What effort does a HIPAA-oriented ClickHouse configuration take, and what drives it?
Effort depends mainly on how many systems touch PHI, how many users and service accounts need access, and how much of the platform is already standardized. The main work areas are:
- Mapping each Security Rule standard in 45 CFR 164.308, 164.310 and 164.312 to a concrete ClickHouse control or an operating procedure.
- Configuring TLS, users, roles and row policies, and restricting the default user.
- Setting up replication, backups and tested restores, and logging access for audit controls.
- Documenting every addressable specification decision, as 45 CFR 164.306(d) requires.
The Security Rule has 36 implementation specifications, 14 required and 22 addressable, so the documentation load is material. Ask any partner for a quote built from a written list of these items and your environment.
Can our internal team run a HIPAA configuration without a partner?
Often yes, if the team already runs production databases and has someone who can own the Security Rule mapping. The skills needed include Linux and network administration, ClickHouse operations, identity integration, key management and backup engineering, plus compliance writing. Teams that lack one of these areas usually benefit from an outside review or a hands-on build for that part. The NIST SP 800-66 Rev. 2 resource guide, published in February 2024, gives key activities and sample questions for each standard and is a useful checklist for an internal team. HHS lists it as informational, not legally binding.
What do we need to provide before the work starts?
Plan to supply the following before scoping can be finished:
- A data flow inventory showing where PHI enters, is stored, is queried and leaves ClickHouse, including any ETL tools and BI users.
- Your identity provider details, such as LDAP, Kerberos or an OIDC or SAML source, and the role model your teams use.
- Storage for backups and data, including whether object storage or local disks are approved and where they sit.
- Change windows for configuration changes, upgrades and restore tests.
- Named owners for risk decisions, access reviews and incident response.
The more of this that exists in writing at the start, the more precise the fixed-scope proposal will be.
How long does a HIPAA-oriented ClickHouse engagement take?
Duration depends on scope: the number of clusters, the number of data sources, the state of your identity and backup systems, and how many addressable decisions need documented reasoning. A single-cluster build with existing identity and backup services is much shorter than a multi-site, replicated deployment that must integrate with several systems. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so ask for a timeline tied to that written scope rather than a generic estimate. Validate the schedule against your change calendar, because restore tests and upgrade windows often set the pace.
What ongoing upkeep does a HIPAA-compliant ClickHouse cluster need?
Upkeep is recurring and should be budgeted as a standing cost. It includes:
- Running only supported versions. The ClickHouse security policy lists 26.9, 26.8, 26.7 and 26.3 as supported with security updates, and all other versions as unsupported.
- Scheduled restore tests. The ClickHouse backup documentation warns that a backup never test-restored will probably not restore properly.
- Periodic access reviews of users, roles and row policies, and review of audit logs.
- Keeping the Security Rule documentation current with the configuration.
Confirm with the vendor and your environment which upgrade cadence and support window apply at the time you build, because the support list changes over time.
Does the HHS audit program or enforcement change the work we must do?
The Security Rule is enforced by the HHS Office for Civil Rights through complaints, compliance reviews and audits, and the 2024 to 2025 HIPAA audits reviewed 50 covered entities and business associates on provisions most relevant to hacking and ransomware. Civil money penalties for violations assessed on or after January 28, 2026 range from $145 to $2,190,294 per violation, with a calendar-year cap of $2,190,294 (45 CFR 102.3). A proposed major revision was published on January 6, 2025, but as of October 2026 no final rule exists, so the current standards still govern. Plan for the existing rule and watch the rulemaking entry for changes.
Will DeployOpen certify our ClickHouse deployment as HIPAA compliant?
No. DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms in infrastructure you control, and prepares systems, controls and evidence for compliance assessments. DeployOpen does not issue audit reports, attestations or certifications. Those come from independent auditors or certification bodies, and HIPAA itself has no certification to issue. Your compliance responsibility stays with your covered entity or business associate role, and your counsel and compliance team should define what evidence is required.
Why the enforcement context matters for engineering choices
The HHS Office for Civil Rights enforces the HIPAA Security Rule through complaint investigations, compliance reviews and audits, and HIPAA has no certification that settles compliance in advance. That means an engineering team running ClickHouse for PHI has to be able to show, after the fact, what its controls were and that they worked. The question an investigator asks is what evidence exists, not what a vendor certificate says. Design decisions such as which accounts can read PHI tables, whether query and login history is kept, and whether backups have been restored in a test all produce records or fail to, so they should be chosen with that record in mind.
OCR's 2024 to 2025 HIPAA audits review 50 covered entities' and business associates' compliance with the Security Rule provisions most relevant to hacking and ransomware, according to OCR's audit program page. For a ClickHouse team, the areas those provisions touch in practice include unique user identification, automatic logoff, access to ePHI, audit controls and contingency planning. Confirm with your compliance lead which provisions your own risk analysis rates highest, then ask which of them your cluster can demonstrate with logs, configuration exports and restore records rather than with descriptions in a runbook.
The civil money penalty table in 45 CFR 102.3, as adjusted by 91 FR 3666, sets the amounts for penalties assessed on or after January 28, 2026. Per violation, the range runs from $145 where the entity did not know of the violation to $2,190,294 for uncorrected willful neglect, with a calendar-year cap of $2,190,294. The gap between those tiers is why documented, timely correction matters: a known misconfiguration left open is judged differently from one found and fixed under a recorded plan. Check the current table in the eCFR before any board or budget discussion, since the figures are adjusted over time.
How DeployOpen scopes and delivers HIPAA-aligned ClickHouse configuration
DeployOpen plans, builds and documents self-managed ClickHouse inside your own infrastructure, with the Security Rule safeguards mapped to specific settings, tests and records before go-live. We do not issue HIPAA certifications or attestations, so the output is a configuration and evidence set that your compliance function and any assessor can review.
How we scope
- We map your ePHI data flows, users and systems to the Security Rule standards that apply to your organization
- The written scope names the ClickHouse version line, cluster topology, Keeper nodes and backup targets involved
- We agree which addressable specifications you will implement, and which equivalent measures you will document
- Scope lists the logging, masking and retention rules that keep PHI out of query logs and application logs
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
How we build
- We configure users, roles, row policies and settings profiles, and restrict the default user before any data loads
- We set up TLS for client and inter-node traffic and integrate external authenticators your identity team already runs
- We deploy ReplicatedMergeTree tables with ClickHouse Keeper on dedicated hosts, following the vendor replication guidance
- We configure BACKUP and RESTORE jobs to storage you control, and test restores on a spare cluster
- We validate each control with a documented test, so every safeguard has a repeatable check
How we hand over
- You receive a safeguard-to-configuration map that ties each implemented control to its setting and owner
- Runbooks cover user provisioning, access reviews, backup restore tests and replica recovery procedures
- We document the upgrade path, including which supported version line you run and how you track security updates
- Your team gets a record of restore test results and access configuration to support your own risk analysis
- Knowledge transfer sessions are scoped in the written agreement so your operators can run the platform alone
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build
- Retainers can cover periodic restore tests, configuration reviews and reviews of access and log retention settings
- We help prepare evidence for your compliance assessments, while independent auditors or certification bodies make the determinations
- Changes to the ClickHouse version line are planned against the changelog and tested in a pre-production environment first
- Confirm with your privacy and legal advisers which Security Rule obligations and business associate terms apply to your engagement
