Open source CMS for financial services

Open source CMS for financial services: why rates, disclosures and patch windows change the build

A bank or insurer editor and a compliance reviewer should be able to share one publishing path for rate tables, product disclosures and fee notices, and the CMS matters less to that goal than the review workflow, audit trail, change control and hosting boundary wrapped around it. In practice, the platform has to show who drafted a rate change, who approved it, what the published version said on a given date and which environment served it. Before comparing products, ask your compliance and legal teams to write down the states required for a rate or disclosure to go live, the roles allowed to move content between them, and the retention period for prior versions. Those answers define the build more than any feature list does. For regulated public content, Drupal is usually the stronger fit when the estate is large, the review states need to be configured per section and the site must integrate with identity, search and document systems. Its revision history, moderation workflows and role model can be shaped around a compliance step, although the workflow modules and configuration still need to be designed and tested. A headless option such as Strapi, Payload or Directus can serve rate and disclosure content to several front ends, but the review UI, approval logic and publication log then become part of what you build and support. Drupal and WordPress carry no license fee, so the cost sits in design and build, hosting, security updates and support, which should be quoted line by line.

Patch windows are where many financial services web estates fall behind. Drupal publishes bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, according to its core release schedule, so your change calendar and the vendor's cadence need to match before go-live. Drupal 10 reaches end of life on December 9, 2026, so any estate still on it should have a dated migration plan in place. Confirm with your implementation partner how a security release is tested in a staging copy that mirrors the production rate and disclosure pages, who signs off the change, and how the rollback is recorded for your audit file. The hosting boundary matters as much as the CMS. If rate and disclosure pages sit alongside logged-in customer areas or application forms, the environment that handles cardholder data or customer identifiers falls under PCI DSS scope, and the assessor will ask how that boundary is documented. Editor access should run through your corporate identity provider, which the contributed SAML Authentication module supports for Drupal sites, with multi-factor authentication enforced at that provider. Ask your partner to map each editor role to a named approval step and to show you the logs that prove it.

Which requirements shape a financial services CMS build

This table maps the regulatory and contractual requirements most likely to reach a bank or insurer website build to the build decisions they force. Read each row as a question to answer before design starts, with the source named so your compliance team can confirm scope. Where a requirement does not apply to your entity or content, the build decision can usually be simplified, so confirm applicability first.

Requirement	Source	What it means for the build
Payment pages and cardholder data in scope	PCI DSS v4.0.1, applicable to entities that store, process or transmit cardholder data or could affect that environment	Any page that collects card data, loads payment scripts or shares infrastructure with payment flows may bring the CMS and its hosts into scope. Keep card capture in a separate, validated service where possible and document which CMS components could affect it.
Future-dated v4.x requirements now active	PCI DSS v4.0.1, with the 51 future-dated v4.0 requirements effective since 31 March 2025	Script inventories, change control and access reviews must already be operating. Retrofitting them after launch is a common gap, so define the evidence set during build.
Register of ICT contractual arrangements	DORA Article 28(3), for EU financial entities	Every open-source component is paid for through an arrangement that must be registered, including hosting, CDN, implementation partner and support. Record the CMS, its extensions and each service provider as separate entries.
Exit strategies and transition plans	DORA Article 28(8), for ICT services supporting critical or important functions	Document how the site content, templates, redirects and editor data move to another host or platform. Choose a CMS with exportable content models and avoid proprietary lock-in in themes and plugins.
Contract terms on location, change notice and data return	DORA Article 30(2), for ICT services contracts	Hosting and support contracts should state where services run and data is processed, require notice of changes and cover data return on termination. Confirm these terms with each provider before signing.
Internal control over financial reporting	SEC Release 33-8810, citing program changes, computer operations and access to programs and data as IT general control areas	If the website publishes financial statements, rates or disclosures covered by SOX Section 404, treat the CMS as an in-scope system. Build change approval, publishing logs and privileged access reviews to match these control areas.
Multi-factor authentication for non-bank editors	FTC Safeguards Rule, 16 CFR 314.4(c)(5), for non-bank financial institutions under FTC jurisdiction	Every editor and administrator account needs MFA unless the Qualified Individual approves an equivalent control in writing. Plan editor SSO with MFA enforced at the identity provider, and record any written exception.
Accessibility deadlines for public entities	US DOJ ADA Title II rule, WCAG 2.1 Level AA, with compliance dates of April 26, 2027 and April 26, 2028	Applies where a public entity is involved, such as a state-owned bank, public pension or municipal insurer. Entities with 50,000 or more people face the earlier date, so confirm which date applies to your organization.

