Ceph for healthcare: where self-hosted storage fits clinical data
Self-hosted Ceph can fit the storage layer for clinical data when your organization controls the infrastructure, the keys and the operating procedures, but it does not make an organization HIPAA compliant on its own. The HIPAA Security Rule applies to covered entities (health plans, health care clearinghouses and covered health care providers) and to their business associates, for all electronic protected health information (ePHI) they create, receive, maintain or transmit. If you hold PACS images, EHR exports or backup sets containing ePHI, the question is whether Ceph's features support the safeguards you must operate and document, and whether your team can run the platform to that standard. Ceph's Object Gateway (RGW) can serve PACS archives and backup targets through S3-compatible APIs, RBD can back virtual machines hosting clinical applications, and CephFS can serve shared file workloads. Messenger v2 secure mode encrypts post-authentication traffic between daemons and clients, and the Dashboard supports SAML 2.0 and, with the Management Gateway and OAuth2 Proxy services, OAuth2 single sign-on.
Ceph is licensed under LGPL-2.1 or LGPL-3, and the project itself offers no paid edition, so your costs are the hardware, the people who operate the cluster and any partner services you buy. The actively maintained releases are Tentacle (20.2.x) and Squid (19.2.x), and you should confirm which release line your deployment will run and its end-of-life date on the Ceph releases page before you design the upgrade path. Technical features do not carry the Security Rule. The Rule's standards, such as unique user identification, emergency access procedures, automatic logoff and encryption, are implemented through configuration, access processes and written policies, and each addressable specification requires a documented decision about whether it is reasonable and appropriate for your environment.
Before you commit, confirm three things with your privacy and security officers. First, whether your Ceph environment will hold ePHI and therefore falls inside your Security Rule risk analysis. Second, whether any vendor or service provider that operates or supports the cluster for you is a business associate that needs a contract under 45 CFR 164.314. Third, which of your own controls (for example, encryption at rest, key custody and audit logging) you will document as the evidence of compliance. Those answers determine how much of the Ceph design, from network isolation to backup immutability, must be specified and tested before go-live.
Which HIPAA requirements shape a Ceph build
This table maps the HIPAA Security Rule provisions most likely to affect a Ceph storage design to what each one asks for and what it means for the build. Read it as a checklist of decisions to settle before hardware is ordered, and confirm final obligations with your privacy and compliance advisers.
| Requirement | What it asks for | What it means for the Ceph build |
|---|---|---|
| Security Rule scope (45 CFR 164.302) | Covered entities and their business associates must protect all electronic protected health information they create, receive, maintain or transmit. | Every pool, RGW bucket, CephFS volume and backup target holding clinical images or records is in scope, including replicas, logs and test copies. Map where ePHI lands before defining the cluster layout. |
| Unique user identification (164.312, required) | Each user of an information system must be assigned a unique identifier that is tracked. | Use individual identities for dashboard, RGW and CephFS access where supported, avoiding shared administrator accounts. Confirm how each client and cephadm host access is attributed in logs. |
| Emergency access procedure (164.312, required) | A documented way to obtain necessary ePHI during an emergency. | Define how storage stays reachable during a monitor or site outage, who can break glass, and how that access is recorded. Test the procedure against your multisite recovery design. |
| Automatic logoff (164.312, addressable) | Electronic sessions end after a period of inactivity, or the entity documents an equivalent measure. | Applies mainly to the Ceph Dashboard and admin sessions. Set session timeouts and document the decision if you choose a different control for command-line access. |
| Encryption and decryption (164.312, addressable) | Mechanisms to encrypt and decrypt ePHI, assessed as reasonable and appropriate. | Decide on encryption at rest for OSDs and encryption in transit for client and cluster traffic. Ceph msgr2 secure mode encrypts post-authentication traffic with AES-GCM, but confirm each client path uses it. |
| Addressable specifications (164.306(d)) | Assess whether each addressable specification is reasonable and appropriate. If not adopted, document why and implement an equivalent alternative if reasonable. | Keep a written decision record for each addressable Ceph control, including the reason and any compensating measure. Assessors will ask for this record even when the technical control is in place. |
| Business associate contracts (164.314(a)(2)(i)) | Business associates must comply with the Security Rule, flow the same terms to subcontractors handling ePHI, and report security incidents, including breaches of unsecured PHI. | If a hosting partner, DeployOpen included, administers the cluster, the contract should cover administrative access, subcontractors such as hardware or cloud providers, and incident notice timelines. Confirm terms with counsel. |
| Appendix A standards and specifications (164.308, 164.310, 164.312) | 18 standards across administrative, physical and technical safeguards, with 36 implementation specifications: 14 required and 22 addressable. | Use the matrix as the control inventory for the build. Each Ceph component maps to one or more standards, and physical controls such as data center access sit outside Ceph but still need evidence. |
How Ceph encryption and access settings map to ePHI handling
The encryption decision for Ceph has two halves, and the HIPAA Security Rule treats them differently in practice. Encryption is an addressable implementation specification under 45 CFR 164.312, so you must document whether you encrypt ePHI at rest and in transit, and if you do not, record why and what equivalent measure you use instead (45 CFR 164.306(d)). For the transit half, the messenger v2 protocol on port 3300 has a secure mode that encrypts all post-authentication traffic with AES-GCM and adds integrity checks. Enable it in the cluster configuration, confirm it with your test clients, and make sure legacy clients that cannot negotiate it are removed from the network path before go-live. For the at-rest half, Ceph's own options depend on how OSDs are provisioned and on the release in use, so confirm the at-rest encryption options with the vendor documentation for your release, record the chosen approach, and test recovery of an encrypted OSD before you rely on it.
Access to ePHI passes through the Ceph Object Gateway and the Dashboard, and each needs a controlled identity source. For RGW, the documented authentication options include Keystone and LDAP, along with multi-factor authentication, and Open Policy Agent integration can express access rules that match your care team's need to know. The 2026 CNIL fine against Hopital Prive de la Loire, which cited missing multi-factor authentication and access control that ignored the care team's need to know, is a useful test case for the policy you write. For the Dashboard, single sign-on works through SAML 2.0, or through OAuth2 when cephadm deploys the Management Gateway and OAuth2 Proxy services. Choose one, confirm which services your release requires, and map Dashboard roles to the same groups used for RGW access.
Keep both exposure points narrow. Limit the Dashboard to a management network reachable only from administrator workstations, and treat cephadm host SSH access as privileged, since the orchestrator controls every daemon on every host. Confirm with your security team which accounts can reach each host and the Dashboard, and keep those lists in your audit evidence. These are operational controls that support your risk analysis under 45 CFR 164.308 but do not by themselves satisfy the Security Rule, so record how each setting maps to the standard it supports.
Configuration that matters for clinical images, records and backups
Clinical storage on Ceph is less about the platform than about how each data type is placed, protected and recovered. The cards below cover the access patterns, hardware and recovery design that shape a healthcare cluster, and the controls that connect them to your identity and audit evidence.
RGW buckets for DICOM and documents
Imaging studies and scanned records fit the S3-compatible Object Gateway, which supports multisite configuration, compression and lifecycle handling. Map one bucket or account per data class so access, quotas and retention can differ between imaging archives and document stores. Set retention periods from your own records policy and legal review, then confirm that lifecycle rules and object locking behave as your policy requires before any clinical data arrives.
RBD for PACS and database volumes
Picture archiving systems, clinical databases and virtual machines that need block devices belong on RBD rather than object storage. Decide per workload whether snapshots are consistent enough for the database engine, and test restores before relying on them. Confirm which hosts map volumes and how access is limited, because a single shared volume exposed to several clients can corrupt clinical records.
CephFS for shared clinical workflows
Use CephFS only where a specific application needs a shared POSIX file system, such as a legacy modality workflow that writes to a mounted share. Each shared path needs its own access rules and an owner who can explain who reads it. Where the workflow can use object storage instead, prefer that, since fewer shared file paths means fewer places for unauthorized access.
Backup targets with separate failure domains
Keep backup pools on separate CRUSH failure domains from primary clinical data so a fault or ransomware event in one does not remove the other. Plan multisite replication for availability across sites, and document the recovery time and recovery point your clinical leaders have agreed. Ask your team to define these targets in writing, since the cluster cannot infer them.
Hardware sized for clinical load
Follow the hardware recommendations: a dedicated drive per OSD, WAL and DB on shared SSDs for HDD-based OSDs, enterprise-class SSDs for metadata, and bonded network links across two switches. Size memory for peak recovery load, not calm periods, and benchmark before buying because no two clusters behave alike. Hardware choices directly affect how long a failed-node recovery keeps clinical systems degraded.
Identity, access and logging integration
Connect the Object Gateway to your identity provider through Keystone or LDAP, and enable multi-factor authentication where the gateway supports it. Use the Dashboard's SAML 2.0 or OAuth2 single sign-on for administrators, and send gateway and cluster logs to your central logging platform. Confirm which access events you can retain as audit evidence, since regulators will ask who touched each record.
How a healthcare Ceph rollout is phased
The sequence moves from knowing which systems hold ePHI to a tested, documented cluster that your own team can operate after cutover. Each phase closes with an output that the next phase depends on.
Classify data and identify ePHI systems
Start by inventorying the workloads that will sit on Ceph: PACS image archives, EHR-adjacent databases, document stores and backup targets. For each, record what electronic protected health information it creates, receives, maintains or transmits, and which business associates touch it. The HIPAA Security Rule applies to ePHI held by covered entities and their business associates, so this inventory defines the boundary the rest of the project protects. Your compliance and clinical informatics leads make the classification decisions, and DeployOpen documents them. Done when every workload has a named data class, an owner and a stated reason for its placement on Ceph or elsewhere.
Complete risk analysis and map requirements
Run the risk analysis your organization owes under the Security Rule, then map each identified risk to the administrative, physical and technical safeguards it touches. NIST SP 800-66 Rev. 2 is a useful informational guide for this mapping. For every addressable implementation specification, record whether it is reasonable and appropriate for your environment and, where it is not, the equivalent measure you chose. Your privacy and security officers own these decisions and sign off on them. DeployOpen prepares the requirement matrix that later phases must satisfy. Done when each requirement has a design owner and an evidence item it will produce.
Design cluster failure domains and networks
Translate the requirements into a cluster design: CRUSH failure domains that match your racks, rooms or sites, replication or erasure coding choices per data class, monitor placement, and separate public and cluster networks with bonded links across two switches, as the Ceph hardware recommendations advise. Size memory for peak use and benchmark representative hardware before purchase. Decisions about how many sites hold copies, and how far apart they sit, belong to your clinical continuity and recovery owners. Done when a written design review approves the failure domains, network layout and capacity model, and the open decisions are recorded with owners.
Deploy cephadm on a supported release in test
Build a test cluster with cephadm on a currently supported release, either Squid or Tentacle. Squid's estimated end of life is October 31, 2026, so confirm the release timeline with your own change calendar before choosing it for production. Bootstrap the cluster, add hosts, apply the placement and drive layout from the design, and confirm the dedicated drive per OSD and WAL and DB placement on shared SSDs for HDD-based OSDs. The test cluster is where your team learns the operating model. Done when the test cluster reports healthy under a simulated host and drive failure, and the deployment steps are captured as runbooks.
Configure RGW, RBD and identity integration
Enable the interfaces your workloads use: RBD volumes for virtual machines and databases, CephFS or RGW where file or object access is required, and the Object Gateway with its S3 API. Connect authentication to your directory, using LDAP or Keystone where it fits your identity design, and set encryption in transit with messenger v2 secure mode. Decide which dashboard single sign-on method you need, SAML 2.0 or OAuth2 through the Management Gateway and OAuth2 Proxy services, and confirm it against your release. Access roles are your identity team's decision. Done when test users reach only the buckets, images and paths their role allows, and access logs show the expected entries.
Test backup, immutability and restore
Configure the backup targets your recovery plan requires, including any immutability or retention settings your backup software and object locking support. Then run restore tests, not just backup jobs: restore an imaging study, a database snapshot and a complete bucket to a separate location, and time the results against your recovery objectives, which your clinical leadership sets. Test a failed-site scenario if your design relies on multiple sites. Confirm which immutability features your chosen release provides before relying on them, since that is a vendor-verified fact to check. Done when each restore test has a recorded result, and failures have tracked fixes.
Capture documentation and compliance evidence
Assemble the records your assessors and your own governance will ask for: the risk analysis, requirement matrix, configuration baselines, access reviews, patching and upgrade records, backup and restore test results, and business associate agreements covering any vendor or subcontractor with ePHI access. HHS states there is no HIPAA certification, so the goal is evidence that your safeguards operate, not a certificate. Your compliance team owns the final policy set. DeployOpen prepares the evidence and does not issue audit reports or attestations. Done when a named owner has reviewed each evidence item and the gaps are logged for remediation before cutover.
Cut over and hand off operations
Move production data in controlled waves, with a rollback path for each workload and a freeze window agreed with clinical operations. After each wave, check replication health, client access and the restore points. Then hand operations to your team with monitoring, alerting, the runbooks from earlier phases, a patching and upgrade procedure, and a named escalation path. Decide which support model you want afterward: in-house operations, or a retainer for upgrades and continuous testing. Done when each wave is signed off, the operations team has completed a supervised run of the runbooks, and the handover record is accepted.
Compliance considerations beyond HIPAA
HIPAA sets the baseline, but the evidence an auditor or regulator asks for depends on who you are, where your patients are and which frameworks your contracts reference. The cards below cover the points that change how a Ceph healthcare platform is documented, tested and operated.
No HIPAA certification exists
HHS states that no Security Rule standard requires certification and that private certifications do not stop HHS from later finding a violation. DeployOpen prepares configurations, control mappings and evidence for your assessors, but it does not issue attestations or certifications. Ask your legal and compliance team which independent assessment, if any, your partners and payers expect, and who in your organization owns the final determination.
OCR enforcement and penalty exposure
The HHS Office for Civil Rights enforces the Security Rule through complaint investigations, compliance reviews and audits. For penalties assessed on or after January 28, 2026, the inflation-adjusted civil money penalty ranges from $145 per violation to $2,190,294 per violation, with a calendar-year cap of $2,190,294. Confirm with counsel how an uncorrected gap in Ceph encryption, access logging or backup testing would be documented, because the penalty tier depends on what you knew and how quickly you corrected it.
Pending Security Rule revision
HHS proposed a major Security Rule revision on January 6, 2025. As of October 2026 no final rule has been published, and the Unified Agenda projects final action for July 2027. Treat the proposal as a planning input rather than a current requirement. Design Ceph key management, audit logging and recovery testing so that stricter controls can be added without rebuilding the cluster, and review the proposal text with your compliance lead.
HITRUST CSF as a voluntary framework
HITRUST CSF is a voluntary control framework that many healthcare buyers request in contracts. Independent assessors apply it, and the certification validity period depends on the assessment type. Map your Ceph controls to the framework only if a customer or payer requires it, and ask the assessor which version and assessment scope they will use before building evidence. Ceph configuration, backup and access records should be collected in a form the assessor can sample.
NIST SP 800-66 Rev. 2 as a guide
NIST SP 800-66 Rev. 2, published in February 2024, gives key activities, descriptions and sample questions for each HIPAA Security Rule standard. HHS lists it as informational rather than legally binding. Use it as a checklist to plan Ceph responsibilities, such as who reviews cephadm host access, who approves RGW user quotas and who tests restores, and record which activities you adopt and why.
EU exposure under NIS2 and GDPR
For EU organizations, the health sector appears in NIS2 Annex I as a sector of high criticality, and GDPR Articles 32 and 34 require appropriate security and breach communication. On 3 September 2026 the French CNIL fined Hopital Prive de la Loire EUR 500,000 after finding external access to patient records lacked VPN and multi-factor authentication and that access control ignored care team need-to-know. For Ceph, confirm that RGW and dashboard access paths require strong authentication and that object access follows clinical need.
What healthcare teams ask before a Ceph implementation
What drives the cost of a Ceph implementation for healthcare?
The main drivers are scope, the number of sites, data volume, integrations and how much documentation the compliance team needs. A single-site block and object cluster with clear data classes costs far less to design and build than a multisite deployment that replicates clinical imaging, connects to a PACS or EHR and must produce evidence for a HIPAA risk analysis. Each cost component is a separate line: discovery and design, hardware or cloud capacity you buy directly, implementation and testing, documentation, and handover. Hardware and licenses are typically paid to vendors, while DeployOpen's fee follows the written scope. Ceph itself is LGPL-licensed with no paid edition from the project, so recurring costs are mostly your staff, hardware refresh and any support retainer. Ask any partner for a quote that itemizes these components and states what is one-time and what recurs.
How long does a phased Ceph build for a hospital take?
Duration depends on the number of sites, how many data classes are in scope, how quickly hardware arrives and how many change windows your clinical systems allow. A phased build usually runs discovery and design first, then a lab or pilot cluster, then production cutover for one workload at a time, such as backups before clinical imaging. Each phase has entry and exit criteria agreed in the written scope, so the timeline is set by those gates rather than a fixed calendar. Ask for a phase plan with named acceptance tests, a dependency list for network, identity and hardware, and a reserved window for failover testing. No duration should be accepted before the design review has confirmed the scope.
What must our team provide before a Ceph engagement starts?
Before work starts, your team should provide a data classification that identifies which records, images and backups contain ePHI, a current HIPAA Security Rule risk analysis or a plan to update it, and a named owner for each system. You also need staff who will operate the cluster after handover, access to your network and identity systems, and change windows agreed with clinical operations. Procurement should confirm hardware lead times, and legal should review whether a business associate agreement is needed before any partner accesses systems. Missing inputs usually extend the design phase, so confirm them in the scope document.
Can a small healthcare IT team run Ceph after implementation?
A small team can operate Ceph if it has people who understand storage fundamentals, Linux administration, networking and container-based deployment, and if it has a runbook for common events. The Ceph documentation describes cephadm managing a cluster as containers, so operators need to be comfortable with orchestrator commands, host management and monitoring. Drive failures, full OSDs, slow requests and scrub errors need documented responses. Plan at least two people trained on the cluster so that one absence does not leave backups unmanaged. If that skill set is not in-house, consider a support retainer for ongoing operations and upgrades alongside your own staff.
Does using Ceph make our organization HIPAA compliant?
No. Ceph is a storage platform, and HIPAA does not certify products or organizations. The Security Rule applies to covered entities and business associates for the ePHI they handle, and HHS states that no Security Rule standard requires certification and that private certifications do not prevent HHS from later finding a violation. Ceph can support safeguards such as encryption in transit through the msgr2 secure mode, access control, and documented configuration, but your organization must perform a risk analysis, select and implement safeguards, assess addressable specifications and keep documentation. NIST SP 800-66 Rev. 2 is a useful reference for mapping those activities. Independent auditors, not DeployOpen, issue any audit reports or attestations.
How are Ceph upgrades planned on a supported release?
Start by identifying which release line you run. The Ceph releases page lists actively maintained releases that receive periodic backports and security fixes, and each has an estimated end-of-life date you should track. Upgrades with cephadm should follow the documented order, usually managers, monitors, OSDs, then gateways, with health checks between steps. For healthcare, plan a lab upgrade first, confirm backup restore still works, schedule a change window, and record the rollback approach and the approval in your change record. Confirm the exact upgrade path for your current release in the official documentation before committing to a date.
What must a business associate agreement cover when a partner touches ePHI?
Under 45 CFR 164.314(a)(2)(i), the agreement must require the business associate to comply with the Security Rule for ePHI it handles, flow the same obligations down to any subcontractor that handles ePHI, and report security incidents, including breaches of unsecured PHI, to the covered entity. Ask the partner to describe how access to systems is granted, logged and removed, where support staff are located, and how incidents are escalated. Confirm return or destruction of data at the end of the engagement and who reviews the contract. Have legal counsel draft or review the agreement, since the exact terms depend on the services and data involved.
What is the current status of the proposed HIPAA Security Rule revision?
HHS proposed a major Security Rule revision on January 6, 2025 (90 FR 898), with comments due March 7, 2025. As of October 2026, no final rule has been published, and the latest Unified Agenda lists final action as projected for July 2027. Until a final rule is published, plan against the current rule, but design your Ceph controls so that encryption, access logging, backup testing and documentation can be extended if the final text changes. Check the Federal Register and reginfo.gov before each planning cycle, since these dates can move.
Which HIPAA documentation an implementation needs
A Ceph implementation for ePHI produces a set of records that the covered entity or business associate can show to HHS Office for Civil Rights during a complaint investigation, compliance review or audit. The HIPAA Security Rule (45 CFR Part 164 Subpart C) does not name documents, so the list below is a working inventory mapped to the standards it supports. The starting point is the risk analysis inputs under 45 CFR 164.308, covering a current inventory of every Ceph cluster, RGW endpoint, client and backup target that holds or moves ePHI, with the CRUSH failure domains and site placement recorded alongside them. Architecture and data flow diagrams should show where encryption in transit (msgr2 secure mode on port 3300) and encryption at rest apply, which feeds the addressable encryption specification in 164.312. Configuration baselines for cephadm hosts, Dashboard settings and RGW authentication support the technical safeguards, and the access and key management procedures cover unique user identification, emergency access and rotation of Ceph and RGW keys.
Backup and restore test records are often the weakest evidence in storage programs. For immutable backups, retain a dated record of each restore test with the scope, the person who ran it and the result, because this supports the contingency planning standard in 164.308(a)(7). Policy and procedure documents under 164.316 should describe who approves changes and how upgrades are tested, and change records for each Ceph upgrade, including the release and its support window from the Ceph releases page, show that the platform stayed within a supported line. For cloud or hosted deployments, business associate agreements under 164.314(a)(2)(i) must flow down to subcontractors that handle ePHI, so confirm in writing which parties can reach the cluster. NIST SP 800-66 Rev. 2 (February 2024) maps key activities and sample questions to each standard and is a useful checklist, though HHS treats it as informational rather than binding.
The client's compliance lead owns the HIPAA program, approves the policies and decides which addressable specifications apply and what equivalent measures are reasonable. DeployOpen prepares the system descriptions, configuration evidence, runbooks and test records that this owner reviews, and can help map them to the Security Rule. DeployOpen does not issue audit reports, attestations or certifications. HHS states that no Security Rule standard requires certification and does not recognize private certifications, so any claim of HIPAA compliance rests on the covered entity's own documented assessment. Ask the compliance lead to confirm the evidence format, retention period and review cycle before the implementation starts, and confirm with counsel how the proposed Security Rule revision, which had no final rule as of October 2026, might change these records.
Decisions to settle before the quote
This sequence turns a healthcare storage idea into a written scope by settling what data goes on Ceph, who owns retention, how sites and encryption are handled, and who runs the cluster after handover. Each decision gives the quote its boundaries.
Inventory the data classes for Ceph
Your compliance lead and clinical informatics owner list each data class you intend to place on Ceph, such as imaging (PACS and DICOM archives), EHR attachments, research extracts and backup copies. For each class, record whether it contains electronic protected health information, which system writes it, and which access path reads it (S3 API, block volumes or file shares). Classes that stay on other platforms are listed as out of scope. The step closes when the list is signed by the data owner and the security officer, because every later decision depends on it.
Assign retention ownership and rules
The data owner, with legal and records management, decides retention periods for each class and who may approve deletion or legal holds. Ceph Object Gateway lifecycle rules can enforce expiry, but the business rule must come from your side. Confirm whether any clinical records carry retention requirements that a lifecycle rule must not override. The step closes with a retention table that names an accountable owner for each class and a documented process for holds, so that storage administrators do not decide clinical retention by default.
Set the site count and replication scope
The infrastructure lead and the continuity owner decide how many sites will hold the cluster or its replicas, which data classes replicate to each site, and what recovery point and recovery time the clinical services need. Ceph multisite configuration for RGW and the failure domains in CRUSH shape what is possible, so the team must confirm which options the chosen Ceph release supports for each design. The step closes with a site diagram and a replication matrix that the quote can price against.
Choose the encryption approach and key custody
The security architect and the privacy officer decide where encryption happens (in transit with messenger v2 secure mode, at rest on the OSD or client side) and who holds the keys. Key custody is the decision with the largest downstream effect, because it determines who can restore data and how key rotation works. Confirm the key management system you will use and whether it sits inside your control boundary. The step closes with an approved encryption design record that names the key owner and the rotation responsibility.
Select the identity source for RGW and Dashboard
The identity team decides which directory or identity provider authenticates administrators and applications. Options described in the Ceph documentation include SAML 2.0 and OAuth2 for the Dashboard, and Keystone or LDAP for RGW, with multi-factor authentication available for RGW users. The team must confirm which of these your environment can support and who approves privileged access. The step closes with a documented access model that lists administrator groups, application accounts and the break-glass path, which the quote will need to cover.
Design backup isolation and immutability
The backup owner and security team decide which copies must be isolated from the production administrative plane, how immutable retention is enforced, and who can alter backup policy. Ceph provides replication and snapshot features, but a replica is not a backup if the same credentials can delete it, so the design must separate credentials and approval paths. The step closes with a written backup architecture showing where each copy lives, which identities can touch it and how a restore is tested, with the test owner named.
Define the support model after handover
The operations manager and the vendor management lead decide who runs the cluster after handover: your own platform team, a managed arrangement or a retainer with DeployOpen. They also agree on release tracking for Ceph, since actively maintained releases receive periodic backports and security fixes, and on who approves upgrades and patch windows. The step closes with a responsibility matrix that assigns each recurring task, such as monitoring, patching, restore testing and access reviews, to a named team, which the quote will reflect.
Confirm the compliance evidence scope
The compliance lead decides which HIPAA Security Rule safeguards the Ceph implementation must document and which evidence the auditor or customer will request. This clarifies that DeployOpen prepares systems, controls and evidence, while independent assessors and the HHS Office for Civil Rights make determinations; there is no HIPAA certification. The step closes with a list of controls, owners and evidence artifacts, plus any business associate contract terms that flow to the implementation partner, so the written scope matches what the organization can defend.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Ceph for healthcare. We start from a written scope that names the clinical data, the sites and the evidence your compliance team will need, then build and hand the cluster over with runbooks your team can operate.
How we scope
- Written scope listing the clinical data types, sites, replication targets and retention periods Ceph will hold
- Review of which HIPAA Security Rule standards and addressable specifications your organization must document for each use
- Agreed deliverables, responsibilities and timelines before any build work starts, since most engagements are fixed-scope
How we build
- Cephadm deployment with encryption in transit, client authentication and dashboard single sign-on configured to your identity provider
- Failure domain, placement and backup design tested against your recovery objectives, with benchmarks run before hardware is accepted
- Immutable backup targets, access logging and key handling validated through documented test cases your team can repeat
How we hand over
- Documentation of configuration, access model, retention rules and the evidence each control produces for your auditors
- Runbooks for drive replacement, health warnings, restore testing and cephadm host access, written for your operations staff
- Knowledge transfer sessions with your engineers so the team can run the cluster without DeployOpen on call
How we support
- Ongoing support, upgrades and periodic restore testing available as a retainer, scoped in writing
- Planned upgrades between Ceph releases, with change records and rollback steps prepared before each window
- Security testing of the storage services and their interfaces, run on a schedule agreed with your security team
