PCI DSS

Requirements and controls

• 1 Network security controls

  • 1.1 Policies and roles for network security controls

    • 1.1.1 Network security policies and procedures

      The organization has written procedures for running firewalls and other network security controls, keeps them up to date, and makes sure the teams operating those controls know and follow them.

      • Information Security & Privacy Policies
      • Management Review of Policies
      • Network Security Policy & Procedure

    • 1.1.2 Network security roles

      Named people or teams are responsible for operating network security controls, and they know what is expected of them.

      • Roles & Responsibilities
      • Cybersecurity Responsibilities
      • Asset Ownership Assignment

  • 1.2 Configuration and maintenance of network security controls

    • 1.2.1 Rule set configuration standards

      Firewalls and other network security controls follow a defined configuration standard that is applied and kept up to date.

      • External System Connections
      • Network Security Policy & Procedure

    • 1.2.2 Change control for network connections

      Every change to network connections or to the configuration of network security controls goes through the formal change management process.

      • Change Management Policy & Procedure
      • Approval of Changes
      • External System Connections

    • 1.2.3 Network diagram

      An up-to-date diagram shows every connection between the cardholder data environment and other networks, wireless ones included.

      • Network & Data Flow Diagrams

    • 1.2.4 Data flow diagram

      An up-to-date diagram traces how account data moves across systems and networks, and it is revised whenever the environment changes.

      • Network & Data Flow Diagrams

    • 1.2.5 Approved services, protocols and ports

      Every service, protocol and port that is allowed through has been identified, approved and tied to a business need.

      • External System Connections
      • Network Security Policy & Procedure

    • 1.2.6 Insecure services and protocols

      Where a service, protocol or port in use is considered insecure, extra security settings are defined and applied to reduce the risk.

      • External System Connections
      • Transmission Confidentiality

    • 1.2.7 Six-monthly rule set review

      Network security control configurations are reviewed at least twice a year to confirm every rule is still needed and effective.

      • External System Connections

    • 1.2.8 Protection of configuration files

      Configuration files for network security controls are protected from unauthorized access and kept in line with the configurations actually running.

      • External System Connections
      • Production Database Access Restriction

  • 1.3 Restriction of network access to and from the CDE

    • 1.3.1 Inbound traffic to the CDE

      Only the traffic the cardholder data environment needs can reach it; everything else is explicitly denied.

      • External System Connections
      • Limit Network Connections

    • 1.3.2 Outbound traffic from the CDE

      The cardholder data environment can only send the traffic it needs; everything else is explicitly denied.

      • External System Connections

    • 1.3.3 Wireless networks and the CDE

      Network security controls sit between every wireless network and the cardholder data environment, so wireless traffic is denied by default and only authorized traffic gets through.

      • External System Connections
      • Wireless Access Point Management

  • 1.4 Connections between trusted and untrusted networks

    • 1.4.1 Controls between trusted and untrusted networks

      Network security controls separate the organization's trusted networks from untrusted ones such as the internet.

      • External System Connections
      • Limit Network Connections

    • 1.4.2 Inbound traffic from untrusted networks

      Traffic from untrusted networks can only reach systems meant to offer public services, or answer connections the trusted network started; all other inbound traffic is blocked.

      • Limit Network Connections
      • External System Connections

    • 1.4.3 Anti-spoofing

      Measures detect and block forged source addresses before they can enter the trusted network.

      • External System Connections

    • 1.4.4 No direct access to cardholder data stores

      Systems that store cardholder data cannot be reached directly from untrusted networks.

      • Limit Network Connections
      • External System Connections

    • 1.4.5 Internal addressing kept private

      Internal IP addresses and routing details are only disclosed to authorized parties.

      • External System Connections
      • Network Security Policy & Procedure

  • 1.5 Risks from devices that connect to both untrusted networks and the CDE

    • 1.5.1 Security of dual-connected devices

      Laptops and other devices, company-owned or personal, that connect both to untrusted networks and to the cardholder data environment run security controls with fixed settings that users cannot switch off without approval.

      • Endpoint Security Policy
      • Malware Protection
      • Endpoint Security Validation
      • Session Lock

• 2 Secure configurations

  • 2.1 Policies and roles for secure configuration

    • 2.1.1 Configuration policies and procedures

      Procedures for hardening and configuring system components exist in writing, are revised as the environment changes, and guide the people who build and maintain systems.

      • Information Security & Privacy Policies
      • Management Review of Policies
      • Change Management Policy & Procedure

    • 2.1.2 Configuration roles

      Responsibility for configuring and hardening each type of system component is assigned and understood by the people who hold it.

      • Roles & Responsibilities
      • Cybersecurity Responsibilities
      • Asset Ownership Assignment

  • 2.2 Secure configuration and management of system components

    • 2.2.1 System hardening standards

      Hardening standards based on accepted industry guidance exist for every type of system component, address known weaknesses, are kept up to date and are applied whenever a system is built or changed.

      • Change Management Policy & Procedure
      • Endpoint Security Policy
      • Endpoint Security Validation

    • 2.2.2 Vendor default accounts

      Default accounts supplied by vendors are either disabled or removed, or have their default passwords replaced before use.

      • Production Database Access Restriction
      • Password Management Guidelines

    • 2.2.3 Separation of primary functions

      Functions that need different levels of security are kept on separate system components, or isolated from each other when they must share one.

      • Change Management Policy & Procedure

    • 2.2.4 Only necessary functionality enabled

      Only the services, protocols, daemons and functions a system needs are enabled; everything else is removed or turned off.

      • External System Connections
      • Change Management Policy & Procedure

    • 2.2.5 Justified insecure services

      Any insecure service, protocol or daemon that remains has a documented business reason and extra safeguards that reduce its risk.

      • External System Connections
      • Transmission Confidentiality

    • 2.2.6 Security parameters against misuse

      System security settings are set to prevent misuse of the component.

      • Change Management Policy & Procedure
      • Endpoint Security Validation
      • Production Database Access Restriction

    • 2.2.7 Encrypted administrative access

      Administrative access that does not happen at the physical console is encrypted with strong cryptography.

      • Transmission Confidentiality
      • External System Connections

  • 2.3 Secure configuration of wireless environments

    • 2.3.1 Wireless vendor defaults

      On wireless networks that connect to the cardholder data environment or carry account data, vendor defaults such as keys, passwords and community strings are changed at installation or confirmed to be safe.

      • Wireless Access Point Management

    • 2.3.2 Wireless key changes

      Wireless encryption keys for those networks are replaced when someone who knew them leaves the role or the organization, or when a key may have been exposed.

      • Wireless Access Point Management
      • Termination of Employment

