Data Access Governance vs DSPM: Which, When and How

Data access governance asks who can reach a data store and whether they should, while data security posture management (DSPM) asks what sensitive data sits where and how exposed it is, and most organisations buy one expecting it to answer both questions. The two disciplines start from opposite ends: one from identities and entitlements, the other from the data itself. They meet in the middle at effective access, where service accounts, workload roles, signed URLs and AI agents quietly accumulate reach that neither view sees on its own. This guide compares the two for data security, identity governance and cloud security teams: the threat model each one answers, how each is built, how each fails, where products now converge, how both connect to identity governance and administration (IGA), and how to choose and combine them. It does not repeat the foundations: for the operating model see the Data Access Governance Guide, and for discovery and classification see Data Security Posture Management (DSPM). Where cloud and data platform features are named they are examples of documented capabilities, listed alphabetically, not recommendations.

Key takeaways

Short answer: DAG is entitlement-centric, DSPM is data-centric. DAG starts from a principal and walks to the data it can reach; DSPM starts from a sensitive data asset and walks back to who and what can reach it. You need both views to answer "is this regulated data reachable by something that should not reach it?"
Non-human access is the gap between them. Workload roles, service users and agents rarely sit in the IGA catalogue that DAG reviews, and DSPM tools often report "who can access" from resource policies without knowing the owner or purpose of the identity.
Not every access path is an identity. Shared links, signed URLs and SAS tokens grant access to whoever holds them; DSPM exposure findings catch these, entitlement reviews usually do not.
Products are converging, but the decision rights are not. DSPM platforms now show permissions and DAG tools now classify data; the open question is who approves, revokes and certifies, which should stay in identity governance.
Combine them through one join key. Feed DSPM sensitivity onto entitlements in IGA so reviewers see what an entitlement exposes, and feed IGA ownership into DSPM so every exposure finding has an accountable owner.

The short comparison

Dimension	Data access governance (DAG)	DSPM
Starting point	Identities, groups, roles and their entitlements	Data stores, objects, tables and columns, classified by sensitivity
Core question	Who can access this data, who approved it, is it still needed?	Where is our sensitive data, how is it configured, how exposed is it?
Primary output	Permission maps, owner-led reviews, revocations, access requests	Data inventory, sensitivity labels, exposure and misconfiguration findings, risk scores
Typical data in scope	File shares, collaboration sites, SaaS repositories, databases and warehouses	Cloud object storage, managed databases, warehouses, SaaS and increasingly AI training stores
Access paths seen	Identity grants: ACLs, group membership, roles, database grants	Resource policies, public and cross-account sharing, links, and grants where the platform exposes them
Decision maker	Data owner or entitlement owner, through IGA workflow	Security team triaging findings, then the data or platform owner
Cadence	Periodic certification plus event-driven review on joiner, mover, leaver	Continuous or scheduled scanning with re-profiling on change
Weak spot	Does not know which of the reachable data is sensitive unless classification is fed in	Does not know whether an access grant is justified or who owns the identity

Option profiles: threat model, architecture, failure modes

Data access governance

Threat model: excessive and stale access. Former project members still in a group, broad "everyone" permissions on shares, privilege creep through role accumulation, and identities whose compromise would expose far more data than their job needs. The attacker it plans for is the one who holds valid credentials, which ATT&CK tracks as T1078.004 Cloud Accounts when the credentials are for cloud identities, followed by collection such as T1530 Data from Cloud Storage.

Architecture in words: connectors read permissions from each repository (ACLs, sharing settings, database and warehouse grants) and resolve nested groups into effective access per identity. Activity logs show which of those permissions are used. A data owner is assigned per repository or folder, and access requests, reviews and revocations run through workflow, ideally the organisation's IGA platform. Query-level logs make usage analysis possible: Snowflake's ACCESS_HISTORY view, for example, records the objects a query names directly and the base objects that supply the data, along with the user, in a record per SQL statement (Enterprise Edition or higher).

Failure modes: reviews that rubber-stamp because the reviewer cannot see what the permission exposes; owners never assigned, so findings land on IT; connectors covering file shares but not the warehouse; and service accounts excluded because "they are not people".

Controls it delivers: least privilege on data (NIST SP 800-53 AC-6), account management (AC-2), owner accountability, provable review evidence for auditors, and revocation of unused grants.

