# The Data Governance Council Playbook ### How to charter, staff, and run a governance council that actually makes decisions. --- ## Executive summary Almost every company past a certain size has a data governance council on paper. Far fewer have one that actually makes decisions. The council meets, people update each other, and the same open question — who owns this data, who can access it, what does it even mean — walks back out of the room unresolved, to be raised again next quarter. This paper covers why governance councils stall out, and the charter-first method we use to stand up a council that has real decision rights, a working cadence, and a track record of closing issues — usually inside twelve weeks. ## The symptom: councils that meet but don't decide The pattern is familiar to anyone who's sat in one of these meetings. An hour gets scheduled. The right people, mostly, show up. Updates get shared. Someone raises the same access dispute or metric disagreement that came up last time. And the meeting ends with "let's take that offline" — which quietly means nobody is actually accountable for resolving it. None of this is because the people in the room are unserious. It's because the council was formed without the two things that make any decision-making body actually work: a defined scope of what it has the authority to decide, and a process for getting from "raised" to "resolved." Without those, a council is a status meeting wearing a governance council's name. ## Why councils fail Four patterns show up in almost every council we're asked to fix. **No charter, so no authority.** Most councils are formed by an email announcing they now exist, not by a document that says what they're accountable for deciding. Without a charter, every decision the council makes is informally negotiated rather than exercised — which means it can always be relitigated by whoever wasn't in the room. **The wrong people were invited, for the wrong reasons.** Councils tend to grow by invitation, not by design — a stakeholder here, a "should probably be included" there — until the room is too large to decide anything and too political to say no to. A council needs the people who can actually commit their function to a decision, not the people whose feelings would be hurt by exclusion. **No cadence discipline.** A council that meets "as needed" meets less and less often, until it's meeting only when something is already on fire. By then it's doing incident response, not governance. A working council runs on a fixed cadence regardless of whether anything urgent is queued, because the routine is what keeps small issues from becoming board-level ones. **Decisions are made but never documented.** Even councils that do resolve something in the room often fail to write down what was decided, why, and who owns the follow-through. Three months later, nobody remembers the decision was made at all, and the same debate happens again from scratch. None of these are failures of intent. They're the predictable result of standing up a council the way most companies stand up any committee — by naming it, not by designing how it will actually work. ## What it actually costs An underpowered council doesn't fail loudly. It fails by accumulation: - **The same disputes resurface every quarter**, because nothing was ever actually decided the first time, just discussed. - **Access and ownership questions get resolved informally**, by whoever's most senior or most persistent, rather than by a documented process anyone can point to later. - **Audit and compliance exposure grows quietly**, because "who owns this data" turns out not to have a real answer when a regulator, auditor, or acquirer finally asks. - **The data team absorbs the escalation work the council should be doing**, fielding disputes directly because there's no functioning body to route them to. ## Why "just create a council" doesn't work The instinctive fix is to stand up a council: pick a name, invite the obvious stakeholders, put a recurring meeting on the calendar. It rarely holds, because a council without a charter is authority in name only. The first time its "decision" gets quietly overturned by someone who wasn't in the room, everyone learns the council doesn't actually decide anything — and stops treating its meetings as anything more than a status update. The fix has to happen before the first meeting: in the charter, the membership, and the decision rights. That's why we start every governance engagement by chartering the council, not by scheduling it. ## The charter-first approach A charter-first engagement runs in three phases, and the council doesn't hold its first real decision-making meeting until the charter is signed. **Phase 1 — Audit (Weeks 1–2).** We map current data ownership — or the lack of it — by domain, and assess where decisions are currently being made informally, by whom, and how often those decisions get revisited. We identify the two or three domains carrying the highest business risk, since those are usually where the first real council decisions need to happen. **Phase 2 — Design & build (Weeks 3–7).** We draft the council's charter: its scope, its decision rights against a RACI model, its membership, and its quorum rules. We name domain Owners and Stewards, define the standards the council will hold them to, and build the issue escalation path so disputes have somewhere specific to go. The council's first meetings run under this charter, with a real backlog of decisions to work through, not a status update. **Phase 3 — Hand off (Weeks 8–12).** We run the council through its first full decision cycle — a policy approved, an issue resolved, a dispute closed — with the process and documentation to prove it happened. We hand stewardship playbooks to domain owners and set the governance roadmap for the following two quarters, so the council has a specific agenda waiting for it, not a blank one. This is the same discipline behind every Tesatori engagement, sized to governance: audit what exists, design and build the fix directly with your team, then hand off so the council keeps deciding things without us in the room. ## What a council that actually decides looks like It's worth being specific about what "working" means here, because it's not about meeting more often or inviting more people. A working council has a one-page charter that states, in plain language, what it has the authority to decide — new data sources, access to Restricted data, policy approval, cross-domain disputes — and what it doesn't. It has a membership sized to actually commit each function to a decision, not to represent every interested party. It runs on a fixed cadence whether or not anything urgent is on the docket. And every decision it makes gets logged: what was decided, by whom, and who owns the follow-through — so the same debate never has to happen twice. Underneath the council sits the same RACI logic that makes any decision-making body work: for each type of decision, exactly one role is Accountable, a defined set of roles are Consulted beforehand, and everyone else is simply Informed after the fact. Nine standing roles typically cover it — an Executive Sponsor who chairs, the Council itself, and Data Owners, Stewards, Custodians, an Architect, a Security Officer, Business Unit Leads, and Legal, each with a specific, non-overlapping job in the model. ## What it looks like in practice One of our clients — a fast-growing healthcare company — came to us after their auditors asked a direct question: who owns data quality here? Nobody in the room had a confident answer. There was a data team, there were informal owners for a few systems, but there was no single body that could be pointed to as accountable for the answer, in writing. The fix wasn't a new committee announcement. It was a chartered council with a defined scope, named domain owners, and an issue register that showed, concretely, how disputes got raised and resolved. By the time the next audit cycle came around, the answer to "who owns data quality" was no longer a scramble — it was a name, a charter, and a paper trail. In the client's own words, they had an answer now, in writing, with a council behind it. ## Signals you're already living this problem A leadership team usually doesn't need a formal audit to know the council isn't working. A few reliable signals: - The same access or ownership dispute has come up in more than one council meeting without ever being formally closed. - Nobody could produce, on request, a document showing what the council actually decided last quarter. - The council's membership has grown past the point where a decision can get made in the room, not just discussed. - Meetings get skipped or shortened whenever nothing urgent is on fire, rather than running on a fixed cadence regardless. - An auditor, regulator, or acquirer has asked "who owns this data" and the honest answer took more than one sentence. If two or more of these sound familiar, the underlying cause is very likely structural, not a scheduling problem — and worth treating as one. ## Getting started Tesatori's Data Governance engagement is a fixed-scope, 8–12 week program built around exactly this method: a full ownership and risk audit, a chartered council with real decision rights, named domain owners and stewards, and a governance roadmap the council can run against for the following two quarters. It's fixed price at $120,000, with no hourly clock and no ambiguity about what's delivered. It's also deliberately the second of three layers. Reporting exposes where the data can't be trusted; this layer fixes the ownership and decision-making model that caused it; AI governance keeps both in place as AI tools start touching the same data. Most companies are ready for this layer once their reporting is trustworthy but nobody can say, with authority, who's accountable for keeping it that way. ## About Tesatori Technologies Tesatori Technologies is a fractional CDO/CAO advisory that builds the reporting, governance, and AI oversight layers growing companies need before the next board meeting, audit, or AI rollout forces the issue. Engagements are fixed-scope and senior-led, sized specifically for mid-market companies that have outgrown informal data practices but haven't yet built a dedicated data function. **Ready to see whether your council can actually decide?** Book a 30-minute fit call, no obligation, at calendly.com/devon-tesatoritechnologies/30min — or reach us at contact@tesatoritechnologies.com.