• 3 Protection of stored account data

  • 3.1 Policies and roles for protecting stored account data

    • 3.1.1 Stored data policies and procedures

      Rules for storing, retaining and protecting account data are set out in writing, kept up to date and followed by every team that handles that data.

      • Information Security & Privacy Policies
      • Management Review of Policies
      • Account Data Minimization
      • Data Retention Policy

    • 3.1.2 Stored data roles

      Each task involved in protecting stored account data has an assigned owner who understands the duty.

      • Roles & Responsibilities
      • Cybersecurity Responsibilities
      • Assigned Security & Privacy Responsibilities

  • 3.2 Minimal storage of account data

    • 3.2.1 Account data retention and disposal

      Account data is kept only as long as a defined business, legal or regulatory need requires, in every location where it lives, and a check at least every three months confirms that anything past its retention period has been securely deleted.

      • Account Data Minimization
      • Data Retention Policy

  • 3.3 No storage of sensitive authentication data after authorization

    • 3.3.1 SAD discarded after authorization

      Sensitive authentication data is not kept once a transaction is authorized, even in encrypted form, and whatever was received is made unrecoverable.

      • Account Data Minimization

    • 3.3.1.1 Track data not retained

      Full magnetic stripe or chip track data is not kept after authorization.

      • Account Data Minimization

    • 3.3.1.2 Card verification code not retained

      The three- or four-digit card verification code is not kept after authorization.

      • Account Data Minimization

    • 3.3.1.3 PIN data not retained

      PINs and encrypted PIN blocks are not kept after authorization.

      • Account Data Minimization

    • 3.3.2 Pre-authorization SAD encrypted

      Sensitive authentication data held electronically while a transaction is still awaiting authorization is protected with strong encryption.

      • Account Data Minimization
      • Encryption of Data at Rest
      • Encryption Policy & Procedure

    • 3.3.3 SAD kept by issuers

      Issuers and organizations supporting issuing services keep sensitive authentication data only where the issuing business needs it, and encrypt it with strong cryptography.

      • Account Data Minimization
      • Encryption of Data at Rest

  • 3.4 Restricted display and copying of PAN

    • 3.4.1 PAN masked on display

      Card numbers are masked whenever they are displayed, so that only people with a documented business need see more than the issuer identification digits (BIN) and the last four digits.

      • PAN Exposure Restrictions

    • 3.4.2 No copying of PAN over remote access

      Technical controls stop staff from copying or moving card numbers when they use remote access tools, unless they have explicit, documented permission for a defined business need.

      • PAN Exposure Restrictions

  • 3.5 Protection of stored PAN

    • 3.5.1 PAN unreadable wherever stored

      Card numbers are made unreadable wherever they are stored, using one-way hashes of the whole number, truncation, tokens or pads, or strong encryption with managed keys.

      • Stored PAN Protection
      • Encryption of Data at Rest
      • Encryption Policy & Procedure

    • 3.5.1.1 Keyed hashes for PAN

      Hashes used to protect card numbers are keyed cryptographic hashes of the full number, with the keys managed like other cryptographic keys.

      • Stored PAN Protection
      • Encryption Policy & Procedure

    • 3.5.1.2 Limits on disk-level encryption

      Disk- or partition-level encryption is relied on to protect card numbers only on removable media, or on other storage when a further mechanism also makes the numbers unreadable.

      • Stored PAN Protection
      • Encryption of Data at Rest

    • 3.5.1.3 Management of disk-level encryption

      Where disk- or partition-level encryption is used, access to it is managed separately from the operating system's own login, and its decryption keys are not tied to user accounts.

      • Stored PAN Protection
      • Encryption Policy & Procedure

  • 3.6 Protection of cryptographic keys

    • 3.6.1 Key protection procedures

      Procedures protect the keys that secure stored account data against disclosure and misuse, limit access to the fewest custodians, and make key-encrypting keys at least as strong as the keys they protect.

      • Encryption Policy & Procedure
      • Encryption of Data at Rest

    • 3.6.1.1 Documented cryptographic architecture

      Service providers only: a current description of the cryptographic architecture lists the algorithms, protocols, keys, hardware security modules and key uses that protect stored account data.

      • Encryption Policy & Procedure

    • 3.6.1.2 Secure storage of secret and private keys

      Keys that encrypt or decrypt account data are always held in a protected form, such as wrapped by a stronger key-encrypting key, inside a secure cryptographic device, or split into components.

      • Encryption Policy & Procedure
      • Encryption of Data at Rest

    • 3.6.1.3 Few key custodians

      Access to cleartext key components is limited to the smallest number of custodians needed.

      • Encryption Policy & Procedure

    • 3.6.1.4 Few key storage locations

      Cryptographic keys are stored in as few places as possible.

      • Encryption Policy & Procedure

  • 3.7 Key management processes

    • 3.7.1 Strong key generation

      Key management procedures cover generating strong keys for protecting stored account data.

      • Encryption Policy & Procedure

    • 3.7.2 Secure key distribution

      Key management procedures cover distributing those keys securely.

      • Encryption Policy & Procedure

    • 3.7.3 Secure key storage

      Key management procedures cover storing those keys securely.

      • Encryption Policy & Procedure
      • Encryption of Data at Rest

    • 3.7.4 Key changes at end of cryptoperiod

      Keys are replaced when they reach the end of the lifetime set by the key owner or application vendor, in line with industry practice.

      • Encryption Policy & Procedure
      • Encryption of Data at Rest

    • 3.7.5 Retiring or replacing keys

      Keys are retired, replaced or destroyed when they expire, when their integrity is in doubt, or when they are known or suspected to be compromised, and retired keys are never used for encryption again.

      • Encryption Policy & Procedure

    • 3.7.6 Split knowledge and dual control

      Manual cleartext key-management operations are carried out with split knowledge and dual control, so no single person ever holds a whole key.

      • Encryption Policy & Procedure
      • Segregation of Duties

    • 3.7.7 No unauthorized key substitution

      Procedures prevent anyone from substituting keys without authorization.

      • Encryption Policy & Procedure

    • 3.7.8 Key custodian acknowledgment

      Key custodians formally accept, in writing or electronically, the duties that come with their role.

      • Encryption Policy & Procedure

    • 3.7.9 Key guidance for customers

      Service providers only: when keys are shared with customers for transmitting or storing account data, the customers receive guidance on handling those keys securely.

      • Encryption Policy & Procedure
      • Shared Responsibility Model

• 4 Encryption of cardholder data in transit

  • 4.1 Policies and roles for encrypting data in transit

    • 4.1.1 Transmission security policies and procedures

      Encryption rules for card data crossing public networks are written down, revised when needed and applied by the teams that run those connections.

      • Information Security & Privacy Policies
      • Management Review of Policies
      • Encryption Policy & Procedure

    • 4.1.2 Transmission security roles

      Responsibility for securing card data in transit is assigned to specific people who understand what it involves.

      • Roles & Responsibilities
      • Cybersecurity Responsibilities
      • Asset Ownership Assignment

  • 4.2 Strong cryptography for PAN in transit

    • 4.2.1 Strong cryptography over public networks

      Card numbers sent over open, public networks are protected with strong cryptography and secure protocols that accept only trusted, valid certificates and keys.

      • Transmission Confidentiality
      • Encryption Policy & Procedure

    • 4.2.1.1 Inventory of trusted keys and certificates

      A current inventory lists the keys and certificates the organization trusts to protect card numbers in transit.

      • Encryption Policy & Procedure

    • 4.2.1.2 Wireless encryption

      Wireless networks that carry card numbers or connect to the cardholder data environment use industry-accepted strong cryptography for authentication and transmission.

      • Wireless Access Point Management
      • Transmission Confidentiality

    • 4.2.2 PAN in end-user messaging

      Card numbers sent through email, chat, SMS or similar end-user messaging are protected with strong cryptography.

      • PAN Exposure Restrictions
      • Rules of Behavior
      • Encryption Policy & Procedure

• 5 Protection against malicious software

  • 5.1 Policies and roles for malware protection

    • 5.1.1 Malware protection policies and procedures

      Anti-malware procedures are documented, refreshed as threats change and applied by the people responsible for endpoint and server protection.

      • Information Security & Privacy Policies
      • Management Review of Policies
      • Endpoint Security Policy

    • 5.1.2 Malware protection roles

      Specific people are accountable for deploying and maintaining anti-malware protection and know their duties.

      • Roles & Responsibilities
      • Cybersecurity Responsibilities
      • Assigned Security & Privacy Responsibilities

  • 5.2 Prevention, detection and removal of malware

    • 5.2.1 Anti-malware coverage

      An anti-malware solution runs on every system component, except those that a periodic evaluation has shown are not at risk from malware.

      • Malware Protection
      • Endpoint Security Policy

    • 5.2.2 Anti-malware capability

      The anti-malware solution detects every known type of malware and removes, blocks or contains it.

      • Malware Protection

    • 5.2.3 Components not at risk from malware

      Systems judged not to be at risk from malware are listed and re-evaluated periodically to confirm they still do not need protection.

      • Malware Protection
      • Risk Assessment

    • 5.2.3.1 Frequency of not-at-risk evaluations

      How often those systems are re-evaluated is set by a targeted risk analysis.

      • Risk Assessment
      • Risk Framing

  • 5.3 Active and monitored anti-malware mechanisms

    • 5.3.1 Automatic anti-malware updates

      The anti-malware solution stays current through automatic updates.

      • Malware Protection
      • Endpoint Security Validation

    • 5.3.2 Scanning or continuous analysis

      The anti-malware solution runs periodic and real-time scans, or analyzes system behavior continuously.

      • Malware Protection

    • 5.3.2.1 Frequency of periodic malware scans

      Where periodic scans are used, their frequency is set by a targeted risk analysis.

      • Malware Protection
      • Risk Assessment

    • 5.3.3 Removable media scanning

      Removable electronic media is scanned automatically when connected, or its behavior is analyzed continuously while it is in use.

      • Malware Protection
      • Endpoint Security Policy

    • 5.3.4 Anti-malware logs

      Audit logging is turned on for the anti-malware solution and its logs are kept for the required retention period.

      • Malware Protection
      • Centralized Security Logging

    • 5.3.5 Anti-malware cannot be disabled by users

      Users cannot turn off or change anti-malware protection unless management has approved it for a specific case and a limited time.

      • Malware Protection
      • Endpoint Security Policy

  • 5.4 Protection against phishing

    • 5.4.1 Anti-phishing mechanisms

      Automated processes and tools detect phishing attempts and protect staff from them.

      • Malware Protection
      • Endpoint Security Policy

