Website governance: ownership, approvals and access

Website governance is the agreement about who can make website decisions, who can publish them, and who checks what happens afterward. A useful website governance framework makes those responsibilities visible in the tools people use every day.

Imagine a housing agency updating an application deadline. Communications prepares the page, the program team confirms the date, and a publisher releases the approved version. A web-development partner can maintain the software and check the implementation, but it should not decide eligibility policy. If the date changes after approval, the revised page needs another review.

Your governance plan should answer those questions for the work your team actually does. The examples below draw on public policies and platform behavior; the housing-agency and nonprofit scenarios are fictional. They do not describe problems at dirango clients. Primary sources were checked on October 22, 2026.

Separate the different meanings of “owner”

“The agency owns the website” can mean several different things. Name each responsibility separately:

• Business owner: accountable for the website's purpose, priorities, budget and unresolved decisions.
• Content owner: responsible for whether a particular program page, policy or product claim is correct and current.
• Account custodian: maintains organization-controlled registration, billing, recovery and authorized access for a platform.
• Technical operator: maintains the application, hosting, integrations, releases and recovery procedures within an agreed scope.
• Publisher: authorized to release a reviewed change and verify it on the public site.

A small organization might assign several of these jobs to one person. It still needs a backup person and an explicit boundary between routine edits and consequential decisions.

Legal ownership of code, designs, content, licenses and domains is a separate contract question. An Administrator login proves a permission level; it does not establish all those rights. Record the agreement and any licensing or transfer restrictions rather than inferring ownership from whoever can log in.

Create an account and responsibility register

List the domain registrar, DNS, hosting, CMS, code repository, analytics, forms, payment/donation services and consent platform. For each, record the accountable organization, authorized custodian, backup contact, billing/renewal owner, recovery procedure reference and vendor exit requirements. Keep secrets and recovery codes in a protected credential system, not in this register.

For content, start with the important journeys. A fictional resident-services site might assign application information to the program director, public notices to the records team and payment instructions to finance. Assign a named person within each team, a deputy and a review trigger. “Everyone in marketing” is difficult to hold accountable when a page expires.

The vendor handoff should include organization-controlled accounts, repository access, deployment instructions, an integration inventory and a tested recovery process. Confirm which licenses can transfer and which need replacement before a contract ends.

Build a content approval workflow around the change

Use a written path: request, draft, factual review, implementation checks, release approval, publication and live verification. Define who performs each step and what evidence allows the next step to begin. Some work can combine steps; high-impact changes need a stronger review path.

For the fictional housing deadline change:

• Communications drafts the page and identifies every place that repeats the deadline.
• The program owner verifies the date, time zone, eligibility wording and authoritative source.
• The technical team checks links, form behavior, headings, accessible instructions and related documents in a review environment.
• The designated approver approves the exact revision, including any linked document being replaced.
• The publisher releases that revision, checks the public page and records the result.

Give reviewers a preview and a before/after comparison. A reply saying “looks good” is ambiguous if the preview changes afterward. Store the content revision or release identifier with the decision. Approval of revision 12 must not authorize revision 13. Changed attachments, form destinations or eligibility wording should also trigger review.

Define an emergency path for an outage or urgent correction: who may act, how to verify the change, when to escalate, and when the retrospective approval record must be completed. Emergency access should leave an attributable history.

GOV.UK's Whitehall publishing guidance provides a real emergency-workflow example. Editors normally publish another person's draft. An urgent self-publication needs a reason, is flagged as not reviewed, and calls for later editor review. Those are Whitehall rules, not default WordPress behavior; the useful principle is an explicit exception with a follow-up decision. GOV.UK standard publishing workflow.

A real organizational example: Fordham

Fordham University's published governance guideline assigns review of official pages to department or division heads or their designees, with University Marketing and Communications approval, followed by ongoing monitoring. It also defines a scope extending beyond one public domain to official information on other infrastructure. That is a concrete example of governance connecting authority, scope and continuing responsibility. Fordham web governance guideline.

Set review authority and ongoing responsibility at a scale your team can maintain.

Check what WordPress roles actually permit

In a standard WordPress installation, a Contributor can prepare their own posts but cannot publish them. An Author can publish their own posts. An Editor can manage other users' posts and pages. Administrator is much broader. These defaults can be changed by plugins or custom code, so inspect actual capabilities. WordPress roles and capabilities.

This matters when a nonprofit asks, “Can the program team update pages without publishing changes directly?” Assigning everyone Editor does not create that boundary. Contributor is not a complete solution either: its default scope is posts, and it lacks media-upload capability. A page-based workflow may need a carefully scoped custom role and a revision/approval implementation.

WordPress revisions let editors compare and restore saved changes. They are useful history, but they are not automatically an enforced two-person approval system. WordPress revisions.

Before accepting an editorial workflow, test it with representative accounts:

