Data Governance

Small companies run without any of this. Every engineer holds database access, analysts build tables whenever they need one, and nothing is ever deleted because no one wrote down when it should be. At ten people that works fine, because everybody knows who built what.

Three things break at once as headcount grows. The people who build tables stop being the people who read them, so when a revenue table looks wrong, half a day goes into finding out who is responsible for it. Access stays open, so the permissions handed out in someone's first week still allow a full download of every customer's contact details, and nobody notices. And with no deletion date, the records of members who closed their accounts three years ago sit inside backup files untouched.

Pagedeck hit all three. Sofia wanted to reach out to an enterprise customer that had churned, so she asked for the list of contacts, and Theo used his own access to export the entire member table into a spreadsheet. That spreadsheet stayed open to anyone with the link for six months. Nobody broke a rule. There was no rule to break.

Write down what data the company holds, then attach an owner, a sensitivity level, and a lifespan to each entry on that list.

1. Build the inventory. Record which tables exist, where they live, and what each column means. A maintained inventory like this is called a data catalog. Flag the columns that hold personally identifiable information (PII) — names, phone numbers, addresses, anything that points at one specific person. Most of the rules that follow branch on that flag.
2. Name one owner per table. A person, not a team: Theo owns the payments table, Mia owns the event log. The owner carries both the duty to fix the table when it's wrong and the authority to decide who gets to open it.
3. Sort tables into levels. Three is usually enough — visible to anyone at the company, visible to one team, visible only to named individuals. Signups by plan sits in the first, revenue per account in the second, member contact details in the third.
4. Attach access rules to each level. The third level should require a request that the owner approves, and the approval should expire. Access that opens once and stays open is what produced the incident above.
5. Set a retention period — the limit on how long a given kind of data may be kept before it has to go. Closed accounts deleted after 30 days, payment records kept for the five years the law requires. Then make the deletion run on a monthly schedule instead of relying on someone to remember it.
6. Create a place where violations surface. Once a quarter, pull the access list and check whether people who left the company or moved teams still hold permissions, and count the tables whose owner field has gone empty.

It starts to matter once the data describes people and more people read it than built it. The signal usually arrives in one of three forms: finding the right person to ask about a broken table now takes half a day, nobody can say how many employees could download member records, or an enterprise customer asks for a written description of your data handling before signing. Pagedeck started on the third.

At five people in one room, working only with usage logs from your own product, the whole apparatus is overhead. Approval flows run without anything to hold back.

Two limits are worth knowing. The first is that rules tilted entirely toward blocking produce workarounds. If approval takes three days, people stop requesting access and ask a colleague who already has it to send a file instead. Controlled originals get replaced by uncontrolled copies, which leaves things worse than before. That's why the goal of an approval flow should be an answer within a day rather than a refusal.

The second is drift between the document and reality. A policy that says closed accounts are deleted after 30 days deletes nothing if no code performs the deletion, and believing a rule is in force is more dangerous than knowing it isn't. Each rule needs a paired answer to how anyone would verify it's being followed; without that, six months later only the document remains.

"Who owns this table? The revenue column seems to be on a different basis than it was."

Looking for whoever is responsible for fixing the number. With an inventory in place, the name comes straight out of it.

"That column is personal data, so it can't go on a dashboard as is — run it through anonymization first."

Anonymization means reshaping values so the individual behind them can't be recognized; the point is that the same analysis is fine once that's done.

"The security review wants evidence of our access revocation process."

The other side is checking whether the rule actually runs and leaves records, rather than only existing on paper.

Pagedeck began this work when Grace was asked to document the company's data handling ahead of an enterprise contract. Mia took it on, and while transferring the 40 tables used for analysis into an inventory she found 12 with no owner at all — built by people who had since left, or created for one question and never removed. Half were deleted and half were assigned.

The first payoff came somewhere other than the review. Questions about odd revenue numbers used to land in a company-wide channel and drift past unanswered. Now whoever is asking goes to the owner.

The common assumption is that legal or security handles this on their own. The phrase "personal data" invites it. But the only people who know what a column means and who actually uses it are the teams building and reading the data. A policy written in isolation by legal doesn't line up with real table names, so applying it starts with asking which table and column "customer information" was supposed to refer to.

The other mistake is treating it as a one-time documentation project. Deliverables appear within a few weeks, which makes it feel like one. In practice new tables appear every week and people change teams, so the inventory starts diverging within a month. Without a refresh habit, six months later the document describes a company that no longer exists, and the next review starts from scratch.