Data Access Control

Data access control is the set of policies, mechanisms, and enforcement rules that determine which users, systems, or processes can read, modify, or delete specific data, and under what conditions. It is a foundational element of data security, ensuring that sensitive information is accessible only to those with a legitimate, verified need.

Effective data access control operates across three layers: authentication (verifying the identity of a user or system), authorization (determining what that identity is permitted to do), and audit (recording what was accessed, by whom, and when). Organizations implement access control to reduce the risk of data breaches, satisfy regulatory requirements such as GDPR, HIPAA, SOX, and the EU AI Act, and protect sensitive data from both external threats and insider risk.

Why does data access control matter?

Every business that collects, processes, or stores data should have a data access control policy and implementation to safeguard their data. The benefits of these data protection controls are maintaining public trust, avoiding liability for any data lost or damages caused through that loss, and securing valuable business information.

One of the primary causes of data breaches is an employee having access to data they shouldn't have access to, and either intentionally or accidentally disclosing that information to others.

Trust

Data breaches have become a frequent and newsworthy topic, with hundreds of incidents reported every quarter and widespread media coverage due to the legal, financial, and societal impact. For example, in April 2026, a cyberattack on a utility technology provider exposed systems used by infrastructure operators, highlighting supply chain risk.

The public (your current and potential future customers) are increasingly aware of the value and sensitivity of their personal information, and its usefulness to bad actors who are looking to extort, imitate, harass, or otherwise harm them using that information.

Customers will not be attracted to a service with a poor reputation for protecting their data.

Regulation and liability

If you do suffer a data breach, and are found not to have taken adequate measures to protect sensitive data, you may be found in breach of government regulation and incur hefty fines. On top of that, affected parties may seek civil penalties for any damages or losses they incur as a result of your negligence.

Companies are regularly fined for infractions of privacy regulations including the EU’s General Data Protection Regulation (GDPR), California’s Consumer Privacy Act (CPRA), and Brazil’s General Data Protection Law (LGPD) — so every day that you handle data, without the correct measures taken to control access to and protect it, puts your business at risk. Industry-specific regulations on user data, like HIPAA, can impose additional fines on top of those. It’s important to be aware of the privacy laws that cover the data you handle and to comply with them.

Protecting your vital data

Your first-party data is an asset that must be protected from accidental disclosure, dilution, deletion, modification, and corruption by inexperienced or inattentive users. First-party data is unique to your business, and is irreplaceable. It describes the internal workings of your organization, including employees, business plans, and audiences.

Online marketplaces exist where stolen and leaked information is regularly traded. If an unscrupulous competitor were to gain access to this information, they could use it to preempt your business plans, or attempt to peel away your user base using information and audience insights that you have worked hard to create.

How does data access control work?

Data access control is both an organizational and a technical process. The data you collect and the ways it is used, along with potential ways it could be exposed, must be documented. You must be aware of — and in control of — the data you collect, where it is stored, and who needs to be able to use it.

Once you know what data you have, you’ll need to define policies dictating the data that specific employees and departments require access to. Your software stack needs to be configured to limit access based on these policies. Programmatic access — such as software accessing data via an API — must also be identified so that access can be limited to only the data required for the software to function.

Once your data has been identified and policies defined, they must be implemented using the authentication and authorization mechanisms in the software you are using to access the data.

• Authentication is the process of making sure that the person accessing a system is who they say they are. It's your username and password (and preferably two-factor authentication) combination, or an API key if you are authenticating for programmatic access.
• Authorization checks whether an authenticated user has the rights to view or update a resource. Once you know who a user is, you can check their credentials against access policies to see what they are allowed (and not allowed) access to.

What is the principle of least privilege (PoLP)?

The principle of least privilege (PoLP) is a security guideline, defined in frameworks such as NIST SP 800-53. It states that any user, process, or system should be granted only the minimum level of access required to perform its function — and for only as long as that access is needed.

PoLP is not a specific technology but a design principle applied across all access control models. It addresses two of the most common causes of data exposure: over-provisioning (granting more access than a role requires) and privilege creep (accumulated permissions from previous roles that were never revoked).

Implementing PoLP in practice:

