1. Requirement 1: Install and maintain a firewall configuration to protect cardholder data
   1. 1.1 Firewall/Router Configurations
      1. 1.1.1 Formal change process
      2. 1.1.2 Network Diagrams
      3. 1.1.3 Data Flow Diagrams
      4. 1.1.4 Firewall implementation (Internet connection/DMZ/Internal Network)
      5. 1.1.5 Groups, Roles & Responsibilities for management of network components
      6. 1.1.6 Business Justification
      7. 1.1.7 6 Month Firewall/Router reviews
   2. 1.2 Firewall/Router configurations to restrict connections between trusted and untrusted
      1. 1.2.1 Restrict inbound/outbound traffic to least privilege
      2. 1.2.2 Secure & Synchronise router configurations
      3. 1.2.3 Install perimeter firewalls (wireless to CDE)
   3. 1.3 Prohibit direct public access between Internet & CDE
      1. 1.3.1 Implement a DMZ
      2. 1.3.2 Limit inbound Internet traffic to IP address in the DMZ
      3. 1.3.3 Implement anti-spoofing
      4. 1.3.4 Prevent unauthorised outbound traffic from CDE to Intenet
      5. 1.3.5 Permit only 'established' connections into the network
      6. 1.3.6 Place system components that store CHD in a secure silo (isolated from DMZ)
      7. 1.3.7 Prevent unauthorised disclosure of private IP addresses
   4. 1.4 Personal software firewall installed on portable devices.
   5. 1.5 Secure networkingpolicies & SOPs
2. Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
   1. 2.1 Change vendor defaults
      1. 2.1.1 Change defaults for wireless environments connected to CDE
   2. 2.2 Secure Build Standards
      1. 2.2.1 Establish 1 primary function per server
      2. 2.2.2 Enable only necessary services, protocols, daemons, etc., as required for the function of the system.
      3. 2.2.3 Implement additional security features for any required services, protocols, or daemons that are considered to be insecure.
      4. 2.2.4 Configure system security parameters to prevent misuse.
      5. 2.2.5 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.
   3. 2.3 Encrypt all non-console administrative access using strong cryptography.
   4. 2.4 Maintain an inventory of system components that are in scope for PCI DSS.
   5. 2.5 Secure Configuration policies & SOPs
   6. 2.6 Shared hosting providers must protect each entity’s hosted environment and cardholder data. (Appendix A1)
3. Requirement 3: Protect stored cardholder data
   1. 3.1 Data Retention
   2. 3.2 Sensitive Authentication (SAD)
      1. 3.2.1 Rrack data
      2. 3.2.2 Card Verification Code/Value (CVC/V)
      3. 3.2.3 Personal Identification Number (PIN)
   3. 3.3 Mask PAN (1st 6, Last 4)
   4. 3.4 Render PAN unreadable anywhere it is stored
      1. 3.4.1 Disk encryption
   5. 3.5 Key Management SOPs
      1. 3.5.1 Additional requirement for service providers only: Maintain a documented description of the cryptographic architecture
      2. 3.5.2 Restrict access to cryptographic keys to the fewest number of custodians necessary.
      3. 3.5.3 Secret and private keys (used to encrypt/decrypt cardholder data) secure storage
   6. 3.6 Documented key management SOPs
      1. 3.6.1 Key generation
      2. 3.6.2 Secure key distribution
      3. 3.6.3 Secure key storage
      4. 3.6.4 Key changes
      5. 3.6.5 Key retirement/replacement
      6. 3.6.6 Manual clear-text
      7. 3.6.7 Unauthorised key substitution
      8. 3.6.8 Key custodian acknowledgement of responsibilities
   7. 3.7 Secure storage policies & SOPs
4. Requirement 4: Encrypt transmission of cardholder data across open, public networks
   1. 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks
      1. 4.1.1 Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment, use industry best practices to implement strong encryption for authentication and transmission.
   2. 4.2 Never send unprotected PANs by enduser messaging technologies (for example, email, instant messaging, SMS, chat, etc.).
   3. 4.3 Secure transmission policies & SOPs