How compliance review workflows and audit trails work on a self-hosted CMS

Every rate or disclosure change should carry a named author, a second-line reviewer, an explicit state and a record of who changed what and when. The state model usually runs draft, review, approved and published, with the rule that the author cannot approve their own change and that only the reviewer's approval can move content to published. Those four states are a starting design, not a standard the CMS provides out of the box, so the first deliverable of any build is a written content lifecycle that compliance, legal and product owners sign off before anyone configures a role.

On Drupal, the core revision history records each saved version with its author and timestamp, which gives a baseline audit trail for published content. Workflow behavior beyond that depends on configuration: the core Content Moderation module with a custom workflow, or a custom approval step built into the content type, can enforce the states and restrict who may publish. Confirm each capability in your own environment rather than assuming it. Test that an editor cannot publish a rate page directly, that a reviewer's approval is attributable, that a rolled-back revision still leaves its original entry in the log, and that deleted content can be traced. Document the roles, moderation states, permission matrix and log retention period as configuration under change control, then re-run those tests after every Drupal core or module update, because the security release cadence described in the Drupal core release schedule means configuration is touched often.

Audit logs need their own decisions. Confirm whether the site writes authentication and administrative events to a central log platform, how long those logs are retained, and whether they are protected from editors who can change content. Ask your partner to show, in a test environment, how a specific disclosure change can be reconstructed from the revision history and the log store together, and who in your organization is named to answer an examiner's question about it. Those answers feed directly into the change-management evidence your internal audit and IT general control testing will ask for.

Which open source CMS platforms fit a bank or insurer website

Financial services teams usually narrow the field to one platform for the public site and one for editorial delivery. The cards below compare the options on license terms, release discipline, identity integration and the open items to confirm before a compliance review signs off.

Drupal 11 for regulated publishing

Drupal core is licensed under GPL-2.0-or-later and has no paid edition, so the licensing cost is zero and the budget goes to design, build, hosting and support. Drupal 11.4.10 was released on October 14, 2026, and Drupal 11 requires PHP 8.3 or later. For editor sign-in, the contributed SAML Authentication module and OpenID Connect module let the site federate with the bank's identity provider. Confirm that each contributed module used has a stable release for your Drupal version and a named maintainer who responds to security issues.

WordPress patch windows

WordPress 7.1.3 was released on October 6, 2026, and WordPress.org maintains only the most recent release in the 7.1 series. That means your patch window must follow each new point release, not a fixed quarterly cycle, or the estate falls out of support. Most bank and insurer WordPress sites depend on third-party plugins, so the risk sits in the plugin inventory. Confirm plugin review for each extension, a staging test path for every update, and whether your hosting provider can apply minor releases within your change control window.

Strapi or Payload for headless delivery

A headless CMS separates content authoring from the public front end, which suits rate tables, disclosures and product pages that must render identically across channels. Strapi v5.58.0 is MIT licensed except components under ee directories, which belong to the separately licensed Enterprise Edition. Payload v3.91.0 is MIT licensed and runs as a Next.js framework. Confirm which Strapi features your design depends on are Enterprise Edition code, and confirm the audit logging and role model against your own control requirements before you commit.

Directus under its own license

Directus is licensed under the Monospace Sustainable Core License 1.0 (MSCL-1.0-GPL). The license permits use for any purpose other than a competing use, and it explicitly includes internal use and professional services to deploy or host the software for a licensee. Legal review should confirm that the license terms match the bank's procurement and open source policy before Directus is shortlisted. Directus v12.5.0 was published on October 7, 2026, so confirm the version your team will pin and how security fixes are delivered for it.

Commerce and learning platforms are out of scope

This page covers public web content, rate and disclosure publishing, and editor access. Commerce storefronts and learning platforms carry different payment, data and hosting obligations and are covered on their own pages. If your site takes card payments or enrolls customers in courses, scope those functions separately so that the cardholder data environment is defined before the CMS architecture is set. Confirm with your QSA or compliance lead which systems sit inside that boundary.

Deployment patterns for a regulated bank or insurer website

A single Drupal site runs in the bank's or insurer's own cloud account, with the web tier, database, file storage and backups all inside accounts the institution controls. The trust boundary is the account perimeter, so network controls, key management and logging are set by the institution's security team and audited on their terms. Editors sign in through the corporate identity provider, usually with the contributed SAML Authentication module (samlauth) or the OpenID Connect module, so the login sits at the Drupal edge while the identity provider remains the system of record.

