Category: Access Control

Discretionary Access Control

Also known as:

Simply put

Discretionary Access Control (DAC) is a way of managing access to files, systems, or other resources in which the owner of a resource decides who else is allowed to use it and what they can do with it. Because the owner has discretion over these permissions, access rights can be granted or changed at the owner's initiative. This is a security model concerned with who can reach data, and it is distinct from data governance concerns such as ownership stewardship, data quality, or policy.

Formal definition

DAC is an access control model in which access to objects is governed by rules and permissions set at the discretion of the subject that owns or controls the object, allowing owners to grant or revoke access rights to other subjects. The Trusted Computer System Evaluation Criteria (TCSEC) defines it as a category of access control, and NIST characterizes it as an access control policy enforced over all subjects and objects in a system. In implementation it is often described as decentralized or flexible, since permission assignment is distributed to resource owners rather than centrally mandated; this contrasts with models such as mandatory access control where a central policy constrains owner discretion. This entry covers the conceptual model and its ownership-based permission mechanism only; it does not address specific implementation mechanisms (for example access control lists or capability systems), configuration guidance, or how DAC maps to particular regulatory or standards requirements, which vary by context.

Why it matters

Discretionary Access Control matters because it shapes who can reach data at the point where access decisions are actually made. In a DAC model, the owner of a resource holds discretion over granting and revoking permissions, which makes the model flexible and easy to adopt but also distributes accountability across many individual owners rather than concentrating it in a central authority. For security and governance teams, this distribution is significant: the effectiveness of access restrictions depends on the judgment and diligence of each resource owner, and that variability can create gaps that are difficult to observe centrally.

Because DAC decentralizes permission assignment, it can complicate efforts to demonstrate accountability. Governance frameworks generally expect demonstrable evidence of who has access to what and why, not merely stated intent. A model that lets individual owners change access rights at their own initiative can make it harder to maintain a reliable, auditable picture of the access landscape unless supporting processes and monitoring are in place. This is a point where information security and data governance intersect without being the same thing: DAC is a security model concerned with reachability of data, while governance concerns such as ownership stewardship, data quality, and policy sit alongside it.

This entry does not assert that DAC satisfies or fails any particular regulatory or standards requirement, nor does it quantify its risks. How DAC maps to specific obligations varies by context, jurisdiction, and implementation, and those mappings are out of scope here.

Who it's relevant to

Security architects and engineers

Those designing access control for systems need to understand where owner discretion is appropriate and where a more centrally constrained model may be warranted. DAC's flexibility can accelerate deployment but places responsibility for sound permission decisions on individual resource owners, which should be weighed against the system's risk profile.

Information governance and data stewardship leads

Governance leads should recognize that DAC is a security model concerned with who can reach a resource, distinct from governance concerns such as ownership stewardship, data quality, and policy. Where access decisions are decentralized to owners, supporting processes are generally needed to maintain a demonstrable, auditable record of access rights rather than relying on stated intent.

Compliance and audit professionals

Because DAC distributes permission assignment to resource owners, compliance and audit teams may find it harder to establish a reliable, centralized view of access. Note that how DAC relates to any particular regulatory or standards requirement varies by context and is not addressed here; assessing that mapping requires reference to the specific regime in scope.

Inside DAC

Owner-Controlled Permissions

Under DAC, access rights to a resource are set at the discretion of the resource owner rather than by a central authority. The owner decides which subjects may read, write, or execute the object.

Access Control List (ACL)

DAC is commonly implemented through ACLs, which associate each object with a list of subjects and the specific permissions granted to each. This is a typical mechanism but not the only one.

Identity-Based Access Decisions

Access decisions in DAC are generally made on the basis of the identity of the requesting subject (or group membership) and the permissions the owner has assigned to that identity.

Transferable Permissions

A defining characteristic of DAC is that a subject with access may typically pass or propagate those permissions to other subjects, subject to the model's rules. This propagation is central to how DAC differs from more restrictive models.

Contrast with Mandatory Access Control (MAC)