• Default all access to deny, then grant explicitly based on defined need
• Define access at the time of role creation, not retroactively
• Set time-bounded access where appropriate (temporary elevated permissions for specific tasks)
• Review permissions regularly — quarterly at minimum — and revoke access that is no longer required
• Apply PoLP to service accounts and automated processes, not just human users

PoLP is the operating principle underlying zero trust architecture, and is required or strongly implied by GDPR, HIPAA, SOX, and the EU AI Act.

Data access control and zero trust

Zero trust is a security architecture built on the principle of "never trust, always verify." In a traditional perimeter-based model, users and systems inside the corporate network were implicitly trusted. Zero trust eliminates that implicit trust: every access request — regardless of origin — must be authenticated, authorized, and continuously validated.

Data access control is the enforcement mechanism that makes zero trust operational. Key elements of a zero trust access control implementation include:

• Identity-centric access: Access decisions are based on verified identity, not network location
• Continuous verification: Authentication is not a one-time event at login; access is re-evaluated as context changes (device health, location, behavior)
• Micro-segmentation: Data resources are isolated into segments with separate access policies, limiting lateral movement if credentials are compromised
• Least-privilege enforcement: Users and systems are granted only the access they need for a specific session or task

Zero trust is increasingly required by enterprise security frameworks, with NIST SP 800-207 serving as the foundational NIST publication on zero trust architecture, alongside more recent guidance such as NIST SP 800-207A. It is also referenced in government compliance initiatives. Organizations moving to cloud or multi-cloud environments find zero trust particularly valuable because the traditional network perimeter no longer exists as a meaningful security boundary.

Data access control models: RBAC, ABAC, DAC, and MAC

The type of access control that you implement for your business will depend on your organizational structure and the policies you wish to implement, as well as the types of data access control available in the software you are using to access your data. This may factor into the decisions you make when choosing those tools.

There are a few common abbreviations that you will come across referring to different data access control types.

What is discretionary access control (DAC)?

Discretionary access control puts users in control of access to the resources they are responsible for. The owner of a document, data store, or other resource decides who has access. Administrators can, where required, manage access to resources, overriding the decisions made by other users.

This simple data access control method is useful in small organizations that lack centralized infrastructure and are composed of 100% trusted parties. The decision to share a resource does not require administrative oversight, streamlining the sharing of information.

However, discretionary access control becomes increasingly dangerous as more parties become involved. Administrators have less control over what data is shared as access is not granted from a central authority, and it can become easy to quickly lose track of what is being shared with whom. Users may accidentally be granted access to data they should not have access to.

For the best data security, DAC should be avoided wherever possible.

What is mandatory access control (MAC)?

Mandatory access control is a non-discretionary access control technique. All data access decisions and authorizations are centralized, allowing full control of who has access to what.

MAC divides users into groups or compartments, and assigns them access based on resource classification. For example, the finance department as a whole would only be granted access to resources categorized for financial use.

This access control method broadly categorizes users and data, provides a basic level of access control and data protection, and is relatively easy to manage.

However, centralized infrastructure is required to implement MAC, and there are operational overheads. Somebody has to be in charge of managing the authentication and authorization system and keeping user and resource classifications up to date. The labels used to classify data must also be maintained and kept consistent. Case sensitivity, pluralization and mixed terminology can result in mis-matched labels and the wrong permissions being applied. For example users may be expected to label their sensitive documents as “confidential”, with access policies being applied based on that label, only for it to be found that some users have been mistakenly labeling theirs “privileged,” leaving the data unprotected.

What is role-based access control (RBAC)?

Role-based access control goes further than MAC’s group-based approach, granting non-discretionary access at an individual level.

Each user has a defined role or roles reflecting their responsibilities, and access is granted based on those roles. Users only ever have access to the resources they require access to, and nothing else. This is a more granular approach than MAC, as users can be granted permission on an individual level based on their role.

RBAC is an effective implementation of PoLP. It establishes a flexible and robust authorization system that is conceptually simple, reducing the chances of accidental access being granted to sensitive resources.

Like MAC, centralized infrastructure is required to implement RBAC. Somebody has to be in charge of making sure permissions are kept up to date, as outdated permissions could hinder work by preventing access for users who require it. Overlapping roles and permission requirements can become confusing; however, you can avoid this problem by properly curating your user directory and keeping user roles and requirements up to date.

What is attribute-based access control (ABAC)?

Attribute-based access control or policy-based access control is commonly used when defining programmatic access to resources.

