For data nobody can quite explain the origin of
Data Governance Services
Data governance fails quietly when a dataset has no named owner, so a schema change surprises three teams at once and nobody can explain why. This practice assigns real stewardship, enforces access as policy rather than habit, and makes lineage visible enough to survive a hard question.
How ownership gets attached to data that has none
Stewardship, access policy and the lineage work that ends a disputed number.
90 secSample frame · video pending01Before any policy is written
Governance depth is a decision, not a checkbox.
Writing a full governance framework for three internal reports few people see is wasted ceremony, and leaving customer data ungoverned past real regulatory exposure is a genuine risk. Four questions settle how much structure a team actually needs.
Does any of this data carry regulatory duties?
Personal or health-adjacent data brings retention and consent obligations that plain internal metrics simply do not carry.
How many teams touch the same dataset?
A dataset one team owns quietly needs less formal stewardship than one five teams pull from without coordination.
How often does an unexplained number get challenged?
Frequent disputes about where a figure came from are the clearest signal that lineage work is overdue.
Is access already mapped to real roles?
Access built up ad hoc over years usually needs remapping before enforcement can mean anything at all.
| Informal habits | Enforced governance | |
|---|---|---|
| Ownership | Assumed, rarely written down | Named and recorded per dataset |
| Access control | Grown from historical requests | Mapped to current roles and need |
| Lineage | Reconstructed from memory | Traceable from source to report |
| Change safety | Breaks discovered downstream | Reviewed before it ships |
| Right for | A handful of low-risk internal datasets | Regulated or widely shared data |
02Agreed before any policy is set
The ledger that keeps the work honest
Every governance engagement fixes the split before work starts: what you bring, what we build, what comes back, and what never leaves your control regardless of scope.
- Your side
You bring
- The tables and datasets currently lacking a named owner
- The teams affected when one of them changes unexpectedly
- Any past incidents caused by an unannounced schema change
- Our side
We build
- Named stewardship assigned to every core dataset
- A change process requiring notice before a schema shifts
- A catalogue recording who owns what and why
- Your side
You receive
- A stewardship model with a named owner per dataset
- A change process that stops silent schema breaks
- A searchable catalogue your team can actually trust
Never leaves you
- Who is appointed as steward for each dataset
- Authority to approve or block a proposed change
- Priorities for which datasets get stewardship first
Where the line sitsThe stewardship system and catalogue are built here. Naming the actual owner of a dataset is a decision only your organisation can make.
03From unowned data to enforced accountability
Four stages, each closing on an artefact
Governance fails quietly when policy exists only as a document nobody enforces. Each stage in this process closes on a record a stakeholder can verify.
Audit ownership and access
Every dataset is checked against who currently owns it, who can access it, and whether that access still matches a real need.
A map of who touches whatAssign stewardship and write policy
Ownership and access rules are documented and agreed with the people who will actually be accountable for them.
Named stewards and a policyEnforce access and track lineage
Access rules move from a document into the systems themselves, and lineage tracking connects reports back to their raw sources.
Policy enforced in the systemsHand over the governance operation
The catalogue, the policy and the review cadence move to your team, so a new dataset gets governed without calling us.
A system your team can maintain
04What actually drives the number
Four drivers, not a flat rate card
Governance work is priced against the audit, not a template, because these four factors change the effort by multiples.
Number of datasets needing stewardship
A handful of core tables cost far less to govern than an estate spanning dozens of disconnected systems.
Regulatory duties the data carries
Plain internal metrics need light governance. Personal or health-adjacent data brings retention and consent requirements to design around.
How far access has already sprawled
Remapping years of accumulated access grants takes longer than designing policy for a newer, tidier system.
Depth of lineage tracking required
Basic source tracing is quick to add. Full lineage across many transformation steps takes considerably longer.
05Evidence and proof
Data that stayed accountable after the audit ended.
Governance proof is ownership that held, not a policy document filed away. Every record here waits for written client approval before production.
Explore case studies
Every core dataset finally has a name attached to it.
Vela Ledger had tables changing shape with no warning to the teams relying on them. Named stewardship and a change process ended the surprise schema breaks.
- Datasets with a named steward
- All core tables
- Unannounced schema breaks
- Down to zero
Patient data access finally matched real clinical roles.
Koru Health had access permissions accumulated over years with no clear mapping to current roles. A rebuilt access policy tied every permission to an actual need.
- Access grants remapped to roles
- Across the whole platform
- Unexplained access grants found
- Identified and closed
Someone finally asked who owned each table before touching it. That single question prevented the outage we used to have every quarter.
Sample · pending client approval
06Read this first
When a governance build is the wrong spend
Selling a full stewardship programme to a team with three low-risk internal reports would cost more than it earns us in trust. The exits are marked before the pitch. When the build is justified, it runs on catalogue and policy-as-code tooling layered over your existing warehouse and pipelines.
Your data carries no meaningful regulatory exposure
Light internal reporting with low sensitivity rarely justifies a formal stewardship programme on its own.
- Data migration
The real problem is a one-time platform move
If data needs moving to a new system once, that is a migration project, not an ongoing governance build.
Your team should own this work directly
If your people understand the regulatory duties and just need capacity, extending it internally is the faster route.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Scoped audit | The exposure and scope are unclear | Priorities from the fix list | The audit and policy design |
| Delivery pod | Governance work spans several practices | Roadmap decisions each cycle | Engineering, enforcement, documentation |
| Team extension | Your leads already run this well | Standards and interpretation | Named engineers and continuity |
07Straight answers
Asked before a governance programme starts.
01Do you provide certified compliance guarantees?
No. This practice designs governance around real regulatory duties, including GDPR-style retention and consent requirements, but a certification claim is not something this team issues or represents. Your legal counsel remains the authority on compliance status.
02How is governance different from a data migration?
Governance assigns ongoing ownership, access rules and lineage tracking to data that keeps living where it is. Migration moves data once to a new platform. Many engagements govern data before or after a migration, but the two are distinct pieces of work.
03What does stewardship actually mean in practice?
A named person or team accountable for a dataset's accuracy, access and change process, recorded somewhere the whole organisation can check. Stewardship without a name attached tends to quietly disappear the first time something breaks.
04Can you fix access without a full governance programme?
Often yes. Access remapping can run as a contained piece of work when regulatory exposure or a specific incident makes it urgent, without committing to a full stewardship rebuild immediately.
05How do you handle regulated data like health or financial records?
By treating retention, consent and access as design requirements from the first architecture decision, not an afterthought. The practice does not claim a certification, but the design work reflects what those regulatory duties actually require.
06What does a governance engagement cost?
The audit is scoped small and fixed. Stewardship and access enforcement are priced from the resulting fix list, weighted by how many datasets and how much regulatory exposure is involved.
07Will our team be able to maintain governance afterwards?
That is the design goal from the first week. The catalogue, the policy and the review cadence move to your team, so governing the next new dataset does not require bringing us back.