5. Requirement 12: Maintain a policy that addresses information security for all personnel.
   1. 12.1 Establish, publish, maintain, & disseminate a security policy.
      1. 12.1.1 Annual security policy review
   2. 12.2 Annual Risk Assessment
   3. 12.3 Acceptable Usage Policy
      1. 12.3.1 Explicit approval
      2. 12.3.2 Authenticated use
      3. 12.3.3 List of devices & personnel with access
      4. 12.3.4 Determine ownership
      5. 12.3.5 Acceptable use
      6. 12.3.6 Acceptable network locations
      7. 12.3.7 List of company -approved products
      8. 12.3.8 Auto disconnect - Remote access
      9. 12.3.9 Remote access tech - 3rd parties
      10. 12.3.10 Remote access to CHD
   4. 12.4 InfoSec responsibilities
      1. 12.4.1 Service Providers Senior Exec program support
   5. 12.5 Individual & Team responsibilities
      1. 12.5.1 Security policies & SOPs awareness
      2. 12.5.2 Monitor and analyze security alerting
      3. 12.5.3 Security incident response team
      4. 12.5.4 User account admin
      5. 12.5.5 Monitor and control all access to data.
   6. 12.6 Formal security awareness program
      1. 12.6.1 Annual security education
      2. 12.6.2 Training acknowledgement
   7. 12.7 Security vetting
   8. 12.8 3rd-Party security assurance
      1. 12.8.1 Maintain list of 3rd-Parties
      2. 12.8.2 3rd-Party security contracts
      3. 12.8.3 Due diligence
      4. 12.8.4 Monitor 3rd-Party PCI DSS compliance
      5. 12.8.5 Identified outsourced services/PCI DSS controls
   9. 12.9 Service provider written customer acknowldgement
   10. 12.10 Incident Response (IR)
       1. 12.10.1 Create IR Plan
       2. 12.10.2 Annual IRP test & review
       3. 12.10.3 Establish IR team
       4. 12.10.4 IR team training
       5. 12.10.5 Alerts response
       6. 12.10.6 Lessons-learned
   11. 12.11 Service Providers: Internal audit
       1. 12.11 Maintain quarterly internal audit program
6. Requirement 11: Regularly test security systems and processes.
   1. 11.1 Quarterly testing for rogue wireless devices
      1. 11.1.1 Maintain an inventory of authorized wireless access points including a documented business justification.
      2. 11.1.2 Implement incident response procedures in the event unauthorized wireless access points are detected.
   2. 11.2 Quarterly internal & external vulnerability scans
      1. 11.2.1 Perform quarterly internal vulnerability scans. Address vulnerabilities and perform rescans to verify all “high risk” vulnerabilities are resolved in accordance with the entity’s vulnerability ranking (per Requirement 6.1). Scans must be performed by qualified personnel.
      2. 11.2.2 Perform quarterly external vulnerability scans, via an Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC). Perform rescans as needed, until passing scans are achieved.
      3. 11.2.3 Perform internal and external scans, and rescans as needed, after any significant change. Scans must be performed by qualified personnel.
   3. 11.3 Pentesting methodology
      1. 11.3.1 Perform external penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).
      2. 11.3.2 Perform internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).
      3. 11.3.3 Exploitable vulnerabilities found during penetration testing are corrected and testing is repeated to verify the corrections.
      4. 11.3.4 If segmentation is used to isolate the CDE from other networks, perform penetration tests at least annually and after any changes to segmentation controls/methods to verify that the segmentation methods are operational and effective, and isolate all out-of-scope systems from systems in the CDE.
         1. 11.3.4.1 Additional requirement for service providers only: If segmentation is used, confirm PCI DSS scope by performing penetration testing on segmentation controls at least every six months and after any changes to segmentation controls/methods.
   4. 11.4 Itrusion Detection System(IDS)/Intrusion Prevention System(IPS)
   5. 11.5 Change detection
      1. 11.5.1 Implement a process to respond to any alerts generated by the changedetection solution.
   6. 11. Security testing policies & SOPs