• 6 Secure systems and software

  • 6.1 Policies and roles for secure systems and software

    • 6.1.1 Secure development policies and procedures

      Secure development and change procedures are written down, maintained and followed by everyone who builds or changes systems and software.

      • Information Security & Privacy Policies
      • Management Review of Policies
      • Change Management Policy & Procedure
      • Vulnerability Management Policy & Procedure

    • 6.1.2 Secure development roles

      Duties for secure development, vulnerability handling and change management are allocated to named roles that understand them.

      • Roles & Responsibilities
      • Cybersecurity Responsibilities
      • Asset Ownership Assignment

  • 6.2 Secure development of bespoke and custom software

    • 6.2.1 Secure development process

      Software built by or for the organization is developed following industry secure development practice, meets PCI DSS needs such as secure authentication and logging, and builds security in at every stage.

      • Change Management Policy & Procedure
      • Input Range Validation
      • Mandatory Field Validation

    • 6.2.2 Developer security training

      Developers working on bespoke and custom software are trained at least once a year on secure coding for their languages, secure design, and using security testing tools.

      • Periodic Security & Privacy Training
      • New Hire Security & Privacy Training
      • Security & Privacy Awareness

    • 6.2.3 Code review before release

      Bespoke and custom software is reviewed before it reaches production or customers, to find and fix coding vulnerabilities and confirm it follows secure coding guidelines.

      • Approval of Changes

    • 6.2.3.1 Manual code review

      Manual code reviews are done by someone other than the author who knows secure coding, and the changes are approved by management before release.

      • Approval of Changes

    • 6.2.4 Preventing common software attacks

      Engineering techniques are in place to prevent or reduce common attacks and weaknesses, such as injection, unsafe data handling, weak cryptography and access control flaws.

      • Change Management Policy & Procedure
      • Input Range Validation
      • Mandatory Field Validation

  • 6.3 Identification and remediation of vulnerabilities

    • 6.3.1 Vulnerability identification and ranking

      New vulnerabilities are identified from recognized industry sources and each is given a risk ranking, with critical and high ones clearly identified.

      • Vulnerability Remediation Process
      • Centralized Flaw Remediation
      • Vulnerability Management Policy & Procedure

    • 6.3.2 Software component inventory

      An inventory of bespoke and custom software, and of the third-party components built into it, is kept to support vulnerability and patch management.

      • Secure System Modification
      • Vulnerability Remediation Process

    • 6.3.3 Timely security patching

      System components get security patches promptly, with critical ones installed within a month of release.

      • Vulnerability Remediation Process
      • Centralized Flaw Remediation
      • Endpoint Security Validation

  • 6.4 Protection of public-facing web applications

    • 6.4.1 Ongoing protection of public web applications

      Internet-facing web applications are protected against known attacks, either by vulnerability assessments at least yearly and after significant changes, or by an automated attack-prevention solution.

      • Penetration Testing
      • Vulnerability Remediation Process
      • Public-Facing Web Application Protection

    • 6.4.2 Automated web attack prevention

      An automated technical solution, such as a web application firewall, sits in front of internet-facing web applications, is kept current, blocks or alerts on attacks, and logs its activity.

      • Public-Facing Web Application Protection

    • 6.4.3 Payment page scripts

      Every script that runs in the customer's browser on a payment page is authorized, checked for integrity and listed in an inventory with a written justification.

      • Payment Page Script Integrity

  • 6.5 Management of changes to system components

    • 6.5.1 Change procedures

      Changes to production systems follow defined procedures that record the reason and impact, get approval, test that security is not weakened and include a way back.

      • Change Management Policy & Procedure
      • Approval of Changes
      • Regression Testing

    • 6.5.2 PCI DSS checks after significant change

      After a significant change, the organization confirms that all relevant PCI DSS requirements apply to new or changed systems and updates its documentation.

      • Change Management Policy & Procedure
      • PCI DSS Scope Confirmation

    • 6.5.3 Separate pre-production environments

      Development and test environments are kept apart from production, with access controls enforcing the separation.

      • Test Data Protection

    • 6.5.4 Separation of duties between environments

      Roles are divided between production and pre-production work so that only reviewed and approved changes are deployed.

      • Segregation of Duties
      • Approval of Changes

    • 6.5.5 No live PAN in pre-production

      Real card numbers are not used in development or test environments unless those environments are part of the cardholder data environment and fully protected.

      • Test Data Protection

    • 6.5.6 Removal of test data and accounts

      Test data and test accounts are removed before a system goes into production.

      • Test Data Protection
      • Change Management Policy & Procedure

• 7 Access restricted by business need to know

  • 7.1 Policies and roles for access restriction

    • 7.1.1 Access restriction policies and procedures

      Need-to-know access rules are recorded in writing, kept current and applied by the people who approve and manage access.

      • Information Security & Privacy Policies
      • Management Review of Policies
      • Access Control Policy & Procedure

    • 7.1.2 Access restriction roles

      The people who define, approve and review access have documented responsibilities they understand.

      • Roles & Responsibilities
      • Cybersecurity Responsibilities
      • Assigned Security & Privacy Responsibilities

  • 7.2 Definition and assignment of access

    • 7.2.1 Access control model

      A defined access control model sets what access each job function needs to system components and data, and at what privilege level.

      • Access Control Policy & Procedure
      • Identity Validation

    • 7.2.2 Least-privilege assignment

      Users, privileged users included, receive only the access their job classification and duties require.

      • Identity Validation
      • Production Database Access Restriction

    • 7.2.3 Approval of privileges

      Required privileges are approved by authorized personnel before they are granted.

      • Access Control Policy & Procedure
      • Identity Validation

    • 7.2.4 Six-monthly user access review

      All user accounts and their access, third-party accounts included, are reviewed at least every six months and inappropriate access is corrected, with management confirming the result.

      • Production System Access Review
      • User Privilege Reviews
      • User Access Reviews

    • 7.2.5 System and application account privileges

      System and application accounts get only the privileges the system needs to run, and only the people or systems that need them can use them.

      • Production Database Access Restriction
      • User Privilege Reviews

    • 7.2.5.1 Review of system and application accounts

      Access held by system and application accounts is reviewed periodically, at a frequency set by a targeted risk analysis, and inappropriate access is corrected.

      • User Privilege Reviews
      • Production System Access Review

    • 7.2.6 Access to cardholder data repositories

      Users reach stored cardholder data only through applications or other programmatic methods that limit what they can do, and only designated administrators can query the repositories directly.

      • Production Database Access Restriction
      • Identity Validation

  • 7.3 Access control systems

    • 7.3.1 Need-to-know enforcement

      Access control systems covering every system component restrict access based on each user's need to know.

      • Identity Validation
      • Production Database Access Restriction

    • 7.3.2 Permissions by job function

      Access control systems apply permissions to people, applications and systems according to job classification and function.

      • Identity Validation

    • 7.3.3 Deny by default

      Access control systems deny all access unless it has been explicitly granted.

      • Identity Validation
      • Access Control Policy & Procedure

