1.1.1 | NSC policies and procedures documented | 19 |
1.1.2 | Roles and responsibilities for Requirement 1 | 21 |
1.2.1 | NSC configuration standards defined | 21 |
1.2.2 | Changes to NSC reviewed and approved | 22 |
1.2.3 | Network diagrams maintained | 20 |
1.2.4 | Data flow diagram of account data | 16 |
1.2.5 | Services, protocols, ports inventoried and justified | 24 |
1.2.6 | Security features for insecure services defined | 20 |
1.2.7 | NSC rule sets reviewed every six months | 20 |
1.2.8 | Configuration files secured and synchronised | 17 |
1.3.1 | Inbound traffic to CDE restricted | 22 |
1.3.2 | Outbound traffic from CDE restricted | 21 |
1.3.3 | NSCs between wireless and CDE | 15 |
1.4.1 | NSCs between trusted and untrusted networks | 26 |
1.4.2 | Inbound traffic from untrusted networks restricted | 22 |
1.4.3 | Anti-spoofing measures implemented | 11 |
1.4.4 | Account data not stored on internet-accessible systems | 22 |
1.4.5 | Internal IP and routing information protected | 13 |
1.5.1 | Security controls on dual-connected computing devices | 19 |
10.1.1 | Requirement 10 policies and operational procedures documented and maintained | 19 |
10.1.2 | Requirement 10 roles and responsibilities documented and assigned | 15 |
10.2.1 | Audit logs enabled on system components | 26 |
10.2.1.1 | Log all user access to CHD | 20 |
10.2.1.2 | Log all admin actions | 21 |
10.2.1.3 | Log access to audit logs | 19 |
10.2.1.4 | Log invalid logical access attempts | 20 |
10.2.1.5 | Log changes to identification and authentication | 20 |
10.2.1.6 | Log initialization, stopping, or pausing of logs | 16 |
10.2.1.7 | Log creation and deletion of system level objects | 17 |
10.2.2 | Audit log content | 21 |
10.3.1 | Read access to logs restricted | 18 |
10.3.2 | Logs protected from modification | 23 |
10.3.3 | Logs backed up to central server | 19 |
10.3.4 | File integrity or change detection on logs | 17 |
10.4.1 | Daily log review for critical systems | 28 |
10.4.1.1 | Automated mechanisms for log review | 19 |
10.4.2 | Periodic review of other system component logs | 20 |
10.4.2.1 | Frequency defined by TRA | 12 |
10.4.3 | Exceptions and anomalies addressed | 26 |
10.5.1 | Audit log retention 12 months | 23 |
10.6.1 | Time synchronization in use | 17 |
10.6.2 | Time settings consistent and accurate | 16 |
10.6.3 | Time settings protected | 18 |
10.7.1 | Critical security control failure detection (SP) | 19 |
10.7.2 | Critical security control failure detection (all entities) | 27 |
10.7.3 | Failure response timeline | 23 |
11.1.1 | Testing policy documented | 22 |
11.1.2 | Testing roles assigned | 15 |
11.2.1 | Wireless AP detection | 17 |
11.2.2 | Authorized wireless AP inventory | 15 |
11.3.1 | Internal vulnerability scans quarterly | 31 |
11.3.1.1 | Address non-high vulnerabilities per TRA | 23 |
11.3.1.2 | Authenticated internal scans | 18 |
11.3.1.3 | Internal scans after significant changes | 21 |
11.3.2 | External vulnerability scans quarterly by ASV | 24 |
11.3.2.1 | External scans after significant change | 17 |
11.4.1 | Penetration testing methodology defined | 22 |
11.4.2 | Internal penetration testing annually | 22 |
11.4.3 | External penetration testing annually | 25 |
11.4.4 | Pen test findings remediated | 29 |
11.4.5 | Segmentation testing | 19 |
11.4.6 | Segmentation testing (service providers) every 6 months | 12 |
11.4.7 | Multi-tenant pen test support | 7 |
11.5.1 | IDS/IPS in place | 24 |
11.5.1.1 | Covert malware channel detection (SP) | 15 |
11.5.2 | Change detection mechanism (FIM) | 23 |
11.6.1 | Payment page change and tamper detection | 12 |
12.1.1 | An overall information security policy is: • Established. • Published. • Maintained. • Disseminated to all relevant personnel, as well as to relevant vendors and business partners | 28 |
12.1.2 | The information security policy is: • Reviewed at least once every 12 months. • Updated as needed to reflect changes to business objectives or risks to the environment | 24 |
12.1.3 | Information security roles and responsibilities defined and acknowledged | 23 |
12.1.4 | CISO or equivalent responsibility | 23 |
12.10.1 | Incident response plan | 31 |
12.10.2 | IRP reviewed and tested annually | 29 |
12.10.3 | 24/7 incident response coverage | 22 |
12.10.4 | Incident responder training | 23 |
12.10.4.1 | Periodic IR responder skill review | 15 |
12.10.5 | IRP includes monitoring and response to security control alerts | 28 |
12.10.6 | IRP refined based on lessons learned | 27 |
12.10.7 | Response procedures for PAN detection in unexpected locations | 19 |
12.2.1 | Acceptable use policies for end-user technologies | 22 |
12.3.1 | Targeted risk analysis documented for requirements that specify one | 28 |
12.3.2 | TRA for customized approach | 22 |
12.3.3 | Cryptographic cipher suites and protocols inventory | 21 |
12.3.4 | Hardware and software technologies reviewed annually | 26 |
12.4.1 | Executive management responsibility for the PCI DSS compliance program (service providers) | 20 |
12.4.2 | Quarterly PCI compliance reviews (SP) | 26 |
12.4.2.1 | Documentation of quarterly reviews (SP) | 22 |
12.5.1 | Inventory of system components in scope | 27 |
12.5.2 | PCI DSS scope documented and confirmed annually | 30 |
12.5.2.1 | Service provider scope confirmed every 6 months | 15 |
12.5.3 | Impact analysis on org structure changes (SP) | 20 |
12.6.1 | Formal security awareness program implemented | 28 |
12.6.2 | Security awareness program reviewed annually | 21 |
12.6.3 | Security awareness training delivered | 30 |
12.6.3.1 | Training on phishing and social engineering | 22 |
12.6.3.2 | Training on acceptable use of end-user technologies | 21 |
12.7.1 | Personnel screening | 25 |
12.8.1 | Third-party service provider inventory | 24 |
12.8.2 | Written agreements with TPSPs | 28 |
12.8.3 | TPSP due diligence | 28 |
12.8.4 | TPSP compliance monitored | 28 |
12.8.5 | Responsibility matrix with TPSPs | 27 |
12.9.1 | TPSP written acknowledgement of responsibility (SP) | 13 |
12.9.2 | TPSP supports customer requests for compliance info (SP) | 17 |
2.1.1 | All security policies and operational procedures that are identified in Requirement 2 are: • Documented. • Kept up to date. • In use. • Known to all affected parties | 37 |
2.1.2 | Roles and responsibilities for performing activities in Requirement 2 are documented, assigned, and understood | 35 |
2.2.1 | Configuration standards are developed, implemented, and maintained to: • Cover all system components. • Address all known security vulnerabilities. • Be consistent with industry-ac | 27 |
2.2.2 | Vendor default accounts are managed as follows: • If the vendor default account(s) will be used, the default password is changed per Requirement 8.3.6. • If the vendor default acco | 187 |
2.2.3 | Primary functions isolated or secured to highest level | 19 |
2.2.4 | Only necessary services enabled | 25 |
2.2.5 | Insecure services or protocols documented | 18 |
2.2.6 | System security parameters configured | 23 |
2.2.7 | Non-console administrative access encrypted | 20 |
2.3.1 | Wireless vendor defaults changed before installation | 16 |
2.3.2 | Wireless encryption keys rotated | 17 |
3.3.1.1 | Full track data not stored after authorization | 11 |
3.3.1.2 | Card verification code not stored after authorization | 3 |
3.3.1.3 | PIN and PIN block not stored after authorization | 5 |
3.3.2 | SAD stored prior to authorization is encrypted | 11 |
3.3.3 | SAD storage by issuers limited | 11 |
3.4.2 | Technical controls prevent unauthorized PAN copy | 17 |
3.5.1 | PAN rendered unreadable wherever stored | 23 |
3.5.1.1 | Hashes of PAN use keyed cryptographic functions | 11 |
3.5.1.2 | Disk-level encryption with logical access controls | 18 |
3.5.1.3 | Disk-level encryption key management | 17 |
3.6.1.1 | Documented description of cryptographic architecture | 16 |
3.6.1.2 | Secret and private keys restricted to fewest custodians | 16 |
3.6.1.3 | Access to cryptographic keys restricted | 18 |
3.6.1.4 | Cryptographic keys stored in fewest possible locations | 15 |
3.7.2 | Secure key distribution | 17 |
3.7.3 | Secure key storage | 17 |
3.7.4 | Cryptoperiod and key changes | 16 |
3.7.5 | Retirement or replacement of keys | 15 |
3.7.6 | Manual cleartext key operations use split knowledge | 11 |
3.7.7 | Prevent unauthorised substitution of keys | 14 |
3.7.8 | Custodians acknowledge responsibilities | 14 |
3.7.9 | Service provider customer key responsibilities | 11 |
4.1.1 | All security policies and operational procedures that are identified in Requirement 4 are: • Documented. • Kept up to date. • In use. • Known to all affected parties | 19 |
4.1.2 | Roles and responsibilities for performing activities in Requirement 4 are documented, assigned, and understood | 18 |
4.2.1 | Strong cryptography and security protocols are implemented as follows to safeguard PAN during transmission over open, public networks: • Only trusted keys and certificates are acce | 24 |
4.2.1.1 | Inventory of trusted keys and certificates | 18 |
4.2.1.2 | Wireless networks transmitting PAN use strong cryptography | 17 |
4.2.2 | PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies | 20 |
5.1.1 | All security policies and operational procedures that are identified in Requirement 5 are: • Documented. • Kept up to date. • In use. • Known to all affected parties | 18 |
5.1.2 | Roles and responsibilities for performing activities in Requirement 5 are documented, assigned, and understood | 17 |
5.2.3.1 | Frequency of periodic evaluations per targeted risk analysis | 15 |
5.3.2.1 | Periodic scan frequency per targeted risk analysis | 15 |
5.3.4 | Audit logs for anti-malware enabled | 19 |
5.3.5 | Anti-malware cannot be disabled by users | 20 |
5.4.1 | Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks | 19 |
6.1.1 | All security policies and operational procedures that are identified in Requirement 6 are: • Documented. • Kept up to date. • In use. • Known to all affected parties | 20 |
6.1.2 | Roles and responsibilities for performing activities in Requirement 6 are documented, assigned, and understood | 18 |
6.2.1 | Bespoke and custom software are developed securely, as follows: • Based on industry standards and/or best practices for secure development. • In accordance with PCI DSS (for exampl | 25 |
6.2.2 | Software development personnel working on bespoke and custom software are trained at least once every 12 months as follows: • On software security relevant to their job function an | 24 |
6.2.3 | Custom software reviewed prior to production | 21 |
6.2.3.1 | Code review findings corrected | 21 |
6.2.4 | Coding practices prevent common attacks | 20 |
6.4.1 | For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks as follows: • Revie | 22 |
6.4.2 | For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks, with at least the following: • Is installed | 16 |
6.5.5 | Live PANs not used in pre-production | 11 |
6.5.6 | Test data and accounts removed before production | 15 |
7.1.1 | All security policies and operational procedures that are identified in Requirement 7 are: • Documented. • Kept up to date. • In use. • Known to all affected parties | 19 |
7.1.2 | Roles and responsibilities for performing activities in Requirement 7 are documented, assigned, and understood | 16 |
7.2.1 | An access control model is defined and includes granting access as follows: • Appropriate access depending on the entity's business and access needs. • Access to system components | 27 |
7.2.2 | Access is assigned to users, including privileged users, based on: • Job classification and function. • Least privileges necessary to perform job responsibilities | 29 |
7.2.3 | Required privileges are approved by authorized personnel | 23 |
7.2.5.1 | App and system account review cadence | 17 |
7.3.2 | The access control system(s) is configured to enforce permissions assigned to individuals, applications, and systems based on job classification and function | 20 |
7.3.3 | The access control system(s) is set to “deny all” by default | 20 |
8.2.1 | All users are assigned a unique ID before access to system components or cardholder data is allowed | 25 |
8.2.2 | Group, shared, or generic IDs, or other shared authentication credentials are only used when necessary on an exception basis, and are managed as follows: • ID use is prevented unle | 21 |
8.2.3 | Additional requirement for service providers only: Service providers with remote access to customer premises use unique authentication factors for each customer premises | 12 |
8.2.4 | Addition, deletion, and modification of user IDs, authentication factors, and other identifier objects are managed as follows: • Authorized with the appropriate approval. • Impleme | 22 |
8.2.5 | Access for terminated users is immediately revoked | 24 |
8.2.6 | Inactive user accounts are removed or disabled within 90 days of inactivity | 19 |
8.2.7 | Third-party access managed | 21 |
8.2.8 | Session idle timeout | 17 |
8.3.1 | All user access to system components for users and administrators is authenticated via at least one of the following authentication factors: • Something you know, such as a passwor | 26 |
8.3.10 | Service provider customer password guidance | 13 |
8.3.10.1 | SP password rotation or posture | 6 |
8.3.11 | Hardware token and other factor protection | 14 |
8.3.2 | Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components | 22 |
8.3.3 | User identity is verified before modifying any authentication factor | 15 |
8.3.4 | Invalid authentication attempts are limited by: • Locking out the user ID after not more than 10 attempts. • Setting the lockout duration to a minimum of 30 minutes or until the us | 19 |
8.3.5 | If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user as follows: • Set to a unique value for first-time use a | 17 |
8.3.6 | If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity: • A minimum length of 12 characters (or | 23 |
8.3.7 | Password history | 12 |
8.3.8 | Authentication policy communicated | 21 |
8.3.9 | Password change frequency if only factor | 15 |
8.4.1 | MFA is implemented for all non-console access into the CDE for personnel with administrative access | 25 |
8.4.2 | MFA is implemented for all non-console access into the CDE | 26 |
8.4.3 | MFA is implemented for all remote access originating from outside the entity's network that could access or impact the CDE | 24 |
8.5.1 | MFA systems are implemented as follows: • The MFA system is not susceptible to replay attacks. • MFA systems cannot be bypassed by any users, including administrative users unless | 22 |
9.1.1 | All security policies and operational procedures that are identified in Requirement 9 are: • Documented. • Kept up to date. • In use. • Known to all affected parties | 18 |
9.1.2 | Roles and responsibilities for performing activities in Requirement 9 are documented, assigned, and understood | 18 |
9.2.1 | Appropriate facility entry controls are in place to restrict physical access to systems in the CDE | 21 |
9.2.1.1 | Individual physical access to sensitive areas within the CDE is monitored with either video cameras or physical access control mechanisms (or both) as follows: • Entry and exit poi | 20 |
9.2.2 | Physical and/or logical controls are implemented to restrict use of publicly accessible network jacks within the facility | 18 |
9.2.3 | Physical access to networking and telecommunications hardware restricted | 21 |
9.2.4 | Consoles in sensitive areas locked when not in use | 13 |
9.3.1 | Procedures are implemented for authorizing and managing physical access of personnel to the CDE, including: • Identifying personnel. • Managing changes to an individual's physical | 22 |
9.3.1.1 | Personnel access readily revoked | 18 |
9.3.2 | Procedures are implemented for authorizing and managing visitor access to the CDE, including: • Visitors are authorized before entering. • Visitors are escorted at all times. • Vis | 18 |
9.3.3 | Visitor badges or identification are surrendered or deactivated before visitors leave the facility or at the date of expiration | 15 |
9.3.4 | Visitor log retention | 15 |
9.4.1 | Media with cardholder data physically secured | 20 |
9.4.1.1 | Offline media backup security | 21 |
9.4.1.2 | Offsite backup location reviewed | 17 |
9.4.2 | Media classified by sensitivity | 20 |
9.4.3 | Media sent outside facility secured | 19 |
9.4.4 | Management approval for media moved outside the facility | 16 |
9.4.5 | Inventory logs of electronic media | 19 |
9.4.5.1 | Inventories of electronic media with cardholder data are conducted at least once every 12 months | 17 |
9.4.6 | Hard copy media destruction | 18 |
9.4.7 | Electronic media destruction | 22 |
9.5.1 | POI device protection | 14 |
9.5.1.1 | POI inventory maintained | 15 |
9.5.1.2 | POI tamper inspection | 11 |
9.5.1.3 | POI personnel training | 17 |
3.1.1 | All security policies and operational procedures that are identified in Requirement 3 are: • Documented. • Kept up to date. • In use. • Known to all affected parties | 20 |
3.1.2 | Roles and responsibilities for performing activities in Requirement 3 are documented, assigned, and understood | 19 |
3.2.1 | Account data storage is kept to a minimum through implementation of data retention and disposal policies, procedures, and processes that include at least the following: • Coverage | 25 |
3.3.1 | SAD is not stored after authorization, even if encrypted. All sensitive authentication data received is rendered unrecoverable upon completion of the authorization process | 12 |
3.4.1 | PAN is masked when displayed (the BIN and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can | 14 |
3.6.1 | Procedures are defined and implemented to protect cryptographic keys used to protect stored account data against disclosure and misuse that include: • Access to keys is restricted | 21 |
3.7.1 | Key-management policies and procedures are implemented to include generation of strong cryptographic keys used to protect stored account data | 20 |
5.2.1 | An anti-malware solution(s) is deployed on all system components, except for those system components identified in periodic evaluations per Requirement 5.2.3 that concludes the sys | 26 |
5.2.2 | The deployed anti-malware solution(s): • Detects all known types of malware. • Removes, blocks, or contains all known types of malware | 24 |
5.2.3 | Any system components that are not at risk for malware are evaluated periodically to include the following: • A documented list of all system components not at risk for malware. • | 17 |
5.3.1 | The anti-malware solution(s) is kept current via automatic updates | 24 |
5.3.2 | The anti-malware solution(s): • Performs periodic scans and active or real-time scans. OR • Performs continuous behavioral analysis of systems or processes | 21 |
5.3.3 | For removable electronic media, the anti- malware solution(s): • Performs automatic scans of when the media is inserted, connected, or logically mounted, OR • Performs continuous b | 21 |
6.3.1 | Security vulnerabilities are identified and managed as follows: • New security vulnerabilities are identified using industry-recognized sources for security vulnerability informati | 28 |
6.3.2 | An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch m | 23 |
6.3.3 | All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows: • Patches/updates for critical vulnerabilities (identif | 29 |
6.4.3 | All payment page scripts that are loaded and executed in the consumer's browser are managed as follows: • A method is implemented to confirm that each script is authorized. • A met | 17 |
6.5.1 | Changes to all system components in the production environment are made according to established procedures that include: • Reason for, and description of, the change. • Documentat | 23 |
6.5.2 | Upon completion of a significant change, all applicable PCI DSS requirements are confirmed to be in place on all new or changed systems and networks, and documentation is updated a | 23 |
6.5.3 | Pre-production environments are separated from production environments and the separation is enforced with access controls | 23 |
6.5.4 | Roles and functions are separated between production and pre-production environments to provide accountability such that only reviewed and approved changes are deployed | 21 |
7.2.4 | All user accounts and related access privileges, including third-party/vendor accounts, are reviewed as follows: • At least once every six months. • To ensure user accounts and acc | 26 |
7.2.5 | All application and system accounts and related access privileges are assigned and managed as follows: • Based on the least privileges necessary for the operability of the system o | 22 |
7.2.6 | All user access to query repositories of stored cardholder data is restricted as follows: • Via applications or other programmatic methods, with access and allowed actions based on | 18 |
7.3.1 | An access control system(s) is in place that restricts access based on a user's need to know and covers all system components | 23 |
8.1.1 | All security policies and operational procedures that are identified in Requirement 8 are: • Documented. • Kept up to date. • In use. • Known to all affected parties | 19 |
8.1.2 | Roles and responsibilities for performing activities in Requirement 8 are documented, assigned, and understood | 18 |
8.6.1 | If accounts used by systems or applications can be used for interactive login, they are managed as follows: • Interactive use is prevented unless needed for an exceptional circumst | 17 |
8.6.2 | Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded in scripts, configuration/property files, or bespoke and cus | 20 |
8.6.3 | Passwords/passphrases for any application and system accounts are protected against misuse as follows: • Passwords/passphrases are changed periodically (at the frequency defined in | 20 |