Data Access Governance Guide: Who Can Access Data

Most organisations can tell you who has an account on a system, but very few can answer the question an auditor, a regulator or an incident responder actually asks: who can read this sensitive dataset, through which path, and why? Data access governance (DAG) is the discipline that answers it. It joins three things that usually live in different teams: knowing where sensitive data is, knowing every identity and permission path that reaches it, and having a business reason and an owner for each of those paths. This guide is for security, data platform and identity governance practitioners. It covers the operating model, how to inventory effective access across warehouses, lakes, SaaS and file stores, how to govern service accounts and AI agents that read data, policy models, enforcement points, detection, metrics and framework mapping.

Key takeaways

Govern the data, not just the account. Identity governance tells you what an identity is entitled to; DAG starts from a sensitive dataset and works back to every identity, group, role, share link and integration that can reach it.
Effective access is the only access that matters. Nested groups, inherited roles, public links, views and API integrations mean the permission you granted is rarely the access that exists. Compute it, do not assume it.
Non-human identities hold most of the bulk access. ETL jobs, BI service accounts, connected apps, OAuth integrations and AI agents read whole tables, often with no owner and no review. Put them in scope from day one.
Every grant needs an owner and a reason. Data owners approve, review and revoke; a grant without a recorded purpose and expiry is a finding, not a default.
Detection closes the loop. Query and access logs show which permissions are used, which can be removed and which access is anomalous, and they are the evidence for reviews.

What data access governance covers

DAG sits where data security and identity governance overlap. Data discovery and classification tell you what is sensitive; identity governance tells you who holds which entitlements; DAG binds them so that access to each sensitive dataset is known, justified, minimal and monitored. It is narrower than data governance (quality, lineage, catalogue) and broader than a single platform's permission model.

Discipline	Starting question	Main output	Where DAG adds
Data classification	What is this data and how sensitive is it?	Labels and tags on datasets	Uses labels as the scope and as policy attributes
DSPM	Where is sensitive data and how is it exposed?	Data inventory, exposure findings	Turns exposure findings into owned, reviewed grants
Identity governance (IGA)	What can this identity do?	Joiner, mover, leaver, access reviews	Reverses the view: who can reach this dataset?
Cloud entitlement management (CIEM)	Which cloud permissions are excessive?	Right-sizing recommendations	Adds data sensitivity so the riskiest excess is fixed first
Data loss prevention (DLP)	Is sensitive data leaving?	Blocks and alerts on egress	Reduces how many identities could exfiltrate in the first place

For the classification and posture inputs, see the Data Classification Guide and the DSPM Buyer's Guide. For the wider control set, see the Data Security Guide.

Operating model: owners, stewards and decisions

DAG fails most often for organisational reasons, not technical ones. Before buying anything, decide who makes which decision.

Data owner: a named business role (not IT) accountable for a dataset or data domain. Approves access requests above a sensitivity threshold, signs off periodic reviews and accepts residual risk.
Data steward or custodian: the platform or data engineering team that implements grants, tags, policies and masking, and keeps the catalogue accurate.
Security: sets the policy (what sensitivity requires which controls), monitors access, and runs exception handling.
Privacy / DPO: confirms that the purpose of access is compatible with the purpose for which personal data was collected. NIST SP 800-53 PT-3 (Personally Identifiable Information Processing Purposes) and PT-2 (Authority to Process Personally Identifiable Information) express the same idea. See the Data Mapping and ROPA Guide.
Identity governance team: runs request, approval and certification workflows, and links each grant to a joiner, mover or leaver event.

Write the decisions down as a short access standard per sensitivity tier, for example: Restricted data needs owner approval, a recorded purpose, an expiry of no more than 90 days for humans, masking by default and quarterly review; Confidential data needs manager plus owner approval and semi-annual review. The numbers are yours to set; the point is that they are set before the first request arrives. NIST CSF 2.0 GV.RR-02 covers establishing these roles and authorities.

Inventory effective access to sensitive data

The core technical task is to compute, for each sensitive dataset, the full set of identities that can read, write, export or share it, and through which path. Granted permissions are only the start.

