Governance by design

Governance that lives in the platform, not in people’s calendars.

Most enterprises already have the ingredients of good data governance: a catalog, a glossary, access controls and people who care. What they usually lack is a mechanism that keeps those agreements true after the meeting ends.

This paper sets out how CWX approaches governance, compliance and tenancy on cloud data platforms. It is opinionated on purpose. The patterns come from our team’s hands-on experience building data and governance platforms in regulated industries and in high-scale retail and e-commerce, where getting it wrong shows up as failed audits, duplicated work and numbers that don’t match.

Three ideas run through everything that follows.

• Mechanisms over good intentions. Definitions, policies and access rules are written as code and enforced by the platform.
• Catch it early. A conflicting metric or an unapproved use of personal data should fail in the pull request, not surface in a board deck.
• Access follows purpose. People get data through time-bound initiatives with a stated justification, not permanent personal entitlements.

Governance is only as good as the last conversation.

Two dashboards both report “demand”, and the numbers disagree. Someone notices. A governance lead gets the two authors in a room, and after some back and forth they settle on a definition.

Demand, they agree, is every transaction received before midnight, less any cancellations made before midnight. The definition, the SQL and a description go into the catalog. Everyone moves on.

Then a new analyst joins in another region. They’re busy, they don’t know the catalog exists, or it never occurs to them to look. They write their own version of demand, it ships, and the cycle starts again, often months after the first round of alignment.

Nobody did anything wrong. The analyst did what good analysts do and found a way to get the job done. The problem is structural: the agreement lived in a conversation and a catalog entry, and neither sits in the path of the work.

Good intentions don’t scale. Mechanisms do.

When governance relies on people remembering to check, it becomes a tax rather than a benefit. Teams route around it, the governance function spends its days brokering meetings, and the platform’s long-term investments compete for the same bandwidth as everyday requests from the business.

The right people, the right data, and no human gatekeeper.

Compliance by design means the workflows, approvals, access groups and controls that compliance requires are built into the platform, so no administrator has to decide by hand who can see what.

It rests on metadata. Once every sensitive column carries a classification, policy attaches to the classification rather than to individual tables. That’s what makes it scale: a new table holding email addresses inherits the right masking and access rules the moment it’s tagged.

1. Step 1Classify
2. Step 2Tag
3. Step 3Enforce
4. Step 4Evidence

• Classification at ingestion. Automated scanning, with LLM-assisted tagging for the context scanners miss, proposes classifications that data owners confirm.
• Policy follows the tag. Column-level policy tags, dynamic masking and row-level access policies apply wherever classified data lands.
• Purpose-bound access. Sensitive data is granted through an approved initiative (chapter 04), never as a standing personal entitlement.
• Evidence by default. Every grant, approval and query is logged and mapped to the control it satisfies.

Access follows purpose, not people.

The same analyst might need card-transaction data for a finance report in the morning and nothing of the sort for a campaign analysis in the afternoon. Personal entitlements can’t express that. Initiatives can.

A data initiative is a governed unit of work with a purpose, a data scope, an accountable owner and an end date. Access is justified and approved once, at the initiative level. People join initiatives and take on a role inside them. When they switch work, they switch context, and the access that belonged to the other context stays behind.

• Isolation by default. Each initiative gets its own workspace, so data used for one purpose doesn’t quietly drift into another.
• A better question for approvers. “Is this purpose and scope reasonable?” is far easier to answer well than “should this person see this table?”
• No single points of failure. Skills move between initiatives. You’re never stuck with one person who is allowed to do fraud analytics.
• Access expires. Initiatives end or are recertified, and access is revoked automatically.

Certified metrics, enforced at the pull request.

Once the business has agreed how a metric is defined, it should be very hard to drift from that definition by accident.

We treat certified metrics and data products as contracts: a definition, an owner, a schema, quality expectations and the consumers who depend on it, all held as code next to the transformations that produce them. The catalog is generated from that source of truth, so it can’t quietly fall out of date.

The CI pipeline then does the remembering. When an analyst introduces a calculation that looks like an existing certified metric, the build flags it and points them to the certified version. When a change would break a contract downstream teams rely on, it doesn’t merge without the owner’s sign-off.

The point isn’t to block analysts. It’s to catch the misunderstanding on day one, kindly and automatically, rather than months later in a reconciliation meeting.

Every meaningful change triggers the right workflow.

Good HR systems solved this years ago. You can’t change your own title, pay or manager; the system routes the request to whoever is allowed to approve it and records the outcome. Data deserves the same discipline.

We map the changes that matter to the workflows they should trigger. Low-risk work stays frictionless. Higher-risk work goes to an accountable person, with the context they need to decide quickly. The thresholds should fit the business, a beverage retailer and a bank shouldn’t have the same ones, but every change leaves a trace.

Governance usually runs on three tracks: business ownership, the administrative work of aligning and documenting, and the digitized workflow that holds it all in place. The first two depend on the third. Without it, council decisions and catalog updates have nowhere to live once the meeting is over.

A practical path from today to business as usual.

Few platforms can jump straight to enforcement. Adding controls to existing assets breaks things downstream, so the first job is getting to a clean, known state, then turning the dial from advice to enforcement.

1. Phase 1

   Discover & classify

   Inventory the estate. Apply an 80/20 taxonomy to the assets that matter most. Shortlist the metrics worth certifying.

2. Phase 2

   Codify

   Write policies, metric contracts and the initiative model as code. Run CI checks in warn-only mode so teams can adjust.

3. Phase 3

   Enforce & operate

   Switch checks from warn to block. Automate compliance reporting. Run with a lightweight governance council.

The discovery phase is where most of the effort goes, and it’s worth being honest about that. At one bank we started from roughly 800,000 tables with no taxonomy at all. Tagging all of it was never the goal; finding the small share that carried real risk and real business value was.

Where we’d start

Pick one domain with a visible pain point, usually a contested metric like demand, and one sensitive dataset that’s currently locked away. Prove the pattern on both in a matter of weeks, show the business what changed, then expand domain by domain.

Build the mechanism once, and the alignment outlives the meeting.

The governance fabric on Google Cloud

How certified definitions, policy and classification plug into the development lifecycle and the warehouse. The same shape applies on other clouds with equivalent services.

• 1Gates. Run on every pull request; start in warn-only mode, then block.
• 2Zones. Freedom is highest in sandboxes and narrows as data becomes certified or sensitive.
• 3Fabric. One horizontal layer of definitions and policy, applied consistently to every zone.
• 4 to 5Outputs. Approvals and audit evidence are by-products of normal work, not separate projects.

Appendix C · Where the patterns come from

Proven in regulated, high-scale environments

The patterns in this paper come from production platforms, not slideware: data platform and governance work in regulated financial services and in high-scale retail and e-commerce.

About the author

Daniel Joanes

Senior Director of Data & AI, CWX

Daniel came to consulting from product engineering. He spent several years at a large e-commerce company in Asia working on catalogs of 100 million products and 300 million active users, then built the loyalty platform for a payments company in Japan. He has since led the design of data and governance platforms for regulated enterprises, bringing the pace of product teams to regulated environments.