Every module on this site so far has assumed data, once correct and available, is simply used. This module is about the questions information security asks before that: who is allowed to see this data, what has to happen to it before someone with fewer privileges can use it, and who is accountable when a rule like that gets broken.
The problem governance solves#
A team of five people sharing one database can operate on trust — everyone knows what the data contains, and informal norms are usually enough. That stops working as an organization grows: more people touch more data than any one person can track, some of that data is sensitive, and "everyone trusts everyone" becomes "no one actually knows who can see what." Data governance is the discipline that replaces informal trust with explicit, checkable rules before that gap becomes a real incident rather than a hypothetical one.
Governance is broader than the quality module
Data Quality Fundamentals covers whether data is correct. Governance covers a different, earlier question: who is allowed to access, change, or delete it in the first place — correctness and authorization are independent concerns, and a pipeline can get one right while getting the other badly wrong.
Three questions every governance program answers#
- Who can access what? Access Control Models covers the mechanisms — role-based and attribute-based — that answer this explicitly instead of leaving it to whoever happens to have database credentials.
- What actually needs protecting? PII Classification and Sensitivity covers identifying which data is sensitive before deciding how to protect it — a step that has to happen first, because a rule cannot be applied to data no one has flagged as needing one.
- Who is accountable, and can it be proven? Data Lineage and Cataloging covers knowing where data actually lives and where it came from — a prerequisite for answering "was this handled correctly" at all.
Why this is an engineering discipline, not only a policy one#
A written policy that says "only authorized staff may access customer PII" is not, by itself, enforced by anything — it depends entirely on every engineer remembering and following it correctly, indefinitely, with no verification. The rest of this module covers turning policies like that into mechanisms: access control systems that actually block an unauthorized query, encryption that actually renders a stolen backup unreadable, a catalog that actually reveals where sensitive data lives without relying on someone's memory.
Common mistakes#
Treating governance as a compliance checkbox, separate from system design#
Access control and classification retrofitted onto a system after it is built are consistently weaker than the same controls designed in from the start — every existing pipeline and query pattern has to be individually checked and possibly reworked, rather than built correctly the first time.
Assuming data quality and data governance are the same problem#
A pipeline can produce perfectly accurate, complete, timely data that the wrong people can see — quality and authorization are answers to different questions, and solving one does not solve the other.
Writing policy with no enforcement mechanism behind it#
A rule that depends entirely on people remembering to follow it, with nothing technical checking or blocking a violation, tends to hold until the first time someone forgets — which is usually also the first time anyone notices the rule was never actually enforced.
Further reading#
- Data governance — the general discipline this module covers in depth.
- Information security — the broader field, including the confidentiality/integrity/availability framing this module's access and encryption articles fall under.
- Access control — the general mechanism behind "who can access what," covered in full in the next article.
- Personal data — the category of data classification exists to identify before it can be protected.
- Data Quality Fundamentals — the related, independent discipline of verifying data is correct.