Skip to main content
Commerce Security Authority
Category: Access Control

Access Control List (ACL)

Also known as: ACL, Network Access Control List, Access-Control List
Simply put

An access control list (ACL) is a set of rules that determines who or what is allowed or denied access to a system resource, such as a file, network, or device. Each rule identifies who the rule applies to and what they are permitted or forbidden to do. ACLs are a basic mechanism for controlling and filtering access in computer and network security.

Formal definition

An access control list (ACL) is a list of permissions associated with a system resource (object or facility) that specifies which trustees are granted or denied particular access rights. In host and object security contexts, an ACL is composed of access control entries (ACEs), where each ACE identifies a trustee and specifies the access rights that are allowed or denied to that trustee. In networking contexts, an ACL is a set of ordered rules that filter traffic to permit or deny it based on defined criteria, used to control network access and reduce exposure to network-based attacks.

Why it matters

Access control lists are one of the foundational mechanisms for enforcing the principle of least privilege, which underpins much of payment security and PCI DSS. By explicitly defining which users, systems, or network sources may access a given resource, ACLs help limit who can reach systems that store, process, or transmit cardholder data. In an environment subject to PCI DSS, restricting access to only those with a legitimate business need is a recurring theme across access control and network security requirements, and ACLs are a common tool for implementing those restrictions at both the network and host levels.

Because ACLs both permit and deny access, misconfiguration is a significant risk. An overly permissive network ACL can leave systems in the cardholder data environment exposed to broader network traffic than intended, while an incorrectly scoped host or object ACL can grant users more access rights than their role requires. ACLs are also order-sensitive in networking contexts, where rules are evaluated in sequence, so the placement of a permit or deny rule can materially change the outcome. Regular review and validation of ACLs is therefore important to confirm that the rules in effect still match the intended access policy.

ACLs are one control among several and should not be treated as a complete access control or segmentation solution on their own. They help reduce exposure to network-based attacks and enforce resource-level permissions, but their effectiveness depends on correct configuration, ongoing maintenance, and how they are combined with other controls such as authentication, segmentation design, and monitoring. Readers should confirm the specific access control and network requirements, including current wording and numbering, against the currently published version of PCI DSS rather than assuming any fixed requirement.

Who it's relevant to

Security engineers
Security engineers configure and maintain ACLs on network devices and host systems to enforce least-privilege access to systems in scope for payment security. They must pay attention to rule ordering in network ACLs, the specific access rights granted in host and object ACLs, and the interaction of ACLs with other controls, since a single misconfigured entry can broaden exposure to network-based attacks.
Compliance officers
Compliance officers rely on ACLs as evidence that access to resources is restricted according to business need, a recurring theme in PCI DSS access control and network security requirements. They should confirm that ACL configurations are reviewed and validated against the intended access policy and against the currently published version of the standard, rather than assuming a fixed requirement number.
Merchant risk and network teams
Teams responsible for network design and merchant environments use network ACLs to filter traffic and limit which sources can reach sensitive systems. Because ACLs both allow and deny access and are only one part of a broader control set, these teams should treat them as a component of segmentation and access control rather than a standalone guarantee of isolation.

Inside ACL

Subject
The entity requesting access, such as a user account, service account, process, host, or network source. In an ACL, each entry associates a specific subject or group with a defined set of permissions.
Object or Resource
The protected item the ACL governs, such as a file, directory, database, application function, or network segment. The ACL is bound to the object and enumerates who may interact with it.
Permitted Actions
The operations allowed or denied for a subject on the object, for example read, write, execute, delete, or, in network ACLs, permit or deny of specified traffic.
Access Control Entry (ACE)
An individual rule within the ACL pairing a subject with permitted or denied actions. The ordered or evaluated collection of ACEs forms the complete ACL.
Network ACL Match Criteria
For network-layer ACLs, the fields used to match traffic, such as source and destination addresses, protocol, and port ranges, followed by a permit or deny decision.
Default Disposition
The implicit or explicit outcome when no entry matches. A default-deny posture denies access unless an entry expressly permits it, which supports least-privilege access.

Common questions

Answers to the questions practitioners most commonly ask about ACL.