• 8 User identification and authentication

  • 8.1 Policies and roles for identification and authentication

    • 8.1.1 Authentication policies and procedures

      Procedures for creating user identities and authenticating them are documented, maintained and applied by administrators, and users are told what is expected of them.

      • Information Security & Privacy Policies
      • Management Review of Policies
      • Access Control Policy & Procedure
      • Password Management Guidelines

    • 8.1.2 Authentication roles

      Responsibility for managing identities and authentication is allocated to specific roles that know their duties.

      • Roles & Responsibilities
      • Cybersecurity Responsibilities
      • Assigned Security & Privacy Responsibilities

  • 8.2 User identification and account lifecycle

    • 8.2.1 Unique user IDs

      Every user gets a unique ID before being allowed to access system components or cardholder data.

      • User Access Reviews
      • Identity Validation

    • 8.2.2 Shared and generic accounts

      Shared, group or generic accounts are used only when truly necessary and in exceptional circumstances, with management approval, confirmed individual identity before use, and traceable actions.

      • User Access Reviews
      • User Privilege Reviews
      • Production Database Access Restriction

    • 8.2.3 Unique credentials per customer

      Service providers only: staff with remote access to customer premises use different authentication factors for each customer.

      • Password Management Guidelines
      • Access Control Policy & Procedure

    • 8.2.4 Authorized changes to user IDs

      Creating, changing and removing user IDs, authentication factors and other identifier objects requires approval and grants only the documented privileges.

      • Access Control Policy & Procedure
      • Identity Validation

    • 8.2.5 Immediate revocation on termination

      Access for people who leave is removed immediately.

      • Termination of Employment

    • 8.2.6 Inactive accounts

      User accounts with no activity for 90 days are removed or disabled.

      • Production Database Access Restriction
      • User Access Reviews

    • 8.2.7 Third-party remote access accounts

      Accounts that third parties use for remote access are enabled only while needed, disabled afterwards and monitored for unexpected activity.

      • Access Control Policy & Procedure
      • Production Database Access Restriction
      • Unauthorized Activity Monitoring

    • 8.2.8 Session idle timeout

      After 15 minutes of inactivity, users must authenticate again to resume their session.

      • Session Lock
      • Cloud Console Session Timeout

  • 8.3 Strong authentication

    • 8.3.1 Authentication factors

      Every user and administrator login to system components is authenticated with at least one factor: something the user knows, has or is.

      • Access Control Policy & Procedure
      • Password Management Guidelines
      • Multi-Factor Authentication

    • 8.3.2 Factors protected with strong cryptography

      Authentication factors are unreadable in transit and in storage on every system component, thanks to strong cryptography.

      • Encryption Policy & Procedure
      • Transmission Confidentiality

    • 8.3.3 Identity verified before factor changes

      A user's identity is confirmed before any authentication factor is changed.

      • Access Control Policy & Procedure

    • 8.3.4 Lockout after failed attempts

      An account is locked after no more than ten failed login attempts, for at least 30 minutes or until an administrator confirms the user's identity.

      • Password Management Guidelines
      • Production Database Access Restriction

    • 8.3.5 Initial and reset passwords

      Passwords set at first use or reset are unique to each user and must be changed straight after first use.

      • Password Management Guidelines

    • 8.3.6 Password strength

      Passwords used as an authentication factor are at least 12 characters long, or 8 where a system cannot support 12, and contain both letters and numbers.

      • Password Management Guidelines
      • Production Database Access Restriction

    • 8.3.7 No reuse of recent passwords

      A new password cannot match any of the user's last four passwords.

      • Password Management Guidelines
      • Production Database Access Restriction

    • 8.3.8 Authentication guidance for users

      Authentication policies and procedures are documented and shared with all users, covering how to choose and protect strong factors and what to do if one may be compromised.

      • Password Management Guidelines
      • Periodic Policy Acknowledgement
      • Access Control Policy & Procedure

    • 8.3.9 Single-factor password changes

      Where a password is the only factor protecting user access, it is changed at least every 90 days or access is decided by real-time analysis of the account's security posture.

      • Password Management Guidelines
      • Multi-Factor Authentication

    • 8.3.10 Password guidance for customer users

      Service providers only: where customers log in with a password as their only factor, they are given guidance on changing their passwords periodically and after a suspected compromise.

      • Password Management Guidelines
      • Shared Responsibility Model

    • 8.3.10.1 Customer password changes

      Service providers only: where customers log in with a password as their only factor, their password is changed at least every 90 days or access is decided by real-time analysis of the account's security posture.

      • Password Management Guidelines

    • 8.3.11 Physical and logical tokens

      Security tokens, smart cards and certificates are assigned to one person, never shared, and usable only by the person they belong to.

      • Password Management Guidelines
      • Access Control Policy & Procedure

  • 8.4 Multi-factor authentication for CDE access

    • 8.4.1 MFA for administrative access

      Administrators accessing the cardholder data environment other than at the console must use multi-factor authentication.

      • Multi-Factor Authentication
      • Production Database Access Restriction

    • 8.4.2 MFA for all CDE access

      All access to the cardholder data environment requires multi-factor authentication.

      • Multi-Factor Authentication

    • 8.4.3 MFA for remote network access

      All remote network access from outside the organization that could reach or affect the cardholder data environment requires multi-factor authentication, for staff and third parties alike.

      • Multi-Factor Authentication

  • 8.5 Configuration of multi-factor authentication systems

    • 8.5.1 MFA system configuration

      MFA resists replay attacks, cannot be bypassed without documented management approval, uses at least two different types of factor and only grants access once every factor succeeds.

      • Multi-Factor Authentication

  • 8.6 System and application accounts

    • 8.6.1 Interactive use of system accounts

      System and application accounts that allow interactive login are used that way only in exceptional cases, for a limited time, with management approval and an identified person accountable.

      • Production Database Access Restriction
      • User Privilege Reviews

    • 8.6.2 No hard-coded passwords

      Passwords for system and application accounts are not written into scripts, configuration files or source code.

      • Change Management Policy & Procedure
      • Approval of Changes
      • Password Management Guidelines

    • 8.6.3 Protection of system account passwords

      Passwords for system and application accounts are complex enough and changed often enough, as set by a targeted risk analysis, and immediately if a compromise is suspected.

      • Production Database Access Restriction
      • Password Management Guidelines

