A data governance framework is easy to over-design and easy to under-build. Over-designed, it becomes a review committee that every new dataset has to clear before anyone can query it, and teams route around it. Under-built, "governance" means a wiki page nobody reads and a GDPR checkbox nobody checks. The frameworks that actually hold up share the same core structure: clear ownership, quality standards, access controls, metadata that's kept current, and a compliance mapping — rolled out to the highest-risk data first, not everywhere at once.
The core components
Every working governance framework covers the same five things, whatever it's called internally: ownership and stewardship (who is accountable for a dataset's accuracy and appropriate use), data quality standards (what "correct" means for a given dataset and how it's checked), access control and security policy (who can see and modify what, and why), metadata management (a catalog of what data exists, where it lives, and what it means), and compliance mapping (which regulations — GDPR, CCPA, SOC 2, HIPAA if relevant — apply to which data, and how the controls satisfy them). Drop any one of these and the framework has a blind spot: quality standards without ownership means nobody fixes what the checks catch, and access control without metadata means you're restricting data you can't even fully enumerate.
Roles: owners, stewards, custodians
These three roles get conflated constantly, and the confusion is a common reason governance stalls. A data owner is accountable for a domain of data — usually a business role (VP of Sales owns customer/pipeline data) who makes policy calls about who gets access and what quality bar applies. A data steward does the day-to-day work of maintaining quality and definitions for that domain — often someone embedded in the team that produces the data, not a separate governance department. A data custodian is technical — the engineer or platform team responsible for the systems that store and secure the data, implementing the access controls the owner and steward define. Without this split, "governance" collapses into one overloaded team that owns policy, quality, and infrastructure at once, and becomes the bottleneck everyone routes around.
The steward for customer data should be someone on the team that actually works with customer data day to day, not a rotating assignment from a central governance function with no domain context. Stewardship that isn't embedded in the team that produces the data rarely keeps up.
Building it incrementally, not all at once
The framework fails when it launches as an org-wide mandate covering every dataset on day one. Start with the data domains that are regulated or genuinely high-risk — customer PII, payment data, health records, anything with a named compliance obligation — and get ownership, access control, and a quality baseline defined there first. Prove the process works on a domain where the stakes justify the friction, then extend it. Trying to catalog and govern every table in the warehouse before shipping anything usually produces a stalled six-month project and no governance at all in the meantime.
dataset: customers.contact_info
owner: vp_sales
steward: sales_ops_team
classification: pii
regulations: [gdpr, ccpa]
access:
read: [sales_team, support_team]
write: [sales_ops_team]
retention_days: 730
quality_checks:
- not_null: [email, customer_id]
- unique: [customer_id]Mapping controls to regulations
Compliance mapping means translating a regulation's requirements into concrete controls on specific datasets rather than treating "GDPR compliance" as an abstract goal. GDPR's right-to-erasure requirement, for instance, only means something once you know which datasets hold EU personal data and have a working deletion process for each of them — the mapping is the bridge between the legal requirement and the technical control. The same dataset often maps to multiple regulations (GDPR and CCPA overlapping on personal data handling, SOC 2 overlapping on access control evidence), so the mapping is usually maintained as a matrix rather than a separate document per regulation.
The tension with data team velocity
Every access control, review step, or classification requirement adds friction to shipping a new dataset or pipeline. Governance that ignores this trade-off — requiring a committee sign-off for every new table regardless of sensitivity — creates exactly the failure mode teams complain about: engineers quietly building "shadow" pipelines and spreadsheets to avoid the process, which is worse for governance than no framework at all, because now ungoverned copies of the data exist outside the system that's supposed to track it.
If your framework applies the same approval overhead to a low-risk internal metrics table as it does to customer payment data, teams will build workarounds. Tier the rigor to the actual risk — heavy process for regulated/sensitive data, lightweight self-serve registration for everything else.
| Component | Owned by | What it prevents |
|---|---|---|
| Ownership/stewardship | Domain business owner + embedded steward | Nobody accountable for accuracy |
| Quality standards | Steward, enforced by custodian tooling | Silent data drift and bad decisions |
| Access control | Owner defines, custodian implements | Over-broad or unmonitored access |
| Metadata/catalog | Steward, platform team tooling | Duplicate or "unknown" datasets |
| Compliance mapping | Legal/compliance + data owner | Regulatory gaps found during an audit |
Wrapping up
A governance framework that works is scoped to the data that actually carries risk, assigns ownership to people who understand the domain rather than a central committee, and treats the compliance mapping as a living matrix rather than a one-time document. Roll it out to your regulated and sensitive data first, prove the process doesn't strangle delivery, and extend from there — governance that teams route around isn't governance, it's a reason to build shadow systems.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.