Does having an ACL in place mean my cardholder data environment is fully protected from unauthorized access?
No. An ACL is one control among many and helps reduce unauthorized access by defining which subjects may reach which resources, but it does not by itself secure a cardholder data environment. ACLs can be misconfigured, overly permissive, or bypassed if other controls such as authentication, network segmentation, logging, and change management are weak. Treat an ACL as part of a layered approach rather than a standalone safeguard, and validate its effectiveness against the current published PCI DSS requirements rather than assuming enforcement from the presence of the rule alone.
Is an ACL the same thing as a firewall ruleset?
Not exactly. The term ACL is used in different contexts: network device ACLs filter traffic based on attributes such as source and destination addresses, ports, and protocols, while file-system and application ACLs govern which users or processes may read, write, or execute specific resources. A firewall ruleset may be implemented using ACLs, but the two are not synonymous. When documenting controls, be precise about which type of ACL you mean and which layer it operates at, because the scoping and validation implications differ.
How should ACLs align with the principle of least privilege?
ACLs should be configured to grant only the access required for a subject to perform its function, denying everything else by default. In practice this means starting from a deny posture and explicitly permitting known, justified flows or permissions rather than permitting broadly and blocking exceptions. Least-privilege intent should be documented so that each entry has a business justification, which supports review and helps reduce the risk of unnecessary access paths into systems that store, process, or transmit cardholder data.
How often should ACLs be reviewed, and what should the review cover?
ACLs should be reviewed periodically and after significant changes, with the cadence aligned to your organization's policy and the applicable PCI DSS requirements in the version you are validating against. A review typically confirms that each entry still has a valid business justification, removes stale or overly permissive rules, checks for conflicting or shadowed entries, and verifies that the deployed configuration matches approved documentation. Confirm specific review frequency and evidence expectations against the current published standard rather than assuming a fixed interval.
What logging and change-control practices support ACL management?
Changes to ACLs should flow through a documented change-management process so that additions, modifications, and removals are approved, recorded, and traceable to a justification. Logging both administrative changes to ACLs and, where feasible, access decisions they influence supports detection and after-the-fact investigation. These records help demonstrate that the enforced configuration reflects approved intent, though the specific logging and retention expectations should be confirmed against the applicable requirements in the version you are validating against.
How do ACLs relate to network segmentation of the cardholder data environment?
Network-layer ACLs are one mechanism used to restrict and control traffic between segments, and they can contribute to isolating the cardholder data environment from out-of-scope systems. However, effective segmentation depends on the overall design and on validation that the restrictions actually limit connectivity as intended, not on the presence of ACL entries alone. Segmentation that reduces scope should be tested to confirm it works as documented; the effect on PCI DSS scope depends on implementation and validation rather than the label.

Common misconceptions

An ACL by itself satisfies PCI DSS access control requirements.
An ACL is one mechanism that helps enforce access decisions. PCI DSS addresses access control through several requirements covering need-to-know, least privilege, unique identification, and authentication, and requirement numbering and wording differ between versions. Readers should confirm applicable controls against the current published standard rather than assuming an ACL alone is sufficient.
Network ACLs and system or file ACLs are interchangeable and provide the same protection.
They operate at different layers and enforce different decisions. A network ACL typically filters traffic based on addresses, protocols, and ports, while a system or file ACL governs which subjects may perform which actions on a resource. Each addresses distinct risks, and one does not substitute for the other.
Once configured, an ACL keeps access correctly restricted over time.
ACLs can drift as accounts, roles, and resources change. Without periodic review, entries may grant access that is no longer needed. An ACL helps reduce unauthorized access but does not guarantee ongoing least privilege absent recurring validation and maintenance.

Best practices

Apply a default-deny disposition so access is granted only through explicit permit entries, supporting least-privilege and need-to-know objectives.
Assign permissions to defined roles or groups rather than to individual accounts where practical, to reduce configuration errors and simplify review.
Review ACL entries on a defined recurring basis and after personnel, role, or system changes to remove access that is no longer required.
Log and monitor access decisions and changes to ACLs so unauthorized or unexpected modifications can be detected and investigated.
Document the business justification for each entry so reviewers can validate that permissions map to a legitimate need.
Use ACLs as one layer within a broader access control approach that includes unique identification, authentication, and other controls appropriate to the environment, and confirm applicable requirements against the current published standard.