• 9 Physical access restrictions

  • 9.1 Policies and roles for physical security

    • 9.1.1 Physical security policies and procedures

      Physical security procedures for sites and media holding cardholder data are documented, kept current and followed by staff at those sites.

      • Information Security & Privacy Policies
      • Management Review of Policies
      • Physical Protection Policy & Procedure

    • 9.1.2 Physical security roles

      Responsibility for physical security tasks, such as badge control and media handling, is assigned and understood.

      • Roles & Responsibilities
      • Cybersecurity Responsibilities
      • Assigned Security & Privacy Responsibilities

  • 9.2 Physical entry controls

    • 9.2.1 Facility entry controls

      Appropriate entry controls at the facility restrict physical access to systems in the cardholder data environment.

      • Physical Protection Policy & Procedure

    • 9.2.1.1 Monitoring of sensitive areas

      Entry to and exit from sensitive areas in the cardholder data environment is watched by cameras, access control systems or both, the records are protected from tampering and kept for at least three months.

      • Physical Protection Policy & Procedure

    • 9.2.2 Publicly accessible network jacks

      Physical or logical controls stop people from using network jacks in public areas of the facility.

      • Physical Protection Policy & Procedure

    • 9.2.3 Network hardware and lines

      Physical access to wireless access points, gateways, networking equipment and telecommunication lines in the facility is restricted.

      • Physical Protection Policy & Procedure

    • 9.2.4 Consoles in sensitive areas

      Consoles in sensitive areas are locked when not in use.

      • Clear Desk & Clear Screen
      • Session Lock

  • 9.3 Physical access for personnel and visitors

    • 9.3.1 Personnel physical access procedures

      Procedures govern how staff are identified, granted physical access to the cardholder data environment, have it changed and have it removed, including how identification badges are controlled.

      • Physical Protection Policy & Procedure

    • 9.3.1.1 Access to sensitive areas

      Staff access to sensitive areas is authorized according to job function and revoked as soon as it is no longer needed, with keys and badges returned or disabled.

      • Physical Protection Policy & Procedure
      • Termination of Employment

    • 9.3.2 Visitor procedures

      Visitors are authorized before entering, escorted at all times, identified and given badges or other identification that makes them easy to tell apart from staff.

      • Physical Protection Policy & Procedure

    • 9.3.3 Visitor badges returned

      Visitor badges or identification are returned or deactivated before visitors leave or when they expire.

      • Physical Protection Policy & Procedure

    • 9.3.4 Visitor log

      A visitor log records each visitor's name, organization, visit date and time and the staff member who authorized them, and is kept for at least three months.

      • Physical Protection Policy & Procedure

  • 9.4 Media containing cardholder data

    • 9.4.1 Physical security of media

      All media holding cardholder data is kept physically secure.

      • Physical Protection Policy & Procedure
      • Clear Desk & Clear Screen

    • 9.4.1.1 Offline backup storage

      Offline media backups that hold cardholder data are stored in a secure location.

      • Data Backup Policy
      • Physical Protection Policy & Procedure

    • 9.4.1.2 Review of backup locations

      The security of offline backup locations holding cardholder data is reviewed at least once a year.

      • Data Backup Policy
      • Physical Protection Policy & Procedure

    • 9.4.2 Media classification

      Media holding cardholder data is classified by how sensitive the data is.

      • Data Classification Labels
      • Data Classification Policy

    • 9.4.3 Media sent off site

      Media with cardholder data that leaves the facility is logged and sent by secure courier or another delivery method that can be tracked.

      • Data Classification Policy
      • Data Classification Labels

    • 9.4.4 Management approval for media transfers

      Management approves every movement of media with cardholder data out of the facility, including to individuals.

      • Data Classification Policy

    • 9.4.5 Electronic media inventory

      An inventory log is kept of all electronic media holding cardholder data.

      • Asset Inventory Updates

    • 9.4.5.1 Yearly media inventory

      The electronic media holding cardholder data is inventoried at least once a year.

      • Asset Inventory Updates

    • 9.4.6 Destruction of hard-copy materials

      Paper with cardholder data is shredded, incinerated or pulped when no longer needed so it cannot be reconstructed, and is kept in secure containers until then.

      • Media Disposal Policy

    • 9.4.7 Destruction of electronic media

      Electronic media with cardholder data is destroyed, or its data made unrecoverable, when no longer needed for business or legal reasons.

      • Media Disposal Policy

  • 9.5 Protection of point-of-interaction devices

    • 9.5.1 POI device protection

      Card-reading devices that capture card data through direct physical interaction are protected from tampering and unauthorized substitution.

      • Payment Terminal Protection

    • 9.5.1.1 POI device list

      An up-to-date list records each card-reading device with its make, model, location and serial number or other unique identifier.

      • Payment Terminal Protection

    • 9.5.1.2 POI device inspections

      Card-reading devices are inspected periodically for signs of tampering or substitution.

      • Payment Terminal Protection

    • 9.5.1.2.1 Frequency of POI inspections

      How often and how thoroughly card-reading devices are inspected is set by a targeted risk analysis.

      • Payment Terminal Protection
      • Risk Assessment

    • 9.5.1.3 POI tampering awareness

      Staff working with card-reading devices are trained to verify repair technicians, avoid installing or swapping devices without checks, and report suspicious behavior or signs of tampering.

      • Payment Terminal Protection
      • Periodic Security & Privacy Training

• 10 Logging and monitoring

  • 10.1 Policies and roles for logging and monitoring

    • 10.1.1 Logging policies and procedures

      Procedures for generating, protecting and reviewing logs are written down, maintained and followed by the teams that operate and monitor systems.

      • Information Security & Privacy Policies
      • Management Review of Policies
      • Centralized Security Logging

    • 10.1.2 Logging roles

      Specific people are responsible for configuring, protecting and reviewing logs and understand those duties.

      • Roles & Responsibilities
      • Cybersecurity Responsibilities
      • Asset Ownership Assignment

  • 10.2 Audit log generation

    • 10.2.1 Audit logs enabled

      Audit logging is turned on and running for every system component and for cardholder data.

      • Centralized Security Logging

    • 10.2.1.1 Logging access to cardholder data

      Logs record every individual user's access to cardholder data.

      • Centralized Security Logging

    • 10.2.1.2 Logging administrative actions

      Logs record every action taken with administrative access, including interactive use of system or application accounts.

      • Centralized Security Logging

    • 10.2.1.3 Logging access to logs

      Logs record every access to the audit logs themselves.

      • Centralized Security Logging

    • 10.2.1.4 Logging failed access attempts

      Logs record every invalid logical access attempt.

      • Centralized Security Logging

    • 10.2.1.5 Logging credential changes

      Logs record every change to identification and authentication credentials, such as new accounts, privilege elevation and changes to administrative accounts.

      • Centralized Security Logging

    • 10.2.1.6 Logging changes to logging

      Logs record when audit logs are initialized and when logging is started, stopped or paused.

      • Centralized Security Logging

    • 10.2.1.7 Logging system-level objects

      Logs record the creation and deletion of system-level objects.

      • Centralized Security Logging

    • 10.2.2 Content of log entries

      Each logged event captures who did it, what kind of event it was, when, whether it succeeded, where it came from and which data or component it affected.

      • Centralized Security Logging

  • 10.3 Protection of audit logs

    • 10.3.1 Read access to logs

      Only people with a job-related need can read audit log files.

      • Centralized Security Logging
      • Production Database Access Restriction

    • 10.3.2 Logs protected from modification

      Audit log files are protected so that no one can change them.

      • Centralized Security Logging

    • 10.3.3 Central log backup

      Audit logs, including those from external-facing technologies, are copied promptly to a secure central log server or other media that is hard to alter.

      • Centralized Security Logging

    • 10.3.4 Integrity monitoring of logs

      File integrity monitoring or change detection on audit logs raises an alert if existing log data is altered.

      • Centralized Security Logging
      • Change Detection on Critical Files

  • 10.4 Review of audit logs

    • 10.4.1 Daily review of security logs

      Security events and the logs of systems that handle cardholder data or perform security functions are reviewed at least once a day.

      • Anomalous Behavior Detection
      • Centralized Security Logging
      • Unauthorized Activity Monitoring

    • 10.4.1.1 Automated log review

      Automated tools carry out the audit log reviews.

      • Anomalous Behavior Detection
      • Centralized Security Logging

    • 10.4.2 Review of other logs

      Logs from all other system components are reviewed periodically.

      • Centralized Security Logging
      • Unauthorized Activity Monitoring

    • 10.4.2.1 Frequency of other log reviews

      How often the other logs are reviewed is set by a targeted risk analysis.

      • Risk Assessment
      • Centralized Security Logging

    • 10.4.3 Follow-up of log anomalies

      Exceptions and anomalies found during log review are investigated and resolved.

      • Incident Tracking
      • Anomalous Behavior Detection
      • Automated Incident Reporting

  • 10.5 Retention of audit log history

    • 10.5.1 Log retention

      Audit log history is kept for at least 12 months, with the most recent three months available for immediate analysis.

      • Centralized Security Logging
      • Data Retention Policy

  • 10.6 Time synchronization

    • 10.6.1 Clock synchronization

      System clocks are kept in sync with time-synchronization technology.

      • Clock Synchronization

    • 10.6.2 Correct and consistent time

      Systems take their time only from designated central time servers that rely on trusted external sources, so time is correct and consistent across the environment.

      • Clock Synchronization

    • 10.6.3 Protection of time settings

      Time data and synchronization settings can only be changed by people with a business need, and every change is logged and monitored.

      • Clock Synchronization
      • Production Database Access Restriction

  • 10.7 Failures of critical security controls

    • 10.7.1 Detecting control failures (service providers)

      Service providers only: failures of critical security controls, such as network security controls, intrusion detection, anti-malware, access controls and audit logging, are detected, alerted on and dealt with promptly.

      • Capacity & Performance Management
      • Centralized Security Logging
      • Anomalous Behavior Detection

    • 10.7.2 Detecting control failures

      Failures of critical security controls, including change detection, segmentation checks and log review tools, are detected, alerted on and dealt with promptly.

      • Capacity & Performance Management
      • Centralized Security Logging
      • Anomalous Behavior Detection

    • 10.7.3 Responding to control failures

      When a critical security control fails, it is restored promptly and the failure's duration, cause, risk and remediation are documented, with monitoring resumed afterwards.

      • Incident Tracking
      • Incident Management Policy & Procedure

