A hospital digital team now runs the main website, a provider directory, patient portal landing pages, telehealth intake pages, and usually an intranet, often on a single healthcare content management system (CMS). A retail- or media-oriented CMS checklist may compare editorial workflows and page speed and stop there. Healthcare adds requirements those checklists never mention: Health Insurance Portability and Accountability Act (HIPAA) technical safeguards under 45 CFR § 164.312, Business Associate Agreements (BAAs), state data residency laws like Texas SB 1188, and access controls granular enough to keep a marketing editor out of clinical content.
Teams tend to find this out late. A platform passes the digital team's review, then legal or security rejects it because the vendor won't sign a BAA or can't produce audit logs, and the project restarts. In the worst case, the platform ships anyway, and the gap surfaces during a breach investigation.
Healthcare CMS evaluation requires sorting content into exposure tiers, applying the three HIPAA provisions that decide most purchases, testing security capabilities, assessing why a headless CMS fits the compliance model, and choosing between self-hosted and managed deployment. Some of the evaluation carries over from other regulated industries, but BAAs and the minimum necessary standard are specific to healthcare.
In brief
- Healthcare CMS exposure depends on whether content workflows create, receive, maintain, or transmit PHI.
- Vendors in the ePHI data path need a signed BAA, while self-hosting shifts obligations to the infrastructure provider and the hospital.
- RBAC, audit logs, encryption, MFA, and SSO are the core security capabilities to test.
- Headless architecture can keep PHI in clinical systems and support self-hosted or managed deployment.
Use these takeaways to identify which legal, security, and deployment questions apply before a platform reaches final review.
Why healthcare CMS requirements are different
HIPAA exposure comes from the content flowing through a CMS for hospitals. A single platform often touches more than one tier, so it has to satisfy the strictest tier it touches.
Public-facing content (hospital websites, provider directories)
Location and hours pages, job listings, visiting policies, press releases, and general service descriptions carry the lowest exposure for protected health information (PHI). The Department of Health and Human Services (HHS) enforces HIPAA through its Office for Civil Rights (OCR). OCR's tracking technologies guidance states that tracking technologies on unauthenticated pages with general information about the entity "do not have access to individuals' PHI" and that such use "is not regulated by the HIPAA Rules." A 2024 federal court ruling vacated OCR's theory that an IP address plus a visit to a health-condition page equals PHI.
Exposure changes the moment you embed a scheduling widget or a contact form that asks about symptoms. OCR says information passed through appointment scheduling tools and "find a doctor" functionality "is likely to include PHI," and that part of the guidance survived the ruling.
Authenticated and patient-facing content (portals, appointment systems)
Portal login and registration pages, post-login portal pages, and billing portals are at the top of the exposure scale. OCR states that tracking on a portal login or registration page that collects a name or email address "is a disclosure of PHI." Authenticated pages, in OCR's words, "generally have access to PHI." That PHI can contain diagnosis information. It can also contain medical record numbers and appointment dates. Any vendor in this data path that creates, receives, maintains, or transmits PHI on behalf of the covered entity needs a BAA; vendors that do not have access to PHI generally do not.
Internal content and clinical workflows (intranets, knowledge bases)
Intranets, clinical knowledge bases, and staff portals get skipped in most CMS evaluations because nobody thinks of them as patient-facing. PHI exposure here depends on what editors publish, but the access-control obligations are identical. HHS gives a concrete negative example: "If a hospital employee is allowed to have routine, unimpeded access to patients' medical records, where such access is not necessary for the hospital employee to do his job, the hospital is not applying the minimum necessary standard." Yakima Valley Memorial Hospital paid $240,000 after 23 security guards accessed 419 patient records they had no reason to see.
HIPAA and CMS: what compliance actually requires
Security Rule provisions govern almost every CMS decision a hospital makes.
Business associate agreements
A BAA is the written contract HIPAA requires between a covered entity and any vendor that creates, receives, maintains, or transmits PHI on its behalf. The HHS business associate guidance explains that under 45 CFR § 164.504(e), the contract must describe permitted uses of PHI, prohibit further disclosure, require return or destruction of PHI at termination, and support individual rights like access and amendment. A cloud service provider handling encrypted ePHI remains a business associate. HHS cloud guidance states that a cloud service provider (CSP) handling electronic PHI (ePHI) is a business associate "even if the CSP processes or stores only encrypted ePHI and lacks an encryption key for the data."
With a SaaS CMS, verify in writing whether the vendor will sign a BAA for the selected plan; a claim of HIPAA readiness must be backed by the agreement HHS requires.
Self-hosting moves the obligation elsewhere. When the CMS runs on infrastructure the health system controls, the software vendor stays outside the ePHI path. The BAA attaches to the cloud provider running the servers under HHS cloud guidance. The hospital then owns Security Rule compliance under § 164.308(a)(1).
Access controls and the minimum necessary standard
The unique user identification requirement in 45 CFR § 164.312 calls for a unique name or number for each user, which makes shared editorial logins a violation on day one. Layered on top, § 164.502(b) requires policies that "reasonably limit access to and use of PHI to the minimum necessary given the job responsibilities of the workforce." HHS privacy guidance spells out the mechanism: covered entities must "develop role-based access policies and procedures that limit which members of its workforce may have access to protected health information."
In CMS terms, this means role-based access control (RBAC) granular enough to enforce minimum necessary access. Depending on the content model, that may require permissions at the Content-Type and field level. A flat admin/editor/viewer toggle may not answer the question in HHS administrative safeguards under § 164.308(a)(4) about whether different workforce members need different levels of access based on job function.
Audit controls
The required audit-control standard under § 164.312(b) has no addressable sub-specifications: "Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information." § 164.308(a)(1)(ii)(D) adds a separate obligation to conduct regular activity reviews. OCR's 2024 report to Congress lists breach-investigation failures. The failures include log reviews conducted only in response to a breach or on an infrequent, ad-hoc basis. Warby Parker's $1.5 million penalty in December 2024 cited, in part, a failure to regularly review information system activity.
For a CMS, each audit log entry needs to identify the user and action with a timestamp on every write, and the OCR audit protocol checks both whether the capability exists and whether it's switched on. Retention is where teams get tripped up. HIPAA's six-year rule under § 164.316(b)(2)(i) covers HIPAA compliance documentation, including records of log reviews, rather than the logs themselves.
Security capabilities to evaluate in a healthcare CMS
The regulatory requirements above translate into four capability areas a procurement team can actually test.
Encryption at rest and in transit
Both encryption specifications, § 164.312(a)(2)(iv) at rest and § 164.312(e)(2)(ii) in transit, are classified as "addressable" under HHS encryption guidance. HHS is explicit about the requirement: "Where it is reasonable and appropriate, the regulated entity must adopt the addressable implementation specification." Under § 164.306(d)(3), skipping it requires written justification and an equivalent alternative. OCR's August 2024 newsletter lists "failure to implement a mechanism to encrypt and decrypt ePHI" among the violations it has found in investigations.
Doing it properly earns the breach safe harbor. Under HHS breach guidance, PHI encrypted consistent with NIST SP 800-111 isn't "unsecured PHI," so a lost database doesn't trigger notification. HHS ransomware guidance warns that consistency depends on sound key management. The encryption algorithm and methodology must also meet the standard.
In transit, the CMS and its hosting should support Transport Layer Security (TLS) 1.2 with FIPS cipher suites plus TLS 1.3, per NIST transport guidance. The database layer should use Advanced Encryption Standard (AES) encryption, specifically AES-256 at rest, which AWS and Google Cloud apply by default. Then check who holds the keys. AWS KMS controls, Azure Key Vault controls, and Google Cloud KMS controls all support customer-managed keys, where the hospital creates and rotates the key and data can't be decrypted without it. A vendor-managed SaaS CMS typically holds platform keys unless it explicitly offers a bring-your-own-key (BYOK) option.
Multi-factor authentication and SSO integration
Hospitals run identity through an identity provider (IdP) such as Microsoft Entra ID, often paired with Imprivata, or Okta, which has documented healthcare identity deployments. The Health Industry Cybersecurity Practices (HICP) published by the HHS 405(d) program discuss single sign-on (SSO) as an access-management approach and identify multi-factor authentication (MFA) as a recommended practice or sub-practice, rather than treating both as separate required practices. HHS cybersecurity practices call for MFA "to access areas of your network with sensitive information" and for SSO so the organization can "centrally maintain and monitor access."
The practical identity test is whether the CMS supports SAML 2.0 or OIDC so the IdP enforces MFA and deprovisions departed staff centrally, instead of the CMS running its own second factor.
Role-based access control granularity
A hospital CMS serves clinical, marketing, IT, and administrative editors at once, and each group needs different rights over different content. Check whether permissions apply per Content-Type and per field, and whether an administrator can define a new role without filing an engineering ticket. Montefiore Medical Center's penalty of $4.75 million, after a workforce member accessed more than 12,000 records and sold them, shows what an over-broad role costs.
Audit trail depth and log retention
Ask four questions: are logs tamper-evident, how long are they kept by default, can they be exported for a compliance review, and do they feed the hospital's security information and event management (SIEM) tooling? Check whether retention is configurable and whether logs past the window are recoverable. The broader headless CMS security checklist covers the surrounding controls.
Why headless architecture suits healthcare compliance
Headless CMS architecture maps directly onto the compliance problems above.
Decoupled architecture reduces attack surface
In a monolithic, plugin-based CMS, the admin interface and content database may share one execution environment with the public frontend, which is why deployment boundaries matter.
Headless allows teams to separate those components. The public frontend can be configured as read-only to fetch content through an API, with forms prevented from writing directly to the database. When the systems run in separate execution environments with appropriate access controls, the design can limit the blast radius of a frontend vulnerability; administration interface isolation still depends on configuration. The API layer carries the remaining risk. OWASP's API Security Top 10 puts Broken Object Level Authorization first. Headless CMS security still requires disciplined endpoint authorization, but the surface is smaller and you configure exactly what the API exposes.
Self-hosting preserves data residency control
HIPAA itself is location-agnostic. The HHS offshore storage FAQ confirms offshore storage is allowed "provided the covered entity (or business associate) enters into a business associate agreement (BAA) with the CSP." State law and payer contracts can be stricter. Under the Texas localization law, SB 1188 has required since January 1, 2026 that electronic health records stored by third parties be "physically maintained in the United States or a U.S. territory."
Self-hosting a headless CMS in your own virtual private cloud (VPC) in a US region satisfies these rules without waiting on a vendor. AWS lists more than 166 HIPAA-eligible services. Azure includes its BAA in the Online Services Data Protection Addendum by default. Google Cloud's BAA covers its entire infrastructure across all regions.
API-first integration doesn't require PHI to live in the CMS
Teams often assume the CMS will become a store for patient records. In a headless model it stores content: articles, form definitions, page layouts, provider bios. Electronic health record (EHR) data stays in the EHR or whatever system already owns it, and the frontend fetches both and composes the page. Configured this way, the CMS may stay outside the PHI chain for those use cases. This narrows HIPAA scope to systems that create, receive, maintain, or transmit ePHI under HHS cloud guidance.
The API layer then needs its own controls. These controls start with tokens scoped to specific Content-Types with limited lifetimes and security headers such as Content Security Policy on every response. These API security practices cover the rest of the hardening.
Self-hosted vs managed: which deployment model fits healthcare
Under HHS cloud guidance, either model can support compliance when the parties in the ePHI path meet their obligations. They differ in who carries the BAA and the patching burden.
Self-hosted deployments
You control the infrastructure and encryption keys. That control extends to the physical location of data. The CMS vendor needs no BAA because it never touches ePHI. The cost is operational. HICP's monthly patching guidance requires routine patching of servers and web applications "at least monthly," and MedHealthReview reported that 57% of hospitals hit by cyberattacks said an available patch would have prevented the breach. Self-hosting suits systems that already have a DevOps team or strict sovereignty requirements that leave no alternative.
Managed and cloud deployments
The vendor runs infrastructure and you deploy faster, but the vendor becomes a business associate. Managed hosting suits smaller healthcare organizations without dedicated DevOps, provided the vendor runs on HIPAA-eligible infrastructure. HHS 405(d) vendor-assessment guidance directs organizations to "conduct security assessments of third-party vendors" and to include "stringent security requirements in contracts." At minimum, request a SOC 2 Type II report, which AICPA guidance explains assesses controls over a period of time rather than a snapshot. Also ask for a BAA for the specific plan tier and a Data Processing Agreement with a sub-processor list. Request documented vulnerability management as well.
Decision framework
Start with whether PHI, or data that could reasonably be combined with PHI to identify a patient, flows through the CMS or its hosting environment. If yes, choose self-hosting on HIPAA-eligible infrastructure or a managed vendor with a signed BAA and audited controls. If no, standard evaluation applies, though encryption, unique user IDs, and audit logging still belong in the requirements because tomorrow's scheduling widget changes the answer.
A practical checklist for healthcare CMS evaluation
Bring these questions to the vendor call for any HIPAA compliant CMS on your shortlist.
- BAA: Does the vendor sign a BAA for the plan tier you're buying, or does self-hosting eliminate the requirement by keeping the vendor out of the ePHI path?
- RBAC: Can permissions be set per Content-Type and per field, with custom roles created by an administrator rather than an engineer?
- Audit logs: Are entries timestamped and user-attributed, are they tamper-evident, can they be exported, and can retention be extended to meet the organization's documented policy?
- Encryption: Is data encrypted at the database level at rest and over TLS 1.2 or 1.3 in transit, and can you hold the keys through KMS, Key Vault, or Cloud KMS?
- Identity: Does the platform support SSO via SAML 2.0 or OIDC so MFA is inherited from Entra ID, Okta, or your existing IdP, with local password login disabled for privileged roles?
- Residency: Can the CMS ensure EHRs are physically maintained in the United States or a U.S. territory to satisfy Texas SB 1188, and support any applicable payer or Texas HHS offshoring restrictions?
- Scope: Does the API architecture keep PHI in the EHR and other clinical systems, with the CMS storing only content?
- Assurance: Does the vendor hold SOC 2 Type II, publish a sub-processor list, and document vulnerability management and patching cadence?
Use the answers to compare vendors consistently and identify any compliance gaps before legal or security review.
Choosing a CMS your compliance team will sign off on
Healthcare CMS selection differs from other verticals because the requirements above are legal obligations, with penalties including Yakima Valley's $240,000 and Montefiore's $4.75 million, rather than preferences a stakeholder can waive. Headless architecture addresses the structural half of the problem by keeping the admin interface off the public server and PHI in clinical systems. With self-hosting, the hospital also controls encryption keys and data location. The checklist covers the procurement half in language legal and security reviewers already use.
Against those criteria, Strapi is an open-source headless CMS that can be self-hosted on HIPAA-eligible or in-scope AWS, Azure, or Google Cloud services, where the relevant cloud provider's BAA covers eligible cloud services or infrastructure. Its RBAC works at the Content-Type and field level, with custom roles built in the Admin Panel. The Enterprise plan includes Audit Logs and SSO, and SSO is also available as a Growth plan add-on. The "Local authentication lock-out" setting forces specified roles to SSO-only login, so the IdP's MFA applies to those editors. Audit log retention defaults to 90 days, which healthcare teams should extend and export to external storage. Strapi holds SOC 2 Type II, and all Strapi Cloud plans list SOC 2 compliance. Confirm BAA terms with Strapi for your plan before PHI touches the environment.
If PHI or residency rules require it, self-host the open-source edition and add the Enterprise plan features the checklist depends on. For content that stays outside the PHI path, start with Strapi Cloud.