Access path	Where it hides	How to surface it
Nested groups and inherited roles	Directory groups inside groups; warehouse role hierarchies where one role is granted to another	Expand the graph to the leaf identity; report depth and inheritance chain
Ownership and admin roles	Database owners, account admins, project owners who bypass object grants	List admin and owner roles per platform; treat them as full read on everything beneath
Views, shares and replicas	A view or data share exposing a sensitive base table to a wider audience	Trace lineage from base table to every view, share, extract and copy
Public and anyone-with-link sharing	File shares, cloud storage objects, signed URLs and SAS tokens	Scan storage and collaboration platforms for public or external links on sensitive items
Cloud IAM on storage	Bucket policies, storage account keys, wildcard actions such as read on all objects	CIEM or cloud-native analysers, filtered to stores tagged sensitive
Integrations and connected apps	OAuth apps, ETL tools, BI connectors, SaaS connected apps with API or export permission	Inventory each integration's scopes and the service identity behind it
AI assistants and agents	Agents with tool access to warehouses, document stores or retrieval indexes	Treat each agent and each retrieval index as an identity and an access path

Scope first: start with the datasets tagged Restricted or containing regulated data (payment card, health, special category personal data). NIST CSF 2.0 ID.AM-07 asks for inventories of data and corresponding metadata for designated data types; NIST SP 800-53 PM-5(1) asks for an inventory of personally identifiable information.
Normalise permission levels: map each platform's privileges to a common set such as read, write, delete, share/grant, export/bulk and admin, so a reviewer sees "can export all rows" rather than a vendor privilege name.
Record the identity type: human employee, contractor, service account, integration, AI agent, anonymous or public. The review route differs for each.

The Microsoft SAS token exposure shows why links must be in the inventory: a single account-level token in a public repository granted full control over a storage account holding about 38TB of internal data, and its expiry had been extended to 2051. No directory group or role review would have found it.

Non-human identities and AI agents

In a typical data platform, a handful of service identities move or read far more data than all human users combined. They are also the identities least likely to have an owner, an expiry or a review.

Service accounts for pipelines and BI: give each pipeline its own identity scoped to the schemas it actually reads, not a shared "etl_user" with read on the whole warehouse. Replace passwords with key pairs, OAuth client credentials or workload identity federation. See the Service Account Security Guide.
Connected apps and OAuth integrations: restrict who can approve them, allowlist approved apps, and limit API and bulk export permissions to integrations that need them. See the SaaS and OAuth App Governance Guide.
AI agents: an agent that queries a warehouse or reads a document store should act under its own identity, or on behalf of the requesting user with that user's permissions, never under a broad shared service account. Enforce limits in the data platform and the tool layer, not in the prompt. See the AI Agent Authorisation Guide.
Retrieval indexes: a vector index built from documents with different permissions flattens those permissions unless the source access control lists are carried into retrieval and checked at query time. See the Permission-Aware RAG Guide.
Ownership: every NHI with access to sensitive data needs a named human owner who answers its review, and is reassigned when that person leaves. See the NHI Ownership Guide.

The ShinyHunters Salesforce campaign is the clearest recent example: employees were talked into authorising a modified Data Loader as a connected app, which then ran API queries that extracted entire tables. The app became a persistent non-human identity with bulk export rights that no one had decided to grant.

Policy models for data access

How you express data access policy decides whether governance scales. Three models are common, and mature programmes combine them.

Model	How it works	Good for	Watch out for
Role-based (RBAC), SP 800-53 AC-3(7)	Permissions granted to roles, roles granted to identities	Stable job functions, auditor familiarity	Role explosion; roles accumulate access and are hard to review
Attribute or tag-based (ABAC), SP 800-53 AC-3(13)	Decision compares attributes of the subject, resource, action and environment against policy (NIST SP 800-162)	Large estates: one policy on a classification tag covers every new table that receives the tag	Tag quality becomes a security control; untagged data falls outside policy
Purpose or request-based	Access granted per project or purpose with an approver and an expiry	Analytics, data science, third-party sharing, personal data	Needs workflow and automatic expiry, or grants become permanent

