Data Governance: Policies, Framework, and Roles
Book: Data Engineering for Beginners
Author: Chisom Nwokwu
ISBN: 9781394325412
Data governance sounds boring until you realize it is the reason you do not get fined millions or repeat your life story to every department that calls. Chapter 10 ties together security and quality from the previous chapters into one framework.
Previous: Data Security | Next: Big Data and Distributed Systems
The abandoned hotel analogy
Nwokwu’s best metaphor in the book: you buy an abandoned hotel full of stuff. Nobody labeled anything.
- Discovery: walk through and find what data assets exist
- Classification: sort into keep, trash, donate (public, private, confidential, restricted)
- Metadata: label every box so you know what is inside
- Policies: rules for what to keep, lock away, or throw out
- Roles: hire staff, assign responsibilities, create processes
Without governance, everyone stores data their own way. Spreadsheets on laptops, duplicate customer records, outdated versions nobody trusts. Call customer service twice and two departments ask for the same info? That is a governance failure.
Facebook’s Cambridge Analytica scandal is the cautionary tale. No clear rules for who accesses what data, and the fallout was massive.
Governance is the umbrella over security and quality. Security locks the data. Quality keeps it clean. Governance sets the rules so both happen consistently across the whole company.
The governance framework
Three pillars:
- Policies (what the rules are)
- Processes (how to follow them)
- Roles and responsibilities (who does what)
A good framework answers: what data do we have, who owns it, who is accountable, what regulations apply, who can access it, how long do we keep it.
Key policies
Regulatory compliance
GDPR (EU, 2018): applies worldwide if you handle EU citizen data. Seven principles: lawfulness/transparency/fairness, data minimization, accuracy, storage limitation, integrity/confidentiality, accountability, purpose limitation.
HIPAA (US healthcare): access policies, encryption, audit logs, breach notification.
CCPA (California): right to know, delete, opt out of sale, nondiscrimination, correct inaccurate data. Applies to companies over $25M revenue or 50K+ consumers.
SOC 2: not a law, but a cloud security checklist. Five principles: security, availability, confidentiality, processing integrity, privacy. Big deal for SaaS companies.
PCI DSS: mandatory if you handle credit cards. Encrypt card numbers, never store plain text, limit access with RBAC, run regular security audits.
Data classification
Four tiers:
- Public: press releases, marketing (free to share)
- Private: internal memos, employee handbooks
- Confidential: customer data, financial records, business strategies
- Restricted: trade secrets, PII, medical records, credit cards
Five implementation steps: inventory assets, define levels, label data, apply access controls, audit periodically.
Retention and disposal
How long to keep data and how to delete it safely. Example retention periods from the book:
| Data type | Retention | Why |
|---|---|---|
| Customer records | 5-7 years | Tax and consumer laws |
| Financial transactions | 7+ years | SOX, IRS |
| Employee records | 3-6 years post-departure | Labor laws |
| System logs | 30-90 days | Security troubleshooting |
Nwokwu’s team auto-deletes PII after 30 days. Shorter retention means less breach risk.
Data sharing
Rules for internal and external sharing. Public data shares freely. Confidential data needs NDAs or user consent for external sharing. Financial records stay locked down.
Key processes
Metadata management: data about data. Three types:
- Technical: schema, column types, table relationships
- Business: what “active customers” means, who owns a dataset
- Operational: when data was last updated, what transformations ran
Stored in catalogs like Apache Atlas, AWS Glue, Google Data Catalog, Microsoft Purview.
Data lineage: visual map of data from source through transformations to destination. When a report breaks, lineage tells you where to look.
Incident management: identify, classify, respond, communicate, root cause analysis, document. Playbooks and simulated breach drills help.
Master data management (MDM): one accurate version of core business entities (customers, products, locations). Processes include agreeing ownership, standardizing definitions, defining attribute rules, amending over time, retiring obsolete fields.
Governance roles
| Role | Who | Does what |
|---|---|---|
| Data owner | Business leader | Sets policies, decides access, retention rules |
| Data steward | Business expert | Day-to-day quality, catalog descriptions, cleanup |
| Data custodian | IT/engineering | Storage, encryption, backups, infrastructure |
| Chief Data Officer | Executive | Overall strategy, executive advocacy |
Smaller companies often combine roles. One person might steward and custodian at the same time. Larger regulated industries (finance, healthcare) tend to have formal CDOs and governance committees.
Governance vs data management
Data management is the daily work: cleaning, modeling, securing, analyzing.
Data governance sets the rules for how that work should happen.
Management executes. Governance directs. You need both.
My take
Governance is the chapter that makes the whole book click. Pipelines (Ch 7), quality (Ch 8), and security (Ch 9) are tactical skills. Governance is why those skills matter at org scale.
The hotel analogy is genuinely useful for explaining governance to non-technical stakeholders. Skip the jargon, talk about labeling boxes and assigning staff.
If you are a data engineer, you will mostly interact with custodian and steward roles. But knowing who the data owner is saves you weeks of “who approved this schema change?” confusion.
The regulatory section is a reference you will come back to. GDPR and PCI DSS show up in job postings and compliance audits constantly. Having the principles memorized is worth the read time.