• 11 Regular security testing

  • 11.1 Policies and roles for security testing

    • 11.1.1 Security testing policies and procedures

      Procedures for wireless checks, vulnerability scans, penetration tests and intrusion detection are documented, maintained and followed by the people who run them.

      • Information Security & Privacy Policies
      • Management Review of Policies
      • Vulnerability Management Policy & Procedure

    • 11.1.2 Security testing roles

      Responsibility for each security testing activity is assigned to people who understand what it requires.

      • Roles & Responsibilities
      • Cybersecurity Responsibilities
      • Assigned Security & Privacy Responsibilities

  • 11.2 Wireless access point detection

    • 11.2.1 Testing for unauthorized wireless access points

      At least every three months the organization tests for wireless access points, identifies all authorized and unauthorized ones, and is alerted when an unauthorized one appears.

      • Wireless Access Point Management

    • 11.2.2 Inventory of authorized wireless access points

      An inventory of authorized wireless access points, each with a documented business reason, is maintained.

      • Wireless Access Point Management

  • 11.3 Vulnerability scanning

    • 11.3.1 Quarterly internal scans

      Internal vulnerability scans run at least every three months, high-risk and critical findings are fixed and rescanned, and the scans are done by qualified, independent staff.

      • Vulnerability Remediation Process
      • Centralized Flaw Remediation

    • 11.3.1.1 Lower-risk internal findings

      Vulnerabilities that are neither high-risk nor critical are fixed on a schedule set by a targeted risk analysis and rescanned.

      • Centralized Flaw Remediation
      • Vulnerability Remediation Process

    • 11.3.1.2 Authenticated internal scans

      Internal scans log in to the systems they test with enough privileges, and systems that cannot accept credentials are documented.

      • Vulnerability Remediation Process

    • 11.3.1.3 Internal scans after significant change

      Internal scans are also run after any significant change, and high-risk and critical findings are fixed.

      • Vulnerability Remediation Process
      • Change Management Policy & Procedure

    • 11.3.2 Quarterly ASV scans

      External vulnerability scans are run at least every three months by a PCI SSC Approved Scanning Vendor, with rescans until the vendor's passing criteria are met.

      • Approved Scanning Vendor Scans

    • 11.3.2.1 External scans after significant change

      External scans are also run after any significant change, and findings with a CVSS score of 4.0 or higher are fixed and rescanned.

      • Approved Scanning Vendor Scans
      • Vulnerability Remediation Process

  • 11.4 Penetration testing

    • 11.4.1 Penetration testing methodology

      A documented penetration testing methodology follows industry-accepted approaches and covers the whole CDE perimeter, critical systems, application and network layers, and segmentation.

      • Penetration Testing

    • 11.4.2 Internal penetration testing

      Internal penetration tests are done at least once a year and after significant changes, by a qualified, organizationally independent tester.

      • Penetration Testing

    • 11.4.3 External penetration testing

      External penetration tests are done at least once a year and after significant changes, by a qualified, organizationally independent tester.

      • Penetration Testing

    • 11.4.4 Fixing penetration test findings

      Exploitable vulnerabilities and weaknesses found in penetration tests are fixed according to their risk and the fix is confirmed by repeat testing.

      • Penetration Testing
      • Centralized Flaw Remediation

    • 11.4.5 Segmentation testing

      Where segmentation keeps other networks out of scope, the segmentation controls are tested at least once a year and after changes to confirm they isolate the CDE.

      • Penetration Testing
      • External System Connections

    • 11.4.6 Six-monthly segmentation testing

      Service providers only: segmentation controls are tested at least every six months and after changes.

      • Penetration Testing
      • External System Connections

    • 11.4.7 Support for customer penetration tests

      Multi-tenant service providers only: customers are supported in running their own external penetration tests.

      • Penetration Testing
      • Shared Responsibility Model

  • 11.5 Intrusion and change detection

    • 11.5.1 Intrusion detection and prevention

      Intrusion detection or prevention watches all traffic at the CDE perimeter and at critical points inside it, alerts staff to suspected compromises, and keeps its engines and signatures current.

      • Anomalous Behavior Detection

    • 11.5.1.1 Covert malware channels

      Service providers only: intrusion detection or prevention also detects, alerts on and addresses covert communication channels used by malware.

      • Anomalous Behavior Detection

    • 11.5.2 Change detection on critical files

      A change-detection mechanism such as file integrity monitoring compares critical files at least weekly and alerts staff to unauthorized changes.

      • Change Detection on Critical Files

  • 11.6 Unauthorized changes to payment pages

    • 11.6.1 Payment page tamper detection

      A change- and tamper-detection mechanism checks the security-relevant headers and script content of payment pages as the customer's browser receives them, at least weekly or as set by risk analysis, and alerts staff to unauthorized changes.

      • Payment Page Script Integrity

