How data ownership, policies, access controls, and compliance are defined, enforced, and monitored across the organisation's data assets.
GOV-CON-01
Visibility of data ownership
When you need to ask a question about a dataset you use — what it means, whether you may use it a certain way, or who can approve a change — how easily can you identify the accountable owner or steward?
Maturity level descriptions
No data owners or stewards are identifiable to business users; the Data Consumer has no way of knowing who is accountable for a dataset. The Data Consumer asks whoever they happen to know, or gives up, because no record of accountability exists that they can consult.
Ownership is known informally by long-tenured colleagues but is not documented; the Data Consumer relies on institutional memory and personal networks. The Data Consumer finds the right person by asking around, and that knowledge is lost when colleagues change roles.
Data owners and stewards are formally named and documented for key datasets in a location business users can reach, with basic role descriptions. The Data Consumer can look up the named owner or steward for priority datasets in a register or catalogue without needing to ask a colleague.
Ownership is documented for all datasets business users consume, kept current through a defined review cycle, and contact routes are measured for responsiveness. The Data Consumer finds current ownership information for essentially any dataset they use, and enquiries are answered within a defined expectation.
Ownership information is maintained dynamically in the data catalogue or platform and surfaced to the Data Consumer at the point of use, with no lag when accountability changes. The Data Consumer sees the current accountable contact directly alongside the dataset or report they are using, updated automatically as ownership changes.
GOV-CON-02
Access to data assets
When you need access to a dataset, report or system you do not currently have, how clear, timely and consistently applied is the process for requesting, obtaining and, where relevant, losing that access?
Maturity level descriptions
Access is obtained informally — a verbal request, an ad hoc email, a colleague sharing their own credentials or an extract — with no defined process, approval or record. The Data Consumer gets access by asking someone directly, or receives data second-hand from a colleague, with no approval step and no record of why access was granted.
An informal approval step exists (typically a manager’s say-so), but it is inconsistently applied, not centrally recorded, and the Data Consumer cannot predict how long it will take. Some requests go through a manager for sign-off and others do not, with no central log and no stated turnaround expectation.
A documented access request process exists, is communicated to business users, and requests are recorded in a defined system with requester, approver and justification captured. The Data Consumer submits access requests through a named, repeatable workflow (form, ticket or catalogue request) and each request is logged.
Access is granted against defined roles or tiers rather than individually negotiated, with turnaround measured against a stated expectation and periodic reviews removing access no longer needed. The Data Consumer’s access is derived from their role, requests are fulfilled within a published service expectation, and access they no longer need is proactively removed.
Access provisioning, review and revocation are largely automated and continuously monitored, with the Data Consumer’s access adjusting automatically as their role changes. A role change automatically grants and withdraws the Data Consumer’s data access, and unused or anomalous access is flagged without waiting for a scheduled review.
GOV-CON-03
Terms and conditions of use
When you are granted access to data, how clearly are the applicable terms and conditions of use — what you may do with the data, what you must not do, and your obligations — communicated to and acknowledged by you?
Maturity level descriptions
The Data Consumer is not made aware of any terms and conditions when access is granted; no acknowledgement is expected or recorded. Access simply arrives, with no statement of permitted use, restriction or obligation accompanying it.
Terms are sometimes mentioned informally at the point of access, but inconsistently and with no record of acknowledgement. The Data Consumer is occasionally told verbally or by email not to share data externally, depending on who grants the access.
A defined step in the access process requires the Data Consumer to view and acknowledge applicable terms and conditions before access is granted. The access workflow includes a specific acknowledgement step — a checkbox, signed form or confirmation email — that must be completed before provisioning proceeds.
Acknowledgements are systematically captured, timestamped and auditable for all access grants, with periodic re-acknowledgement required for long-standing access. Every current access grant held by the Data Consumer has a timestamped acknowledgement record, and they are asked to re-confirm periodically rather than only once.
Acknowledgement is enforced technically as a precondition of access, with acknowledgement status visible in real time and access automatically suspended if terms lapse. The provisioning system blocks the Data Consumer’s access until acknowledgement is completed and suspends or flags it automatically if a required renewal is missed.
GOV-CON-04
Policy awareness and everyday compliance
How well do you understand, and consistently follow, the organisation’s data policies in your everyday work — classification and handling of sensitive data, retention, and treatment of personal information — as opposed to relying on general caution?
Maturity level descriptions
No data handling policy is known to the Data Consumer; decisions about sharing, storing and retaining data are made on individual judgement. The Data Consumer decides for themselves whether an extract may be emailed, saved locally or kept indefinitely, with no policy available to consult.
Policies exist and the Data Consumer is aware of them in general terms, but has not read them and practice frequently diverges without correction. The Data Consumer knows policies exist somewhere on the intranet but works from general caution, and non-compliant practice attracts no correction.
Policy is translated into concrete, role-relevant guidance for business users, supported by defined procedures the Data Consumer is expected and trained to follow. The Data Consumer has completed defined training and can follow specific procedures — how to classify an extract, where sensitive data may be stored, how long it may be kept.
Compliance by business users is systematically measured, with controls configured to support correct behaviour and deviations identified through monitoring rather than by accident. The Data Consumer works within systems that enforce classification and handling rules, and compliance is measured and reported (for example through sampling or automated checks).
Policy is enforced continuously and largely automatically at the point of use, with the Data Consumer guided or blocked in real time rather than corrected after the fact. Classification, retention and sharing rules are applied automatically as the Data Consumer works, with violations blocked or flagged immediately and guidance offered in context.
GOV-CON-05
Issue escalation
If you encountered a data governance concern — data you can see but should not, an extract shared inappropriately, or a suspected privacy breach — how clear and effective is the path for raising it?
Maturity level descriptions
No escalation path is known to business users; a concern would be handled informally by whoever noticed, or not raised at all. The Data Consumer would mention it to a colleague, or say nothing, because no defined next step exists.
Concerns are raised reactively through informal channels once noticed, with no ticket, tracking or audit trail. The Data Consumer raises the issue to whoever seems relevant, and any resolution happens without a record of what occurred.
A defined escalation process exists (named contact, reporting category, escalation matrix), communicated to business users and expected to be used. The Data Consumer knows the specific channel to use, and reported concerns reach a defined initial responder with an expected response step.
Concerns raised by business users are logged, tracked to resolution and reviewed for root cause, with response expectations and closure accountability documented. The Data Consumer receives acknowledgement and a resolution outcome within a stated timeframe, and significant issues carry a documented root-cause note.
Detection is proactive — monitoring identifies most governance problems before a business user reports them — and reported patterns feed back into policy and control improvement. The Data Consumer is more often informed of an issue than the one to discover it, and their reports demonstrably trigger control or policy change.
GOV-CON-06
Governance of AI use of data
How clearly do the organisation’s governance rules tell you what you may do with organisational data when using AI/GenAI tools — including pasting data into a chat tool, uploading files, or using AI features embedded in business applications?
Maturity level descriptions
No governance rules address AI/GenAI use of data in terms that reach business users; the Data Consumer proceeds on personal judgement. Organisational data flows into AI tools with no policy coverage the Data Consumer can consult, even if they wished to check.
General data policy is assumed to cover AI use, but this has never been stated explicitly or interpreted for the situations business users actually face. The Data Consumer assumes existing rules on personal information apply to AI tools too, without any confirmation or worked example.
Explicit AI data-use rules exist and are communicated to business users, covering approved tools and baseline prohibitions. The Data Consumer can consult written rules stating which AI tools are approved and what data must never be entered into them.
AI data-use rules are differentiated by use case and data sensitivity, reviewed on a defined cycle, with business-user adherence monitored. The Data Consumer follows rules that differ by scenario (drafting versus analysis, internal versus public tools) and adherence is periodically checked and reported.
AI data-use rules are enforced technically at the point of use and updated proactively as tools and capabilities change. Controls prevent the Data Consumer from submitting restricted data to an AI tool, and rules are updated and communicated before new AI capability is enabled.
GOV-CON-07
Onward sharing and reuse
When you share data you have been given — with a colleague, another business area, an external partner, or by embedding it in a report or briefing — how clear and consistently applied are the rules governing that onward use?
Maturity level descriptions
No rules govern onward sharing; the Data Consumer forwards extracts, reports and files at their own discretion. Data is emailed on, copied into decks and shared with external parties without any rule, check or record.
Informal expectations exist (“don’t send this outside”), communicated inconsistently and dependent on who supplied the data. The Data Consumer is sometimes told a dataset is sensitive, but there is no consistent rule and no record of what was shared with whom.
Documented onward sharing rules exist, differentiated by data classification, and business users are trained in applying them. The Data Consumer can determine from a dataset’s classification whether and how it may be shared, and has been trained in the rule set.
Onward sharing is controlled and recorded — sensitive data carries handling markings, external sharing requires defined approval, and sharing activity is monitored. The Data Consumer’s external sharing goes through a defined approval, sensitive material carries visible markings, and sharing activity is auditable.
Onward sharing controls are applied automatically at the point of action, with the Data Consumer prevented from inappropriate sharing rather than relied upon to avoid it. Technical controls (labelling, data loss prevention, rights management) block or challenge inappropriate sharing in real time, with continuous visibility of where data has travelled.