DAC is distinguished from MAC, where access is governed by system-enforced policy and security labels rather than owner discretion. In DAC, control rests with owners; in MAC, control is centrally enforced and cannot be overridden by owners.

Common questions

Answers to the questions practitioners most commonly ask about DAC.

Does DAC give data owners unrestricted freedom to share data however they choose?

Not in a governance sense. While DAC is defined by the fact that the owner or a subject with rights over a resource can grant access at their discretion, that discretion is typically constrained by organizational policy, and it does not relieve the organization of its accountability obligations. The technical ability to delegate access should not be confused with a lawful or policy-compliant basis for doing so, and demonstrable controls and evidence are still generally expected under governance frameworks.

Is DAC simply a weaker or outdated version of role-based access control (RBAC)?

No. DAC and RBAC are different models rather than points on a single quality scale. DAC assigns access at the discretion of the resource owner or a subject holding rights, whereas RBAC assigns access based on defined roles independent of individual owner decisions. They address different concerns and can coexist, and neither is inherently more compliant than the other. Suitability depends on context, the sensitivity of the data, and the surrounding governance and security controls.

How should permission grants under DAC be recorded so accountability can be demonstrated?

Because accountability under governance frameworks generally requires demonstrable evidence rather than stated intent, grants, changes, and revocations should be logged in a way that identifies who granted access, to whom, over which resource, and when. This entry does not specify retention periods or particular logging tools; those depend on jurisdiction, applicable policy, and implementation.

What review practices help manage the risk of permission sprawl in a DAC environment?

Because DAC allows owners or rights-holding subjects to grant access at their discretion, permissions can accumulate over time. Periodic access reviews, recertification of grants, and revocation of unused or excessive rights are commonly used practices. This entry does not prescribe review frequency or attestation formats, which vary by organization and regime.

How does DAC interact with the separation between data governance and information security?

DAC is primarily an access control mechanism, which falls within information security's concern for confidentiality. Governance concerns such as ownership, stewardship, and policy determine who should be permitted to grant access and under what rules, while security enforces those decisions technically. The two overlap where owner-driven grants must reflect governance policy, but they remain distinct functions and should not be collapsed.

Does implementing DAC on a dataset change whether that data is personal data?

No. Applying an access control model such as DAC governs who can reach the data; it does not alter the classification of the data itself. Personal data, and where applicable special category or sensitive data, remains subject to its obligations regardless of the access model used. This entry does not address anonymization, pseudonymization, or any transformation that might affect data classification.

Common misconceptions

DAC and role-based access control (RBAC) are the same thing.

They are distinct models. DAC bases decisions on owner-assigned, identity-based permissions that owners can typically propagate, while RBAC assigns permissions to roles that subjects hold. An implementation may combine elements of both, but they should not be treated as interchangeable.

DAC is a security control that on its own satisfies data protection obligations.

DAC is an access control mechanism within the information security domain and does not by itself guarantee compliance with any particular regime such as the EU GDPR, UK GDPR, or HIPAA. Compliance generally depends on broader context, governance, and other controls; access control is one contributing element, not a complete solution.

Because owners control access, DAC provides strong protection against unauthorized disclosure.

The discretionary and transferable nature of DAC permissions means access can propagate widely once granted, which generally makes it weaker at constraining onward flow than centrally enforced models such as MAC. DAC's protection depends heavily on how owners exercise their discretion.

Best practices

Establish clear ownership for each resource so that discretionary permission decisions are made by an accountable and identifiable owner rather than by default or ambiguity.

Maintain and periodically review access control lists to confirm that assigned permissions still reflect current need, removing stale or excessive grants.

Constrain the propagation of permissions where possible, since the transferable nature of DAC permissions can otherwise lead to uncontrolled spread of access.

Position DAC as one layer within a broader control set rather than treating it as sufficient on its own, recognizing that it does not by itself demonstrate compliance with any specific regime.

Retain demonstrable evidence of access decisions and reviews, since accountability under governance frameworks generally requires records rather than stated intent alone.

Where stronger, non-discretionary constraints on data flow are required, evaluate whether a centrally enforced model such as MAC is more appropriate than relying solely on owner discretion.