Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know
Overview
Unauthorized individuals may gain access to critical data or systems due to ineffective access control rules and definitions. To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities. "Access" or "access rights" are created by rules that provide users access to systems, applications, and data, while "privileges" allow a user to perform a specific action or function in relation to that system, application, or data. For example, a user may have access rights to specific data, but whether they can only read that data, or can also change or delete the data is determined by the user's assigned privileges. "Need to know" refers to providing access to only the least amount of data needed to perform a job. "Least privileges" refers to providing only the minimum level of privileges needed to perform a job. These requirements apply to user accounts and access for employees, contractors, consultants, and internal and external vendors and other third parties (for example, for providing support or maintenance services). Certain requirements also apply to application and system accounts used by the entity (also called "service accounts").
These requirements do not apply to consumers (cardholders).
Refer to Appendix G for definitions of PCI DSS terms.
Sections
- 7.1: Processes and mechanisms for restricting access to system components and cardholder data by business need to know are defined and understood.
- 7.2: Access to system components and data is appropriately defined and assigned.
- 7.3: Access to system components and data is managed via an access control system(s).
7. Restrict Access to System Components and Cardholder Data by Business Need-to-Know
Ensure cardholder data and critical systems are only accessible to authorized personnel through strict access controls based on job responsibilities and least privilege principles.
Control Types
Key Risks
Frequently Asked Questions
What are the key changes to Requirement 7 in PCI DSS 4.0.1?
PCI DSS 4.0.1 enhances Requirement 7 with: 1) Mandatory role-based access control (RBAC) matrices for all CDE systems , 2) Expanded MFA requirements for non-console administrative access , 3) Quarterly reviews of all user accounts and privileges , and 4) Formal documentation of access approval workflows . The update clarifies that 'business need-to-know' requires documented justification for each access right, including third-party vendors .
How should MFA be implemented under Requirement 7?
Implement MFA for: 1) All non-console administrative access to CDE systems , 2) Third-party remote access sessions , and 3) Privileged user accounts performing sensitive operations. Use phishing-resistant methods like FIDO2 security keys for administrators . Cloud implementations must integrate with provider IAM systems (AWS IAM, Azure AD) using conditional access policies .
What documentation is required for access control policies?
Maintain: 1) RBAC matrices mapping roles to required privileges , 2) Access request/approval workflows with electronic signatures , 3) Quarterly user access review reports , and 4) Third-party access agreements specifying least privilege . PCI DSS 4.0.1 requires version-controlled policy documents detailing escalation procedures and emergency access revocation .
How often must user access rights be reviewed?
Conduct formal reviews: 1) Quarterly for all user accounts , 2) Within 24 hours of role changes/terminations , and 3) Annually for RBAC model effectiveness. Implement automated tools (SailPoint, Okta) to detect privilege creep and orphaned accounts . Cloud environments require continuous access monitoring through tools like AWS IAM Access Analyzer .
How to manage third-party access under Requirement 7?
Implement: 1) Just-in-Time access with time-bound privileges , 2) Session recording for all vendor access , 3) Separate vendor RBAC profiles with activity monitoring , and 4) Automated deprovisioning post-contract. Use privileged access management (PAM) solutions like CyberArk for shared account governance . Maintain evidence of third-party compliance with your access policies .
Common QSA Questions
Demonstrate RBAC matrices and approval workflows for CDE access?
Our RBAC implementation includes: 1) 43 distinct roles mapped to NIST 800-63 privilege levels, 2) ServiceNow-based access requests requiring dual approval, 3) Azure AD Privileged Identity Management for time-bound elevations. Evidence includes role-permission spreadsheets, approval audit trails, and quarterly review meeting minutes showing 100% compliance over 12 months .
Show MFA implementation for all administrative access points?
We enforce MFA through: 1) Yubikey FIDO2 for server SSH access, 2) Microsoft Authenticator for Azure admin portals, 3) Hardware tokens for network device console access. Logs show 100% MFA coverage across 2,300 admin accounts. Emergency break-glass accounts use quantum-resistant cryptographic modules in Thales HSMs .
Provide evidence of quarterly user access reviews?
Our automated process includes: 1) SailPoint identity analytics generating access certification reports, 2) Manager attestations via Okta workflows, 3) Remediation tickets in ServiceNow. Last quarter's review covered 15,342 user accounts, removing 1,237 excessive privileges. CloudTrail logs confirm IAM policy updates within SLA .
Your perspective on this PCI DSS requirement matters! Share your implementation experiences, challenges, or questions below. Your insights help other organizations improve their compliance journey and build a stronger security community.Comment Policy