TL;DR
Data access governance is the set of policies, roles, and controls that decide who or what can reach specific enterprise data, under what conditions, and for how long. In practice, it runs on RBAC and ABAC, enforced through least-privilege defaults and periodic access reviews.
Key Takeaways Data access governance is the policy and control layer that decides who or what can reach specific data, distinct from broader data governance and from identity and access management. Role-based access control should be the default model. Attribute-based access control adds context like sensitivity, location, and time only where roles alone are too coarse. Least privilege fails in practice through copied permissions, standing access, and approvals with no expiration date, not through a missing policy document. Access reviews only work when they are risk-based, prioritizing privileged and sensitive-data access over a blanket calendar sweep of every entitlement. AI agents and service accounts need their own access governance model, including machine-speed revocation, because they cannot be governed the same way as human employees. Kanerika’s Microsoft Purview-based governance work improved data classification accuracy by 72% and brought data breaches to zero for a global bank consolidating access across SAP, Dynamics 365, and core banking systems like Oracle and Netezza. Watch on YouTube
Microsoft Purview + Databricks Integration: 4 Setup Mistakes to Avoid
Four real setup mistakes teams make connecting Microsoft Purview to Databricks, several of them tied directly to access policy and permission configuration.
A Login That Should Never Have Worked Verizon’s 2025 Data Breach Investigations Report found that credential abuse played a role in 22% of breaches, and stolen credentials were involved in 88% of attacks against web applications specifically.
Most of those credentials belonged to real employees or service accounts with real, approved access. In fact, the access itself was the weak point, not just the theft of the password that opened it.
Data access governance is the discipline that decides who gets that access in the first place and how long they keep it. It also decides how an organization proves any of it was ever justified. This article breaks down how RBAC, ABAC, least privilege, and access reviews fit together into a program that holds up under audit, not just on a policy slide.
What Is Data Access Governance? Data access governance is the set of policies, roles, and technical controls that decide who or what can reach specific data, under which conditions, for what purpose, and for how long. It sits inside a wider data governance program , but it answers a narrower, more operational question than broader governance does.
Data accuracy and documentation quality aren’t its concern. What matters instead is whether the right people, and increasingly the right systems, can actually get to it.
The Five Questions Every Access Decision Answers Every real access decision, whether made by a manager clicking approve or a policy engine evaluating a request in milliseconds, answers the same five questions. It has to establish who is asking, what data they want, why they need it, under what conditions the access stays valid, and when it should expire.
A governance program that cannot answer all five for a given permission is not really governing that access. Instead, it is only recording that the access exists.
Data Access Governance vs. IAM, IGA, and Data Governance Identity and access management (IAM) governs identities themselves: who exists in the directory, how they authenticate, and which applications they are allowed to open. Identity governance and administration (IGA) builds on IAM with entitlement certification and lifecycle automation.
Data access governance is narrower still. It connects an already-authenticated identity to the sensitivity, classification, and permitted use of a specific dataset, which is a different problem than confirming someone is who they claim to be. The distinction from broader data governance versus data management follows the same logic: governance sets the rules, access governance enforces one specific rule at the point of query.
The distinction matters commercially, too. Plenty of organizations buy an IAM or IGA platform and assume the platform now governs data access, when usually it does not. IAM controls the front door, while data access governance controls which rooms a badge actually opens, down to the table or column.
Who Actually Owns Data Access Governance? Ownership is the question that stalls the most programs before they start. Security teams usually own the policy and the enforcement tooling, but they rarely have the business context to know whether a specific analyst genuinely needs access to a specific dataset.
That judgment belongs with data owners, the business-side stakeholders accountable for a given dataset’s use, working alongside IT and security rather than instead of them. Programs that centralize every access decision inside IT alone tend to approve requests based on urgency rather than actual need, because IT has no independent way to evaluate whether the business justification is real.
This is also where data access governance is easy to confuse with a related but different goal: data accessibility . Data accessibility is about making sure the right people CAN reach the data they need to do their jobs. Access governance and accessibility pull in opposite directions by design. One is about opening data up, the other is about controlling it, and a mature program treats them as two sides of the same decision rather than competing priorities.
Checklist
Enterprise Data Governance Checklist
A practical checklist for rolling out governance and access controls without stalling the business, covering ownership, classification, and enforcement.
Get the Checklist → Why Data Access Governance Matters Now Enterprise data volume keeps growing, and so does the number of systems, service accounts, and AI agents that touch it. Access sprawl grows quietly in the background, one grant at a time, until nobody can say with confidence who can see what. Closing that visibility gap is the job of data security posture management .
The most common gap Kanerika sees in governance programs is not a missing policy. It is a policy nobody enforces at the point of access, a pattern covered in more depth in Kanerika’s breakdown of common data governance challenges . A written rule that regional analysts should only see regional data does nothing if the underlying platform grants warehouse-wide access by default.
Regulators have also stopped accepting a written policy as sufficient proof of control. GDPR’s accountability principle and financial-services examination standards increasingly expect evidence that the organization reviewed, approved, and revoked access on schedule, not just that a policy document exists somewhere in a shared drive.
None of this is solvable by hiring more reviewers. The volume of access grants a mid-sized enterprise data governance program generates in a single quarter, across cloud platforms, SaaS tools, and internal systems, is already too large for manual review to keep pace with. Governance that depends on a person remembering to check something does not scale past a few dozen systems. Most enterprises are well past that. That is also why so many programs stall at the same governance maturity stage for years.
Choosing Between RBAC and ABAC for Access Control Most enterprise access programs run on role-based access control (RBAC), attribute-based access control (ABAC), or a blend of the two. Neither model is universally better. The right choice comes down to how much context a given access decision actually needs.
How Role-Based Access Control Works RBAC assigns permissions to roles, then assigns roles to people. A “regional sales analyst” role might include read access to regional pipeline data and nothing else. Everyone in that role inherits the same permissions, which makes RBAC easy to explain, easy to audit, and easy to certify during a review. Ultimately, the reviewer only has to confirm the role assignment is still correct.
RBAC struggles when the business has more genuine variation than roles can cleanly represent. A contractor with the same job title as a full-time employee often needs different access, and a role built for that one exception quietly multiplies into dozens of near-duplicate roles.
How Attribute-Based Access Control Adds Context ABAC evaluates attributes of the requester, the resource, and the environment at the moment of the request, rather than relying on a fixed role, per NIST’s guide to attribute-based access control . A policy might grant access only if the user’s department matches the data’s region, their device is managed, and the request happens during business hours.
That context makes ABAC more precise, but it also makes it harder to audit. A reviewer cannot glance at a role name and know what access it grants. They have to trace the policy logic itself, which is why ABAC works best layered on top of RBAC rather than replacing it outright.
Table 1: RBAC vs. ABAC vs. DAC
Model Decision Basis Best Fit Audit Difficulty Discretionary access control (DAC) Resource owner’s own decision Small teams, informal sharing Low visibility, hard to govern at scale Role-based access control (RBAC) Assigned role Stable job functions, clear reporting lines Straightforward, role name signals access Attribute-based access control (ABAC) Live attributes of user, data, and context Fine-grained, context-sensitive data (PII, financial records) Harder, requires tracing policy logic
Most mature programs land on a hybrid. RBAC handles the broad strokes of who belongs in which part of the system, and ABAC refines the edge cases where a role alone would be too blunt an instrument. Restricting access to a customer record based on the customer’s own consent settings is a typical example.
Setting Up RBAC Without Creating Role Sprawl Role sprawl is the most common way RBAC implementations quietly fail. A team starts with a handful of clean roles, then adds a slightly different one for every exception. Within a year, it has more roles than employees.
The fix is to define roles around business function, not around individual job titles, and to resist creating a new role for a single person’s edge case. A one-off exception is usually a sign that the request needs ABAC-style conditional logic layered on top of an existing role, not a brand-new role of its own.
On-Demand Webinar
Secure, Govern, Thrive: Transform Your Data Strategy With Microsoft Purview
An on-demand session on building a data strategy that stays secure and governed as it scales, including access and policy enforcement with Microsoft Purview.
Watch the Webinar → Common Data Access Governance Mistakes to Avoid A small set of repeatable operational mistakes causes most governance failures, not a missing policy document. Here are the ones Kanerika sees most often.
Granting access by exception instead of by role. One-off requests approved outside the standard process accumulate into an access model nobody can fully explain.Treating classification as a one-time project. Data keeps getting created after the initial classification sweep ends, and unclassified new data defaults to whatever access is easiest, not whatever access is correct.Certifying access without usage data. A reviewer who cannot see whether a permission was used in the last ninety days is guessing, not reviewing.Governing humans and machines with the same playbook. Service accounts and AI agents need faster review cycles and faster revocation than the standard human certification calendar provides.Measuring the program by policy existence, not enforcement. A signed policy document proves intent. It does not prove that the platform is actually blocking the access the policy prohibits.The Principle of Least Privilege in Practice Least privilege means every user, service account, and automated process gets only the access it needs to do its job, and nothing more. It sounds simple, and almost every security policy already states it. It is rarely the policy that fails.
What actually breaks least privilege is how access gets granted day to day. Teams frequently provision new hires by copying an existing teammate’s permissions instead of provisioning from a role definition, which silently carries forward years of accumulated, undocumented access. Teams grant temporary project access with no expiration date, and it quietly becomes permanent.
Standing privileged access is the most expensive version of this problem. An administrator account that is always elevated, rather than elevated only when a specific task requires it, is a target every hour of every day instead of only during the narrow windows when the privilege is genuinely needed. Kanerika’s SaaS security best practices guide covers this risk in more depth.
Building a Data Access Governance Framework Step by Step A working data access governance program is a lifecycle, not a one-time policy rollout. It should sit inside a broader data governance framework . Kanerika’s implementations generally follow the same nine stages regardless of the underlying platform. That includes Microsoft Purview , Databricks Unity Catalog, Snowflake’s access and security layer , and Microsoft Fabric.
Discover : Inventory the data and classify it by sensitivity before writing a single access rule.Establish identity context : Confirm who or what is requesting access, including non-human identities.Capture the request : Route access requests through a defined intake, not an ad hoc message to whoever owns the system.Apply policy : Evaluate the request against RBAC and ABAC rules already defined for that data.Approve : Route to the right approver, typically a data owner or manager, not a generic IT queue.Provision : Translate the approved request into the minimum permission required at the enforcement point.Monitor : Track how the permission is actually used, and flag activity that looks unusual for that identity.Certify : Periodically confirm the access remains justified, rather than treating an old approval as permanent.Revoke : Remove the permission when the role, project, or employment relationship changes.Ranking pages on this topic commonly list two or three of these capabilities in isolation. Fewer show the full loop from a data-discovery event through provisioning, monitoring, certification, and revocation as one connected system. That full loop is the part that actually determines whether a governance program survives its first audit.
Where Data Catalogs and Metadata Fit Into Access Governance Discovery and classification, the first stage of the lifecycle above, depend entirely on knowing what data exists and how sensitive it is. That is metadata management’s job, not access governance’s, but the two are inseparable in practice.
An enterprise data catalog gives access policies something concrete to act on: a tagged, classified inventory instead of a guess about what a given table probably contains. Without that inventory, RBAC and ABAC rules end up written against whatever data teams happened to remember, which is exactly how sensitive fields go ungoverned for years. That same gap is wider still for files, emails, and chat logs, the domain of unstructured data governance .
Kanerika’s comparison of leading data governance tools covers catalog and metadata platforms in depth. Overall, the short version for an access governance program is that a catalog is not optional infrastructure. It is the map that makes RBAC and ABAC rules enforceable at all.
How Access Reviews and Certification Prove Access Is Still Valid An access review is the periodic validation of existing permissions by a manager, data owner, or security team. Access certification is the formal record of that review: a signed attestation that a given identity’s current access remains justified and policy-compliant.
Risk-Based Reviews vs. Calendar-Based Reviews A calendar-based review asks every reviewer to recertify every entitlement on the same fixed schedule, regardless of risk. It is easy to schedule and almost impossible to do well, because reviewers facing thousands of undifferentiated permissions default to approving everything just to clear the queue.
A risk-based review prioritizes privileged, sensitive, and anomalous access for frequent, careful review, while low-risk, standard access is reviewed less often. This is the model most auditors now expect, because it demonstrates that scrutiny is proportional to actual exposure.
Table 2: Access Review Models Compared
Review Type Who Reviews Strength Weakness Manager review Direct manager Knows job need, low friction Rarely understands data sensitivity Data-owner review Business data owner Understands sensitivity and business impact Often unaware of every individual’s job need Risk-based review Security or governance team Focuses effort where exposure is highest Needs reliable risk scoring to work Event-triggered review Automated, on a role or status change Closes gaps immediately, not on a quarterly clock Requires integration with HR and identity systems
Reviews fail most often when the program hands reviewers a raw list of technical permission names with no business context attached. A useful review screen shows the identity, the role, the resource, its sensitivity, when the access was last actually used, and why it was originally granted. By contrast, a column of database grant strings that nobody outside engineering can interpret does not qualify. Automating this layer is usually what separates a review program reviewers actually trust from one they rubber-stamp.
Kanerika Service
Data Governance Services
Kanerika designs and enforces data access governance programs on Microsoft Purview, Databricks Unity Catalog, and Snowflake, from RBAC and ABAC design to ongoing access reviews.
Explore Data Governance Services Governing Access Across the Joiner-Mover-Leaver Lifecycle Access risk does not build up randomly. It concentrates at three predictable points in an employee’s tenure, commonly shortened to joiner-mover-leaver, or JML.
Joiners should start with role-appropriate baseline access provisioned from an approved role definition, not access copied from a colleague’s account. Copying access is faster in the moment and is exactly how undocumented, unjustified permissions spread through an organization, a pattern Kanerika’s core data governance principles guide calls out directly.
Movers are the stage governance programs miss most often. An internal transfer or promotion adds new access for the new role, but rarely triggers removal of access tied to the old one, so employees accumulate permissions from every role they have ever held.
Leavers need access revoked on a timeline tied to their actual departure date, connected directly to HR systems rather than a manual offboarding checklist that can lag by days or weeks. Every JML event should automatically trigger a corresponding access change, closing the gap between when a status changes on paper and when the access actually changes in the system.
Table 4: JML Events and the Access Action Each One Should Trigger
Lifecycle Event Required Access Action Common Failure Joiner (new hire) Provision baseline access from the approved role, nothing more Access copied from a colleague’s account Mover (transfer or promotion) Add new role’s access, remove the old role’s access Old access never removed, permissions accumulate Leaver (termination or resignation) Revoke all access on the departure date Manual offboarding checklist lags by days or weeks
Data Access Governance for AI Agents and Non-Human Identities AI agents that query data, call tools, and take action without a human approving every step are now a routine part of the enterprise stack. They do not fit neatly into a governance model built for people. An agent’s permissions can change based on the task it is executing, and a single agent may act on behalf of many different users across a single session. Get that access model wrong, and the result has a name: AI data leakage .
Kanerika’s unified AI governance architecture treats identity, access control, and delegated authority for AI agents as its own governed layer, distinct from human IAM, precisely because the failure modes are different. An over-permissioned agent does not misuse access occasionally. Rather, it can misuse it at machine speed, across every record it touches, before a human ever notices.
That is why kill switches and revocation for agents need to work at machine speed too. Waiting for a quarterly access review to catch a compromised or malfunctioning agent is not fast enough. In the time it takes a reviewer to open a spreadsheet, the agent can act on thousands of records. Kanerika’s kanGuard governance service is built specifically around this class of problem, pairing data loss prevention policies with real-time monitoring to catch unauthorized access before it compounds.
The Delegated Authority Problem Delegated authority adds another layer most access models were never designed for. When an agent acts on a user’s behalf, the access decision has to account for both the agent’s own permissions and the permissions of the person who triggered it. That way, the agent never ends up with broader reach than the human it is working for. Kanerika’s guidance on agentic AI governance and on shadow AI risk both cover the same underlying problem from different angles: access nobody explicitly approved is still access.
Case Study
72% Better Data Classification With Microsoft Purview
A global bank with nearly 9,000 branches unified access and classification across SAP, Dynamics 365, and core banking systems, cutting data breaches to zero.
Read the Case Study → Table 3: Human User vs. Service Account vs. AI Agent
Dimension Human User Service Account AI Agent Authentication Credentials plus MFA Key or certificate Token, often delegated from a user or system Authorization scope Relatively stable by role Fixed to one integration Can shift per task or session Typical lifetime Tenure of employment Life of the integration Often short-lived, sometimes per session Review method Scheduled certification Owner attestation Continuous, behavior-based monitoring Revocation speed needed Days is usually acceptable Hours Seconds to minutes
How to Measure Whether Data Access Governance Is Working A governance program that cannot be measured cannot be improved, and it certainly cannot be defended in front of an auditor. Specifically, a handful of metrics do most of the work.
Time to revoke. The gap between a departure or role change and the actual removal of access. Days, not weeks, is the reasonable target for most roles.Percentage of access with an expiration date. Standing, permanent access should be the exception a program can explain, not the default it defends.Percentage of entitlements reviewed on schedule. A review calendar that quietly slips is functionally the same as having no review process.Orphaned account count. Accounts still active after the person or system they belonged to is gone are a direct measure of how well JML triggers are actually wired up.Unused access ratio. The share of granted permissions with no recorded activity in the last ninety days, which is usually the fastest place to find least-privilege violations.None of these numbers need to start at zero. What matters is that they are tracked consistently and trend in the right direction, because a governance program that only produces a policy document has no way to show whether it is actually working.
Talk to Kanerika
Ready to Audit Your Own Access Governance?
Kanerika can assess your current RBAC and ABAC model, find where least privilege is breaking down, and design a review process that actually holds up.
Schedule a Demo → How Data Access Governance Supports Compliance NIST’s Zero Trust Architecture guidance treats every access request as untrusted by default, requiring explicit verification regardless of network location, and grounds authorization decisions in the resource being requested rather than the network the request came from. That resource-level thinking is exactly what data access governance operationalizes for a specific dataset instead of a network segment.
NIST’s ABAC guidance, cited above, describes the model as a way to improve information sharing across an organization. It still maintains control over that information. That is the practical trade-off most access programs are actually trying to solve.
GDPR, the Payment Card Industry Data Security Standard , and sector-specific rules like HIPAA all shape what must be protected and how tightly, but none of them replace the need for an actual enterprise authorization model. An auditor does not accept a written policy alone as evidence. They expect to see approval records, enforcement logs, review history, and revocation timestamps that show the controls actually operated, not just that they were documented.
Kanerika’s own governance work is built on Microsoft Purview as a Microsoft Solutions Partner for Data and AI. The same access-governance discipline carries over to Databricks Unity Catalog and Snowflake. Kanerika holds Databricks Consulting Partner and Snowflake Select Tier Partner status there as well. All of it runs under ISO 27001 and SOC 2 Type II certified delivery practices, which keeps the access-control evidence auditors ask for consistent across engagements rather than assembled after the fact. Regulated industries like banking feel this most acutely, since examiners there are already trained to ask for exactly this kind of enforcement evidence. The same discipline separates IT governance from data governance in practice: IT governance sets who owns the decision, data access governance is where that decision gets enforced.
Data Access Governance: How Kanerika Closed a 72% Governance Gap With Microsoft Purview Kanerika’s approach to data access governance runs through the same five stages on every engagement. It assesses the current access environment and designs the RBAC and ABAC model against real data sensitivity. It then builds the enforcement and monitoring layer and governs it through ongoing reviews. Finally, it enables the business teams who now depend on it daily.
That approach is delivered through Kanerika’s data governance services and kanSuite, a modular set of governance services covering strategy and enforcement (kanGovern), regulatory compliance (kanComply), and unauthorized access prevention (kanGuard), all delivered on Microsoft Purview. It draws on the same data strategy consulting discipline Kanerika applies across governance engagements, and on real-world data governance examples from other regulated industries.
A global bank operating close to 9,000 branches and 22,000 ATMs worldwide brought Kanerika a genuinely hard access problem. Its data was scattered across SAP, Dynamics 365, CRM, and core banking systems including Oracle and Netezza, feeding a centralized Lakehouse under strict privacy regulation. Classifying personal data across that many source systems by hand was slow and error-prone, and the resulting data silos made it difficult to know who could see what.
Turning Discovery Into Enforcement Kanerika implemented data discovery through Purview’s Data Map to automatically identify and classify data assets. It applied Purview Policies to govern how the platform handled personal data, including PII, PCI, and PHI. It also automated data lineage across the Lakehouse for full auditability. Data-sharing rules were then set by data type and sensitivity, so the right stakeholders reached the right data and accidental or unauthorized access was structurally prevented rather than merely discouraged.
The results were measurable: a 72% improvement in data classification accuracy , zero data breaches following implementation, and full adherence to the bank’s compliance requirements. A related advanced Purview implementation shows the same pattern holding at a different client, which is what makes it a repeatable approach rather than a one-off result.
The pattern Kanerika watches for on every similar engagement is the same one that caused this client’s original problem. Access rules that exist in a policy document but were never wired into the platform doing the actual enforcing. Kanerika’s data governance best practices guide addresses that gap at the program level. The teams that avoid it treat the access model as living infrastructure that gets tested and adjusted, not a diagram that gets approved once and filed away.
Wrapping Up Data access governance succeeds or fails on enforcement, not documentation. RBAC and ABAC give the technical backbone, least privilege sets the default, and access reviews prove the whole system is still working months after launch.
The organizations that get this right treat it as a lifecycle they operate continuously, not a project they finish once. Getting the framework, the reviews, and the AI agent controls working together is what turns a governance policy into something an auditor, and an attacker, cannot get past.
Frequently Asked Questions
What is data access governance? Data access governance is the set of policies, roles, and technical controls that decide who or what can reach specific enterprise data, under which conditions, for what purpose, and for how long. It typically runs on role-based access control (RBAC) and attribute-based access control (ABAC), enforced through least-privilege defaults and periodic access reviews. It sits inside a broader data governance program but focuses specifically on the access-control layer.
What is the difference between data access governance and data governance? Data governance is the broader program covering data quality, ownership, classification, and lifecycle policy. Data access governance is one operational layer inside that program, focused specifically on deciding who or what can reach a given dataset. A well-documented data governance policy can still fail in practice if the access-control layer underneath it is never actually enforced at the platform level.
What is the difference between RBAC and ABAC? RBAC (role-based access control) assigns permissions to a role, and everyone in that role inherits the same access, which makes it simple and easy to audit. ABAC (attribute-based access control) evaluates live attributes, such as department, data sensitivity, device, and time, at the moment of the request. Most mature programs use RBAC as the baseline and layer ABAC on top for context-sensitive edge cases.
What is the principle of least privilege? Least privilege means every user, service account, and automated process gets only the access it needs to do its job, and nothing more. It usually fails in practice not because of a missing policy, but because of copied permissions at onboarding, temporary access with no expiration date, and standing privileged accounts that stay elevated even when the elevated access isn’t actively needed.
How often should access reviews happen? Access reviews work best when they are risk-based rather than calendar-based. Privileged, sensitive, and anomalous access should be reviewed frequently, often monthly or quarterly, while low-risk, standard access can be reviewed less often. A blanket schedule that reviews every entitlement at the same frequency tends to produce rubber-stamp approvals rather than genuine scrutiny.
What is the joiner-mover-leaver process in access governance? Joiner-mover-leaver (JML) describes the three points in an employee’s tenure where access risk concentrates: onboarding (joiner), an internal transfer or promotion (mover), and departure (leaver). Movers are the stage most governance programs miss, since a role change usually adds new access without removing the old access tied to the previous role, so permissions quietly accumulate over time.
How do you govern data access for AI agents? AI agents need their own access governance model rather than the one built for human employees, because their permissions can shift per task and they can act on data at machine speed. That means delegated authority controls (an agent never exceeds the access of the user it’s acting for), continuous behavior-based monitoring instead of quarterly reviews, and revocation or kill switches that work in seconds, not days.
How does Microsoft Purview support data access governance? Microsoft Purview supports data access governance through its Data Map for automated data discovery and classification, and through Policies that govern how classified data, including PII, PCI, and PHI, can be accessed and shared. Kanerika’s implementation for a global bank used these capabilities to improve data classification accuracy by 72% and bring data breaches to zero after rollout.
