How to Choose a Secure CMS Platform for Regulated Organizations

CMS vendors will claim their product is a secure content management system, and their marketing team might try to claim it’s the most secure CMS. Those claims are difficult to apply to the security needs of regulated organizations because they rarely map to regulatory expectations.

To understand just how secure a particular CMS platform is relative to competitors requires examining each through a common lens. Figure out who is accountable for each security control, what each security credential demonstrates, and what was reviewed before the platform made it on an approved list. If you are choosing a free platform for a small site, this guide isn’t meant for you.

What is the most secure CMS?

The “most secure CMS” is as fictional as a unicorn. Security is established through a combination of how a platform is run, accountability for each security control, and the verifications made during an independent audit. The same software might pass a federal security review in one vendor configuration and fail an internal audit in another.

Instead of asking if a platform is the most secure, look at how you plan to run it, who is responsible for each security control, and how to demonstrate security to an auditor. Security audits don’t fail because the platform was missing a feature. They fail because ownership isn’t proven or because a credential didn’t apply to the system being audited.

A clear understanding of what your vendor is responsible for and where each credential they hold applies, combined with a common set of questions to ask each vendor, gives you an accurate answer to that question.

Who is accountable for what: the responsibility line

Responsibility for security starts with where your CMS is deployed. Running the software in-house means security is owned by your internal teams. Managed platforms provide a clear set of responsibilities and attest to them. An authorized platform takes that a step further and has security controls verified by an independent assessor.

• Self-run software is a CMS installed on in-house infrastructure or rented from a cloud provider like AWS or Azure. As the name suggests, your team is accountable for everything. The software might have great security features, but how you configure, monitor, and maintain the hosting environment, operating system, software patches, plugins, extensions, and backups determines the overall security level. You still need independent verification if certification is required.
• Managed platforms are offered by vendors that take on a significant portion of security. A SOC 2 report helps your security team understand precisely where the platform’s responsibility starts and ends, with ownership of specific security controls spelled out in a responsibility matrix. Your organization is almost always responsible for how the CMS is configured for your use case, the content you publish, and the decisions around which users have access and the extent of that access.
• An authorized platform relies on an independent assessor to evaluate a managed platform’s controls against a government framework like FedRAMP, with an authorizing body choosing to accept the results (or not). The authorization is limited to the systems, services, and data flows included in the assessment. Anything outside those boundaries remains your responsibility.

The documented authorization boundary and a responsibility matrix provide a clear picture of enterprise CMS security. When a vendor can’t produce either of those documents, be wary of the state of their security operations.

What each security credential actually proves

Security credentials are a combination of what was assessed and who signed off. SOC 2 reports describe security controls. ISO 27001 certifies an organization’s security approach. FedRAMP, GovRAMP, and TX-RAMP authorize cloud services within defined boundaries for different levels of government. HIPAA and GDPR are laws with obligations.

• SOC 2: Organizations are evaluated against AICPA Trust Services Criteria to produce a SOC 2 report. A SOC 2 Type 1 report assesses whether controls were suitably designed at a single point in time. SOC 2 Type 2 reports test whether controls operated over a period that is typically six to twelve months in length. Reports always cover security and may extend to cover processing integrity, confidentiality, and/or privacy in combination with the systems that were evaluated.
• ISO 27001: This standard examines how an organization identifies and manages risk, without evaluating the security of any specific product. It certifies that an organization runs an information security management system that meets the standard. Read the certificate’s scope statement to see which parts of a vendor’s business units, locations, and services were assessed.
• FedRAMP, GovRAMP, and TX-RAMP: Each is a cloud service authorization at a defined impact level. FedRAMP is for U.S. federal agencies, GovRAMP is for state and local governments, and TX-RAMP covers Texas state agencies and public universities. The authorization is limited to anything inside the service’s authorization boundary. This FedRAMP guide explains how that process works.
• HIPAA and GDPR: Both are laws that work through obligations and agreements. There is no HIPAA certification program. When a vendor states they are “HIPAA compliant,” it means they will sign a business associate agreement and promise to maintain the Security Rule’s safeguards. GDPR certifications do exist, but “GDPR compliant” generally means a vendor has a data processing agreement and the required security controls to support it.

Look at the scope of a certification when evaluating vendor claims. Vendors frequently commingle data center credentials with platform credentials. The SOC 2 Type 2 report for a data center covers physical and infrastructure controls, without telling you anything about application security. When you are reviewing credentials as part of a vendor evaluation, be sure to ask about what the credential covers.

What CMS has built-in hosting and security?

Managed platforms take on a defined share of security responsibilities. They are the very definition of “built-in” because they cover hosting, patching, extension review, monitoring, and support. Self-run software requires your team to configure and maintain all aspects of security, regardless of what the feature list says.

Platforms with built-in hosting and security include managed platforms that use open source software like WordPress or Drupal, as well as software-as-a-service CMS products, including headless vendors. “Built-in” in these instances means the vendor hosts the software and takes contractual responsibility for running it securely. 

Some vendors host the software and leave extension review, software patches, and monitoring to you. Those are hosting relationships where security remains your responsibility. 

The Ford Foundation faced this choice when its previous CMS neared end-of-life and would stop receiving security updates. It moved to the WordPress VIP managed platform, which made it easy to get its security team on board.

You can tell the difference between platforms with built-in hosting and security by checking:

