Restrict access by business need to know
Restrict access by business need to know requires that access to system components and cardholder data be limited to only those individuals whose job functions specifically require it. It mandates the implementation of "least privilege," ensuring users have the minimum level of access necessary to perform their duties.
What it means
The intent of this requirement is to minimize the attack surface by reducing the number of people and systems that can interact with sensitive payment data. If a user's daily tasks do not require them to view or modify cardholder data, they should have no technical ability to do so.
In practice, this applies to all system components within the Cardholder Data Environment (CDE). It is not just about preventing unauthorized external actors from getting in, but also about restricting internal users—including administrators—from accessing data that is irrelevant to their specific role.
This control moves organizations away from "blanket" permissions toward a granular access model. Access should be granted based on defined job roles rather than individual requests or convenience, ensuring consistency and auditability across the organization.
How to meet it
- Define formal job roles for all personnel with access to the CDE and document the specific access requirements associated with each role.
- Implement Role-Based Access Control (RBAC) within your systems to ensure permissions are tied to these defined roles rather than assigned ad-hoc.
- Configure system settings, folders, and databases using "deny all" by default, explicitly granting access only where a business need is documented.
- Establish a formal request and approval process for granting new access or elevating existing privileges.
- Remove or disable unnecessary default accounts provided by vendors and change any remaining default passwords.
Evidence an auditor asks for
- A written Access Control Policy that defines the "need to know" philosophy and the process for granting access.
- An access matrix or user list mapping every individual with CDE access to their specific job role and corresponding permission level.
- Documented approvals (e.g., ticketing system logs or signed forms) showing that management authorized access based on a business need.
- System configuration screenshots demonstrating that restricted permissions are active for non-privileged users.
Common pitfalls
- Over-provisioning "Administrative" rights to too many users to avoid the friction of managing granular permissions.
- Granting access based on seniority or title rather than actual technical necessity for a specific job function.
- Failing to maintain documentation, resulting in "orphan" permissions where a user has access but there is no record of why it was granted.