Every large web presence eventually produces a governance document. Forty pages, a committee, a section on tone of voice, an approval workflow with four swim lanes. It gets circulated, approved, and posted to an intranet page nobody will visit again. Meanwhile the site keeps drifting, because a document has no way to stop anyone from doing anything.
I have been on both sides of this. I built a university's first CMS, which meant handing publishing rights to departments across a decentralized, multi-site environment where not one of those editors reported to me. I now own web strategy for a WordPress platform with the same problem at a different scale. The lesson held in both places: you cannot govern people who do not report to you with a policy. You govern with the system they work in.
Three things actually govern
The permission model. Not what an editor should do. What the CMS physically allows them to do. If someone can publish an image without alt text, some of them will. If someone can create a top-level navigation item, the navigation will grow one a month. Most governance failures are permission failures wearing a training costume, and training does not survive staff turnover. Permissions do.
The content model. Templates, fields, and taxonomy decide what the site can become. A page type with one hero, three required fields, and a closed set of tags produces consistent pages by default. A free-text body field with a WYSIWYG produces whatever the last person felt like. Structured content is not a technical nicety. It is the governance mechanism that runs while everyone is asleep, and it is the same structure that makes content findable later, both to search engines and to the models increasingly answering questions on a reader's behalf.
The decision path. Who says yes, and at what moment. Not a diagram. The actual answer to "can I have a microsite" has to be known by whoever fields that request on a Tuesday.
The counterintuitive part
Good governance reduces the number of decisions. It does not add review steps.
This is where most programs go wrong. When quality slips, the instinct is to add a gate. Every gate is a queue, every queue needs someone to staff it, and the week that person is on vacation the organization learns to route around them. A review step that can be bypassed is worse than no review step, because it produces the paperwork of governance without the effect.
The alternative is to move the decision earlier and make it once. Press releases get one template. The tag vocabulary is closed. New top-level navigation requires evidence, and what counts as evidence is written down. You spend the political capital a single time instead of relitigating it per request.
What to measure
Governance that works is boring to report on, which is what makes it hard to fund. The numbers worth tracking: how many pages use a non-standard template, how many published pages fail an automated accessibility or metadata check, how long a typical publishing request waits, and how many exceptions were granted last quarter.
That last one matters most. A program with zero exceptions is too rigid to be real. A program with constant exceptions is not a program.
The part that is not a technique
Governance reads to colleagues like you are taking something away from them. Sometimes you are. The honest case for it is not consistency or brand compliance, both of which sound like your problem rather than theirs.
It is that a good system takes the blame away. An editor working inside constraints that make the common mistakes impossible does not have to become an accessibility expert, an SEO, and a designer in order to publish something decent. For most of them that is worth more than the freedom you removed, and it is a far better argument than brand standards.