PCI DSS 4.0: the evidence behind every control

249 controls. For each, the artefacts auditors ask for, which ones a system already holds, and the first move to stop evidencing it by periodic review.

Req 1: Network Security Controls

1.1.1NSC policies and procedures documented hard 1.1.2Roles and responsibilities for Requirement 1 hard 1.2.1NSC configuration standards defined moderate 1.2.2Changes to NSC reviewed and approved easy 1.2.3Network diagrams maintained hard 1.2.4Data flow diagram of account data hard 1.2.5Services, protocols, ports inventoried and justified hard 1.2.6Security features for insecure services defined hard 1.2.7NSC rule sets reviewed every six months moderate 1.2.8Configuration files secured and synchronised easy 1.3.1Inbound traffic to CDE restricted hard 1.3.2Outbound traffic from CDE restricted moderate 1.3.3NSCs between wireless and CDE moderate 1.4.1NSCs between trusted and untrusted networks hard 1.4.2Inbound traffic from untrusted networks restricted moderate 1.4.3Anti-spoofing measures implemented moderate 1.4.4Account data not stored on internet-accessible systems moderate 1.4.5Internal IP and routing information protected easy 1.5.1Security controls on dual-connected computing devices hard

Req 2: Secure Configurations

2.1.1All security policies and operational procedures that are identified in Requirement 2 are: • Documented. • Kept up to date. • In use. • Known to all affected parties hard 2.1.2Roles and responsibilities for performing activities in Requirement 2 are documented, assigned, and understood moderate 2.2.1Configuration standards are developed, implemented, and maintained to: • Cover all system components. • Address all known security vulnerabilities. • Be consistent with industry-accepted system hardening standards or vendor hardening recommendations. • Be updated hard 2.2.2Vendor 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 account(s) will not be used, hard 2.2.3Primary functions isolated or secured to highest level hard 2.2.4Only necessary services enabled easy 2.2.5Insecure services or protocols documented hard 2.2.6System security parameters configured moderate 2.2.7Non-console administrative access encrypted easy 2.3.1Wireless vendor defaults changed before installation moderate 2.3.2Wireless encryption keys rotated moderate

Req 3: Protect Stored Account Data

3.1.1All security policies and operational procedures that are identified in Requirement 3 are: • Documented. • Kept up to date. • In use. • Known to all affected parties hard 3.1.2Roles and responsibilities for performing activities in Requirement 3 are documented, assigned, and understood hard 3.2.1Account 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 for all locations of stored account data. hard 3.3.1SAD is not stored after authorization, even if encrypted. All sensitive authentication data received is rendered unrecoverable upon completion of the authorization process moderate 3.3.1.1Full track data not stored after authorization hard 3.3.1.2Card verification code not stored after authorization hard 3.3.1.3PIN and PIN block not stored after authorization moderate 3.3.2SAD stored prior to authorization is encrypted hard 3.3.3SAD storage by issuers limited moderate 3.4.1PAN 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 hard 3.4.2Technical controls prevent unauthorized PAN copy hard 3.5.1PAN rendered unreadable wherever stored moderate 3.5.1.1Hashes of PAN use keyed cryptographic functions hard 3.5.1.2Disk-level encryption with logical access controls hard 3.5.1.3Disk-level encryption key management hard 3.6.1Procedures 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 to the fewest number of custodians necessary. hard 3.6.1.1Documented description of cryptographic architecture hard 3.6.1.2Secret and private keys restricted to fewest custodians easy 3.6.1.3Access to cryptographic keys restricted hard 3.6.1.4Cryptographic keys stored in fewest possible locations hard 3.7.1Key-management policies and procedures are implemented to include generation of strong cryptographic keys used to protect stored account data hard 3.7.2Secure key distribution hard 3.7.3Secure key storage moderate 3.7.4Cryptoperiod and key changes moderate 3.7.5Retirement or replacement of keys hard 3.7.6Manual cleartext key operations use split knowledge hard 3.7.7Prevent unauthorised substitution of keys hard 3.7.8Custodians acknowledge responsibilities hard 3.7.9Service provider customer key responsibilities hard

Req 4: Protect Cardholder Data in Transit