• Can the drafter edit the intended content types and upload the needed media?
• Can that account publish, schedule, delete or change somebody else's content when it should not?
• What happens when someone edits a published page that needs approval?
• Do imports, integrations and API requests follow the same rules?
• Can a reviewer approve only the permitted scope, and does a later change invalidate that decision?

Keep workflow permissions on the server. Hiding a Publish button or using a browser-only role selector does not authorize or block the underlying request. Custom post types also need the intended capability mapping; see the WordPress content-model example.

Bind technical approvals to the reviewed version

For a site managed through GitHub, protected branches can require reviews and status checks. A configurable option dismisses stale approvals when the reviewed diff changes. Restrictions normally exclude administrators and bypass roles unless configured otherwise, and availability depends on the plan and repository type. This is a real version-aware approval mechanism, not proof that a site is already configured correctly. GitHub protected branches.

Code review and release approval can be separate decisions. A developer can verify a form implementation while the program owner verifies its questions. Passing tests cannot authorize a policy change.

A CMS or release system should track approval, release and verification as separate steps. For example, the program owner approves revision 12, the publisher is responsible for putting it live, and someone still needs to check the deadline, document link and application form after publication.

In production, the server must establish the authenticated actor, current permissions, approved content and current revision from trusted records. It must reject conflicting edits and prevent a change between its checks and its write. It cannot trust a user ID or approval decision supplied by the browser. Record publication and readback separately so an approved item is never reported as completed merely because it entered a queue.

Review access when people and vendors change

Give people individual accounts and the smallest permissions their work requires. Use multi-factor authentication where supported; CISA recommends moving toward phishing-resistant MFA. Keep administrative work separate from routine editing where the platform allows it. CISA guidance for implementing MFA.

A CMS account review alone is incomplete. Check hosting, DNS, repositories, tag managers, analytics, backups, form destinations, integrations and recovery access. Include service accounts and API tokens with a recorded purpose, owner, scope and review date.

For a departing contractor, identify their accounts and integrations, transfer operational ownership and remove their access. Revoke or rotate credentials they could retain when needed, including tokens, active sessions and recovery methods supported by the provider. Disabling one shared mailbox does not necessarily revoke an API token. Verify the revocation rather than assuming every system follows the same identity provider.

Keep access reviews small enough to complete: person or integration, required work, current scope, reviewer, decision, date and evidence. Schedule them according to risk and staff turnover, and repeat them after a vendor handoff or security incident.

Give every important page a lifecycle

A published page needs a content owner, a next review date or trigger, and a decision about what happens when it is no longer useful. A grant application closes; a staff member leaves; an annual report becomes an archive; a service moves to a new address.

GOV.UK's publishing guidance provides a real lifecycle example: it distinguishes withdrawal, where content remains available with a notice, from unpublishing, where it is removed and an appropriate redirect or explanatory outcome is considered. Your retention and public-record obligations may require a different decision. GOV.UK guidance on unpublishing and withdrawing content.

For a nonprofit annual report, identify the owner of financial corrections, the final approval version and the archive policy. A reusable microsite still needs maintenance when its dependencies or links change. The annual-report microsite article explains those implementation choices.

A review should result in an action: keep, correct, consolidate, archive or retire, with the appropriate authorization. A “last reviewed” date is weak evidence if nobody checked the facts, links and user task.

Make ongoing oversight produce decisions

Set intervals that fit the site's risk and service agreement. A starting cadence could be:

• After important releases: verify public pages, related documents, forms and tracking; record the release result and unresolved issues.
• Weekly: review urgent failures, access changes, pending approvals and new accessibility barriers on important journeys.
• Monthly: examine overdue content, broken links, consent/vendor changes, recurring accessibility findings and the next priorities.
• Quarterly, and at personnel/vendor changes: review permissions, account custody, ownership gaps, recovery evidence and whether the workflow still matches the team.

These intervals are operating suggestions, not universal legal requirements or an automatic service commitment. Agree on scope, response expectations and escalation contacts.

An oversight report should identify the pages or systems checked, changes made, what remains unverified, who owns each issue and what decisions are needed. For example: “Three program pages are overdue for review; one application form has an unresolved keyboard defect; the department head needs to approve the revised deadline.” A green dashboard without scope or evidence gives the team little to act on.

Connect related work without assuming one check proves another. An accessibility audit and retest needs its own evidence. A cookie and Global Privacy Control review needs vendor and request checks. WordPress support and maintenance keeps the platform operational; governance determines responsibility and decisions around that work.

Start with one critical journey

Choose a visitor task such as an application, donation, purchase or program signup, then name its owner and deputy. Take one change through drafting, review, approval, release and verification. Test the drafter's access boundaries and confirm that an edit made after approval needs a new review. Set a review trigger and resolve missing account ownership.

Keep the initial plan short enough to use. State who decides and acts, how permissions are enforced, what evidence is kept and what happens when something goes wrong.

dirango's website governance and ongoing oversight service can help put that framework into a working publishing process, account register and review cadence. Use the project brief to describe your team, platforms and the decisions that currently get stuck.