A Discretionary Access Control List is the list of access control entries attached to a securable object in Windows. It grants or denies permissions to users, groups or service accounts, and the object owner can usually change it, which makes it a core part of Windows access control.
What a DACL is in Windows
A DACL is the Windows access control list that sits on a securable object, such as a file, registry key, process, or service. It contains access control entries that allow or deny specific permissions to named security principals.
The important idea is that the DACL is not the permission itself, but the rule set Windows evaluates when a subject tries to use an object. That makes it the practical enforcement point for object-level access control, not just a bookkeeping structure.
How DACLs decide access
Windows evaluates the ACEs in a DACL to decide whether a requester can read, write, execute, modify, take ownership, or perform another object-specific action. Allow and deny entries can coexist, and ordering matters because the evaluation path can change the effective result.
This means a DACL is only as clear as the ACEs inside it. Overlapping entries, inherited permissions, explicit denies, and broad group membership can make the effective decision less obvious than the raw list suggests.
Why ownership matters
Unlike a purely centralised policy model, a DACL is discretionary because the object owner can usually change it. That ownership model is powerful, but it also means access control can be expanded or weakened at the object level without a separate approval layer unless one is added by policy.
In practice, DACLs often reflect a blend of local administration, inherited defaults, and ad hoc changes. The result is that the security posture of a Windows object depends not only on the intended policy, but also on who has the ability to rewrite the list.
DACLs in real access control design
DACLs are foundational to Windows authorisation because they are the mechanism that turns group membership, service account usage, and ownership into effective access decisions. If the DACL is too permissive, the object can be overexposed; if it is too restrictive, legitimate operations fail and teams work around the control.
That is why DACL management is usually tied to broader access governance, not treated as a one-off configuration task. The useful question is not only “does access work”, but also “does the ACL still reflect the minimum access required by current roles and services?”
Risk and Threat Considerations
DACLs create direct security risk when they grant excessive rights, contain unexpected inheritance, or allow a low-trust principal to rewrite permissions on a sensitive object. Because they govern object-level access, a weak DACL can become a privilege-escalation path, a persistence mechanism, or a way to hide follow-on activity.
Failure mechanism: An attacker or overprivileged user abuses a permissive ACE, permission inheritance, or object ownership to gain access they should not have, then uses that access to alter data, plant persistence, or expand control over adjacent objects.
Impact: The resulting exposure can include data disclosure, configuration tampering, service disruption, credential or secret access, and broader lateral movement across the Windows environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | DACLs enforce object permissions by restricting access to only what a subject needs. |
| AC-2 — Account Management | DACLs often grant access to users, groups, and service accounts that must be governed over time. | |
| AC-3 — Access Enforcement | A DACL is the Windows mechanism that enforces allow and deny decisions on securable objects. | |
| Recommendation — Apply AC-6 to limit object permissions to the minimum necessary rights. Use AC-2 to manage which accounts and groups can receive object access. Use AC-3 to enforce object-level access decisions through defined access rules. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | DACLs are a core Windows access-control mechanism covered by account and permission governance. |
| Recommendation — Centralize and review Windows object permissions under CIS-6. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | DACLs are an operating-system access control mechanism that must align with access policy. |
| Recommendation — Define and review Windows object permissions under A.5.15. | ||
Practitioner Guidance
What to watch for: Treat DACL review as both an authorisation and an operations issue. Pay attention to objects with inherited permissions, broad group grants, explicit denies that mask intended access, and owners that can silently regrant access without oversight.
Governance implication: A DACL should be understood as a changeable control surface, not a static policy artifact. Teams should keep object ownership, delegated administration, and privilege boundaries clear enough that access changes are intentional, reviewable, and reversible.
Related resources from NHI Mgmt Group
- How does a discretionary access control list work?
- Why does Discretionary Access Control List matter for security teams?
- What breaks when access control list reviews are not built into DevSecOps workflows?
- What breaks when discretionary access control is used without strong administrative oversight?