• The authorization list: Which credentials does the platform hold, at what level, and with what scope?
• The responsibility matrix: Where does vendor responsibility end and your responsibility begin?
• What the platform allows to run: Are custom code and extensions reviewed prior to deployment, and if so, who reviews them?

Security is one of many criteria for choosing a CMS, see additional criteria in this guide on how to choose an enterprise CMS.

Is WordPress secure enough for a regulated organization?

With proper configuration and management, WordPress can meet any of the compliance requirements and authorizations discussed here. The open source WordPress core has a dedicated security team and a reliable patch cycle. 

Themes and plugins are the primary source for most reported WordPress vulnerabilities. The security of a given WordPress install depends on who runs the platform and which plugins and customizations they allow.

WordPress core is maintained by a security team that coordinates disclosure and ships security releases, often as automatic background updates. Because 43% of websites run WordPress, WordPress security receives attention from a large population of site administrators, resulting in detailed security documentation and near-immediate patching.

The more than 60,000 available plugins offer plenty of choice, but they also increase the potential for new attack vectors without careful review. Some plugins are written securely, and others have very loose security standards. Plugin and code review prior to inclusion in a site have a big impact on whether a specific WordPress deployment remains secure.

Each unique deployment is the determining factor in whether WordPress is secure. Self-hosted WordPress makes every security decision your responsibility. A managed enterprise WordPress platform reviews and restricts the code that runs, patches core for you, and may hold government authorizations that validate security. 

WordPress VIP, for example, holds FedRAMP Moderate, GovRAMP Moderate, TX-RAMP Level 2, and SOC 2 Type 2 on the platform, which runs in SOC 2 Type 2 data centers.

For practices that apply to any deployment, see enterprise WordPress security best practices.

Security requirements by regulated sector

Public Sector (Federal, State, and Local): A CMS used in federal content workflows requires FedRAMP authorization aligned to the system’s impact level (typically Moderate if user accounts or other PII are involved). That authorization is part of the reason WhiteHouse.gov, NASA, and the Veterans Administration use WordPress VIP as their platform for delivering content to the public. 

GovRAMP is becoming a standard part of state and local procurement, alongside state-specific mandates like TX-RAMP in Texas. Public websites also need to meet Section 508 accessibility requirements and WCAG accessibility guidelines, which makes accessibility part of any platform evaluation. See also: WordPress VIP for government and public sector.

Healthcare: When protected health information (PHI) is created, stored, or transmitted, HIPAA applies. Unless your CMS is specifically being used to build a patient portal, it’s better to keep PHI out of it. Many healthcare websites isolate patient-intake workflows for exactly this reason. If the CMS frontends customer intake, allowing customers to enter PHI in form fields, even if that data only passes through in transit, the CMS vendor will need to sign a business associate agreement.

Financial services providers: The financial sector has strict regulations about what needs to be disclosed and how information like loan rates is shared. Auditors expect verifiable logs that disclose each step of the publishing process from the first approval through the publish event that makes content live. Forcing regulatory disclosures or APR tables to publish through a role-gated approval process helps avoid making the platform a liability. Financial companies are also popular targets for bad actors, so a SOC 2 Type 2 report is a standard expectation when evaluating a CMS.

Public education and research: FERPA governs student records, which are almost never stored in a CMS. The primary risk is when the CMS acts as a frontend for information gathering activities like admissions forms input, where improper configuration can lead to student PII getting stored in the backend. Like state agencies, public universities in Texas require TX-RAMP authorization for cloud services. University research institutions may be required to adopt security compliance standards as a condition of receiving federal grants or contracts.

Ten questions a security reviewer should ask a CMS vendor

A set of questions relates back to each of the topics covered in this guide. As you evaluate vendors, use the same set of questions so that you can make an apples-to-apples comparison of the answers you get back in response.

1. Which security credentials does your company hold, and where do the boundaries of those credentials start and end? Include any distinction between infrastructure and application credentials.
2. At a per-control level, who is responsible for what in your responsibility matrix?
3. Are you responsible for patching the CMS core, and how soon is it patched following a new security release?
4. How do you police the extensions and plugins allowed on the platform? What dependency scanning and approval workflows are required before third-party code or community-created modules are allowed in a production environment?
5. Can roles and permissions be defined to restrict access? Is it possible to enforce SAML/SSO with mandatory MFA at our identity provider?
6. Are audit logs tamper-proof and exportable via API? Can we stream logs directly into an SIEM like Splunk or Datadog, or are they locked in a proprietary admin interface?
7. What is your contractual incident notification timeline? If your platform suffers a breach or exposure, do we get notified within a fixed time period (24-48 hours, for example), or does your contract rely on vague “reasonable effort” language?
8. Where do you store our data, how often do you back it up, and what’s the test plan to make sure restores succeed? Can you guarantee data residency within our required jurisdiction?
9. Can we review an unredacted summary of your latest third-party penetration test? When was the most recent test completed, who conducted it, and have all high-severity findings been resolved?
10. What does the offboarding process look like when the contract ends? How is our data returned, and what is your process for wiping backups, media assets, and database snapshots from your infrastructure?

Choosing the platform your security team can approve

The right enterprise CMS for regulated industries is security team-approved and auditor-verified. Start by establishing who is responsible for what, down to the level of each individual security control. Review vendor credentials for both what the credential demonstrates and the scope it covers, then use the 10 questions above to evaluate each vendor.

To see how WordPress VIP divides that responsibility and what’s covered by its credentials, review our security, compliance, and governance capabilities. When you’re ready to walk through it with your security team, request a demo.

Frequently Asked Questions