• 12 Security policies and programs

  • 12.1 Information security policy

    • 12.1.1 Overall information security policy

      An overall information security policy is established, published, maintained and shared with all relevant staff, vendors and business partners.

      • Security Governance Program
      • Information Security & Privacy Policies
      • Publishing Security & Privacy Documentation

    • 12.1.2 Yearly policy review

      The information security policy is reviewed at least once a year and updated when business objectives or risks change.

      • Management Review of Policies
      • Information Security & Privacy Policies

    • 12.1.3 Security roles defined for all staff

      The policy sets out security roles and responsibilities for all staff, and everyone acknowledges their own.

      • Cybersecurity Responsibilities
      • Roles & Responsibilities
      • Periodic Policy Acknowledgement

    • 12.1.4 Executive security responsibility

      Responsibility for information security is formally given to a chief information security officer or another knowledgeable executive.

      • Assigned Security & Privacy Responsibilities

  • 12.2 Acceptable use of end-user technologies

    • 12.2.1 Acceptable use policies

      Acceptable use policies for end-user technologies are documented and applied, covering approval to use them, acceptable uses and a list of approved products.

      • Rules of Behavior
      • Periodic Policy Acknowledgement

  • 12.3 Risk analysis and technology review

    • 12.3.1 Targeted risk analysis for flexible frequencies

      Every requirement that lets the organization choose how often to do something is backed by a documented targeted risk analysis that is reviewed at least once a year.

      • Risk Framing
      • Risk Assessment
      • Risk Assessment Policy & Procedure

    • 12.3.2 Targeted risk analysis for the customized approach

      A targeted risk analysis is done for each requirement met through the customized approach, approved by senior management and reviewed at least once a year.

      • Risk Framing
      • Risk Assessment

    • 12.3.3 Review of cipher suites and protocols

      The cryptographic cipher suites and protocols in use are documented and reviewed at least once a year, with a plan to respond to expected changes in cryptographic weaknesses.

      • Encryption Policy & Procedure
      • Transmission Confidentiality

    • 12.3.4 Review of hardware and software technologies

      Hardware and software in use are reviewed at least once a year to confirm vendors still provide security fixes and to plan for technologies nearing end of life, with results reported to senior management.

      • Inventory of Infrastructure Assets
      • Asset Inventory Updates
      • Endpoint Security Validation

  • 12.4 Executive responsibility for PCI DSS compliance

    • 12.4.1 Executive accountability for compliance

      Service providers only: executive management takes responsibility for protecting cardholder data and runs a PCI DSS compliance program with defined accountability and reporting to executives.

      • Security & Privacy Program Review
      • Assigned Security & Privacy Responsibilities
      • Compliance Program Manager

    • 12.4.2 Quarterly operational reviews

      Service providers only: at least every three months, someone independent of the work checks that staff carry out key security tasks such as log reviews, rule set reviews and change management as the policies require.

      • Internal Audit
      • Compliance Program Manager

    • 12.4.2.1 Documentation of operational reviews

      Service providers only: each quarterly review records its results and remediation actions and is signed off by the people responsible for the PCI DSS compliance program.

      • Internal Audit
      • Security & Privacy Program Review

  • 12.5 Documentation and validation of PCI DSS scope

    • 12.5.1 Inventory of in-scope components

      An inventory of system components in PCI DSS scope, with a description of what each one does, is maintained and kept current.

      • Inventory of Infrastructure Assets
      • Asset Inventory Updates
      • Inventory of Endpoint Assets

    • 12.5.2 Yearly scope confirmation

      PCI DSS scope is documented and confirmed at least once a year and after significant changes, covering data flows, account data locations, connected systems, segmentation and third-party connections.

      • PCI DSS Scope Confirmation
      • Network & Data Flow Diagrams

    • 12.5.2.1 Six-monthly scope confirmation

      Service providers only: PCI DSS scope is confirmed at least every six months and after significant changes.

      • PCI DSS Scope Confirmation

    • 12.5.3 Scope impact of organizational changes

      Service providers only: significant changes to the organization's structure trigger a documented review of their effect on PCI DSS scope and controls, shared with executive management.

      • PCI DSS Scope Confirmation
      • Management Review of Org Chart

  • 12.6 Security awareness

    • 12.6.1 Security awareness program

      A formal security awareness program makes all staff aware of the security policy and of their role in protecting cardholder data.

      • Security & Privacy Awareness
      • Periodic Security & Privacy Training

    • 12.6.2 Yearly program review

      The awareness program is reviewed at least once a year and updated for new threats and vulnerabilities.

      • Security & Privacy Awareness
      • Periodic Security & Privacy Training

    • 12.6.3 Training at hire and yearly

      Staff receive security awareness training when hired and at least once a year, through several communication methods, and confirm they have read the security policy.

      • New Hire Security & Privacy Training
      • Periodic Security & Privacy Training
      • Periodic Policy Acknowledgement

    • 12.6.3.1 Phishing and social engineering topics

      Awareness training covers threats that could affect the cardholder data environment, including phishing and social engineering.

      • Periodic Security & Privacy Training
      • Security & Privacy Awareness

    • 12.6.3.2 Acceptable use topics

      Awareness training covers the acceptable use of end-user technologies.

      • Periodic Security & Privacy Training
      • Rules of Behavior

  • 12.7 Personnel screening

    • 12.7.1 Screening of staff with CDE access

      People who will have access to the cardholder data environment are screened before hiring, within the limits of local law.

      • Personnel Screening

  • 12.8 Management of third-party service providers

    • 12.8.1 List of third-party service providers

      A list is kept of every third-party service provider that receives account data or could affect its security, with a description of the service each provides.

      • Third-Party Criticality Assessments
      • Vendor Management Policy & Procedure

    • 12.8.2 Written agreements with providers

      Written agreements with those providers include their acknowledgment of responsibility for the account data they handle or the security of the environment they can affect.

      • Vendor Management Policy & Procedure
      • Third-Party Criticality Assessments

    • 12.8.3 Due diligence before engagement

      An established process, including due diligence before signing, is followed when engaging a third-party service provider.

      • Third-Party Criticality Assessments
      • Vendor Management Policy & Procedure

    • 12.8.4 Monitoring provider compliance status

      The PCI DSS compliance status of each third-party service provider is checked at least once a year.

      • Subservice Organization Evaluation
      • Management Review of Third-Party Risks
      • Third-Party Criticality Assessments

    • 12.8.5 Responsibility split with providers

      Records show which PCI DSS requirements each provider handles, which the organization handles and which are shared.

      • Shared Responsibility Model
      • Vendor Management Policy & Procedure

  • 12.9 Support for customers of service providers

    • 12.9.1 Acknowledgment of responsibility to customers

      Service providers only: customers receive a written acknowledgment that the provider is responsible for the security of the account data it handles for them or the environment it can affect.

      • Contractual Obligations Register
      • Shared Responsibility Model

    • 12.9.2 Compliance information for customers

      Service providers only: on request, customers receive the provider's PCI DSS compliance status and the split of requirement responsibilities.

      • Shared Responsibility Model
      • Contractual Obligations Register
      • Publishing Security & Privacy Documentation

  • 12.10 Incident response

    • 12.10.1 Incident response plan

      An incident response plan is ready to activate for suspected or confirmed security incidents, covering roles, communication including card brand and acquirer notification, containment, recovery, evidence and business continuity.

      • Incident Management Policy & Procedure
      • Data Breach Notification Policy

    • 12.10.2 Yearly plan review and test

      The incident response plan is reviewed, updated and tested at least once a year.

      • Incident Management Policy & Procedure

    • 12.10.3 Round-the-clock responders

      Specific people are available at all times to respond to suspected or confirmed security incidents.

      • Incident Management Policy & Procedure
      • Automated Incident Reporting

    • 12.10.4 Incident responder training

      People responsible for incident response are trained regularly on their duties.

      • Incident Management Policy & Procedure
      • Periodic Security & Privacy Training

    • 12.10.4.1 Frequency of responder training

      How often incident responders are trained is set by a targeted risk analysis.

      • Risk Assessment
      • Incident Management Policy & Procedure

    • 12.10.5 Response to security monitoring alerts

      The incident response plan covers monitoring and responding to alerts from intrusion detection, change detection, payment page tamper detection and the detection of unauthorized wireless access points.

      • Automated Incident Reporting
      • Anomalous Behavior Detection
      • Incident Management Policy & Procedure

    • 12.10.6 Lessons learned

      The incident response plan is updated with lessons learned and industry developments.

      • Incident Management Policy & Procedure
      • Incident Tracking

    • 12.10.7 Unexpected storage of PAN

      Incident procedures start whenever card numbers are found where they should not be, covering how to retrieve, delete or move them, determine how they got there and fix the cause.

      • Account Data Minimization
      • Incident Management Policy & Procedure

• A1 Additional requirements for multi-tenant service providers

  Applies only to multi-tenant service providers, whose customers share the same hosting, cloud or application platform.

  • A1.1 Separation of customer environments

    • A1.1.1 Separation between provider and customers

      The provider and its customers are logically separated, so the provider cannot get into customer environments and customers cannot get into the provider's environment without authorization.

      • Tenant Isolation
      • Access Control Policy & Procedure
      • Identity Validation
      • External System Connections

    • A1.1.2 Customers limited to their own data

      Each customer can reach only its own cardholder data and cardholder data environment, never those of another customer.

      • Tenant Isolation
      • Production Database Access Restriction
      • Access Control Policy & Procedure

    • A1.1.3 Customers limited to their assigned resources

      Each customer can use only the computing resources allocated to it and cannot affect resources assigned to other customers.

      • Tenant Isolation
      • Limit Network Connections
      • Capacity & Performance Management

    • A1.1.4 Six-monthly testing of customer separation

      Penetration tests at least every six months confirm that the logical separation between customer environments still works, on top of the segmentation testing in requirement 11.4.6.

      • Tenant Isolation
      • Penetration Testing

  • A1.2 Logging and incident response for customers

    • A1.2.1 Audit logging for each customer

      Logging that meets requirement 10 is on by default for every customer environment, including common third-party applications, and each customer is told where its logs are kept and is the only one who can read them.

      • Centralized Security Logging
      • Tenant Isolation
      • Shared Responsibility Model

    • A1.2.2 Forensic investigation support

      The provider has processes ready to support a prompt forensic investigation whenever a security incident is suspected or confirmed for any of its customers.

      • Incident Management Policy & Procedure
      • Centralized Security Logging
      • Incident Tracking

    • A1.2.3 Customer reporting of incidents and vulnerabilities

      Customers have a secure way to report suspected security incidents and vulnerabilities to the provider, which investigates and fixes them following requirement 6.3.1.

      • Incident Reporting Assistance
      • Incident Management Policy & Procedure
      • Incident Tracking
      • Vulnerability Remediation Process