DSPM

Threat model: sensitive data in the wrong place or wrongly configured. Shadow copies of production data in development accounts, snapshots shared outside the organisation, unencrypted stores, publicly reachable buckets, and AI training data containing personal data. The attacker it plans for is the one who finds an exposed store, or the insider who copies data into a place no control watches.

Architecture in words: agentless discovery through cloud and SaaS APIs builds an inventory of stores, samples content, classifies it and attaches risk context: exposure, encryption, location and, increasingly, who can access it. Amazon Macie continually evaluates the S3 bucket inventory and samples representative objects, creating policy findings for bucket security issues such as a bucket becoming publicly accessible and sensitive data findings for objects. Google Cloud Sensitive Data Protection builds data profiles for BigQuery, Cloud SQL, Cloud Storage and Vertex AI training data with calculated data risk and sensitivity levels, re-profiling on change or on a daily, weekly or monthly schedule. Microsoft Purview DSPM describes itself as answering what data you have, where it is stored, who can access it and how it is protected, with data risk assessments for oversharing and remediation such as removing public sharing links.

Failure modes: an inventory with thousands of findings and no owner for any of them; classification that misses the organisation's own data types; "who can access" reported as a raw count of principals with no context; and scanning that covers cloud object storage but not the SaaS repositories where most collaboration data lives.

Controls it delivers: data inventory (CSF 2.0 ID.AM-07), protection of data at rest (PR.DS-01), detection of misconfiguration and shadow data, and evidence of where regulated data lives for privacy obligations.

Entitlement-centric vs data-centric: why the direction matters

The two tools traverse the same graph of identities, permissions and data, from opposite ends. That choice decides what each finds first and what each misses.

From the identity (DAG): "This role can read 40 databases." Useful for least privilege, but the reviewer still needs to know that three of the 40 hold payment data, otherwise all 40 look equally important.
From the data (DSPM): "This table holds 2 million national insurance numbers and 312 principals can read it." Useful for prioritising, but the analyst still needs to know which of the 312 are justified and who owns each, otherwise the finding cannot be closed.
The join: effective access, meaning the permissions that actually resolve after group nesting, role chaining, resource policies and deny rules. Ask every product how it resolves nested groups, role assumption and cross-account trust.

Cloud identity tooling offers a third, overlapping view. AWS IAM Access Analyzer, for example, has three analyser types: external access (resources shared outside the zone of trust, including S3, KMS keys, RDS and DynamoDB), internal access (which principals inside the account or organisation can reach selected critical resources such as S3 buckets, RDS snapshots and DynamoDB tables) and unused access (unused roles, access keys, passwords, services and actions for IAM roles and users). That is DAG-style analysis from the platform itself, a baseline to reconcile any product against.

Non-human identity access paths to data stores

Most data in cloud warehouses and object stores is read by machines: pipelines, applications, analytics jobs and, increasingly, AI agents and retrieval systems. These paths are where DAG and DSPM disagree most, and where breaches happen.

Access path	Example	Seen by DAG?	Seen by DSPM?	Control to add
Workload role or managed identity	An application role with read on many buckets	Only if the role is onboarded as an entitlement with an owner	Usually, as a principal with access to the store	Owner and purpose on every role; unused-access findings feed revocation
Service user with static credential	A warehouse service user used by an ETL tool	Often excluded from reviews	Listed among principals, owner unknown	Register in the NHI inventory, move to key-pair or federated auth, review like a privileged account
Bearer link or signed URL	Shared link, presigned URL, SAS token	No: no identity to review	Yes when the platform reports sharing or public exposure	Short expiry, narrow scope, scanning for links in code and documents
Cross-account or third-party trust	A vendor role assumed into your account	Rarely, unless third parties are catalogued	Yes as external or cross-account access	Third-party ownership and expiry in IGA; external access findings reviewed monthly
OAuth app or SaaS integration	An integration with read on all files in a tenant	Sometimes, through SaaS connectors	Sometimes, through SaaS scanning	App consent governance and scope review
AI agent or retrieval index	An assistant that can read any document the user or its service identity can	Only through the underlying identity	Increasingly, through AI activity views	Scope agent identities to curated sources; review what the index ingests