7. Requirement 10: Track and monitor all access to network resources and cardholder data
   1. 10.1 Linked audit trails
   2. 10.2 Automated audit trails
      1. 10.2.1 All individual user accesses to cardholder data
      2. 10.2.2 All actions taken by any individual with root or administrative privileges
      3. 10.2.3 Access to all audit trails
      4. 10.2.4 Invalid logical access attempts
      5. 10.2.5 Use of and changes to identification and authentication mechanisms—including but not limited to creation of new accounts and elevation of privileges—and all changes, additions, or deletions to accounts with root or administrative privileges
      6. 10.2.6 Initialization, stopping, or pausing of the audit logs
      7. 10.2.7 Creation and deletion of systemlevel objects
   3. 10.3 Audit logs
      1. 10.3.1 User identification
      2. 10.3.2 Type of event
      3. 10.3.3 Date and time
      4. 10.3.4 Success or failure indication
      5. 10.3.5 Origination of event
      6. Subtopic 6
   4. 10.4 Time synch
      1. 10.4.1 Critical systems have the correct and consistent time.
      2. 10.4.1 Critical systems have the correct and consistent time.
      3. 10.4.3 Time settings are received from industry-accepted time sources.
   5. 10.5 Secure audit trails
      1. 10.5.1 Limit viewing of audit trails to those with a job-related need
      2. 10.5.2 Protect audit trail files from unauthorized modifications
      3. 10.5.3 Promptly back up audit trail files to a centralized log server or media that is difficult to alte
      4. 10.5.4 Write logs for external-facing technologies onto a secure, centralized, internal log server or media device
      5. 10.5.5 Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert)
   6. 10.6 Log and security event reviews
      1. 10.6.1 Daily reviews
      2. 10.6.2 Review logs of all other system components periodically based on the organization’s policies and risk management strategy, as determined by the organization’s annual risk assessment
      3. 10.6.3 Follow up exceptions and anomalies identified during the review process
   7. 10.7 Audit retention (12 months (3 months immediate))
   8. 10.8 Service Providers: Timely detection of critical system failures
      1. 10.8.1 Additional requirement for service providers only: Respond to failures of any critical security controls in a timely manner.
   9. 10.9 Monitoring policies & SOPs
8. Requirement 9: Restrict physical access to cardholder data
   1. 9.1 Use appropriate facility entry controls
      1. 9.1.1 Use either video cameras or access control mechanisms (or both) to monitor individual physical access to sensitive areas. Review collected data and correlate with other entries. Store for at least three months, unless otherwise restricted by law
      2. 9.1.2 Implement physical and/or logical controls to restrict access to publicly accessible network jacks.
      3. 9.1.3 Restrict physical access to wireless access points, gateways, handheld devices, networking/communications hardware, and telecommunication lines.
   2. 9.2 Visitor ID
   3. 9.3 Visitor control
   4. 9.4 Visitor process
      1. 9.4.1 Visitors are authorized before entering, and escorted at all times within, areas where cardholder data is processed or maintained.
      2. 9.4.2 Visitors are identified and given a badge or other identification that expires and that visibly distinguishes the visitors from onsite personnel.
      3. 9.4.3 Visitors are asked to surrender the badge or identification before leaving the facility or at the date of expiration
      4. 9.4.4 A visitor log is used to maintain a physical audit trail of visitor activity to the facility as well as computer rooms and data centers where cardholder data is stored or transmitted.
   5. 9.5 Secure backups
      1. 9.5.1 Store media backups in a secure location, preferably an off-site facility, such as an alternate or backup site, or a commercial storage facility. Review the location’s security at least annually.
   6. 9.6 Secure media handling
      1. 9.6.1 Classify media so the sensitivity of the data can be determined
      2. 9.6.2 Send the media by secured courier or other delivery method that can be accurately tracked.
      3. 9.6.3 Ensure management approves any and all media that is moved from a secured area (including when media is distributed to individuals)
   7. 9.7 Secure media storage
      1. 9.7.1 Properly maintain inventory logs of all media and conduct media inventories at least annually.
   8. 9.8 Secure media destruction/disposal
      1. 9.8.1 Shred, incinerate, or pulp hardcopy materials so that cardholder data cannot be reconstructed. Secure storage containers used for materials that are to be destroyed.
      2. 9.8.2 Render cardholder data on electronic media unrecoverable so that cardholder data cannot be reconstructed.
   9. 9.9 Card present device tampering protection
      1. 9.9.1 Maintain an up-to-date list of devices
      2. 9.9.2 Periodically inspect device surfaces to detect tampering (for example, addition of card skimmers to devices), or substitution (for example, by checking the serial number or other device characteristics to verify it has not been swapped with a fraudulent device).
      3. 9.9.3 Provide training for personnel to be aware of attempted tampering or replacement of devices
   10. 9.10 Physical security policies & SOPs