ABAC looks at the attributes or properties of both the user and the resource being accessed, to determine whether permission is granted.

ABAC allows for complex rules that give even more granular control than RBAC, but it can be challenging to manage. One of the most prominent implementations of ABAC is AWS Identity and Access Management (IAM), which grants access to files, databases, and other AWS resources based on the evaluated attributes defined in the IAM policy.

Whichever access control approach you use to secure your data, you should implement streamlined mechanisms for updating users’ permissions as their roles and access requirements change. This will discourage employees from trying to seek workarounds to expedite a task if they are kept waiting for access to the resources they need.  One method to reduce the time it takes to update permissions is by combining the above approaches, granting managers permission to assign access for data relating to their department.

Which access control model should you use?

No single model is universally correct. Most organizations use a combination:

A common pattern in enterprise environments is to implement role-based access control (RBAC) as a baseline and layer attribute-based access control (ABAC) policies on top to enable more granular, context-aware access decisions. This combines RBAC's conceptual simplicity with ABAC's contextual flexibility.

Data access control for AI agents and automated pipelines

AI agents, large language model (LLM) integrations, and automated data pipelines are now routine components of data infrastructure — and they require access control policies just as human users do. This is an area where many organizations' existing access control frameworks have gaps.

Why AI agents create new access control challenges

• Non-human identities at scale — AI agents and pipeline services operate as non-human identities. Unlike human users, they can make thousands of data requests per minute and may access data across many systems simultaneously.
• Broad scope by default — LLM-integrated agents are often granted wide data access during development and that access is rarely scoped down before production deployment.
• Indirect data access — AI agents may access sensitive data as a byproduct of completing a task (e.g., a summarization agent that reads emails or documents containing personal data), without the access being visible in traditional user access logs.
• Chained access — Agentic systems can invoke other tools and services, creating chains of delegated access that are difficult to audit with standard tooling.

Access control principles for AI agents

• Apply PoLP strictly — define the minimum data scope required for the agent's specific task
• Use dedicated service accounts or managed identities for each agent or pipeline (not shared credentials)
• Enforce read-only access wherever write access is not required
• Log all data access events at the agent level, not just the system level
• Review agent permissions as part of regular access control audits

The EU Artificial Intelligence Act introduces data governance, documentation, and record-keeping requirements for high-risk AI systems under Articles 10–12. While these articles do not prescribe access control in the same way a security standard would, they make controlled data handling, traceability, and accountability central to compliance. Organizations deploying AI systems on regulated or sensitive data, including health records, financial data, or biometric data, should therefore treat access control as part of their compliance posture, not just a security best practice.

Compliance requirements: GDPR, HIPAA, SOX, CCPA/CPRA, and the EU AI Act

Data access control is not only a security best practice. It is a legal or compliance-relevant control under multiple regulatory frameworks. The specific requirements vary by law, jurisdiction, and data type, so organizations should consult legal counsel for compliance advice.

What GDPR, HIPAA, SOX, CCPA/CPRA, and the EU AI Act require

GDPR (EU General Data Protection Regulation)
GDPR requires organizations to process personal data lawfully, fairly, transparently, and only to the extent necessary for a specified purpose. Article 5 establishes principles including data minimization and accountability, while Article 32 requires appropriate technical and organizational measures to protect personal data. In practice, access controls help organizations limit access to personal data, support confidentiality and integrity, and demonstrate accountable data handling.

HIPAA (Health Insurance Portability and Accountability Act, US)
HIPAA’s Security Rule explicitly requires covered entities and business associates to implement technical safeguards for electronic protected health information. Its access control standard includes unique user identification, emergency access procedures, automatic logoff, and encryption/decryption, with some specifications required and others addressable. HIPAA’s minimum necessary standard also aligns closely with the principle of least privilege.

SOX (Sarbanes-Oxley Act, US)
SOX Section 404 requires management to assess the effectiveness of internal controls over financial reporting, with auditor attestation required for many public companies. While SOX is not written as an access-control statute, SOX compliance programs commonly rely on IT general controls such as role-based access, segregation of duties, change management, and audit logs to protect systems that affect financial reporting.