• A2 Additional requirements for SSL and early TLS on POS POI terminals

  Applies only to entities whose card-present POS POI terminals still connect over SSL or early TLS, and to the service providers that terminate those connections.

  • A2.1 POI terminals still using SSL or early TLS

    • A2.1.1 Terminals not exposed to known protocol exploits

      Where card-present POS POI terminals at a merchant or other acceptance location still use SSL or early TLS, the entity operating them confirms the devices are not open to any known exploit of those protocols.

      • Payment Terminal Protection
      • Transmission Confidentiality
      • Encryption Policy & Procedure
      • Vulnerability Remediation Process

    • A2.1.2 Risk mitigation and migration plan

      Service providers only: a provider whose POS POI connection points still accept SSL or early TLS keeps a formal plan covering how the protocols are used, the risk assessment and controls in place, how new vulnerabilities are tracked, how change control keeps the protocols out of new environments, and how they will be replaced.

      • Transmission Confidentiality
      • Encryption Policy & Procedure
      • Risk Assessment
      • Change Management Policy & Procedure
      • Threat Intelligence & Security Advisories

    • A2.1.3 Secure service option

      Service providers only: the provider offers customers a way to use its service over a secure protocol.

      • Transmission Confidentiality
      • Encryption Policy & Procedure
      • Shared Responsibility Model

• A3 Designated Entities Supplemental Validation (DESV)

  Applies only to entities that a payment brand or acquirer has designated for validation beyond the 12 principal requirements.

  • A3.1 PCI DSS compliance program

    • A3.1.1 Executive responsibility and program charter

      Executive management is accountable for protecting cardholder data and for a chartered PCI DSS compliance program, and executives and the board receive updates on compliance initiatives, issues and remediation at least once a year.

      • Security & Privacy Program Review
      • Assigned Security & Privacy Responsibilities
      • Compliance Program Manager
      • Security Governance Program

    • A3.1.2 Formal compliance program

      A formal program defines the day-to-day activities that keep PCI DSS compliance in place, the yearly assessment, ongoing validation of each requirement at its own frequency, and an analysis of how strategic business decisions affect PCI DSS.

      • Security Governance Program
      • Compliance Program Manager
      • Internal Audit
      • PCI DSS Scope Confirmation

    • A3.1.3 Compliance roles and responsibilities

      Named staff are formally assigned to run the day-to-day compliance activities, the yearly assessment, ongoing validation and the business impact analysis.

      • Compliance Program Manager
      • Assigned Security & Privacy Responsibilities
      • Roles & Responsibilities
      • Cybersecurity Responsibilities

    • A3.1.4 Yearly training for compliance staff

      Staff with PCI DSS compliance duties receive up-to-date PCI DSS or information security training at least once a year.

      • Periodic Security & Privacy Training
      • Compliance Program Manager

  • A3.2 Documentation and validation of PCI DSS scope

    • A3.2.1 Quarterly scope confirmation

      PCI DSS scope is documented and confirmed at least every three months and after significant changes, covering every payment flow and acceptance channel, every place account data is found, connected components, segmentation and third-party connections, with any data found outside the CDE deleted, moved or brought into scope.

      • PCI DSS Scope Confirmation
      • Network & Data Flow Diagrams
      • Account Data Minimization
      • Inventory of Infrastructure Assets

    • A3.2.2 Scope impact of system and network changes

      Every change to systems or networks, including new systems and connections, gets a formal assessment of its PCI DSS impact that identifies the applicable requirements, updates scope and is approved by the responsible staff.

      • Change Management Policy & Procedure
      • PCI DSS Scope Confirmation
      • Approval of Changes

    • A3.2.2.1 Confirmation after change

      Once a change is complete, the organization confirms that all relevant PCI DSS requirements are in place on the new or changed systems and networks and updates its documentation.

      • Change Management Policy & Procedure
      • PCI DSS Scope Confirmation
      • Regression Testing

    • A3.2.3 Scope review after organizational change

      Changes to the organization's structure trigger a formal internal review of their effect on PCI DSS scope and on which controls apply.

      • PCI DSS Scope Confirmation
      • Management Review of Org Chart

    • A3.2.4 Six-monthly segmentation testing

      Where segmentation reduces scope, penetration tests of every segmentation control at least every six months and after changes confirm the controls work and isolate the CDE from out-of-scope systems.

      • Penetration Testing
      • External System Connections

    • A3.2.5 Data discovery methodology

      A data discovery method confirms scope by finding every source and location of clear-text card numbers, including outside the defined CDE, at least every three months and after significant changes.

      • Account Data Minimization
      • PCI DSS Scope Confirmation

    • A3.2.5.1 Testing of data discovery methods

      The data discovery methods are tested at least once a year to confirm they can find clear-text card numbers on every type of system component and file format in use.

      • Account Data Minimization
      • Internal Audit

    • A3.2.5.2 Response to card numbers found outside the CDE

      Procedures cover what to do when clear-text card numbers turn up outside the CDE: retrieve, securely delete or move them, find out how and from where they got there, check whether track data came with them, and close the gap.

      • Account Data Minimization
      • Incident Management Policy & Procedure
      • Incident Tracking

    • A3.2.6 Preventing card numbers from leaving the CDE

      Always-on mechanisms detect and stop clear-text card numbers leaving the CDE through unauthorized channels, methods or processes, and produce audit logs and alerts when it happens.

      • PAN Exposure Restrictions
      • Anomalous Behavior Detection
      • Centralized Security Logging

    • A3.2.6.1 Response to data leakage alerts

      Responsible staff promptly investigate alerts about attempts to move clear-text card numbers out of the CDE and fix the leak or process gap to prevent data loss.

      • Incident Management Policy & Procedure
      • Automated Incident Reporting
      • Incident Tracking

  • A3.3 PCI DSS in business-as-usual activities

    • A3.3.1 Detection of critical security control failures

      Failures of critical security controls, from network security controls, intrusion detection and anti-malware to access controls, audit logging, segmentation and automated log or code review tools, are detected, alerted on and dealt with promptly.

      • Capacity & Performance Management
      • Centralized Security Logging
      • Anomalous Behavior Detection

    • A3.3.1.2 Response to critical security control failures

      When a critical security control fails, the organization restores it, records how long it was down, finds and fixes the root cause, deals with any security issues that arose meanwhile, and resumes monitoring.

      • Incident Tracking
      • Incident Management Policy & Procedure

    • A3.3.2 Yearly technology review

      Hardware and software technologies are reviewed at least once a year to confirm they still meet the organization's PCI DSS requirements, with a plan to fix or replace those that no longer do.

      • Inventory of Infrastructure Assets
      • Asset Inventory Updates
      • Endpoint Security Validation
      • Software Inventory & Authorization

    • A3.3.3 Quarterly business-as-usual reviews

      At least every three months, staff assigned to the compliance program check that business-as-usual activities and operating procedures are being followed, record how they checked, gather evidence for the yearly assessment, approve the results and keep the records for at least 12 months.

      • Internal Audit
      • Compliance Program Manager
      • Security & Privacy Program Review

  • A3.4 Logical access to the CDE

    • A3.4.1 Six-monthly access review

      User accounts and access privileges on in-scope system components are reviewed at least every six months to confirm they still match each job role and are all authorized.

      • Production System Access Review
      • User Privilege Reviews
      • User Access Reviews

  • A3.5 Identification of and response to suspicious events

    • A3.5.1 Detection of attack patterns

      A defined method spots attack patterns and unwanted behavior across systems as they happen, alerts the responsible staff promptly, and handles each alert under documented response procedures.

      • Anomalous Behavior Detection
      • Centralized Security Logging
      • Automated Incident Reporting
      • Incident Management Policy & Procedure