9. Requirement 8: Identify and authenticate access to system components
   1. 8.1 Defines access policies & SOPs
      1. 8.1.1 Assign all users a unique ID before allowing them to access system components or cardholder data
      2. 8.1.2 Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.
      3. 8.1.3 Immediately revoke access for any terminated users
      4. 8.1.4 Remove/disable inactive user accounts within 90 days.
      5. 8.1.5 Manage IDs used by third parties to access, support, or maintain system components via remote access
      6. 8.1.6 Limit repeated access attempts by locking out the user ID after not more than six attempts.
      7. 8.1.7 Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID.
      8. 8.1.8 If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.
   2. 8.2 User-authentication management
      1. 8.2.1 Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components.
      2. 8.2.2 Verify user identity before modifying any authentication credential
      3. 8.2.3 Passwords/passphrases requirements
      4. 8.2.4 Change user passwords/passphrases at least once every 90 days.
      5. 8.2.5 Do not allow an individual to submit a new password/passphrase that is the same as any of the last four passwords/passphrases he or she has used.
      6. 8.2.6 Set passwords/passphrases for first-time use and upon reset to a unique value for each user, and change immediately after the first use.
   3. 8.3 Secure remote access using Multi Factor Auth (MFA)
      1. 8.3.1 Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.
      2. 8.3.2 Incorporate multi-factor authentication for all remote network access (both user and administrator, and including third-party access for support or maintenance) originating from outside the entity’s network.
   4. 8.4 Authentication policies & SOPs
   5. 8.5 Prohibit group/shared/generic IDs/password/authentication methods
      1. 8.5.1 Additional requirement for service providers only: Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer
   6. 8.6 Appropriate use of physical or logical tokens/smart card/certificates
   7. 8.7 CHD database access restrictions
   8. 8.8 Access Control polices & SOPs
10. Requirement 7: Restrict access to cardholder data by business need to know
    1. 7.1 Limit access
       1. 7.1.1 Define access needs for each role
       2. 7.1.2 Least privilege
       3. 7.1.3 Role based asccess control
       4. 7.1.4 Documented approval
    2. 7.2 Access Control System
       1. 7.2.1 Coverage of all system components
       2. 7.2.2 Assignment of privileges to individuals based on job classification and function.
       3. 7.2.3 Default “deny-all” setting.
    3. 7.3 Need To Know/Access policies & SOPs
11. Requirement 6: Develop and maintain secure systems and applications
    1. 6.1 Vulnerability identification & threat management
    2. 6.2 Security patching & updates
    3. 6.3 Secure DevOps (internal/external applications)
       1. 6.3.1 Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers.
       2. 6.3.2 Review custom code prior to release to production or customers in order to identify any potential coding vulnerability (using either manual or automated processes)
    4. 6.4 Formal change control
       1. 6.4.1 Separate development/test environments from production environments, and enforce the separation with access controls.
       2. 6.4.2 Separation of duties between development/test and production environments
       3. 6.4.3 Production data (live PANs) are not used for testing or development
       4. 6.4.4 Removal of test data and accounts from system components before the system becomes active / goes into production.
       5. 6.4.5 Change control procedures
          1. 6.4.5.1 Documentation of impact.
          2. 6.4.5.2 Documented change approval by authorized parties.
          3. 6.4.5.3 Functionality testing
          4. 6.4.5.4 Back-out procedures.
          5. 6.4.6 PCI DSS controls implementation
    5. 6.5 Common code vulnerability remediation
       1. 6.5.1 Injection flaws
       2. 6.5.2 Buffer overflows
       3. 6.5.3 Insecure cryptographic storage
       4. 6.5.4 Insecure communications
       5. 6.5.5 Improper error handling
       6. 6.5.6 All “high risk” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1).
       7. Note: Requirements 6.5.7 through 6.5.10, below, apply to web applications and application interfaces (internal or external):
          1. 6.5.7 Cross-site scripting (XSS)
          2. 6.5.8 Improper access control
          3. 6.5.9 Cross-site request forgery (CSRF)
          4. 6.5.10 Broken authentication and session management.
    6. 6.6 Web Application Testing (Annual/Significant change) or Web Application /Firewall
    7. 6.7 SecDevOps policies & SOPs
12. Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
    1. 5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).
       1. 5.1.1 Ensure that anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software
          1. 5.1.2 For systems considered to be not commonly affected by malicious software, perform periodic evaluations to identify and evaluate evolving malware threats in order to confirm whether such systems continue to not require anti-virus software.
    2. 5.2 Ensure that all anti-virus mechanisms are maintained
    3. 5.3 Ensure that anti-virus mechanisms are actively running and cannot be disabled or altered by users, unless specifically authorized by management on a case-by-case basis for a limited time period.
    4. 5.4 Antivirus policies & SOPs