Why editorial governance is the main requirement for enterprise CMS
For most large organizations, editorial governance, not page building, decides the CMS choice. When dozens of editors publish across many sections and sites, the hard questions are who may change which section, who approved a page before it went live, and whether you can prove that later. Drupal and WordPress can both meet these needs, but by different routes. Drupal typically reaches them through its content moderation and workflow capabilities, role-based permissions scoped by content type and section, and configurable revision handling, usually with contributed modules layered on top. WordPress typically reaches them through its roles and capabilities model plus editorial workflow plugins, and the choice of plugin, and how well it fits your approval chain, carries more of the weight. Confirm each route against the exact versions you plan to run, because module and plugin behavior changes between releases.
Neither core carries a license fee. Drupal is released under GPL-2.0-or-later, and WordPress is released under the GPLv2 or later, so the money goes to configuration, workflow design, testing and maintenance. Start by writing down your states (draft, legal review, brand review, published, archived), the roles that move content between them, and the section-level permissions each role needs. Then decide how scheduled publishing, content owners and review dates will be recorded and reported. These design decisions are one-time work, but the permission model and plugin set recur as costs because every upgrade, new site or new editor group must be tested against them.
Ask any implementation partner to demonstrate the approval chain on a copy of your own content types, not on a demo site. Ask who maintains each workflow module or plugin, how it is upgraded alongside core, and what happens to pending approvals during a migration. A governance design that cannot survive a core upgrade will cost more over its life than the initial build suggests.
Which governance requirements apply to a multi-site editorial estate
This table lists the governance requirements a large editorial team usually needs, the source that creates each need, and what it means for the build. Read it as a checklist: confirm the source for each row with your legal, accessibility and content owners before you write the requirement into a scope.
| Requirement | Source of the need | What it means for the build |
|---|---|---|
| Moderation states (draft, in review, approved, published, archived) | Internal editorial policy; sector review duties where content carries regulatory or medical accuracy risk | Define each state, who can move content between states, and which states are visible on the live site. Confirm the exact state names and transitions with your content owners before configuration. |
| Roles and permissions per section | Internal policy on who owns which section; WCAG 2.1 Level AA conformance under the ADA Title II rule for public entities | Map roles to site sections and sites, not only to the whole estate. Test that a section editor cannot publish or alter pages outside their section, and document the matrix. |
| Scheduled publishing | Internal policy for launches, campaigns and time-limited notices; sector rules on when disclosures must go live | Confirm the scheduling behavior of your chosen CMS, including time zones and what happens to a scheduled page that fails review. Test publish and unpublish on each site. |
| Revision history and rollback | Internal audit needs; evidence for accessibility remediation and incident review | Set retention rules for revisions, since keeping every revision has storage and privacy implications. Confirm who can view and restore older revisions. |
| Content ownership and owner assignment | Internal policy; accountability for accuracy on public pages | Require a named owner on every page or content type. Build an owner field and a report of pages without an owner, so orphaned content is found before it goes stale. |
| Review dates and recertification | Internal policy on content freshness; WCAG 2.1 AA remediation cycles under the ADA Title II rule, with compliance dates of April 26, 2027 and April 26, 2028 depending on entity size | Set a review interval per content type and an automated reminder to owners. Keep review records alongside accessibility audit results so remediation dates can be shown. |
| Approval audit trail | Internal policy and sector review duties; evidence that a named reviewer approved published content | Record who approved, when, and which version. Confirm whether the approval record is stored in the CMS or in an external workflow tool, and where those logs are retained. |
| Accessibility checks in the review step | WCAG 2.1 Level AA conformance under the ADA Title II rule (compliance dates April 26, 2027 and April 26, 2028) | Add an accessibility check as a required step before publication for templates and components. Automated checks do not replace manual testing, so confirm the testing method with your accessibility lead. |
How Drupal and WordPress handle governance differently
Drupal ships with core content moderation, which lets you define editorial states such as draft, review and published, and attach transitions that control who can move content between them. Governance on Drupal is usually built from core concepts plus contributed workflow modules when you need extra states, per-section approvals or scheduled transitions. Role and permission design is the real work: you map roles to content types, sections and workflow transitions, then test each combination so an editor cannot publish outside their section.
- Core moderation: states and transitions are defined in configuration, so the workflow can be exported, reviewed and versioned.
- Contributed workflow modules: check each module's maintenance status and compatibility with your Drupal version before you rely on it for approvals.
- Per-section permissions: design roles for content types and sections together, then test publish, unpublish and revert rights for every role.
- Configuration cost: workflow design, permission matrices and automated tests are one-time build work, while module updates and retesting recur with each release.
- Upgrade planning: Drupal 11.4 is a current feature release and Drupal 12.0.0 is scheduled for the week of December 7, 2026, so confirm that every contributed module supports the version you will run.
Verify each module against your specific workflow, including its support for your Drupal version, before selecting it.
WordPress handles editorial control through its built-in user roles, such as Author, Editor and Administrator, and extends them with plugins that add workflow states, approval steps or editorial calendars. The core roles cover basic separation of duties, but they do not model per-section approval chains on their own. Plugin-based workflows vary widely in maintenance quality, so the plugin you choose becomes part of your governance evidence and your patching responsibility.
- Built-in roles: Editor and Author roles are simple to explain to editors but limited for multi-section approvals.
- Plugin variation: plugins differ in update frequency, compatibility testing and developer responsiveness, so review each one's changelog and release history.
- Audit-grade approvals: a plugin's approval log may not meet an auditor's expectations for who approved what and when, so test the record before you depend on it.
- Security releases: WordPress 7.1.3 is the only actively maintained 7.1 release, so plan to stay on the current release series.
- Automatic updates: plugins and themes receive automatic updates only in special cases chosen by WordPress.org, so your own update process must cover the rest.
Verify each plugin against your approval requirements, its update history and its audit log before you select it.
The choice depends on how much governance you must prove and how many sections or sites share one workflow. Drupal's workflow is built into the platform's configuration model, which makes approvals easier to version and test across many sections. WordPress can deliver a simpler editorial model quickly, but governance-heavy estates often depend on plugin choices that need closer review. Either option needs the same discipline: documented roles, tested transitions and a dated upgrade plan.
- Approval depth: multi-level sign-off across sections usually favors a configuration-driven workflow that is tested per role.
- Team skills: confirm whether your editors and maintainers can support the chosen platform's workflow tooling.
- Dependency risk: count the contributed modules or plugins that each approval path requires, since each one adds an update obligation.
- Evidence: keep exported workflow configuration, role matrices and test results so you can show how approvals worked at any point.
- Upgrade timing: map each option's current release series and end-of-life dates against your planned migration window.
Ask any implementation partner to show a tested approval path for your highest-risk section on both platforms before you decide.
Which platforms fit a governance-led estate and why
Governance-led estates usually fail on roles, review steps and ownership, not on publishing speed. The options below differ mainly in how much workflow logic they ship with, how many sites and editor groups they can separate cleanly, and how much of the editorial model lives apart from the front end.
Drupal core with contributed workflow modules
Drupal core provides content moderation, revisions and role-based permissions, and contributed workflow modules extend these into multi-step approval chains. This fits estates where legal, brand and regional reviewers must sign off in sequence. Check that each contributed module supports your Drupal major version before you commit, and confirm how section-level permissions and review-date reminders are configured. Plan for Drupal 10 end of life on December 9, 2026, since governance rules built on a version you cannot patch become a compliance gap.
WordPress with a governance plugin
WordPress suits smaller editorial groups that need editorial calendars, a few approval steps and familiar editor screens. Governance depends on a plugin, so you own the risk of that plugin's update cadence, its permission model and its audit log coverage. Confirm how revision history, scheduled publishing and content ownership fields are stored and whether they survive a major upgrade. Only the most recent release in the 7.1 series is actively maintained, so update policy must be written into the governance model.
Drupal CMS 2.0 for marketing teams
Drupal CMS is a distribution built on Drupal core for marketers and content teams, with recipes, site templates and the Drupal Canvas visual page builder. It shortens setup for marketing-led sites that still need Drupal's permission model. The question for governance is whether the recipes ship the workflow, role and review settings your policy requires, or whether those must be built and tested. Treat recipes as a starting configuration that your editorial owners approve, not as a finished control set.
Headless CMS when editing is separate
Strapi, Payload or Directus fit only when editors work in a content model that is separate from the front end, for example when several channels read the same content. Governance then lives in the CMS admin, role settings and the front-end publish pipeline, which you must design and test together. Compare how each option handles draft and published states, webhooks for scheduled release and audit history. Strapi Enterprise Edition features and Directus terms for your use case must be checked by the buyer before selection.
Confirm licensing for paid editions
Some headless options separate features into commercial tiers. Strapi's Enterprise Edition sits under components in ee directories with its own license, and Directus is licensed under the Monospace Sustainable Core License, which restricts competing uses. Governance features such as audit trails, advanced roles or SSO may sit behind those terms. Ask each vendor in writing which governance features are included under the license you would accept, and whether hosting or professional services for your deployment change those terms.
Check supported versions before selection
Governance rules are only as durable as the platform beneath them. Drupal 11 receives feature releases every six months, Drupal 12 is scheduled for the week of December 7, 2026, and Drupal 7 security support ended on January 5, 2025. Any platform choice should name the supported major version, the patch cadence your security team requires and the date by which current sites must move. Ask your partner for a written version plan that covers both content model and workflow configuration.
How a governance rollout moves from policy to live workflow
The sequence turns a written content policy into a workflow that editors use daily, with each phase ending in a named artifact that the governance owner can sign off before the next phase starts.
Confirm governance policy and role inventory
The governance lead, content owners and the security or compliance contact agree the policy: who may create, review, approve and publish content in each section, which content types need legal or clinical review, and which review dates apply. Engineers and the platform owner list every existing account, group and role, including shared editor logins and retired staff accounts that need removing. The step closes with a signed role inventory that maps each person to a business role and names the approver for each section. Without that signature, later permission design has no authority behind it.
Design the content model and moderation states
The implementation team translates the policy into content types, required fields and a set of moderation states such as draft, in review, approved and published, with the transitions allowed between them. Owners define mandatory fields for accountable content, including the content owner, the next review date and the reviewer of record. The output is a workflow diagram that shows each state, the role that can move content into it and the notifications sent at each transition. Ask the partner to show the diagram against two real content types from your estate before approving it.
Build the permission matrix per section
Each section, site or language in the estate gets a permission matrix that lists the actions each role can take on each content type and workflow state. The matrix covers who can edit, who can approve, who can schedule and who can unpublish, and it states how cross-section content such as shared components or legal notices is controlled. Platform engineers implement the matrix in the chosen CMS and document the configuration so it can be reviewed without reading code. The step is done when the governance lead signs the matrix and the team has a list of every permission that differs from the default.
Run a pilot on one site
The team selects one site with representative content, several editor groups and at least one approval chain that involves a second role, then configures the workflow, permissions and review reminders there first. Pilot editors perform the core tasks in a non-production environment, including creating and approving content, scheduling a publish, reverting a revision and handling an expired review date. Issues found in the pilot are logged, fixed and retested, and the content owner for the pilot site confirms that the workflow matches the policy. The output is a pilot report with a list of accepted deviations and the decision to proceed.
Test training materials and the audit trail
Editors complete training on the live workflow using the runbook drafts, and the team tests whether the audit trail records what the policy requires. Testers check that each transition logs the user, the time and the state change, that revision history can be retrieved for a published page, and that the record of who approved content survives a role change or account removal. Compliance staff review a sample of logged events against the policy. The step ends with written test evidence that shows which checks passed, which failed and how each failure was resolved. Confirm with your auditors which evidence format they accept before this step starts.
Roll out in phases and enforce review dates
The workflow moves to the remaining sites in groups, with the governance owner approving each group before it goes live and with editors in that group receiving the training tested in the previous step. Review-date enforcement is switched on for each group so that content past its review date is flagged to its owner and, where the policy requires, is unpublished or escalated. Reports on overdue content, pending approvals and permission changes go to the governance lead on an agreed schedule. The final artifact is a runbook covering onboarding, offboarding, permission changes, incident handling and the process for updating the workflow itself.
Integrations that governance depends on
Editorial governance only holds if the systems around the CMS agree with it. Who signs in, where changes are tested, what reaches the public and how long the record of changes is kept all determine whether a moderation state means anything. The cards below cover the integrations that most often decide whether governance works in practice.
SSO through SAML or OpenID Connect
Editor identity should come from the organization's directory, so that offboarding removes CMS access on the same day as every other system. On Drupal, the contributed SAML Authentication module (samlauth) lets the site act as a SAML service provider. Its latest stable release, 8.x-3.14, supports Drupal 10.3 and later and Drupal 11. The OpenID Connect module offers built-in clients for Okta and Google as well as generic OAuth 2.0. Check how role mapping from directory groups to CMS roles is handled, and who approves changes to that mapping.
Staging for approval testing
Reviewers need to see a workflow state in a copy of the site that matches production before anything is published. A staging environment should carry the same content types, moderation states, roles and theme as production, with content refreshed on a set schedule. Confirm who can promote configuration from staging to production, and whether editorial content is ever copied in the other direction. Without a clear rule, approvals made in staging can apply to a different version of the page than the one that goes live.
Search index and CDN invalidation on publish
A published change is only visible to the public once the search index and the caching layers have caught up. Define which events trigger a search re-index and which trigger a CDN purge, and whether unpublishing or expiring content clears both. Stale pages after a withdrawal or a legal correction are a governance failure, not a performance issue. Ask the implementation partner to test the unpublish path as carefully as the publish path, and to document the purge scope for each content type.
Owner notifications before review dates
Review dates only work if a named owner receives a reminder before the date arrives, and if the content is handled when it passes that date. Notifications can come from the CMS itself or from a scheduled job that reads content ownership and review fields. Decide who receives escalations when an owner has left the organization, and whether an expired page is unpublished, flagged or left live by default. Test the reminder path with real owner accounts before rollout, since mail relays and directory changes often break it silently.
Revision history, logs and retention
The revision history that supports governance depends on the database and on the logs around it. Decide how long revisions are kept, whether deleted content and its revisions are retained, and where web server, authentication and CMS audit logs go. Retention periods should come from the organization's records policy, not from the default settings of the platform. Confirm that backups include the revision tables and that a restore has been tested against a point in time, since a backup that cannot reproduce an earlier version of a page does not support an audit.
Hosting boundary for logs and identity
Identity assertions, audit logs and backups often leave the CMS host and reach services in other locations, including directory services, log platforms and off-site backup storage. Map every system that receives editor identity data or content revisions, and record where each one is hosted and who operates it. This map is also the starting point for any data residency or access review. Confirm the hosting arrangement for each component with the organization's infrastructure team and the implementation partner in writing before scope is agreed.
Evidence that proves editorial controls to auditors and reviewers
This table maps each editorial control to the artifact an assessor or internal reviewer will ask for, the component that produces it, and where the evidence commonly goes missing. Read it as a checklist to settle before the platform goes live, since logs and exports that were never configured cannot be reconstructed later. DeployOpen prepares and organizes this evidence, but independent auditors and certification bodies issue any attestation or certification.
| Evidence item | Produced by | What the reviewer checks and where it usually fails |
|---|---|---|
| Role and permission matrix export | Drupal role and permission configuration, or WordPress roles and capabilities (with a plugin for per-section rules) | Shows who can create, edit, review and publish in each section. Fails when permissions were set in the interface and never exported or versioned. |
| Workflow configuration export | Drupal content moderation and workflow modules, or the approval plugin used on WordPress | Shows the states, transitions and who may move content between them. Fails when a workflow changed in production without a recorded change request. |
| Revision and approval logs | Drupal revision history with moderation state, or WordPress post revisions plus plugin approval records | Shows who changed content, when, and who approved it before publication. Fails when revisions are pruned on a short schedule or approvals happen by email. |
| Scheduled publish logs | Drupal scheduler or workflow scheduling, or WordPress scheduled posts and plugin job logs | Shows content that went live on a timer and who set it. Fails when time zones differ between the editor and the server or failed jobs leave no record. |
| Content ownership and review date reports | Custom fields and reports built on the CMS content model, exported on a set schedule | Shows every page with a named owner and next review date, and overdue items. Fails when ownership is optional or stored in spreadsheets outside the platform. |
| Accessibility test records for published content | Automated scans and manual test results held with the CMS release records, linked to page or template IDs | Shows which templates and pages were tested, against which WCAG 2.1 AA criteria, and what was fixed. Fails when tests cover staging only or results are not tied to live content. |
| Change records for module or plugin updates | Version control, deployment pipeline logs, and the security release calendar for Drupal or WordPress core, modules and plugins | Shows what changed, when, who approved it, and whether it was tested. Fails when plugins update automatically without a review step or staging evidence is missing. |
| Access and sign-in records for editors | Identity provider logs, plus SAML or OpenID Connect module configuration in Drupal, or the SSO plugin on WordPress | Shows which accounts accessed the editing tools and when. Fails when local editor accounts remain active after staff leave. |
What teams ask before they scope governance work
How much effort does editorial governance add to a CMS build?
Governance adds design and configuration work on top of the base site build, and the amount grows with how many distinct roles, sites, approval levels and languages the workflow must cover. A single site with one editor group and two approval steps is a small task. A multi-site estate where each section has its own reviewers, legal sign-off and translation states is a much larger one. Costs have three parts: the workflow design (who approves what, in which order), the build (moderation states, permissions, scheduled publishing, review dates) and the testing against real editorial scenarios. Ask any partner to price these as separate line items so you can see which drivers you can reduce. Drupal and WordPress carry no license fee, so the difference in quotes comes from design and build hours, not software.
Can our internal team configure editorial workflows on its own?
Often yes, if the team has someone who understands both the CMS configuration model and the business approval rules. Drupal's workflow capabilities are configured through core and contributed modules, and WordPress governance usually depends on plugins with their own settings, so the skills required differ by platform. The harder part is rarely the configuration screens. It is agreeing on states, owners and exceptions across departments before anything is built. Teams that succeed usually keep a named product owner for governance, document the workflow in writing, and use an outside partner for a review of permissions and an audit of the result. Confirm with your own engineers how many sites and roles they have already configured before deciding to do it in house.
How long does a governance rollout take, and what sets the timeline?
The timeline is set by decisions and dependencies more than by the configuration itself. The main drivers are the number of sections and sites moving onto the shared workflow, how many approval levels legal or compliance require, whether content must be migrated and re-reviewed, and how quickly stakeholders sign off on the role matrix. Identity integration with single sign-on and translation workflows add further steps. Ask a partner for a written schedule that separates discovery, workflow design, build, editor testing and rollout by site, and confirm which milestones depend on your staff's availability. No duration should be accepted without a written scope, since DeployOpen agrees scope, deliverables and timelines in writing before work starts.
What do editors and compliance staff need to contribute?
Editors and compliance staff provide the rules the system will enforce, so their time is needed early and at acceptance. Editors should map real publishing paths, identify which content types need a second reviewer, and test the states on live content before go-live. Compliance or legal staff should define which pages require sign-off, what evidence of approval must be kept, and how review dates and retirement of outdated content should work. Plan for named reviewers with decision rights, not a general committee, because unclear approvers are the most common cause of stalled workflows. Confirm how many hours each group can give per week during design and testing.
Should a governance-heavy estate run on Drupal or WordPress?
Drupal is usually the stronger fit when governance is the main requirement, because its core and contributed modules allow more granular workflow states, role and permission models across sections, and multi-site structures. WordPress can meet simpler approval needs well through plugins, but large estates with many section-level permissions need careful plugin selection and more ongoing maintenance. Both are GPL-licensed, so the decision turns on the workflow you need, the skills you can hire, and the update model. WordPress.org states that only the most recent release in the 7.1 series is actively maintained, and WordPress 7.1.3 was released on October 6, 2026. Drupal 11.4.10 and 10.6.19 were released on October 14, 2026. Run a proof of concept with your real approval paths before committing.
How do upgrades to Drupal 11 or 12 affect workflow configuration?
Upgrades can change workflow configuration in ways that need testing, because contributed modules, permission settings and content states may depend on versions that have changed. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12.0.0 is scheduled for the week of December 7, 2026, according to the Drupal core release schedule. Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later. Before upgrading, inventory every workflow, role, permission and scheduled job, check each contributed module for support of the target version, and test publishing paths in a staging copy. Confirm with your partner how regression tests for editorial states will be written and kept after the upgrade.
What should we ask about review dates and ongoing governance support?
Ask how review dates are enforced, who is notified, and what happens when content passes its review date without action. Ongoing governance also depends on maintenance: updating the role matrix as staff change, keeping modules and plugins current, and checking that scheduled jobs still run after platform updates. Ask whether support is fixed-scope or covered by a retainer, since DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and most engagements are fixed-scope. Request a written list of recurring tasks, their owners and how often they are reviewed.
What to ask an implementation partner about editorial governance
Start by asking how the partner maps roles to sections before any content type or workflow is configured. Ask them to show you a role matrix that lists each editorial group, the sections and sites it can edit, the moderation states it can move content through, and who holds the final publish permission. Ask how permissions are tested: whether they write test cases for each role against each section, whether those tests run again after every module or plugin update, and who signs off the results. Ask how review dates and content ownership are stored, since a page without an owner and a next review date will drift out of date on a large estate. Confirm whether scheduled publishing and revision history are tested under the same role matrix, because a scheduled item can bypass an approval step if the permission model is not checked end to end.
Ask how the partner documents the audit trail. You want to know which events are logged (creation, state changes, approvals, publishes, rollbacks and permission changes), where those logs are kept, how long they are retained, and whether an auditor can export them without database access. Ask how the partner handles contributed modules on Drupal or plugins on WordPress that affect workflow: who reviews them, how they are pinned to versions, and what happens when a maintainer stops releasing fixes. Ask how workflow changes are scheduled alongside security updates. Drupal publishes security releases on the third Wednesday of the month and WordPress security fixes arrive in bugfix releases, so the partner should explain how a workflow change is tested against those releases before it reaches production. Finally, ask what you will receive at handover: exported role and permission configuration, the test scripts, a written runbook for editors and administrators, and the documentation for each custom workflow step. Confirm in writing that DeployOpen works through fixed-scope agreements, so that scope, deliverables and timelines for each of these items are agreed before work starts.
How DeployOpen scopes and supports governance on enterprise CMS
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For editorial workflow and content governance, we start from the approval paths, roles and review obligations your organization already has, then configure the CMS to enforce them and produce the records your teams and auditors need.
How we scope
- Map every content type, section and site to its owner, approvers and publishing rights before any configuration starts.
- Define moderation states, transition rules and scheduled publishing behavior for each content class in writing.
- Agree in the written scope which Drupal or WordPress modules or plugins are in use, and which are custom.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- Configure roles and section-level permissions, then test them with named editors, reviewers and publishers.
- Set review dates, content ownership fields and revision retention so stale or unowned pages surface automatically.
- Connect editor sign-in to your identity provider and confirm group-to-role mapping with your identity team.
- Test workflow paths, permission boundaries and accessibility checks in a staging environment before release.
How we hand over
- Document the workflow states, role matrix, review calendar and escalation paths in a form your governance board can approve.
- Provide runbooks for editors, reviewers and site administrators, covering publishing, rollback and revision recovery.
- Deliver test records showing which permission and workflow checks passed, with the evidence stored in your environment.
- Train the editorial owners named in the scope so they can run the workflow without relying on the build team.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
- Track core and module security releases so workflow and permission configuration is retested after each update.
- Review role assignments and dormant editor accounts on a schedule agreed with your governance and security teams.
- Confirm with us during scoping which support hours, response channels and update windows your retainer will include.