Use classification tags as policy attributes: NIST SP 800-53 AC-16 (Security and Privacy Attributes) covers binding attributes to information. Data platforms implement this as tag-based grants; for example, AWS Lake Formation LF-Tags let administrators assign tags to databases, tables and columns and grant permissions on tag expressions. AWS's documentation notes that named-resource grants scale with principals multiplied by resources, while tag-based grants scale with principals plus resources.
Apply row and column controls: row access policies and column masking let one table serve several audiences without copies. Masking and tokenisation reduce what a permitted reader sees; see the Tokenisation and Data Masking Guide.
Separate duties: the person who requests access should not approve it, and data engineers who administer a platform should not routinely read Restricted data in it. See the Segregation of Duties Guide. For model choice in depth, see the Authorisation Models Guide.
Prefer time-bound grants: standing access to Restricted data should be the exception. See the JIT Access Guide.

Enforcement points

Policy must be enforced where data is read. Most estates need several enforcement points, and DAG keeps them consistent.

Data platform native controls: warehouse and lakehouse grants, row access and masking policies, and tag-based access. This is the most precise layer and should be the primary one for structured data.
Cloud storage IAM: bucket and container policies, blocking public access at the account level, preferring short-lived, revocable signed access over account keys.
Collaboration and file platforms: sharing policies that block anonymous links on labelled content, external sharing restricted by domain, expiry on guest access.
Network and session controls: network policies or allow lists on data platforms so a valid credential from an unexpected network is refused.
Brokered access: a policy layer or proxy in front of several platforms can enforce one policy across them. It adds a dependency and must not be bypassable through direct credentials.

The Snowflake customer breaches of 2024 illustrate the gap between data permissions and access conditions: valid passwords stolen by infostealers, on accounts without MFA or network allow lists, were enough to export data from about 165 organisations' instances. Good grants did not help once any identity with those grants could sign in from anywhere.

Request, approval and review

NIST SP 800-53 AC-2 (Account Management), AC-6 (Least Privilege) and AC-6(7) (Review of User Privileges) are the control anchors. In data terms:

Request: the requester selects a dataset or data product, not a raw privilege, and states the purpose and duration.
Approve: the data owner approves for Restricted data; policy can auto-approve low sensitivity requests that match the requester's attributes.
Provision: grants are applied by automation to a group or role tied to the request, so they can be removed by the same route.
Expire: time-bound grants are removed automatically; extensions need a fresh approval.
Review: owner-centric reviews list every identity that can reach the dataset, with last-used date and identity type. Include NHIs and integrations in the same campaign.
Revoke and verify: confirm removal in the platform, not just in the workflow tool.

Usage data changes reviews: an owner who sees "service account, read on all customer tables, last used 200 days ago" revokes it; an owner who sees a role name approves it. See the Access Reviews Guide.

Detection and measurement

Monitor access to sensitive data for both hygiene (unused access) and threat (abnormal use). NIST SP 800-53 AU-2 (Event Logging), AU-12 (Audit Record Generation), AU-6 (Audit Record Review, Analysis, and Reporting) and AC-2(12) (Account Monitoring for Atypical Usage) apply.

Collect object-level access logs: warehouse query and access history, cloud storage data-plane logs (which are often off by default), SaaS API and export events, and file sharing audit events. Snowflake's ACCESS_HISTORY view, for example, records the objects and columns each query read and wrote, including base tables behind views, and requires Enterprise Edition or higher.
Alert on: bulk reads or exports well above an identity's baseline; first access to a Restricted dataset by an identity; access from new networks, client tools or user agents; a service identity used interactively; new public or external links on labelled data; grant changes on Restricted objects outside change windows.
Map to attacker behaviour: MITRE ATT&CK T1530 (Data from Cloud Storage), T1213 (Data from Information Repositories), T1078.004 (Cloud Accounts) and T1567 (Exfiltration Over Web Service) describe the patterns these alerts should catch. See the Data Exfiltration Guide.

Metric	What it shows	Direction
% of Restricted datasets with a named owner and complete effective-access inventory	Coverage of the programme	Towards 100%
Identities with access to Restricted data, by type (human, NHI, agent, public)	Exposure size, and whether NHIs are counted	Down, with zero public
% of grants to Restricted data unused in 90 days	Excess access to remove	Down
% of grants to Restricted data with expiry	Standing versus time-bound access	Up
Review completion and revocation rate per campaign	Whether reviews are real or rubber-stamped	Completion near 100%; a zero revocation rate is a warning
Median time from leaver or project end to removal of data access	Lifecycle effectiveness	Down