Login path: SAML or OpenID Connect redirects go to the corporate identity provider, and Drupal creates or maps accounts on first sign-in. Confirm which roles are mapped from claims and who approves changes.
DORA data location: Article 30(2) expects the contract to state where services are provided and data processed. Name the account region and any backup or log destinations in the contract schedule.
Vendor and hosting contracts: Each hosting, support or managed service provider appears in the register of information under Article 28(3). Record which party operates the account.
Embedded payment or application forms: Forms hosted in the same account keep submissions inside the trust boundary, but any third-party payment script or form widget adds a processor that must be scoped for PCI DSS.
Exit planning: Keep infrastructure as code and database exports so the institution can move the site without a rebuild, as Article 28(8) expects for critical or important functions.

Before committing, confirm with your cloud and compliance teams where logs, backups and support access terminate, and who holds the keys.

Rollout phases for replacing a proprietary DXP

This sequence moves a bank or insurer from a proprietary digital experience platform to a self-hosted open-source CMS in controlled stages, with each phase producing evidence that compliance, security and business owners can review before the next phase starts.

Inventory content, rate tables and owners
Catalog every site, section, template, rate or disclosure table, form, integration and editor account on the current DXP, and name an accountable owner for each item. Include legal, product, pricing and compliance reviewers, not only web teams. Classify content by risk, such as rate and disclosure content that carries regulatory wording. Done means the inventory is signed off by the business owners and each high-risk item has a named approver and a source system of record.
Map controls to PCI DSS, DORA and SEC ITGC areas
Map each in-scope system and data flow to the control requirements that apply to it. For cardholder-adjacent flows, confirm with your QSA which PCI DSS v4.0.1 requirements the new CMS and its hosting boundary touch. For DORA, record the ICT service in the register of information and confirm the contract terms on data location, exit and data return. For SEC IT general control areas, identify program change, computer operations and access controls the CMS will affect. Done means a control map exists that your compliance and internal audit teams have accepted as the basis for design.
Design the target architecture and workflow
Define the content model, approval states, publishing permissions, audit logging, separation between authoring and public delivery, and the rate-table data path. Confirm how editor identity will federate with your workforce identity provider, and whether your chosen CMS module supports the SAML or OpenID Connect pattern you require. Done means an architecture decision record and workflow specification are approved, including which capabilities are native, which are configured and which are custom.
Build the fixed-scope platform with workflow and SSO
Under a written fixed-scope agreement, the implementation partner builds the templates, approval workflow, roles, single sign-on, logging, rate and disclosure components, and hardening baseline in your environment. Your internal team reviews builds at agreed checkpoints, and security testing runs against the staging environment before any content migrates. Done means the acceptance criteria in the statement of work are met, test evidence is filed, and the change record for production is complete.
Run parallel publishing and test redirects and rate tables
Operate the old and new platforms in parallel for a defined period you set in your own plan. Compare published output for rate tables, disclosures and legal footers, verify that every redirect resolves to the intended target, and confirm that scheduled publishing and expiry dates behave correctly. Record discrepancies in a defect log with owners and closure evidence. Done means the defect log shows no open high-risk item and business owners have signed the cutover readiness review.
Execute cutover with rollback criteria
Schedule the cutover window with change management approval, freeze content changes during the switch, and run a post-cutover verification of key pages, forms, authentication and rate publication. Document rollback criteria in advance and keep the old platform available for read-only reference until your retirement decision is made. Ask your partner to confirm exit and data return steps as part of this phase. Done means verification checklists are complete, the change is closed, and the retirement plan for the proprietary DXP is approved.
Operate patching and evidence collection
Set a recurring cycle for CMS core, module and dependency updates, security testing and access reviews, and keep each release's approval, test and deployment records in an evidence store your auditors can access. Track the vendor's supported release lines so that patches are applied within the windows your policy sets. Done means the first full cycle of patches, access recertifications and audit log reviews is recorded and reviewed by the control owners.

Evidence auditors and regulators ask for from a CMS

This table maps each piece of evidence that bank and insurer reviewers commonly request to what it shows and the CMS component that produces it. Read it as a checklist to agree with auditors early, since DeployOpen prepares this evidence but independent auditors and certification bodies form any opinion on it.

