Putting governance into practice: rules that follow data.

Responsibility before tools

Governance starts with decisions: who can publish, who validates a contract and who decides on access requests. A tool can support the process, but the people taking part need to understand their responsibilities.

Contracts make expectations visible

A data product contract can specify structure, refresh expectations, quality and terms of use. Reviewing a version creates an opportunity to discuss consumer impact. Incompatible changes require a planned transition, with communication and timing suited to the context.

Approval needs to reach consumption

Approving a request is one step. Enforcing authorisation in the consumption channel, tracking its validity and revoking it when needed complete the journey. Evidence should connect the decision to effective access, respecting the limits of each technology.

Give each decision an accountable owner

Publishing a product, approving a contract and granting access are different decisions. Name who proposes, reviews, approves and operates each one. Avoid relying on a generic administrator to stand in for a business owner. Delegation can be useful, but should have a scope and an endpoint. The goal is not more signatures: it is a decision process that remains understandable when people or responsibilities change.

Translate a policy into observable controls

“Only authorised use” is too broad to test. Break it into conditions: a defined purpose, a recognised beneficiary, the relevant dataset or interface, an approval authority and a validity period. Then identify the mechanism that applies each condition. Some checks belong in workflow, others in the data engine or API gateway. A written rule without a corresponding enforcement point is a gap to record, not a control to count as complete.

Handle exceptions without creating invisible permissions

An urgent access request still needs a reason, a responsible approver and a review date. Exceptions should be distinguishable from the normal path and visible to the people accountable for risk. Record the actual permission and its removal, not just the request ticket. When a product is retired or a person changes role, examine the access granted through downstream tools and service accounts as well as the catalogue entry.

Use automation to support judgement

Schema checks, expiry reminders and audit correlation can reduce repetitive work. They do not decide whether a purpose is appropriate or whether a new use needs additional assessment. A useful operating model combines human decisions with consistent execution and evidence. Start with a small number of important policies and automate those that have clear inputs, an explicit owner and a way to verify the outcome.

Measure execution

Observe request-to-decision time, ownership, current contracts and grants needing review. These indicators help identify pending work. The aim is observable governance, without equating activity in a tool with organisational certification.

Questions to take into your next discussion

• Separate proposal, approval and technical execution.
• Link each policy to a verifiable enforcement point.
• Give exceptions a reason, owner and review date.
• Test denied access and effective revocation.