CCPA/CPRA (California Consumer Privacy Act / California Privacy Rights Act)
CCPA/CPRA requires covered businesses to protect consumer personal information through reasonable security procedures and practices. CPRA also introduced additional consumer rights, including the right to correct inaccurate personal information and the right to limit the use and disclosure of sensitive personal information. Although the statute does not prescribe a single access-control model, access controls are a common and important way to reduce unauthorized access, use, modification, or disclosure.

EU AI Act
For high-risk AI systems, the EU AI Act requires data governance and management practices for training, validation, and testing datasets, along with technical documentation and automatic logging capabilities. These requirements focus on dataset quality, relevance, representativeness, bias assessment, traceability, and compliance evidence. While Articles 10–12 do not prescribe access control in the same way as a cybersecurity framework, access controls are a practical compliance-supporting measure for protecting regulated or sensitive data used in AI development and operation.

Data access control best practices

The first step to securing your data is to put someone in charge of protecting it. This avoids the bystander effect, where people assume that somebody else in the group is on top of a problem, when nobody is. Once responsibility is established, the following steps should be taken to improve your data security:

• Apply PoLP (principle of least privilege). Once your data control mechanisms are in place, use them. Enact the principle of least privilege to ensure that your data is secure by default, and only grant the required access, at the required level, to the required parties.
• Regularly review and update your data handling practices and data access control policies. Your policies will need to be updated if you change the types of data you work with. Regulations also change over time, and your policies will need to reflect those changes.
• Regularly audit your data access control policies, mechanisms and permissions. Make sure that your data access controls actually work at a technical level. You may have restricted permissions for a resource in the GUI, but does it actually prevent that data from being accessed? Employees often change roles, or leave to work elsewhere — make sure that their access is updated or revoked as necessary. Reviewing access and maintenance logs will assist with this task and reveal any illegitimate access that may be the result of misconfigured or outdated policies.
• Ensure that all of your data tools support data access controls, and centralize user roles and management. Data tools should allow you to manage user access and permissions, and ideally integrate with existing authentication and authorization systems. All of the tools in your digital infrastructure should be centrally managed using a solution such as LDAP or Active Directory, so that user logins and permissions are consistent across your entire network, from operating system logins to email to your data tools.
• Track and trace your data as far as you can. Know where your data comes from, and where it is going. Ensure that all data events are logged, so that you know who viewed and updated data, when they did it, and what happened to it next.
• Communicate. Make sure your staff know that access to the data they are working with is being monitored to discourage any mishandling. Clearly communicating data requirements will assist with implementing a robust PoLP policy, and making sure all parties are aware of the risks and repercussions if there is an accidental data disclosure will encourage careful data handling.
• Onboard (and offboard) your employees. When a new employee arrives, follow the PoLP to determine their required access level. When an employee changes role or leaves, ensure that access is revoked. Data handling requirements and responsibilities should be communicated during employee onboarding and included in employee handbooks.

The person or persons responsible for your data policies should schedule regular check-ups and assessments to ensure that all possible measures are being taken to protect customer data.

Security information and event management (SIEM) software provides real-time monitoring and notifications about data as it moves through your infrastructure, allowing you to update user permissions if sensitive data is being incorrectly handled and respond quickly to potential data incidents.

By implementing a customer data platform (CDP) and providing a single, secure portal to access your customer data, your potential attack surface is greatly reduced. A CDP should provide the tools you need to implement your data access management plan with reduced technical overhead.

Data access control in data platforms and cloud environments

CDPs process data from multiple sources and make it available in a centralized location. This data, by its nature, will include sensitive personally identifiable information that must be handled carefully to ensure customer confidence and regulatory compliance.

When choosing a CDP, you must ensure that it has the technical features to implement data access controls appropriate for your organization. Your CDP should provide or integrate with a user authentication system and allow you to authorize access to data at a granular level. You should be able to define user roles, and update access to data based on the roles assigned (or unassigned) to users.

In addition to data access control, a CDP should ensure accountability by tracking data movement and who is accessing and updating data. This will ensure that if there is misuse, the cause can be quickly identified and mitigated. A historical record of audit logs from your CDP will prove invaluable — days, months, or even years down the road — in identifying the mishandling of confidential information.

Further reading

This article outlined the different access control methods that you can use to secure your data. For more information on customer data, and how it is managed and stored, see our other learning center articles:

• What Is Customer Data?
• Customer Data Protection
• Data Warehouses vs Data Lake