Companies that process credit card payments must comply with the Payment Card Industry (PCI) Data Security Standards (DSS). This framework, developed and enforced by the Security Standards Council (SSC), requires strict protocols for access control, such as automatic lockout and other restrictions on cardholder data access. Read on to learn about the relevant PCI DSS Goals and Requirements you need to follow for a fully compliant PCI information security policy.
Account Lockout Protocols for a PCI Information Security Policy
The PCI DSS account lockout policy is couched within the fourth Goal in the DSS: “Implement Strong Access Control Measures.” It includes three Requirements to safeguard user accounts:
- PCI DSS Requirement 7: Restrict cardholder data access by business need to know
- PCI DSS Requirement 8: Authenticate identities for access to system components
- PCI DSS Requirement 9: Restrict physical and proximal access to cardholder data
Also relevant is the last DSS Goal—“Maintain an Information Security Policy”—which comprises:
- PCI DSS Requirement 12: Maintain a policy addressing security needs for all personnel
Taken together, these controls govern the PCI DSS security policy and complement all other DSS Goals and Requirements, which depend upon access control and the information policy to protect cardholder data.
PCI DSS Requirement 7: Restricting Access By Need to Know
The explicit lockout protocols are articulated in Requirement 8, which governs how all user accounts must be managed. However, Requirement 7 outlines how and why access needs to be controlled, stipulating the “business need to know” restrictions across three sub-requirements:
- PCI DSS Requirement 7.1 – Provide access to system components with cardholder data exclusively to individuals whose work responsibilities necessitate such access.
- PCI DSS Requirement 7.2 – Design one or more systems to deny all access not explicitly designated as within an individual’s “business need to know,” per 7.1.
- PCI DSS Requirement 7.3 – Ensure all security policies related to 7.1 and 7.2 are formally documented, known, and used by all impacted personnel and third parties.
These controls determine foundations for user account privileges and characteristics, which in turn, inform the account lockout and other authenticating controls detailed in Requirement 8.
PCI DSS Requirement 8: Authenticating Access to Components
Requirement 8 is home to the sub-requirements governing PCI account lockout protocols:
- PCI DSS Requirement 8.1 – Implement policies for user identification for internal staff across all system components, including the following controls for lockouts specifically:
- PCI DSS Requirement 8.1.6: Restrict repeated login attempts, locking users out of accounts after a maximum of six failed attempts at authenticating their identity.
- PCI DSS Requirement 8.1.7: Ensure lockout duration is at least 30 minutes or require administrative oversight to override a lockout and re-enable the account.
- PCI DSS Requirement 8.1.8: Automatically lock a user out and require re-authentication after an authorized access session has been idle for a maximum of 15 minutes.
These are a critical part of Requirement 8’s account management scheme, which also includes:
- PCI DSS Requirement 8.2 – Utilize multi-factor authentication (MFA) to identify users, enforce minimum credential complexity, and encrypt all data pertaining to credentials.
- PCI DSS Requirement 8.3 – Apply MFA to non-console administrative access and all remote user access to system components containing or connected to cardholder data.
- PCI DSS Requirement 8.4 – Ensure documentation and communication of all account authentication processes protocols to all individuals who own or operate user accounts.
- PCI DSS Requirement 8.5 – Prohibit the use of any shared, generic, default, and other easily compromisable user account credentials for all administrative or critical accounts.
- PCI DSS Requirement 8.6 – Safeguard all permitted uses of alternative login methods, such as tokens; ensure these are minimal and subject to physical controls (see below).
- PCI DSS Requirement 8.7 – Restrict access to databases containing cardholder data to programmatic methods; ensure only administrators can directly query these databases.
- PCI DSS Requirement 8.8 – Ensure all security policies related to 8.1 through 8.8 are formally documented, known, and used by all impacted personnel and third parties.
Collectively, these sub-requirements exert maximum control and visibility over all behaviors enacted within user accounts. Outside of their scope, however, is access control over devices.
PCI DSS Requirement 9: Controlling Physical Access to Data
The last Requirement within the access control Group extends the primarily behavior-based restrictions above to physical control over areas in and devices on which data is accessed:
- PCI DSS Requirement 9.1 – Control and monitor entrance into facilities and internal spaces that house system components containing or connected to cardholder data.
- PCI DSS Requirement 9.2 – Design processes to swiftly and accurately distinguish between visitors and on-site personnel, modifying access requirements accordingly.
- PCI DSS Requirement 9.3 – Restrict physical and proximal access to sensitive areas for on-site personnel according to business need to enter areas and access systems.
- PCI DSS Requirement 9.4 – Design and implement processes to identify or authorize visitors, before an on-site visit, during initial access, and throughout access duration.
- PCI DSS Requirement 9.5 – Physically secure all media on which cardholder data is stored or processed, including secure backups ideally housed in an off-site location.
- PCI DSS Requirement 9.6 – Control all internal and external media distribution via classification, secure couriers, and approval before, during, and after transmission.
- PCI DSS Requirement 9.7 – Control storage and accessibility of all media containing or connected to cardholder data, including robust inventory logs and regular assessments.
- PCI DSS Requirement 9.8 – Destroy all media containing cardholder or other sensitive data when it no longer satisfies a legal or business-specific reason for being retained.
- PCI DSS Requirement 9.9 – Safeguard devices that come into physical contact with credit cards (for card-present transactions) against threats of tampering or substitution.
Requirements 7, 8, and 9 define the specifications of a PCI information security policy pertaining to user accounts, including but not limited to the PCI DSS account lockout policy in Requirement 8. These are all subject to broader, system-wide PCI security policy requirements.
PCI DSS Requirement 12: Maintaining an Information Security Policy
Departing from the access control Group, the final DSS Requirement instead stipulates that companies must articulate all responsibilities across all Requirements in a formal information security policy. Its sub-requirements define the thresholds the policy needs to meet, breaking down as follows:
- PCI DSS Requirement 12.1 – Plan, design, publish, and disseminate security policy to all applicable individuals, including internal personnel and third parties such as vendors.
- PCI DSS Requirement 12.2 – Implement risk assessments regularly (at least annual intervals, at a minimum) and upon significant environmental changes (relocation, merger, etc.).
- PCI DSS Requirement 12.3 – Define proper uses for all critical technologies; develop formal policies delineating these uses for all personnel who use these technologies.
- PCI DSS Requirement 12.4 – Ensure all formalized policies clearly address and define security responsibilities for all personnel who come into contact with cardholder data.
- PCI DSS Requirement 12.5 – Designate an individual or team responsible for security policy administration, including the development, distribution, and enforcement of policies.
- PCI DSS Requirement 12.6 – Design and implement a rigorous security awareness training program to ensure staff-wide familiarity and facility with security responsibilities.
- PCI DSS Requirement 12.7 – Implement robust onboarding processes for new staff, including thorough screening and training, to minimize the potential for internal threats.
- PCI DSS Requirement 12.8 – Monitor and exert control over service providers and all third parties who store, process, or otherwise come into contact with cardholder data.
- PCI DSS Requirement 12.10 – Design and implement a dedicated incident response plan, with individual stakeholders’ responsibilities articulated formally and accessibly.
Two additional sub-requirements, 12.9 and 12.11, apply exclusively to service providers; they govern notice to customers about security responsibilities and regular staff-wide security scans. Collectively, these 11 sub-requirements cover all aspects of designing, implementing, and then enforcing a company-wide PCI information security policy, including all other Requirements.
Other Considerations for a Compliant PCI DSS Security Policy
The PCI DSS account lockout policy and PCI DSS security policy appear in Requirements 8 and 12, respectively. However, companies need to account for other elements of PCI DSS implementation to ensure a full-fledged PCI DSS compliance policy. All other PCI DSS Requirements must be installed, for example.
Additionally, companies need to assess and verify their compliance alongside building out the appropriate controls and cybersecurity architecture. Those at the lowest annual transaction level must only file a Self Assessment Questionnaire (SAQ). Those at higher transaction levels will need to work with a Qualified Security Assessor (QSA) to file an Attestation of Compliance (AOC) or Report on Compliance (ROC).
Here at RSI Security, our dedicated PCI compliance services cover all elements of design, implementation, assessment, and reporting.
Remaining DSS Requirements for a PCI DSS Compliance Policy
PCI DSS Requirements 7, 8, 9, and 12 are most closely related to PCI account lockouts and information security policy protocols, but the entire framework is interlocked. As a result, the Requirements across all Groups impact these critical areas in direct and indirect ways.
For example, the first Group, “Maintaining Security Across Networks And Information Systems,” comprises the following:
- PCI DSS Requirement 1 – Maintain firewall configurations to protect cardholder data.
- PCI DSS Requirement 2 – Replace default, vendor-supplied security configurations.
Then, the “Protecting Cardholder Data Across All Information Technology” Group includes:
- PCI DSS Requirement 3 – Protect all cardholder data stored in information systems.
- PCI DSS Requirement 4 – Encrypt cardholder data for transmission on public networks.
The “Implementing and Maintaining a Vulnerability Management Program” Group comprises:
- PCI DSS Requirement 5 – Maintain antivirus and antimalware programs on all systems.
- PCI DSS Requirement 6 – Develop secure applications and maintain long-term security.
And the fifth Group, “Regularly Monitoring and Testing Networks’ Information Security,” has:
- PCI DSS Requirement 10 – Monitor all access to systems containing cardholder data.
- PCI DSS Requirement 11 – Assess the efficacy of security procedures at regular intervals.
Along with the fourth and sixth Groups, detailed above, these controls offer optimal control and visibility, not to mention DSS compliance. However, certain companies may also need to abide by other PCI frameworks beyond the PCI DSS, requiring additional security policy protocols.
PCI Information Security Policy Requirements Beyond PCI DSS
One last set of considerations for companies who need to build a PCI-compliant information security policy involves the SSC’s various other standards. Per a PCI standards overview, two additional frameworks apply widely: the Payment Application (PA) DSS and the PIN transaction Security (PTS) Requirements. The latter applies to manufacturers of PIN terminals, while the former applies to all developers and integrators of payment apps.
The PCI DSS states that both PA DSS and PCI DSS Requirements may apply to a company simultaneously. The controls for each need to be assessed and reported on separately despite their overlaps. So, companies may need to adopt additional PA DSS controls for account lockouts (and general access control), along with a distinct PA DSS security policy.
PA DSS Requirements for Account Safety and Information Security
Of the 14 controls that make up the PA DSS framework, one pertains to access control and corresponds to PCI DSS Requirements 7, 8, and 9. It breaks down as follows:
- PA DSS Requirement 3 – Provide authentication features on devices, ensuring unique user IDs, complex credentials, MFA, timed access sessions, and automatic lockouts.
And, also like the PCI DSS, the PA DSS requires a formal PCI information security policy:
- PA DSS Requirement 13 – Develop and disseminate one or more guides to PA DSS implementation to all customers, resellers, and integrators with security responsibilities.
- PA DSS Requirement 14 – Designate specific PA DSS responsibilities for these same stakeholders and ensure they are upheld with rigorous training and guide accessibility.
Implementing all these controls and verifying their integrity with the appropriate PCI reporting documentation is much easier with the help of a PCI compliance partner.
Professional PCI Compliance and Security Program Advisory
Implementing a fully compliant PCI information security policy requires following all the specific controls in PCI DSS Requirements 8 and 12 carefully; by extension, this necessitates following the closely related Requirements 7 and 9, along with the remaining DSS framework.
Companies may also need to apply relevant controls from the PA DSS framework, and all implementation needs to be verified by a PCI SAQ, AOC, or ROC.