Can Ceph hold HIPAA ePHI, and which Security Rule specifications it helps with
Ceph can hold ePHI, and it helps with the addressable encryption specifications in 45 CFR 164.312(a)(2)(iv) and 164.312(e)(2)(ii) and with the contingency plan specifications in 164.308(a)(7)(ii)(A) and (B), which cover retrievable exact copies and restoring lost data. Ceph does not decide whether those specifications apply to your environment. For each addressable specification, the covered entity or business associate must assess whether it is reasonable and appropriate, and if it is not, document why and implement an equivalent alternative where reasonable. That assessment belongs in your risk analysis, and the risk analysis is owned by your organization, not by the storage platform or by DeployOpen.
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 a storage team should not ask for a Ceph badge or a HIPAA certificate. DeployOpen plans, configures and documents Ceph inside your infrastructure and prepares the evidence that your assessors will ask for, such as encryption settings, replication layout and restore test records. DeployOpen does not issue audit reports, attestations or certifications, and independent auditors remain responsible for any assurance opinion you obtain.
The practical first step is to confirm which specifications your risk analysis covers and which Ceph component each one maps to. Encryption at rest, msgr2 secure mode for traffic between daemons and clients, and the key handling for each layer are separate questions, and each needs an owner and a documented decision. Confirm with your compliance lead whether the risk analysis is current, and confirm with the Ceph release you plan to run that the features you rely on are supported on that version, using the Ceph active releases page as the starting point.
Which HIPAA storage requirements map to Ceph features and configuration
This table compares each HIPAA Security Rule requirement in scope for Ceph-hosted ePHI with the Ceph capability that supports it, the configuration it needs and the part that stays with the covered entity. Read it as a starting checklist for the risk analysis, not as proof of compliance, since the covered entity owns the decisions and the evidence. The main takeaway is that Ceph supplies mechanisms, while the documented decisions, key custody and business associate terms remain the organization's responsibility.
| Requirement | Ceph capability | Configuration needed | What stays with the covered entity |
|---|---|---|---|
| 164.312(a)(2)(iv) and (e)(2)(ii): encryption at rest and in transit (addressable) | Encryption at rest for OSD data and msgr2 secure mode for traffic between daemons and clients | Enable at-rest encryption on OSDs or the chosen object layer, set msgr2 secure mode, and confirm the at-rest mechanism and its FIPS status for the chosen release | Deciding whether encryption is reasonable and appropriate, key custody, rotation policy and proof that keys are stored separately from the data |
| 164.306(d): documented decision for an addressable specification | No Ceph feature performs this step. Ceph settings can be captured as evidence for the decision | Record each encryption setting, the release and version in use, and any equivalent alternative chosen | The risk analysis, the written rationale if encryption is not implemented, and the review schedule for that decision |
| 164.308(a)(7)(ii)(A): retrievable exact copies of ePHI | Replication or erasure coding across failure domains, with RGW multisite or RBD mirroring for copies at other sites | Set CRUSH failure domains (host, rack or site), pool redundancy, and a replication target that is separate from the primary cluster | Defining which systems hold ePHI, the copy schedule, retention periods and where copies may be stored |
| 164.308(a)(7)(ii)(B): procedures to restore any loss of data | Ceph does not provide a restore procedure. Snapshots, object versioning and backup tooling can support restores | Document restore runbooks for OSD, host and site loss, and test restores into an isolated environment | Restore testing, recovery time and recovery point targets, and records showing each test and its results |
| 164.314(a)(2)(i): business associate contract terms | No Ceph feature applies. Relevant only where a hosting provider or managed service operates Ceph on the covered entity's behalf | Confirm that the contract requires Security Rule compliance, flows terms to subcontractors and requires incident reporting | Negotiating and signing the contract, and checking that operator access to keys and clusters is covered by it |
Where encryption at rest can sit in the Ceph data path
Encryption at the OSD or device layer protects data written to disks, so a drive removed from a chassis, returned under warranty or sent for disposal cannot be read without its keys. It does not change what an authenticated client sees through the cluster, so any user or service with valid Ceph access still reads plaintext. Confirm with your release whether OSD encryption is enabled at deployment through cephadm and where the key material is stored.
- What it protects: data at rest on OSD devices, including any WAL and DB devices encrypted alongside the OSDs, and drives leaving the data center.
- Key separation: keys are usually managed within the cluster's own tooling, so the administrators who run the cluster may be able to reach them. Plan where keys are escrowed and who can retrieve them.
- What an auditor asks for: the encryption configuration for each OSD, the key custody model, the re-keying or rotation procedure, and records of drive return, reuse or destruction.
- What to confirm for your release: which encryption options are supported, whether keys can be held in an external key management service, and how a replacement drive is enrolled without exposing key material.
Document this control as one measure inside the risk analysis, and record the reason for any gap that the other placements must cover.
Server-side encryption at the Ceph Object Gateway (RGW) encrypts object payloads as the gateway writes them, so the protection applies to S3 clients and not only to the disks. When the key is fetched from a key management service outside the cluster, the cluster stores ciphertext and the key sits with a separate system under its own access policy. Confirm the supported encryption modes and key service integrations in the Ceph Object Gateway documentation for your release.
- What it protects: object payloads written through the S3 API, including copies that replication or data movement places elsewhere in the cluster.
- Key separation: the key service, its access policies and its administrators are kept apart from the Ceph administrators, which is the separation HHS guidance describes as keeping the decryption key apart from the data.
- What an auditor asks for: the encryption setting for each bucket or the default policy, the key service access policy, rotation and revocation records, and logs of key retrieval by the gateway.
- What to confirm: whether your release supports the key service you require, which requests are encrypted by default, and whether indexes, metadata and gateway logs are covered.
Run a restore test with the key service unavailable and record the result, because the outcome belongs in the contingency plan.
Application-level encryption encrypts records or files before the application writes them, so Ceph, its gateways and its administrators handle only ciphertext. This gives the clearest separation of duties when the application owns its keys. The trade-off is more engineering work in search, reporting, exports, backups and migrations, all of which must handle encrypted values correctly. Of the three placements, it is the only one where the storage platform never receives plaintext.
- What it protects: the specific fields or files the application encrypts, wherever copies of them later appear, including snapshots, replicas and backup targets.
- Key separation: keys are issued and held by the application's key service. Envelope encryption, where data keys are wrapped by a master key that the storage team cannot read, is a common pattern to evaluate.
- What an auditor asks for: an inventory of encrypted fields or files, the key hierarchy and custody model, rotation and re-encryption procedures, and restore tests that show decryption works after recovery.
- What to confirm: which indexes, logs, search services and exports receive plaintext, and whether backup jobs capture the keys needed to recover the data as well as the data itself.
Record which encrypted fields support which entries in the risk analysis, because any ePHI left unencrypted in the cluster still depends on the other two placements.
Configuration sequence for an ePHI-holding Ceph cluster
This sequence turns the risk analysis into a working Ceph configuration, so each encryption, replication and backup choice is set deliberately and can be shown to an assessor. It produces a cluster where every ePHI data set has a mapped pool or bucket, a recorded decision on each addressable specification, and restore evidence.
Inventory ePHI data sets and map them to storage
The covered entity or business associate lists every system that creates, receives, maintains or transmits ePHI, then the storage team maps each data set to the Ceph pool, RGW bucket or RBD image that will hold it. Include application logs, exports, analytics copies and backups, since each one is ePHI storage in scope. The step is done when every data set has a named target and an owner, and no ePHI location is left unassigned.
Record risk analysis input and addressable decisions
Using the inventory, the security or compliance lead records the risk analysis inputs for each storage location and states the decision for each addressable specification, including encryption at rest, encryption in transit, and automatic logoff where it applies. If an addressable measure is not implemented, the record explains why and names the equivalent alternative. The step is done when each decision has a dated owner sign-off and the risk analysis references the cluster design.
Deploy on a supported Ceph release
The platform team deploys the cluster with cephadm on a release that is still receiving fixes. The releases page lists Squid (19.2.x) with an estimated end of life of October 31, 2026, and Tentacle (20.2.x) with an estimated end of life of June 1, 2027, so confirm the current status before choosing a release and plan the upgrade path early. The step is done when cluster health is OK, all hosts are managed by cephadm, and the release version is recorded in the system documentation.
Enable and verify msgr2 secure mode
The team sets the messenger v2 protocol to secure mode so that post-authentication traffic between daemons and clients is encrypted with AES-GCM and checked for integrity. Verify the setting on every daemon and client path, and confirm that legacy connections are refused where your design requires it. The step is done when a connection check shows secure mode in use across monitors, OSDs and gateway clients, and the configuration is captured in version control.
Configure encryption at rest per decision
Apply the encryption method chosen in the risk record, such as encrypted OSDs or RGW server-side encryption, and confirm where the keys are held and who can retrieve them. HHS guidance treats data as secured only when the decryption key is not breached and is stored separately from the data, so document the key custody model and the separation. The step is done when a test write to each ePHI location is confirmed encrypted at rest and the key custody record is signed.
Restrict administrator access and enable dashboard SSO
Limit cephadm host access and administrator roles to named people, separate day-to-day operator accounts from break-glass access, and disable default or shared accounts. Where the Management Gateway and OAuth2 Proxy run under cephadm, enable Dashboard single sign-on through OAuth2; otherwise confirm the SAML 2.0 option against your identity provider. The step is done when an access review lists every privileged account with its role and the sign-in path is tested.
Set up a separate backup target
Create a backup target that is independent of the production cluster's failure domains, with its own administrator credentials and access path. Replication inside one cluster protects against drive or host loss but does not provide a retrievable exact copy if the production environment is compromised, so confirm the target design with your recovery requirements. The step is done when a backup job writes an encrypted copy of each ePHI location to the target and the job log shows success.
Run and document restore tests
Restore a sample of each ePHI data set from the backup target into an isolated environment, then verify integrity and completeness against the source record. Record the restore date, the data set, the person who ran the test, the time taken and any defects, and schedule the next test according to your contingency plan. The step is done when the restore record shows a successful test for every data set and each defect has a tracked fix.
Evidence auditors and OCR will ask Ceph to produce
A HIPAA assessment asks whether your decisions were reasoned, your settings were deliberate, and your recovery works. The records below show each of those things for a Ceph cluster holding ePHI, and each one only stays useful if it is updated through change control.
Risk analysis record and addressable decisions
This is the written risk analysis that names where ePHI sits in Ceph, including RBD images, CephFS shares and RGW buckets, and rates the risk to each. For encryption, it must record whether encryption at rest and in transit is reasonable and appropriate, and if not, why and which equivalent measure applies. Review it when the cluster, its pools or its sites change, and keep the dated sign-off with it.
Versioned configuration baselines
A baseline records the cluster configuration you approved, including pool settings, encryption options, network layout and daemon placement. Export it from cephadm and store the export in version control, so each change produces a diff that someone reviewed and approved. Ask your team to confirm which configuration keys hold encryption and authentication state, because those are the values an assessor will check first.
Msgr2 settings and verification output
Record the messenger v2 settings that enforce secure mode for in-transit traffic, along with the command output that shows the effective values on each daemon. Capture this output after every upgrade or host change, because a restarted daemon can fall back to a different configuration. Note any client or gateway that cannot use secure mode and the compensating control applied to it.
Backup and restore test records
Under the contingency plan standard, you must keep retrievable exact copies of ePHI and procedures to restore any loss. Keep a dated log of each restore test: the scope restored, the source copy, the time taken, the integrity check result and the person who signed off. Include failed tests and the fixes that followed, since an assessor reads a clean record with no failures as a sign the test was not real.
Administrator and access review records
List every account that can reach the cluster, including dashboard users, RGW users, cephadm host access and key holders, with the role each one holds and why. Review the list on a set schedule and record who approved each removal or change. For ePHI access, the review should show that each person's rights match their job, which is the point most often questioned in enforcement cases.
Patch and release records
Record the Ceph release each cluster runs, the date you moved to it, and the source of the release information. Tie each record to the Ceph releases page, which lists the actively maintained branches and their estimated end-of-life dates. A cluster on a branch past its end of life receives no further backported fixes, so the record should show when you planned the next upgrade.
How HHS enforcement and the pending Security Rule revision affect the evidence you keep
The evidence you keep for Ceph encryption and backup has to hold up under HHS Office for Civil Rights (OCR) review, and OCR reaches the Security Rule through complaint investigations, compliance reviews and audits. OCR's 2024 to 2025 HIPAA audits review 50 covered entities and business associates on the provisions most relevant to hacking and ransomware, so the records that show how encryption at rest, msgr2 secure mode and replicated or immutable copies were configured and tested are the records most likely to be requested. Ask your team to keep the cephadm service specifications, the encryption settings for each OSD and gateway, and dated restore test results together, not scattered across tickets.
Penalty exposure is set by the inflation-adjusted schedule in 45 CFR 102.3 (91 FR 3666). For penalties assessed on or after January 28, 2026, the range runs from $145 per violation where the entity did not know of the violation to $2,190,294 per violation for uncorrected willful neglect, with a calendar-year cap of $2,190,294. The practical lesson is that documented, corrected findings carry a very different exposure from undocumented gaps, so your risk analysis and remediation log matter as much as the configuration itself. Confirm current figures against the eCFR text before citing them in a board paper.
HHS proposed a major Security Rule revision on January 6, 2025 (90 FR 898). As of October 2026 no final rule has been published, and the Unified Agenda projects final action for July 2027, so plan for the current text while tracking the rulemaking. NIST SP 800-66 Rev. 2 (February 2024) is a useful informational guide for mapping Ceph controls to each standard with sample questions, but it is not a binding requirement. Also note that no Security Rule standard requires certification, so any third-party attestation you commission is evidence you choose to produce, not proof of compliance.
What Ceph and the setup do not cover for HIPAA
Ceph can supply encryption, replication and immutable copies, but it does not make a deployment HIPAA compliant. The cards below name the decisions and evidence that stay with your organization, your business associates and your key management owner.
Risk analysis and policy decisions
The Security Rule requires you to decide whether encryption is reasonable and appropriate for each system holding ePHI, and to document the reasoning if you choose an equivalent alternative. Ceph cannot make that call for you. Your compliance lead and security officer own the risk analysis, the encryption decision record and the contingency plan. Confirm that your risk analysis names the Ceph pools, RGW buckets and RBD images that hold ePHI, and that each one has a documented decision on encryption at rest and in transit.
No HIPAA certification exists
HHS states that no Security Rule standard requires certifying compliance, and that private certifications do not stop HHS from later finding a violation. Any vendor or integrator who offers a HIPAA certificate for a Ceph cluster is describing something HHS does not recognize. Your compliance owner should request evidence of configuration, testing and documentation instead, and should be cautious about any claim that a product or cluster is HIPAA certified.
Key management and separation
HHS guidance treats encrypted ePHI as secured only when the decryption key has not been breached and is stored separately from the data. If you use an external KMS or key store with Ceph, the key owner, rotation schedule, access logs and recovery procedure must be designed and documented outside the cluster. Confirm with your Ceph operator how keys are supplied to OSDs or RGW, who can read them, and whether the key store runs on separate infrastructure with its own backups.
FIPS validation status
Whether the cryptographic modules used by your Ceph version, operating system and TLS libraries are FIPS 140 validated is a question for your environment, not a default you can assume. The Security Rule does not require FIPS, but many customers, auditors and contracts ask for it. Confirm the validation status of each module in your build, including the kernel crypto path for OSD encryption, the TLS stack in front of RGW, and any external KMS client, and record the answer in your risk analysis.
Workforce, physical and business associate safeguards
Ceph covers only the technical safeguards in the storage layer. Workforce training, access termination, data center physical controls, workstation rules and the business associate contract under 45 CFR 164.314 remain with your organization and your vendors. If a managed service provider or DeployOpen operates the cluster on your behalf, the business associate agreement must require Security Rule compliance and incident reporting. Confirm who holds the Ceph admin keys, who can enter the racks and how those people are trained.
Release lifecycle and upgrade planning
Ceph's actively maintained releases receive periodic backports and security fixes, and each release has an estimated end-of-life date. Running an unsupported release leaves known vulnerabilities in the storage layer that your risk analysis must address. Your team owns the upgrade calendar and the test plan, and should track the Tentacle and Squid end-of-life dates against your review cycle. Confirm with your Ceph operator how security patches will be applied, tested and documented, and how a failed upgrade would be rolled back.
What HIPAA storage work costs, how long it takes and what you must provide
What drives the cost of a HIPAA Ceph storage project?
Cost follows the written scope, and DeployOpen does not publish a price list, so a quote is issued from that scope. The main drivers are the number of ePHI data sets (block volumes, file shares and object buckets), the number and location of backup and replica targets, the identity integration needed for administrator and application access, and the volume of evidence to be produced for the risk analysis and any later assessment. Ask for a quote that separates one-time build work (design, deployment, encryption and backup configuration, restore testing, documentation) from any recurring retainer for support, upgrades and testing. Engagements are fixed-scope, so the quote should name the deliverables and the systems they cover.
How long does a Ceph HIPAA storage engagement take?
Duration depends on how many systems hold ePHI, how much of the data inventory and access model already exists, whether a cluster must be built or an existing one hardened, and how many restore tests the contingency plan requires. Each of these adds stages, and the written scope should show them as separate phases with dependencies, such as the risk analysis decisions that must be made before encryption settings are finalized. Ask for a timeline tied to the agreed deliverables and to the dates your own reviewers and approvers will need, since their availability often sets the pace.
What inputs must our team provide before the work starts?
The work needs several inputs from your side before design can be finalized:
- The risk analysis inputs, including the systems you already consider in scope, known threats and your current safeguards.
- A data inventory listing each ePHI data set, where it is created, stored, replicated and backed up, and who or what accesses it.
- Access to the identity provider and the directory groups that will map to storage roles.
- Named owners for storage, backup and restore, security, and the compliance decisions, with authority to approve the addressable choices.
Without these, the design will rest on assumptions, and the documentation will be weaker when an auditor or the HHS Office for Civil Rights asks how a decision was reached.
Can our own team do this without DeployOpen?
Yes, an internal team can build and document this work, and many do. The team must be able to show how each decision traces to your risk analysis, so the documentation they produce should include the risk analysis record, the encryption and key handling decisions with reasons, the backup and contingency plan, the restore test results, the business associate and vendor records, and the procedures for access and change. For each addressable specification, the file should state whether the measure is implemented or, if not, why it is not reasonable and appropriate and what equivalent alternative is in place. Where the team lacks Ceph operating experience, a partner can take part of the build while your team keeps ownership of the decisions and the evidence.
Does enabling Ceph encryption make our storage HIPAA compliant?
No. Turning on encryption at rest or in transit does not by itself make an environment compliant. Under the Security Rule, encryption is an addressable implementation specification, so you must assess whether it is reasonable and appropriate, implement it or document why not and use an equivalent measure if reasonable. That decision belongs to your risk analysis, and the rule also covers access control, audit controls, integrity, contingency planning and documentation. Encryption also only protects data as HHS guidance describes when the decryption key is not breached and is stored separately from the data, which depends on how keys are managed. Compliance is also not certified: HHS does not recognize private certifications, so the evidence you keep is what your assessors will examine.
What business associate contract terms apply when DeployOpen works on ePHI systems?
If a service provider creates, receives, maintains or transmits ePHI for you, the arrangement typically needs a business associate contract under 45 CFR 164.314(a)(2)(i). That contract should require the provider to comply with the Security Rule, pass the same terms to any subcontractor that handles ePHI, and report security incidents, including breaches of unsecured PHI. Whether DeployOpen needs access to ePHI, or can work only on infrastructure and configuration without viewing patient data, depends on the written scope, and that determines what contract terms are needed. Confirm the exact terms, data access limits and subcontractor flow-down with your legal counsel before any work begins, and do not rely on this summary as legal advice.
What recurring costs follow the initial build?
After the build, recurring work includes operating the cluster, applying patches and upgrades, running restore tests on the schedule your contingency plan sets, reviewing access, and keeping the risk analysis and documentation current as systems change. Some of this can stay with your team, and some can be contracted as a retainer covering support, upgrades and continuous testing. Ask whether the retainer covers restore testing and documentation updates, and which events, such as a new data set or a change in backup targets, would reopen the written scope and require a new quote.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms in infrastructure you control, including Ceph storage for ePHI. We scope encryption and backup design against your own risk analysis, then hand over configuration records and test evidence that your compliance team and auditors can review, without claiming that the work itself makes you HIPAA compliant.
How we scope
- Review your risk analysis and identify which ePHI pools, buckets and backup targets the cluster will hold.
- Record the encryption decision for data at rest and in transit, including any documented equivalent alternative.
- Agree in writing which contingency plan copies, restore tests and retention periods are in and out of scope.
How we build
- Deploy the cluster with cephadm in your own data centers or cloud accounts, with failure domains set to your site design.
- Configure encryption at rest, msgr2 secure mode and key custody with your chosen key management approach.
- Set up replicated or separate backup targets and run restore tests against recovery objectives you define.
How we hand over
- Deliver configuration records, network and key diagrams, and the settings behind each safeguard mapped to your risk analysis.
- Provide restore test results, logs and runbooks so your team can repeat the tests after handover.
- Document open items and decisions you still own, such as business associate terms and workforce access policy.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing upgrades, patching, backup verification and periodic restore testing are available as a retainer.
- Confirm with your legal and compliance advisers how the HIPAA Security Rule applies to your organization, since DeployOpen does not issue attestations.