Two incidents show the two halves. In the Capital One breach, temporary credentials for a firewall's workload role could list and read far more S3 buckets than the firewall needed: an entitlement problem that a data-centric view would have flagged only as "many principals can read this bucket". In the Microsoft SAS token exposure, a token scoped to an entire storage account with full control and a far-future expiry was published in a public repository: no identity was over-entitled, so only an exposure view of the data or secret scanning could catch it. For the identity side of this problem see the NHI Inventory Reconciliation guide.

Microsoft Purview DSPM now lists AI observability and reports on risky behaviour of users and AI agents, and Google profiles Vertex AI training data. This is the clearest example of convergence: DSPM products are moving towards "who and what is touching this data", which was traditionally DAG territory. For the agent-specific review process see AI data access review.

Where products converge, and where they should not

The overlap between the product categories is real, but uneven.

Converged well: discovery and classification (both need it), basic "who has access" lists, public and external sharing detection, and remediation of open links.
Still distinct: owner assignment, access request and approval, certification evidence and segregation of duties. These are governance workflows with audit consequences and belong in IGA, not in a posture console.
Often thin in both: effective access through nested groups and role chains, usage-based right-sizing for service identities, and coverage of on-premises file shares alongside cloud warehouses.

A practical test: ask a vendor to take one sensitive table and show, in one screen, every identity that can read it (human and non-human), how each got that access, when each last used it, who owns each identity, and the button that starts a revocation through your IGA workflow. Products that stop after the first item are posture tools; products that cannot do the first item without your classification are governance tools.

Integration with identity governance (IGA)

The combination works when each system does what it is good at and passes the result on.

DSPM to IGA: sensitivity onto entitlements. Tag each entitlement (group, role, database grant, share) with the highest sensitivity of the data it exposes. Reviewers then see "this group grants read on payment data" instead of a group name. Prioritise certification campaigns by sensitivity.
IGA to DSPM: ownership onto findings. Every principal in a DSPM finding should resolve to an owner from IGA or the NHI inventory, so the finding routes to a person who can act. Unresolvable principals are themselves a finding.
DAG to IGA: usage onto reviews. Push last-used dates from activity logs into reviews so unused access is pre-marked for removal. Microsoft Entra access reviews, for example, offer recommendations to help reviewers decide, and cover groups, enterprise apps, roles and access packages.
IGA to both: lifecycle events. Leaver and mover events should trigger data-access re-evaluation, and workload decommissioning should trigger removal of the role's data grants.
Close the loop in the ticket. Revocations happen through IGA or the platform's own policy, not by a posture tool editing permissions directly without a record, unless that automated remediation is itself approved and logged.

See the Access Reviews Guide for campaign design and the Entitlement Catalogue Guide for making data entitlements reviewable.

Decision guidance

Situation	Lead with	Why
Audit finding on excessive access or missing reviews	DAG	The finding is about entitlements and evidence; DSPM does not produce certification records
You do not know where regulated data lives in cloud accounts	DSPM	Reviews are meaningless until you know which stores matter
Heavy on-premises file shares and collaboration sites	DAG	Permission sprawl on shares is the classic DAG problem
Cloud-first, many accounts, warehouses and data lakes	DSPM first, then DAG on the top stores	Inventory and exposure first, then right-size access on the stores that hold the most sensitive data
AI assistants and agents getting access to enterprise content	Both	DSPM finds what the agent can reach; DAG and IGA scope and review the agent's identity
Small organisation with one cloud and one SaaS suite	Native tools	Cloud-native posture and access analysis plus platform sharing reports may be enough before buying either

Small vs large organisations: smaller teams can start with platform-native capabilities and a register of owners. Large organisations need a product on each side, or one that genuinely does both, plus IGA integration; the hidden cost is owner time for reviews and triage, not licences.

Worked scenario

A retailer's DSPM scan finds a warehouse schema containing customer card holder names and partial card numbers copied from production for a fraud model. The finding lists 140 principals with read access.

Resolve principals: 96 are human users through two broad analyst roles, 31 are service users for BI and ETL tools, 9 are workload roles from two cloud accounts, and 4 cannot be resolved to any owner.
Add usage: query history shows only 22 principals queried the schema in 90 days, including 6 service users.
Route through IGA: the two analyst roles are tagged with the schema's sensitivity and put into an urgent review by the data owner; the 4 unowned principals are disabled after a notice period; unused service users lose the grant.
Fix the data, not just the access: the data owner decides the model needs tokenised card data only, so the copy is replaced and DSPM confirms the sensitive columns are gone.
Prevent recurrence: new schemas in that warehouse inherit a restricted default role, and DSPM alerts if card data reappears outside approved stores.

