Last updated: December 26, 2025
In cybersecurity, discretionary access control (DAC) is an access control approach where the resource owner (or another authorized user) can decide who gets access and what level of access they receive. DAC security (Discretionary Access Control) here refers to access control, not any other “DAC” acronym.
Direct answer: DAC security (Discretionary Access Control) is an access control policy where access decisions depend on user identity and permissions set by an owner, and where someone with access may be able to share information, delegate privileges, or change security attributes—creating flexibility but also real security risks if permissions are spread too widely.
What is DAC Security?
Discretionary access control (DAC) is “discretionary” because the model can allow a subject who already has access to pass information, grant privileges, or change security attributes/rules—capabilities that centralized models intentionally restrict.
In practice, DAC often maps to “owner-based access control” where the owner (or someone authorized) sets permissions for an object (like a file, folder, database row, or cloud resource).
Key terms (mini-glossary)
- Subject: A user, service account, process, or system component that requests access.
- Object: The resource being protected (file, folder, record, app, API, device).
- Permissions: Allowed actions (read/write/execute/delete/share/admin).
- Access control list (ACL): A list (per object) defining which subjects/groups can do what.
- Privilege delegation: Letting a subject pass access/rights to other subjects.
- Security attributes: Properties that influence decisions (e.g., ownership, labels, flags).
- Auditing: Tracking who accessed what, when, and what changed.
How Discretionary Access Control Works
DAC uses “subjects” and “objects” language: a subject requests an action on an object, and the system checks whether the subject has the required permissions.
Most DAC implementations rely on a permission model such as ACLs and/or owner/group/world-style file permissions, where the object’s owner can grant and revoke access.
At a high level, the flow looks like this:
- Authenticate the subject (prove identity).
- Authorize the request (evaluate permissions against the object).
- Enforce the decision (allow/deny, plus log/audit where required).
Benefits, Risks, and DAC vs MAC
Benefits of DAC
- Flexible collaboration: owners can grant access quickly without waiting for a centralized policy change.
- Simple administration at a small scale: straightforward for teams where ownership and responsibility are clear.
- Familiar model: widely understood because it resembles common file/folder permission behavior.
Security Risks & Limitations
DAC can become weaker than centralized models when users can share access too broadly (permission creep) or delegate privileges without consistent governance.
It also increases the chance of inconsistent permissioning across teams (different owners applying different standards), which makes auditing and incident response harder.
DAC vs MAC (and RBAC)
Mandatory access control (MAC) is designed to restrict the discretionary capability that DAC allows—meaning end users generally cannot override policy just because they “own” something. Security teams often compare DAC and MAC as a “flexibility vs control” decision, where DAC fits collaboration, and MAC fits high-assurance environments with strict policy enforcement.
Decision-maker
- DAC: Resource owner (or authorized user) sets permissions
- MAC: Central authority/system policy
- RBAC (optional): Roles defined by the organization
Permission flexibility
- DAC: High; easy to grant/share
- MAC: Low; tightly constrained by policy
- RBAC (optional): Medium–high; depends on role design
Security tradeoffs
- DAC: Risk of privilege sharing + permission sprawl
- MAC: Strong control, less user discretion
- RBAC (optional): Scales well, but role explosion is possible
Best use cases
- DAC: Team shares, internal apps, file collaboration
- MAC: Military/gov, highly regulated, high assurance
- RBAC (optional): Enterprises with consistent job functions
Implementation Steps (Checklist)
Use this tool-agnostic checklist to implement DAC securely (on-prem, cloud, or hybrid):
1. Assign ownership
- Define who “owns” each resource type (files, repos, SaaS workspaces, datasets, buckets).
- Document who can change ownership and under what conditions.
2. Choose the permission model
- Decide whether permissions are managed by ACLs, groups, inheritance, or a combination.
- Standardize permission levels (e.g., Viewer / Editor / Owner / Admin) to reduce chaos.
3. Implement ACLs/permissions
- Create default templates (least privilege by default).
- Require group-based assignments where possible (avoid user-by-user exceptions).
- Restrict privilege delegation for sensitive objects (or require approval).
4. Set review & audit cadence
- Review high-risk objects (customer data, finance, HR, credentials) more frequently.
- Log permission changes and access events; alert on risky changes (public access, “everyone” grants, owner changes).
When We See DAC Used in Practice
- A shared department drive where file owners grant read/write access to teammates for collaboration, then revoke it after a project ends.
- A cloud storage bucket where the “owner” team manages object-level access through ACLs or sharing settings, while security enforces guardrails (like blocking public exposure).
FAQs
What is DAC security?
DAC security means Discretionary Access Control—an owner-driven access control model where permissions can be granted (and sometimes re-granted) by users with access, making governance and auditing critical.
How does discretionary access control work?
A subject requests access to an object, and the system checks the subject’s permissions (often via ACLs or equivalent) to allow or deny actions like read/write/execute.
DAC vs MAC: what’s the difference?
DAC lets owners manage and share access, while MAC relies on centrally enforced rules that restrict discretionary sharing and changes.
When should you avoid DAC?
Avoid relying on DAC alone when a strict, centrally enforced policy is required (high-assurance environments, highly sensitive datasets, or where privilege delegation must be tightly controlled).
Explore our other blog posts here
5-Step Security Risk Assessment: Types & How to Start
How to Detect a Tracking Device (GPS Tracker) on Your Vehicle