Implementation roadmap

Weeks 1 to 4, scope: pick two or three high-value data domains (for example customer, payment, HR). Name owners. Agree sensitivity tiers and the access standard per tier.
Weeks 4 to 10, discover: run discovery and classification on those domains, then compute effective access including NHIs, integrations, links and admin roles. Do not change anything yet; measure the baseline metrics above.
Weeks 8 to 14, quick wins: remove public and anonymous access, unused grants older than 90 days, and orphaned service accounts. Run changes in a pilot domain first, keep an export of every removed grant so it can be restored within hours, and announce a contact route for broken access.
Months 3 to 6, policy: move Restricted data to tag-based grants and masking by default; introduce request, approval and expiry workflows; bring NHIs and connected apps into the same review.
Months 6 onward, monitor and extend: switch on object-level logging and alerts, run owner-centric reviews with usage data, and add the next data domains.

Small organisations can do most of this with platform-native tags, grants and audit logs plus a spreadsheet of owners; the discipline matters more than the tooling. Large organisations with many platforms usually need a DAG, DSPM or data security platform to compute effective access across estates; test that it handles your NHIs and SaaS integrations, not only human users. See the Data Security Platform Buyer's Guide.

Framework mapping

DAG activity	NIST CSF 2.0	NIST SP 800-53 Rev. 5
Data inventory and classification	ID.AM-07	PM-5(1), RA-2
Roles and decision rights	GV.RR-02	PT-2, PT-3
Least privilege, grants and reviews	PR.AA-05	AC-2, AC-3, AC-6, AC-6(7)
Attribute and role-based policy	PR.AA-05	AC-3(7), AC-3(13), AC-16
Sharing with other parties	PR.AA-05	AC-21
Protection of stored data	PR.DS-01	SC-28
Monitoring access	DE.CM-03	AU-2, AU-6, AU-12, AC-2(12)

The NIST Privacy Framework (version 1.0, with version 1.1 published as an initial public draft) is the privacy counterpart and helps align DAG with privacy risk management. CIS Controls v8.1 Control 3 (Data Protection) covers identifying, classifying, securely handling, retaining and disposing of data, and is the natural CIS anchor.

Common failure patterns

Reviewing accounts instead of data: entitlement reviews by manager approve role names and never ask who can read the customer table. Add owner-centric, dataset-first reviews.
Leaving NHIs out: the human access review is clean while one pipeline account and three connected apps can export everything. The ShinyHunters campaign above turned on exactly this gap.
Trusting granted permissions: nested groups, views and data shares widen access beyond what any approver saw. Compute effective access before reporting on it.
Ignoring links and tokens: signed URLs, SAS tokens and anyone-with-link shares are access grants outside identity systems; long expiries make them permanent.
Tags without quality control: tag-based policy is only as good as tagging. Untagged sensitive tables silently fall outside policy; alert on new tables in sensitive schemas without a tag.
Grants without conditions: correct permissions on accounts with no MFA, no network restriction and no credential rotation, as in the Snowflake customer breaches.

Practitioner checklist

Name a business owner for every Restricted dataset and write an access standard per sensitivity tier.
Compute effective access for Restricted data, including nested groups, admin roles, views, shares, links and integrations.
Record the identity type for every path and include service accounts, connected apps and AI agents in scope.
Remove public and anonymous access to sensitive data and replace long-lived links with short, revocable ones.
Move Restricted data to tag-based grants with masking by default, and alert on untagged tables in sensitive schemas.
Require purpose, approver and expiry for human access to Restricted data.
Run owner-centric reviews that show last-used date and identity type, and verify revocation in the platform.
Enable object-level access logging and alert on bulk reads, first access and unusual networks.
Restrict sign-in to data platforms by MFA and network policy, for humans and service identities alike.
Track the six metrics above and report them to data owners each quarter.

Data Access Governance Guide: Who Can Access Sensitive Data and Why