Evidence item	What it shows	Which component produces it
Change record and approver for each published rate	Who changed a rate or disclosure, what changed, when, and who approved it before publication	CMS revision history combined with the approval workflow and a ticketing or change system
Role matrix and access reviews	Which editor roles can publish to which sections, and evidence that access was reviewed on a set schedule	CMS role and permission configuration exported on a schedule, plus signed review records
SSO configuration and MFA evidence	That editor sign-in goes through the corporate identity provider and that multi-factor authentication applies	SAML or OpenID Connect settings in the CMS and the identity provider's MFA policy and logs
Register and exit plan entries under DORA	That the CMS vendor and hosting providers are listed, and that an exit and transition plan exists for functions supporting critical services	Contract and ICT service register maintained by the bank, with the open-source CMS entry and documented exit steps
Patch records against Drupal security release dates	That security releases were applied within the bank's own patch window after upstream release	Deployment logs, staging test sign-off and upgrade tickets tied to Drupal security advisory dates
Restore test log	That backups of the CMS database and files can be restored and the site works afterward	Backup tooling reports and dated restore test records from a non-production environment
Logging of administrative changes	Who changed site configuration, modules or the theme, and when, outside normal content edits	CMS audit log, web server logs and infrastructure logging forwarded to a central store

Questions financial services teams ask before hiring a CMS partner

What drives the build cost of an open source CMS for a bank or insurer?

The build cost is driven by scope, not by a software license, because Drupal and WordPress core carry no license fee. Cost comes from design and build work, content model and workflow design, integration with your identity and content systems, accessibility testing, migration from the existing platform, hosting, and the ongoing security and support work. Ask the partner to price each component separately in a written scope, so you can see which items are one-time and which recur, such as hosting, patching, monitoring and retainer support. The Drupal licensing page confirms that Drupal is GPL-2.0-or-later with no paid edition, so any license line in a quote should be questioned.

How long does it take to replace a proprietary DXP with open source?

The timeline depends on scope and must be agreed in writing before work starts. The main variables are the number of sites and languages, the volume of content to migrate, how many rate and disclosure pages need reviewed templates, the number of integrations with existing systems, and how many approval workflows you need to reproduce. Run a content inventory and an integration inventory first, because those two inputs usually determine the schedule. Ask the partner to show phases, exit criteria for each phase and the parallel-run period in the proposal, rather than a single end date.

What does the bank's team have to provide during a CMS project?

A CMS project needs named people from the business and from IT, and their time is usually the constraint that sets the schedule. Typical roles include content owners for each product or rate area, reviewers from compliance and legal who approve disclosures, an identity administrator who can configure SSO and manage group mappings, a security contact who signs off on hosting and patching, and change board time for production releases. Ask the partner to list every role, the hours each role is expected to give per week, and the decision dates that depend on them. Confirm these commitments with your own governance before signing.

Can our internal team run an open source CMS without the partner after launch?

Some internal teams can run it, but the answer depends on the skills you already have and on how much of the platform you are prepared to own. Running it well requires people who can apply security releases, maintain custom modules and themes, administer hosting, and support editors. Ask the partner for a handover plan with documented runbooks, role-based training for editors and administrators, and a clear split of responsibilities between your staff and any retainer. DeployOpen provides ongoing support, upgrades and continuous testing as retainers, and these can be scoped to cover only the parts you do not want to staff internally.

Does Drupal 10 end of life on December 9, 2026 affect a new build?

A new build should not start on Drupal 10, because the Drupal core release schedule states that Drupal 10 reaches end of life on December 9, 2026. Drupal 11 is the current major version, and Drupal 12 is scheduled for the week of December 7, 2026. Ask the partner which major version the build targets, how the upgrade path to the next major version will be handled, and how contributed modules will be checked for compatibility. Also confirm the PHP version requirements for the chosen Drupal version, since the Drupal.org PHP requirements page sets different minimums for each major release.

How are security patching windows set against the Drupal release cycle?

Patching windows are set by a written policy that matches the Drupal release cycle, not by ad hoc decisions. The Drupal core release schedule says bugfix releases come out on the first Wednesday of each month and security releases on the third Wednesday, so your change board needs a standing window that can absorb both. Ask the partner to describe how a security release is tested on staging, how emergency releases are handled outside the normal window, how contributed modules are included, and how your change board approves each deployment. Your own risk team should set the maximum time allowed between a security release and production deployment.

What can a CMS partner certify, and what can it not certify?

A partner can prepare systems, controls and evidence for an assessment, but it cannot issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those roles. For PCI DSS, the Council does not enforce compliance, and assessments are documented as a Report on Compliance by a Qualified Security Assessor or a Self-Assessment Questionnaire with an Attestation of Compliance. Ask the partner which evidence it will produce, such as access reviews, change records, patch logs and configuration baselines, and which assessor or certification body will review it. DeployOpen prepares systems, controls and evidence for compliance assessments, and it does not issue audit reports or attestations.

What to ask an implementation partner before signing