4.1.1All security policies and operational procedures that are identified in Requirement 4 are: • Documented. • Kept up to date. • In use. • Known to all affected parties hard 4.1.2Roles and responsibilities for performing activities in Requirement 4 are documented, assigned, and understood moderate 4.2.1Strong cryptography and security protocols are implemented as follows to safeguard PAN during transmission over open, public networks: • Only trusted keys and certificates are accepted. • Certificates used to safeguard PAN during transmission hard 4.2.1.1Inventory of trusted keys and certificates hard 4.2.1.2Wireless networks transmitting PAN use strong cryptography moderate 4.2.2PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies hard

Req 5: Anti-Malware

5.1.1All security policies and operational procedures that are identified in Requirement 5 are: • Documented. • Kept up to date. • In use. • Known to all affected parties hard 5.1.2Roles and responsibilities for performing activities in Requirement 5 are documented, assigned, and understood hard 5.2.1An 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 system components are not at risk from malware hard 5.2.2The deployed anti-malware solution(s): • Detects all known types of malware. • Removes, blocks, or contains all known types of malware hard 5.2.3Any 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. • Identification and evaluation hard 5.2.3.1Frequency of periodic evaluations per targeted risk analysis hard 5.3.1The anti-malware solution(s) is kept current via automatic updates hard 5.3.2The anti-malware solution(s): • Performs periodic scans and active or real-time scans. OR • Performs continuous behavioral analysis of systems or processes easy 5.3.2.1Periodic scan frequency per targeted risk analysis hard 5.3.3For removable electronic media, the anti- malware solution(s): • Performs automatic scans of when the media is inserted, connected, or logically mounted, OR • Performs continuous behavioral analysis of systems or processes when the hard 5.3.4Audit logs for anti-malware enabled moderate 5.3.5Anti-malware cannot be disabled by users hard 5.4.1Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks hard

Req 6: Secure Systems and Software

6.1.1All security policies and operational procedures that are identified in Requirement 6 are: • Documented. • Kept up to date. • In use. • Known to all affected parties hard 6.1.2Roles and responsibilities for performing activities in Requirement 6 are documented, assigned, and understood hard 6.2.1Bespoke 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 example, secure authentication and logging). • Incorporating hard 6.2.2Software 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 and development languages. • Including secure hard 6.2.3Custom software reviewed prior to production hard 6.2.3.1Code review findings corrected hard 6.2.4Coding practices prevent common attacks hard 6.3.1Security vulnerabilities are identified and managed as follows: • New security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (CERTs). • Vulnerabilities hard 6.3.2An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management hard 6.3.3All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows: • Patches/updates for critical vulnerabilities (identified according to the risk ranking process at Requirement 6.3.1) are installed within one hard 6.4.1For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks as follows: • Reviewing public-facing web applications via manual or automated application hard 6.4.2For 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 in front of public-facing web applications and is configured easy 6.4.3All 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 method is implemented hard 6.5.1Changes to all system components in the production environment are made according to established procedures that include: • Reason for, and description of, the change. • Documentation of security impact. • Documented change approval hard 6.5.2Upon 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 as applicable hard 6.5.3Pre-production environments are separated from production environments and the separation is enforced with access controls hard 6.5.4Roles and functions are separated between production and pre-production environments to provide accountability such that only reviewed and approved changes are deployed moderate 6.5.5Live PANs not used in pre-production hard 6.5.6Test data and accounts removed before production hard

Req 7: Restrict Access by Need to Know

7.1.1All security policies and operational procedures that are identified in Requirement 7 are: • Documented. • Kept up to date. • In use. • Known to all affected parties hard 7.1.2Roles and responsibilities for performing activities in Requirement 7 are documented, assigned, and understood hard 7.2.1An 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 and data resources that is based hard 7.2.2Access is assigned to users, including privileged users, based on: • Job classification and function. • Least privileges necessary to perform job responsibilities moderate 7.2.3Required privileges are approved by authorized personnel hard 7.2.4All 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 access remain appropriate based on job function. hard 7.2.5All 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 or application. • Access is limited hard 7.2.5.1App and system account review cadence hard 7.2.6All 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 user roles and least privileges. • hard 7.3.1An access control system(s) is in place that restricts access based on a user's need to know and covers all system components hard 7.3.2The access control system(s) is configured to enforce permissions assigned to individuals, applications, and systems based on job classification and function hard 7.3.3The access control system(s) is set to “deny all” by default hard

Req 8: Identify and Authenticate Users