DSPM found the exposure; governance decided which access was justified and removed the rest with evidence.

Phased approach to combining them

Agree scope and owners (weeks 1 to 4): list data domains, name an owner per domain, and agree which repositories each tool covers. Decide which system is authoritative for ownership (normally IGA).
Inventory and classify (months 1 to 3): run DSPM discovery in report-only mode, tune classifiers on your own data types, and agree a sensitivity scale shared by both tools.
Map effective access on the top stores (months 2 to 4): pick the 20 stores with the most sensitive data and resolve every principal, human and non-human, to an owner. Reconcile against platform-native access analysis.
Integrate (months 3 to 6): push sensitivity tags into IGA, push owners into DSPM findings, and run a pilot certification campaign on the top stores only.
Automate cautiously (month 6 onwards): enable automated remediation for low-risk, reversible actions such as removing anonymous links, with a log and a rollback path. Keep revocation of identity grants in workflow.
Rollback: every automated action records the previous permission so it can be restored; pilot automation on non-production accounts first.

Detection and measurement

Sensitive stores with an owner: percentage of DSPM-classified sensitive stores with a named data owner. Target near 100% for regulated data.
Resolved principals: percentage of principals with access to sensitive stores that resolve to an owner in IGA or the NHI inventory.
Unused access on sensitive data: number of grants to sensitive stores unused for 90 days, trending down.
Exposure findings closed in SLA: public, external and link-based exposure findings closed within the agreed time.
Sensitivity-informed reviews: share of certification items that show the sensitivity of data exposed.
Non-human coverage: share of service identities with data grants included in review campaigns.

Log sources: data platform query logs, cloud control plane logs for policy and sharing changes, IGA decision logs and DSPM finding history.

Common failure patterns

Buying DSPM to pass an access review audit: it produces findings, not certification evidence; the audit gap remains.
Running reviews without sensitivity: reviewers approve everything because every group looks the same.
Leaving machines out: service users and workload roles excluded from DAG scope while holding the broadest data reach, the pattern in the Capital One case.
Ignoring bearer access: signed URLs and shared links treated as configuration rather than credentials, so no review or expiry applies.
Two inventories, no join: DSPM and IGA each keep their own owner list and they drift apart within months.
Automated revocation without a record: a posture tool removes access, an application breaks, and nobody can show who changed what.

Framework mapping

Framework	Reference	DAG	DSPM
NIST CSF 2.0	ID.AM-07 Inventories of data and metadata	Supports	Primary
NIST CSF 2.0	PR.AA-05 Access permissions managed and reviewed with least privilege	Primary	Supports
NIST CSF 2.0	PR.DS-01 Data at rest protected	Supports	Primary
NIST SP 800-53 Rev. 5	AC-2 Account Management, AC-6 Least Privilege	Primary	Supports
NIST SP 800-53 Rev. 5	CM-8 System Component Inventory, RA-3 Risk Assessment	Supports	Primary
NIST SP 800-53 Rev. 5	AC-21 Information Sharing	Supports	Primary for external and link sharing
CIS Controls v8.1	Control 3 Data Protection (data inventory, access control lists)	Yes	Yes
MITRE ATT&CK v20	T1078.004 Cloud Accounts, T1530 Data from Cloud Storage	Limits blast radius of valid accounts	Finds exposed and sensitive stores

Practitioner checklist

Decide which system owns data ownership records and make the other consume it.
Agree one sensitivity scale used by DSPM classification and IGA entitlement tags.
Resolve every principal on your top 20 sensitive stores to an owner, including service users, workload roles and agents.
Reconcile product access maps against platform-native access analysis on at least one account.
Treat signed URLs, SAS tokens and shared links as credentials with expiry and scope limits.
Put data sensitivity in front of reviewers in every certification campaign.
Keep identity grant revocation in IGA workflow; automate only reversible, low-risk remediation.
Report the six metrics above to the data governance forum monthly.

Data Access Governance vs DSPM: Combining Entitlement and Data Risk Views