IT Glossary
An access control list (ACL) defines who can reach a resource and what they can do with it. Learn how ACLs work and why they stop scaling in SaaS.
August 7, 2026
An access control list (ACL) is a list attached to a resource that names which users or groups may access it and which operations they are allowed to perform. It is the most direct form of access control: the permissions live on the object itself rather than in a central policy. File systems, network devices, cloud storage buckets, and most SaaS sharing menus all work this way.
An ACL is easy to write and very hard to audit. Permissions are scattered across thousands of objects instead of sitting in one place, so answering the question of what a given person can reach means walking every resource in every system. That is why organizations past a certain size move to role-based or attribute-based models, where access follows the role rather than the object.
A 200-person company shares a finance folder in Google Drive with three named people, then someone adds an external accountant for a one-off audit. Eighteen months later the entry is still there, invisible to anyone who does not open that specific sharing panel. Multiply that by every Drive, Notion page, and Jira project and you have the real access surface of a mid-market company. Corma consolidates those permissions across the SaaS estate so a review covers the whole picture rather than one folder at a time.
An ACL attaches permissions to the resource. RBAC attaches them to a role that users inherit. ACLs are more granular, while RBAC is far easier to audit and to revoke at scale.
A single line inside an ACL, pairing one subject with the permissions granted or denied on that specific resource.
Yes. AWS S3 bucket policies, Google Drive sharing, and Azure network security groups are all ACL-based, even when a role model sits above them.
Because the permissions live on each object. There is no single place to query, so a complete answer requires enumerating every resource in every system.