Content management vs content governance: what the difference means for Australian government teams
When I led the digital content consolidation across ACT Government, the hardest part was never the technology. It was deciding who owned content that crossed directorate lines, because an unowned page is a page that rots.
That is the difference between content management and content governance, and it is the distinction most Australian government teams get wrong. Content management is how content gets published. Content governance is who decides, who owns accuracy, and what happens when no one does. Most teams buy a capable CMS and assume they have bought both. They have not.
A CMS stores content. Governance decides who is accountable for it.
Content management is the system and process for creating, storing, publishing, and updating content. It is your CMS, whether that's Squarespace, Drupal, Squiz Matrix, Sitecore, or whatever your agency runs, plus the workflows that move a draft to a live page.
Content governance is the set of decisions wrapped around that content: who owns it, who can approve it, when it gets reviewed, and who is accountable when it is wrong. Governance is not software. It is named people, real review dates, and a clear escalation path.
A CMS can tell you when a page was last edited. It cannot tell you whether anyone is responsible for whether that page is still true.
Why the two keep getting confused
Most explanations of content governance come from software vendors, and in that framing governance becomes a feature you switch on: permissions, version history, approval queues.
Those things are useful. They are also not governance. A permission setting decides who is allowed to publish. It does not decide who is accountable for being right. A team can have a fully permissioned CMS and still have no one who owns whether the content on it is true.
This matters more in government than almost anywhere else. The cost of an out-of-date page is not a missed marketing target. It is a person acting on the wrong information about their visa, their payment, or their safety.
What governance actually looks like in a government team
Real governance assigns four things to named people, not to teams in the abstract: ownership of each content area, authority to approve changes, a review cycle with actual dates on the calendar, and an escalation path for when content is disputed or goes stale.
The Australian Government Architecture lists governance of government content as one of the ways the web content management capability is realised, alongside planning, creation, and delivery. It is not framed as a publishing tool on its own.
The Style Manual's guidance on content and user research sets out a content lifecycle that runs from intent through to removal, including a maintain stage and a remove stage where teams review analytics and user feedback and recommend pages for removal. A lifecycle on paper is not a lifecycle in practice until a name is attached to each stage.
Where to start, without buying anything
You do not need new software to begin. Governance is far cheaper than the CMS migration teams reach for instead.
Take your ten highest-traffic pages. For each one, write down a single name: the person accountable for whether it is accurate today. If you cannot fill in a name, you have found your real problem, and it is not your CMS.
The Digital Service Standard's criteria to monitor your service and keep it relevant both assume someone is watching a page after it goes live, not just publishing it once. That is a governance job, not a CMS setting, and no amount of software will do it for you.
So before your next platform business case, ask the harder question: when a page goes out of date, who is supposed to notice, and what happens if no one does?
Did this land?
I write these to be used, not just read. Tell me if this wouldn't work in your organisation, and why.