Start by asking the partner to show, in writing, how each control in the build maps to the evidence you will need. Ask for a control mapping matrix that links Drupal configuration, hosting settings and operating procedures to the DORA requirements you are subject to, the PCI DSS requirements if cardholder data touches the site, and the IT general control areas named in SEC Release 33-8810 for your ICFR assessment. Ask who maintains that matrix after go-live and how often it is re-checked. For the ICT register under DORA Article 28(3), ask what the partner will supply: service descriptions, sub-processors, hosting locations and contract identifiers. For the exit strategy under Article 28(8), ask for a documented export of site content, configuration and editor accounts that you can run without the partner present, and ask when it was last tested. Next, ask how SSO and MFA are tested rather than assumed. Request the test cases for the SAML or OpenID Connect integration, including account creation on first sign-in, deprovisioning when an editor leaves, and what happens when the identity provider is unavailable. Confirm whether the partner will verify the MFA path against your Safeguards Rule and identity policy. Ask how audit logs for editor actions and publishing events are retained, where they are exported, and in what format your SIEM can ingest them. Ask how the partner patches Drupal core and contributed modules within your change calendar, how it handles out-of-band security releases, and what it does when a patch must wait for a freeze window. Ask who is named for incident response, with a direct escalation path and a stated response expectation written into the contract. Finally, request a written, fixed scope that lists deliverables, environments, excluded items and acceptance criteria before any work begins. Ask the partner to sign data location terms that state which countries host the site, the database, backups and form submissions, and that name every sub-processor and advance-notice period for changes, in the form DORA Article 30(2) expects. Ask whether the contract covers return of data on termination or insolvency of the provider. Confirm these terms with your legal and third-party risk teams before procurement, not after the first release.

How DeployOpen scopes, builds and supports this function for financial services

The sequence moves a bank or insurer from a written scope of published-content workflows, controls and integrations to a hardened, documented CMS that the institution's own team can run and that produces evidence for its compliance assessments.

Confirm scope and regulatory boundary
DeployOpen works with your compliance, legal, digital and security leads to define which sites, brands, product pages, rate and disclosure content, and forms are in scope, and which systems they touch. The team records whether any page handles cardholder data or feeds a payment flow, since that determines whether the cardholder data environment and PCI DSS v4.0.1 requirements apply. The output is a written scope document that names each system, data flow and responsible owner before any build work starts.
Map controls, evidence and vendor obligations
The team maps review workflow, editor access, patching, logging and backup requirements to the controls your auditors and assessors will test, including IT general control areas and multi-factor authentication expectations where they apply. Contract terms for the hosting provider and any third-party ICT services are reviewed against the register of information and data location duties your regulator expects. The output is a control matrix that lists each requirement, the configuration or procedure that meets it, and the evidence that will be retained.
Design architecture and integrations
DeployOpen designs the hosting boundary inside your own cloud accounts, data center or private network, along with the editorial workflow states, the approval routing for rate and disclosure content, and the connections to identity, analytics, consent tooling and any core banking or product data sources. Each connection is documented with its data fields, direction and owner. The output is a reference architecture and integration specification that your security architects can review and sign off.
Build, configure and harden the platform
The engineering team installs the chosen open-source CMS, configures roles, editorial states, audit logging and single sign-on through your identity provider, and applies a hardening baseline covering the server, database, content delivery and administrative interfaces. Custom workflow and disclosure components are built with automated tests. The output is a hardened build with a configuration record, a test report and a list of any deviations approved in writing by your security owner.
Test security and accessibility before launch
DeployOpen runs application and infrastructure security testing against the build, reviews findings with your team, and tests the editorial and publishing workflows for access control and audit trail completeness. Accessibility checks are run against the site templates and forms, since financial sites face consumer-facing conformance expectations. Findings are fixed, retested and logged. The output is a signed test summary, a remediation log and a record of any accepted residual risk.
Deliver documentation, runbooks and handover
The team writes the operating documentation: architecture records, access procedures, change and release process, backup and restore steps, incident contacts and the patching procedure for security releases. Your staff are trained on the workflows they will run. The output is a handover pack and a recorded walkthrough, with a list of open items your team owns after go-live.
Support, patch and retest on an agreed cadence
After launch, the platform moves to an ongoing support model. Optional retainers cover security patch application, upgrades, backup verification and periodic security testing, so your change records stay current. DeployOpen does not issue audit reports or certifications. Your internal audit, independent assessors and certification bodies evaluate the evidence this sequence produces. The output is a maintained evidence set and a recurring patch and test log that your assessors can review.

Open source CMS for financial services