8.1.1All security policies and operational procedures that are identified in Requirement 8 are: • Documented. • Kept up to date. • In use. • Known to all affected parties hard 8.1.2Roles and responsibilities for performing activities in Requirement 8 are documented, assigned, and understood hard 8.2.1All users are assigned a unique ID before access to system components or cardholder data is allowed moderate 8.2.2Group, 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 unless needed for an exceptional hard 8.2.3Additional requirement for service providers only: Service providers with remote access to customer premises use unique authentication factors for each customer premises hard 8.2.4Addition, deletion, and modification of user IDs, authentication factors, and other identifier objects are managed as follows: • Authorized with the appropriate approval. • Implemented with only the privileges specified on the documented approval moderate 8.2.5Access for terminated users is immediately revoked hard 8.2.6Inactive user accounts are removed or disabled within 90 days of inactivity hard 8.2.7Third-party access managed moderate 8.2.8Session idle timeout easy 8.3.1All 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 password or passphrase. • Something you hard 8.3.2Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components moderate 8.3.3User identity is verified before modifying any authentication factor hard 8.3.4Invalid 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 user's identity moderate 8.3.5If 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 and upon reset. • moderate 8.3.6If 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 IF the system does not support 12 moderate 8.3.7Password history hard 8.3.8Authentication policy communicated hard 8.3.9Password change frequency if only factor hard 8.3.10Service provider customer password guidance hard 8.3.10.1SP password rotation or posture moderate 8.3.11Hardware token and other factor protection hard 8.4.1MFA is implemented for all non-console access into the CDE for personnel with administrative access hard 8.4.2MFA is implemented for all non-console access into the CDE hard 8.4.3MFA is implemented for all remote access originating from outside the entity's network that could access or impact the CDE hard 8.5.1MFA 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 specifically documented, and authorized by moderate 8.6.1If 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 circumstance. • Interactive use is limited moderate 8.6.2Passwords/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 custom source code moderate 8.6.3Passwords/passphrases for any application and system accounts are protected against misuse as follows: • Passwords/passphrases are changed periodically (at the frequency defined in the entity's targeted risk analysis, which is performed according to all hard

Req 9: Restrict Physical Access

9.1.1All security policies and operational procedures that are identified in Requirement 9 are: • Documented. • Kept up to date. • In use. • Known to all affected parties hard 9.1.2Roles and responsibilities for performing activities in Requirement 9 are documented, assigned, and understood hard 9.2.1Appropriate facility entry controls are in place to restrict physical access to systems in the CDE hard 9.2.1.1Individual 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 points to/from sensitive areas within the hard 9.2.2Physical and/or logical controls are implemented to restrict use of publicly accessible network jacks within the facility hard 9.2.3Physical access to networking and telecommunications hardware restricted hard 9.2.4Consoles in sensitive areas locked when not in use moderate 9.3.1Procedures are implemented for authorizing and managing physical access of personnel to the CDE, including: • Identifying personnel. • Managing changes to an individual's physical access requirements. • Revoking or terminating personnel identification. • hard 9.3.1.1Personnel access readily revoked moderate 9.3.2Procedures are implemented for authorizing and managing visitor access to the CDE, including: • Visitors are authorized before entering. • Visitors are escorted at all times. • Visitors are clearly identified and given a hard 9.3.3Visitor badges or identification are surrendered or deactivated before visitors leave the facility or at the date of expiration moderate 9.3.4Visitor log retention moderate 9.4.1Media with cardholder data physically secured hard 9.4.1.1Offline media backup security hard 9.4.1.2Offsite backup location reviewed hard 9.4.2Media classified by sensitivity hard 9.4.3Media sent outside facility secured hard 9.4.4Management approval for media moved outside the facility moderate 9.4.5Inventory logs of electronic media hard 9.4.5.1Inventories of electronic media with cardholder data are conducted at least once every 12 months hard 9.4.6Hard copy media destruction moderate 9.4.7Electronic media destruction moderate 9.5.1POI device protection hard 9.5.1.1POI inventory maintained hard 9.5.1.2POI tamper inspection moderate 9.5.1.3POI personnel training hard

Req 10: Logging and Monitoring

10.1.1Requirement 10 policies and operational procedures documented and maintained hard 10.1.2Requirement 10 roles and responsibilities documented and assigned hard 10.2.1Audit logs enabled on system components easy 10.2.1.1Log all user access to CHD moderate 10.2.1.2Log all admin actions easy 10.2.1.3Log access to audit logs easy 10.2.1.4Log invalid logical access attempts easy 10.2.1.5Log changes to identification and authentication easy 10.2.1.6Log initialization, stopping, or pausing of logs easy 10.2.1.7Log creation and deletion of system level objects easy 10.2.2Audit log content easy 10.3.1Read access to logs restricted easy 10.3.2Logs protected from modification easy 10.3.3Logs backed up to central server moderate 10.3.4File integrity or change detection on logs moderate 10.4.1Daily log review for critical systems hard 10.4.1.1Automated mechanisms for log review easy 10.4.2Periodic review of other system component logs hard 10.4.2.1Frequency defined by TRA hard 10.4.3Exceptions and anomalies addressed moderate 10.5.1Audit log retention 12 months hard 10.6.1Time synchronization in use moderate 10.6.2Time settings consistent and accurate moderate 10.6.3Time settings protected easy 10.7.1Critical security control failure detection (SP) easy 10.7.2Critical security control failure detection (all entities) easy 10.7.3Failure response timeline moderate

Req 11: Test Security Regularly

11.1.1Testing policy documented hard 11.1.2Testing roles assigned hard 11.2.1Wireless AP detection easy 11.2.2Authorized wireless AP inventory hard 11.3.1Internal vulnerability scans quarterly moderate 11.3.1.1Address non-high vulnerabilities per TRA hard 11.3.1.2Authenticated internal scans moderate 11.3.1.3Internal scans after significant changes easy 11.3.2External vulnerability scans quarterly by ASV easy 11.3.2.1External scans after significant change easy 11.4.1Penetration testing methodology defined hard 11.4.2Internal penetration testing annually hard 11.4.3External penetration testing annually hard 11.4.4Pen test findings remediated hard 11.4.5Segmentation testing hard 11.4.6Segmentation testing (service providers) every 6 months hard 11.4.7Multi-tenant pen test support hard 11.5.1IDS/IPS in place moderate 11.5.1.1Covert malware channel detection (SP) hard 11.5.2Change detection mechanism (FIM) moderate 11.6.1Payment page change and tamper detection moderate

Req 12: Information Security Policies

12.1.1An overall information security policy is: • Established. • Published. • Maintained. • Disseminated to all relevant personnel, as well as to relevant vendors and business partners hard 12.1.2The 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 hard 12.1.3Information security roles and responsibilities defined and acknowledged hard 12.1.4CISO or equivalent responsibility hard 12.2.1Acceptable use policies for end-user technologies hard 12.3.1Targeted risk analysis documented for requirements that specify one hard 12.3.2TRA for customized approach hard 12.3.3Cryptographic cipher suites and protocols inventory hard 12.3.4Hardware and software technologies reviewed annually hard 12.4.1Executive management responsibility for the PCI DSS compliance program (service providers) hard 12.4.2Quarterly PCI compliance reviews (SP) hard 12.4.2.1Documentation of quarterly reviews (SP) hard 12.5.1Inventory of system components in scope moderate 12.5.2PCI DSS scope documented and confirmed annually hard 12.5.2.1Service provider scope confirmed every 6 months hard 12.5.3Impact analysis on org structure changes (SP) hard 12.6.1Formal security awareness program implemented hard 12.6.2Security awareness program reviewed annually hard 12.6.3Security awareness training delivered moderate 12.6.3.1Training on phishing and social engineering hard 12.6.3.2Training on acceptable use of end-user technologies hard 12.7.1Personnel screening hard 12.8.1Third-party service provider inventory hard 12.8.2Written agreements with TPSPs hard 12.8.3TPSP due diligence hard 12.8.4TPSP compliance monitored hard 12.8.5Responsibility matrix with TPSPs hard 12.9.1TPSP written acknowledgement of responsibility (SP) moderate 12.9.2TPSP supports customer requests for compliance info (SP) hard 12.10.1Incident response plan hard 12.10.2IRP reviewed and tested annually hard 12.10.324/7 incident response coverage hard 12.10.4Incident responder training hard 12.10.4.1Periodic IR responder skill review hard 12.10.5IRP includes monitoring and response to security control alerts easy 12.10.6IRP refined based on lessons learned hard 12.10.7Response procedures for PAN detection in unexpected locations hard