In regulated industries, the deployment model is frequently decided outside the project team. Security, risk and compliance functions set standards on where systems may run, and those standards — rather than an IT cost or staffing preference — often determine the answer before a CMS evaluation begins. In short, regulated industries do not share one deployment answer.
Most content platforms support only one deployment model, which means those requirements have to be worked around rather than met. A platform that supports several gives an organization real options for satisfying them.
This article looks at what drives the deployment decision in financial services, healthcare, government, and manufacturing, and how the three models — vendor-managed cloud, managed deployment in the customer's own cloud, and self-hosting — meet those requirements.
What you'll learn
The three deployment models, who owns the infrastructure and who operates the software
The regulatory requirements that drive the decision in four industries, and which model each usually points to
Common cases where a requirement appears to rule out any form of a cloud but does not if the right cloud offering is available
Which governance, security and certification controls stay the same across all three models
Four costs that are frequently left out of deployment cost comparisons
How the major CMS platforms compare on deployment options.
Where the deployment requirement comes from
In most enterprise software evaluations, the deployment question is answered by IT based on cost, staffing, and existing infrastructure standards. In regulated industries, the decision often sits elsewhere. A security team's standard on which environments critical systems may run in, a compliance boundary already defined and accredited, or a governance review that has to approve any third-party access can each settle the question in advance. These standards are usually the organization's own interpretation of regulation rather than something a regulator specifies directly — which is why two banks under the same rules can reach different answers.
These requirements are specific, and they are documented. An architect evaluating a CMS is generally not expressing a preference when they ask whether the platform can run in the organization's own cloud account. They are checking the platform against a control they are obliged to satisfy.
The difficulty is that the models a platform supports may not include the one an organization needs. Most vendors run a managed cloud service, several still support self-hosting, and some support both — but the option of having the vendor operate the platform inside infrastructure the customer owns is uncommon. When none of the available models matches the requirement, the organization grants a policy exception, adds compensating controls, or leaves the workload where it is.
Where a platform supports more than one deployment model, that trade-off does not arise in the same way. The requirement can be matched directly, and it can be matched at the level of the individual workload rather than for the whole organization at once.
That is the practical argument of this article. Regulated industries do not share one deployment answer. What they share is a method: state the control requirement precisely, then select the model that satisfies it with the least additional overhead. Financial services typically lands in a different place from healthcare, and a single manufacturer can reasonably need two models at the same time.
What changed
Four developments have made these requirements more specific over the last two years.
Data sovereignty is increasingly written into law. The European Commission's proposed Cloud and AI Development Act, published 3 June 2026, defines a four-level sovereignty assurance framework that public bodies select from based on their own risk assessment. Underneath it is a distinction that matters in practice: residency is not the same as jurisdiction. A US-incorporated provider remains subject to the CLOUD Act regardless of where its servers are located, so hosting in an EU region does not by itself resolve a sovereignty requirement.
Concentration risk is now a regulatory obligation. DORA has been in force since 17 January 2025 and requires EU financial entities to assess, document and report concentration on ICT providers. In November 2025 the European Supervisory Authorities published their first list of 19 designated Critical ICT Third-Party Providers, which includes the major hyperscalers. Adding a new provider dependency now has to be documented and justified.
Cloud repatriation figures are frequently misread. The Barclays CIO Survey finding that 86% of CIOs plan to move workloads back is often cited as evidence of a broad move away from public cloud. IDC's research puts the share of organizations repatriating entire workloads at roughly 8%. The two findings are consistent: organizations are reassessing placement workload by workload rather than moving wholesale in either direction.
Sovereign cloud spending is growing quickly, and European buyers are repositioning deliberately. Gartner projects sovereign cloud IaaS spending will reach $80 billion in 2026, an increase of 35.6%, with around 20% of existing workloads moving from global public clouds to local providers. In a survey of 241 Western European CIOs and IT leaders, 61% said geopolitical factors will increase their reliance on local or regional cloud providers, and 53% said geopolitics will restrict their future use of global providers. The shift is directional rather than wholesale — Forrester expects no European enterprise to move entirely off US hyperscalers in 2026. The practical consequence for a CMS is straightforward: when an organization changes where its infrastructure lives, the platform has to be able to go with it. That requires deployment options beyond the vendor's own cloud.
None of this indicates which model a given workload needs. That depends on the specific requirement.
Three models, one platform
The most useful way to distinguish deployment models is by who owns the infrastructure, who operates the software, and who is responsible for producing evidence to an auditor.
dotCMS Cloud | Cloud Anywhere | Self-Hosted | |
|---|---|---|---|
Infrastructure ownership | dotCMS | Customer's AWS, Azure or GCP account | Customer data center or cloud account |
Cloud contract and bill | dotCMS (infrastructure bundled) | Customer, directly with the provider | Customer |
Who operates dotCMS | dotCMS | dotCMS | Customer |
Patching and upgrades | dotCMS | dotCMS | Customer (assisted upgrades available) |
Monitoring | dotCMS, 24/7 | dotCMS, 24/7 | Customer; dotCMS critical-care support |
Uptime SLA | 99.9%+ | 99.9%+ | Customer-defined |
Residency | Customer-selected region | Any provider, any region | Fully customer-controlled |
Network isolation | Standard cloud isolation | Customer VPC, peering, controlled egress | Air-gap possible |
Ops headcount required | None | None | Funded 24/7 platform team |
One row is absent from the table because it does not vary between the models: certifications and the governance model.
dotCMS holds ISO/IEC 42001:2023 for AI management, ISO/IEC 27001:2022, SOC 2 Type II, TX-RAMP Level II and a maintained CAIQ. dotCMS security and compliance documentation states that dotCMS Cloud is one deployment option rather than the only one, and the same certified governance model applies across all of them.
This distinction is worth noting, because for many vendors compliance posture is a property of a specific cloud service. If a customer moves off that service, the posture does not transfer with them.
The underlying system is the same in all three models: the same container image, the same REST and GraphQL APIs, the same administrative interface, the same permission model and the same release line. Stateless application nodes run against PostgreSQL, OpenSearch and a shared file volume, orchestrated with Docker or Helm on Kubernetes, with liveness and readiness probes and a documented five-tier reference architecture. The deployment model determines who operates the platform. It does not change what the platform does.
Cloud Anywhere and DORA. Two obligations are worth separating. For concentration risk, running in the customer's own cloud account means the CMS sits within a provider the organization's assessment already covers rather than introducing a new one; and because dotCMS is not reselling infrastructure, the subcontracting chain that must be disclosed is one layer shorter. For exit planning, the content database, assets, and backups already reside in the customer's tenancy, eliminating the data-return step in most exit plans.
Financial services: usually Cloud Anywhere
The main requirements are DORA concentration and exit obligations, PCI scope, CLOUD Act jurisdiction for EU and UK entities, and — as often as any regulation — an internal policy that critical systems do not run in a third party's tenancy.
These requirements have something in common: they concern tenancy and contractual relationships rather than the software itself. That is why most regulated financial institutions land on Cloud Anywhere. Content runs in the bank's own VPC under the bank's own cloud agreement, so the concentration assessment covers infrastructure the bank has already accounted for, and the bank still carries no operational headcount for the platform.
As an illustration, when one global bank worked through its technical due diligence with dotCMS, its questions covered deployment topology, building the container image from source, horizontal scaling across a shared file volume, and the role and permission model.
Where Cloud fits. A US-domiciled retail bank's brand, campaign and microsite estate — no gated content, no European entity, no regulated customer data — generally has no requirement that a managed cloud fails to meet. It also gains multi-region failover and CDN delivery that the bank would otherwise design and staff itself.
Where self-hosting fits. Relatively rarely, and usually because of an internal platform standard that predates the evaluation rather than a regulatory requirement.
A common scoping error. The public marketing site and the authenticated member portal are frequently scoped as a single system, and the marketing site inherits the portal's controls as a result. Often the better approach is not to relocate the CMS but to author content in it and deliver it headlessly into the secure portal. The content stays in the governed repository and the portal keeps its boundary.
diva-e
Global financial institution achieves 10x performance gains with dotCMS and diva-e
Read the case study →Healthcare: usually Cloud
The regulatory picture is changing. The HIPAA Security Rule NPRM, published 6 January 2025, would remove the distinction between required and addressable safeguards, making encryption, multi-factor authentication, network segmentation and annual business-associate certification mandatory. HHS has moved final action to an anticipated July 2027, so architects are designing against it well ahead of the rule taking effect.
The operative question is narrower than whether an organization is HIPAA compliant overall. It is whether the CMS sits inside the business associate agreement boundary. For most health systems, it does not. Service line pages, location pages, physician biographies, campaigns and news carry no protected health information.
The enforcement record is instructive here. OCR and the FTC sent warning letters to roughly 130 hospital systems and telehealth providers regarding online tracking technologies, and pixel-related settlements have exceeded $100 million, including Advocate Aurora at $12.25M and Mass General Brigham at $18.4M.
None of these enforcement actions involved a hosting failure. They involved governance failures — typically a marketing tag deployed to a scheduling page without review. Moving the CMS into a hospital data center would not have prevented them. Approval workflows, version history, audit trails and controlled publishing would have.
Workflows & Approvals
See content move through review, legal, and compliance approvals with full audit trails.
Where Cloud Anywhere fits. When the CMS genuinely does sit inside the BAA boundary — scheduling flows, symptom checkers, portal content, or directories carrying patient-adjacent data — and the security team wants that boundary inside an environment it has already accredited and monitors.
Where self-hosting fits. Integrated delivery networks with an established platform team and a standing policy that patient-facing systems run inside the hospital network.
Government and public sector: usually Cloud
Federal authorization dominates most discussions of government CMS selection, but for state, county and municipal work it is often not the governing constraint. Several other requirements matter more.
Accessibility is a dated, enforceable mandate. ADA Title II requires conformance to WCAG 2.1 Level AA. In April 2026 the Department of Justice extended the compliance deadlines to 26 April 2027 for entities serving populations of 50,000 or more, and 26 April 2028 for smaller entities and special district governments. The substantive requirements were unchanged. The obligation applies to every page an entity publishes and applies continuously, which favors central template governance, automated scanning within the authoring workflow, and a platform that can be updated without a procurement cycle.
Traffic surges are a common and frequently unstated requirement. Elections, severe weather, public health events and enrollment windows can raise traffic by two orders of magnitude with little notice. CDN delivery and elastic managed infrastructure handle this; infrastructure sized for typical traffic does not.
Staffing capacity is a practical constraint. Public sector IT organizations often cannot recruit and retain staff for 24/7 platform operations. Where that is the case, self-hosting moves operational risk onto a team that is already constrained rather than reducing it.
Governance across departments is the main scale problem. A state agency or mid-sized city typically runs dozens to hundreds of departmental sites. The requirement is delegated authoring within guardrails a central team defines, with consistent permissions, approvals and audit across all of them.
Records obligations are product capabilities rather than hosting capabilities. Version history, audit trails and workflow approvals address retention and public-records requirements identically in all three models.
Where Cloud Anywhere fits. States with in-state or named-provider residency mandates, or agencies standardized on Azure or GCP.
Where self-hosting fits. Where the platform must sit inside an accredited enclave, or where an air-gapped environment is required. Deploying into an environment the agency has already accredited means the CMS operates within that existing authorization rather than needing one of its own — which is a different route to the same assurance than selecting a vendor whose cloud service carries its own federal authorization.
A U.S. Government Agency uses dotCMS to share investigation findings with the public
Read the case study →Manufacturing: often two models at once
The main forcing function is CMMC. The DoD issued its final DFARS rule on 9 September 2025, Phase 1 enforcement began 10 November 2025, and full compliance is required by 10 November 2028. Cloud services handling Controlled Unclassified Information must be FedRAMP Moderate or documented-equivalent. Alongside CMMC sit ITAR and export-control obligations and the ordinary commercial requirement to protect specifications, pricing and design data.
Manufacturing is the clearest case in which one organization needs more than one deployment model.
A global manufacturer typically runs a brand estate, regional sites, and dealer and distributor portals that are commercially sensitive but not regulated. A separate division may run a technical documentation portal that handles CUI under a defense contract. These are different risk tiers. Forcing them into a single deployment model means either applying enclave-level controls to the entire marketing estate at significant cost, or placing the CUI workload in an environment that does not meet its requirement.
The workable pattern is Cloud for the commercial estate and self-hosting inside the enclave for the regulated division: the same platform, content model, authoring skills and governance in both, with controlled push-publishing between environments.
Where Cloud Anywhere fits. Where export-control counsel requires tenancy and egress control but the division cannot staff platform operations.
A global leader in HVAC markets decreases operational costs and increases marketing effectiveness by replatforming multiple brands to dotCMS
Read the case study →What stays the same across all three models
A common assumption in regulated buying is that on-premise deployment is inherently more secure. It is worth examining, because most of the controls a security review evaluates are properties of the product rather than the hosting environment.
The following are identical in all three models:
Identity and access. Separate front-end and back-end user types. System roles for administrators, anonymous visitors, content owners and authenticated site users. Per-object permissions for read, write, publish, edit-permissions, add-children and delete. Hierarchical roles, per-role control over which administrative screens a user can see, and API tokens scoped to roles.
Change control. Version history, workflow approvals, and push-publishing that moves content between environments as a logged, deliberate step rather than an ad-hoc copy.
Auditability. Audit trails across content, users and configuration, independent of where the containers run.
Integration security. SAML and SSO, an encrypted secrets store for integration credentials, and AI features that allow the organization to select the model and keep inference within its own boundary, governed under ISO 42001.
Scale. The same governance applied across tens or hundreds of sites.
Multisite Management
See how teams manage dozens of websites, brands, and regional experiences from a single dotCMS instance.
IDC's guidance to this market is that governance should be treated as non-negotiable: granular roles, approvals, versioning, audit trails, data residency, SSO and SCIM, delivered as configurable platform features rather than services engagements. Self-hosting changes who operates these controls. It does not add controls that the other models lack.
Four costs that are often left out
Deployment cost comparisons frequently account for one line item and present it as a total.
Infrastructure is the line everyone includes. Under Cloud, it is bundled into the subscription. Under Cloud Anywhere it appears on the customer's own cloud bill, which for an enterprise with a large committed-spend agreement is often the largest single difference between the options, and usually in the customer's favor.
Operations headcount is the line most often missing from self-hosted business cases: patching, version upgrades, monitoring, on-call and capacity planning. As CMSWire puts it in its assessment of DXP operational burden, this converts directly into labor — "if routine content changes require engineering support, labor costs increase even if licensing costs are moderate." The questions that surface it are concrete: how many engineers are dedicated to infrastructure management, and how much roadmap capacity is consumed by version transitions.
Compliance and audit labor is the least visible: evidence collection, security questionnaires, penetration test coordination and annual business-associate certification. This cost is lowest when a vendor's certification already covers the operating layer, and highest under self-hosting, where the organization produces every artifact itself.
Exit cost is best budgeted as two separate lines, because only one of them varies with the deployment model. The cost of switching off the software is driven by how much custom template and plugin code exists, and is broadly similar across all three. The cost of an unplanned exit — a vendor failure, a termination, or a regulatory designation — is not. A self-hosted or customer-tenancy deployment continues serving traffic while a migration is planned; a multi-tenant SaaS deployment provides a notice period and a data export.
The point is not that one model is cheapest. It is that the lowest-cost model is frequently not the one that satisfies the requirement, and the objective is to select the model that meets the requirement without adding control the organization does not need and will still have to operate, audit and pay for.
How the market compares on deployment options
Platform | Vendor-managed cloud | Managed in your own cloud account | Self-hosted / on-premise |
|---|---|---|---|
dotCMS | Yes | Yes | Yes |
Adobe AEM | Yes | No | Core support ends Feb 2027; extended to Feb 2028 |
Sitecore | Yes | No | Yes — XM/XP only |
Optimizely | Yes | No | Yes — CMS 12 |
Acquia | Yes | No | No — Drupal core only |
WordPress VIP | Yes | No | No — WordPress core only |
Contentful | Yes | No | No |
Contentstack | Yes | No | No |
Magnolia | Yes | No | Yes |
Sources by platform:
Adobe AEM — release roadmap
Sitecore — XM Cloud · Managed Cloud · Managed Cloud subscriptions (KB0133931) · Managed Cloud Containers
Optimizely — CMS hosting options · deployment learning path
WordPress VIP — infrastructure
Contentful — EU data residency
Contentstack — regions
Magnolia — self-hosted deployment · DX Cloud onboarding
Vendor-managed cloud is universal, and several platforms still support self-hosting. Operating the platform inside infrastructure the customer owns is rarer: among the platforms compared here, dotCMS is the only one that does it. That is the model many of the governance and control requirements call for though, which is why it comes up regularly in regulated evaluations despite being available in few places.
Choosing a model
Work through the following in order. The first match sets the model, and it should be applied per workload rather than once for the whole organization.
Must this workload sit inside an already-accredited or air-gapped boundary? → Self-Hosted.
Must the infrastructure sit in your own tenancy, or in a specific jurisdiction? → Cloud Anywhere.
Does a committed-spend agreement make infrastructure materially cheaper on your own cloud contract? → Cloud Anywhere.
Do you have funded, named 24/7 platform operations you intend to use? → Self-Hosted.
Otherwise → Cloud, which covers the majority of regulated web estates and includes regional failover and CDN delivery.
Two notes on applying it. As the manufacturing example shows, one organization can legitimately arrive at two answers, and that is a sign the estate has been scoped accurately rather than inconsistently. And the sequence should be re-run when the organization's requirement changes, rather than when a vendor changes its supported deployment options.
Bottom line
The constraints described in this article are real ones. A bank's concentration assessment, a health system's BAA boundary, and a county's accessibility deadline and surge traffic all impose genuine limits on where a workload can run.
What does not follow is that any one of them dictates a single hosting model for everything an organization publishes. They apply to specific workloads, and they are satisfied by specific controls — most of which are properties of the platform rather than the data center.
For a compliance-led CMS, supporting three deployment models means the requirement determines the architecture, and that when the requirement changes, the platform can change with it.
If you are evaluating a CMS against control, residency or audit requirements, the useful starting point is the requirements themselves and what the platform has to satisfy.
If you are mapping specific workloads to these models, dotCMS can walk your architects through the reference architecture for each one. Book an architecture review.
FAQ
Deployment Models for Regulated Industries
Generally no. Regulations specify controls and evidence — encryption, access control, auditability, residency, breach notification — and rarely specify hosting topology. The requirements that genuinely require on-premise are narrow: an accredited enclave the workload must sit inside, an air-gap requirement, or an internal policy that predates the evaluation.
Yes. That is Cloud Anywhere: the infrastructure is the customer's, contracted directly with their cloud provider, and dotCMS operates the platform inside it with 24/7 monitoring, patching and upgrades.
In the region you select. dotCMS operates in multiple regions across North America, Europe and Asia-Pacific and is not limited to the current footprint; where a customer requires a region we do not yet operate in, we stand one up.
dotCMS holds ISO/IEC 27001:2022 for information security management, ISO/IEC 42001:2023 for AI management, SOC 2 Type II, and TX-RAMP Level II, and maintains a CAIQ through the Cloud Security Alliance. The same certified governance model applies across all three deployment models. Current certifications, audit reports and supporting documentation are available in the dotCMS Trust Center.
It changes who operates the controls rather than how many controls exist. The access model, audit trail, approval workflows, versioning and secrets handling are identical across all three models. Self-hosting adds control over the infrastructure layer, along with the responsibility to patch, monitor and produce audit evidence for it.
Yes. All three use the same container image, content model and APIs, so a change of model is an infrastructure migration rather than a replatform.