Framework № PCI DSS 4.0 от 01.03.2022

1.1.1 
Defined Approach Requirements: 
All security policies and operational procedures that are identified in Requirement 1 are:

Customized Approach Objective:
Expectations, controls, and oversight for meeting activities within Requirement 1 are defined, understood, and adhered to by affected personnel. All supporting activities are repeatable, consistently applied, and conform to management’s intent.

Defined Approach Testing Procedures:

Purpose:
Requirement 1.1.1 is about effectively managing and maintaining the various policies and procedures specified throughout Requirement 1.
While it is important to define the specific policies or procedures called out in Requirement 1, it is equally important to ensure they are properly documented, maintained, and disseminated.

Good Practice:
It is important to update policies and procedures as needed to address changes in processes, technologies, and business objectives. For these reasons, consider updating these documents as soon as possible after a change occurs and not
only on a periodic cycle.

Definitions:
Security policies define the entity’s security objectives and principles. Operational procedures describe how to perform activities, and define the controls, methods, and processes that are followed to achieve the desired result in a consistent manner and in accordance with policy objectives. 

1.1.2 
Defined Approach Requirements: 
Roles and responsibilities for performing activities in Requirement 1 are documented, assigned, and understood. 

Customized Approach Objective:
Day-to-day responsibilities for performing all the activities in Requirement 1 are allocated. Personnel are accountable for successful, continuous operation of these requirements. 

Defined Approach Testing Procedures:

Purpose:
If roles and responsibilities are not formally assigned, personnel may not be aware of their day-to-day responsibilities and critical activities may not occur. 

Good Practice:
Roles and responsibilities may be documented within policies and procedures or maintained within separate documents. 
As part of communicating roles and responsibilities, entities can consider having personnel acknowledge their acceptance and understanding of their assigned roles and responsibilities. 

Definitions:
A method to document roles and responsibilities is a responsibility assignment matrix that includes who is responsible, accountable, consulted, and informed (also called a RACI matrix). 

Examples:
A method to document roles and responsibilities is a responsibility assignment matrix that includes who is responsible, accountable, consulted, and informed (also called a RACI matrix). 

1.2.1 
Defined Approach Requirements: 
Configuration standards for NSC rulesets are: 

Customized Approach Objective:
The way that NSCs are configured and operate are defined and consistently applied. 

Defined Approach Testing Procedures:

Purpose:
The implementation of these configuration standards results in the NSC being configured and managed to properly perform their security function (often referred to as the ruleset). 

Good Practice:
These standards often define the requirements for acceptable protocols, ports that are permitted to be used, and specific configuration requirements that are acceptable. Configuration standards may also outline what the entity considers not acceptable or not permitted within its network. 

Definitions:
NSCs are key components of a network architecture. Most commonly, NSCs are used at the boundaries of the CDE to control network traffic flowing inbound and outbound from the CDE. 
Configuration standards outline an entity’s minimum requirements for the configuration of its NSCs.

Examples:
Examples of NSCs covered by these configuration standards include, but are not limited to, firewalls, routers configured with access control lists, and cloud virtual networks.  

1.2.2
Defined Approach Requirements: 
All changes to network connections and to configurations of NSCs are approved and managed in accordance with the change control process defined at Requirement 6.5.1. 

Customized Approach Objective:
Changes to network connections and NSCs cannot result in misconfiguration, implementation of insecure services, or unauthorized network connections. 

Applicability Notes:
Changes to network connections include the addition, removal, or modification of a connection. 
Changes to NSC configurations include those related to the component itself as well as those affecting how it performs its security function. 

Defined Approach Testing Procedures:

Good Practice:
Changes should be approved by individuals with the appropriate authority and knowledge to understand the impact of the change. Verification should provide reasonable assurance that the change did not adversely impact the security of the network and that the change performs as expected. 
To avoid having to address security issues introduced by a change, all changes should be approved prior to being implemented and verified after the change is implemented. Once approved and verified, network documentation should be updated to include the changes to prevent inconsistencies between network documentation and the actual configuration. 

1.2.3 
Defined Approach Requirements: 
An accurate network diagram(s) is maintained that shows all connections between the CDE and other networks, including any wireless networks. 

Customized Approach Objective:
A representation of the boundaries between the CDE, all trusted networks, and all untrusted networks, is maintained and available. 

Applicability Notes:
A current network diagram(s) or other technical or topological solution that identifies network connections and devices can be used to meet this requirement. 

Defined Approach Testing Procedures:

Purpose:
Maintaining an accurate and up-to-date network diagram(s) prevents network connections and devices from being overlooked and unknowingly left unsecured and vulnerable to compromise. 
A properly maintained network diagram(s) helps an organization verify its PCI DSS scope by identifying systems connecting to and from the CDE. 

Good Practice:
All connections to and from the CDE should be identified, including systems providing security, management, or maintenance services to CDE system components. Entities should consider including the following in their network diagrams:

Diagrams should be updated by authorized personnel to ensure diagrams continue to provide an accurate description of the network. 

1.2.4
Defined Approach Requirements: 
An accurate data-flow diagram(s) is maintained that meets the following: 

Customized Approach Objective:
A representation of all transmissions of account data between system components and across network segments is maintained and available. 

Applicability Notes:
A data-flow diagram(s) or other technical or topological solution that identifies flows of account data across systems and networks can be used to meet this requirement. 

Defined Approach Testing Procedures:

Purpose:
An up-to-date, readily available data-flow diagram helps an organization understand and keep track of the scope of its environment by showing how account data flows across networks and between individual systems and devices. 
Maintaining an up-to-date data-flow diagram(s) prevents account data from being overlooked and unknowingly left unsecured. 

Good Practice:
The data-flow diagram should include all connection points where account data is received into and sent out of the network, including connections to open, public networks, application processing flows, storage, transmissions between systems and networks, and file backups. 
The data-flow diagram is meant to be in addition to the network diagram and should reconcile with and augment the network diagram. As a best practice, entities can consider including the following in their data-flow diagrams:

1.2.5 
Defined Approach Requirements: 
 All services, protocols, and ports allowed are identified, approved, and have a defined business need. 

Customized Approach Objective:
 Unauthorized network traffic (services, protocols, or packets destined for specific ports) cannot enter or leave the network. 

Defined Approach Testing Procedures:

Purpose:
Compromises often happen due to unused or insecure services (for example, telnet and FTP), protocols, and ports, since these can lead to unnecessary points of access being opened into the CDE. Additionally, services, protocols, and ports that are enabled but not in use are often overlooked and left unsecured and unpatched. By identifying the services, protocols, and ports necessary for business, entities can ensure that all other services, protocols, and ports are disabled or removed. 

Good Practice:
The security risk associated with each service, protocol, and port allowed should be understood. Approvals should be granted by personnel independent of those managing the configuration. Approving personnel should possess knowledge and accountability appropriate for making approval decisions. 

1.2.6 
Defined Approach Requirements: 
Security features are defined and implemented for all services, protocols, and ports that are in use and considered to be insecure, such that the risk is mitigated. 

Customized Approach Objective:
The specific risks associated with the use of insecure services, protocols, and ports are understood, assessed, and appropriately mitigated. 

Defined Approach Testing Procedures:

Purpose:
Compromises take advantage of insecure network configurations. 

Good Practice:
If insecure services, protocols, or ports are necessary for business, the risk posed by these services, protocols, and ports should be clearly understood and accepted by the organization, the use of the service, protocol, or port should be justified, and the security features that mitigate the risk of using these services, protocols, and ports should be defined and implemented by the entity. 

Further Information:
For guidance on services, protocols, or ports considered to be insecure, refer to industry standards and guidance (for example, from NIST, ENISA, OWASP). 

1.2.7 
Defined Approach Requirements: 
Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effective. 

Customized Approach Objective:
NSC configurations that allow or restrict access to trusted networks are verified periodically to ensure that only authorized connections with a current business justification are permitted. 

Defined Approach Testing Procedures:

Purpose:
Such a review gives the organization an opportunity to clean up any unneeded, outdated, or incorrect rules and configurations which could be utilized by an unauthorized person. Furthermore, it ensures that all rules and configurations allow only authorized services, protocols, and ports that match the documented business justifications. 

Good Practice:
This review, which can be implemented using manual, automated, or system-based methods, is intended to confirm that the settings that manage traffic rules, what is allowed in and out of the network, match the approved configurations. 
The review should provide confirmation that all permitted access has a justified business reason. Any discrepancies or uncertainties about a rule or configuration should be escalated for resolution. 
While this requirement specifies that this review occur at least once every six months, organizations with a high volume of changes to their network configurations may wish to consider performing reviews more frequently to ensure that the configurations continue to meet the needs of the business. 

1.2.8 
Defined Approach Requirements: 
Configuration files for NSCs are:

Customized Approach Objective:
NSCs cannot be defined or modified using untrusted configuration objects (including files). 

Applicability Notes:
Any file or setting used to configure or synchronize NSCs is considered to be a “configuration file.” This includes files, automated and system-based controls, scripts, settings, infrastructure as code, or other parameters that are backed up, archived, or stored remotely. 

Defined Approach Testing Procedures:

Purpose:
To prevent unauthorized configurations from being applied to the network, stored files with configurations for network controls need to be kept up to date and secured against unauthorized changes. 
Keeping configuration information current and secure ensures that the correct settings for NSCs are applied whenever the configuration is run. 

Examples:
If the secure configuration for a router is stored in non-volatile memory, when that router is restarted or rebooted, these controls should ensure that its secure configuration is reinstated. 

1.3.1 
Defined Approach Requirements: 
Inbound traffic to the CDE is restricted as follows:

Customized Approach Objective:
Unauthorized traffic cannot enter the CDE. 

Defined Approach Testing Procedures:

Purpose:
This requirement aims to prevent malicious individuals from accessing the entity’s network via unauthorized IP addresses or from using services, protocols, or ports in an unauthorized manner. 

Good Practice:
All traffic inbound to the CDE, regardless of where it originates, should be evaluated to ensure it follows established, authorized rules. Connections should be inspected to ensure traffic is restricted to only authorized communications—for example, by restricting source/destination addresses and ports, and blocking of content.

Examples: 
Implementing a rule that denies all inbound and outbound traffic that is not specifically needed— for example, by using an explicit “deny all” or implicit deny after allow statement—helps to prevent inadvertent holes that would allow unintended and potentially harmful traffic. 

1.3.2 
Defined Approach Requirements: 
Outbound traffic from the CDE is restricted as follows:

Customized Approach Objective:
Unauthorized traffic cannot leave the CDE. 

Defined Approach Testing Procedures:

Purpose:
This requirement aims to prevent malicious individuals and compromised system components within the entity’s network from communicating with an untrusted external host. 

Good Practice:
All traffic outbound from the CDE, regardless of the destination, should be evaluated to ensure it follows established, authorized rules. Connections should be inspected to restrict traffic to only authorized communications—for example, by restricting source/destination addresses and ports, and blocking of content. 

Examples:
Implementing a rule that denies all inbound and outbound traffic that is not specifically needed— for example, by using an explicit “deny all” or implicit deny after allow statement—helps to prevent inadvertent holes that would allow unintended and potentially harmful traffic. 

1.3.3
Defined Approach Requirements: 
NSCs are installed between all wireless networks and the CDE, regardless of whether the wireless network is a CDE, such that:

Customized Approach Objective:
Unauthorized traffic cannot traverse network boundaries between any wireless networks and wired environments in the CDE. 

Defined Approach Testing Procedures:

Purpose:
The known (or unknown) implementation and exploitation of wireless technology within a network is a common path for malicious individuals to gain access to the network and account data. If a wireless device or network is installed without the entity’s knowledge, a malicious individual could easily and “invisibly” enter the network. If NSCs do not restrict access from wireless networks into the CDE, malicious individuals that gain unauthorized access to the wireless network can easily connect to the CDE and compromise account information. 

1.4.1 
Defined Approach Requirements: 
NSCs are implemented between trusted and untrusted networks. 

Customized Approach Objective:
Unauthorized traffic cannot traverse network boundaries between trusted and untrusted networks. 

Defined Approach Testing Procedures:

Purpose:
Implementing NSCs at every connection coming into and out of trusted networks allows the entity to monitor and control access and minimizes the chances of a malicious individual obtaining access to the internal network via an unprotected connection. 

Examples: 
An entity could implement a DMZ, which is a part of the network that manages connections between an untrusted network (for examples of untrusted networks refer to the Requirement 1 Overview) and services that an organization needs to have available to the public, such as a web server. Please note that if an entity’s DMZ processes or transmits account data (for example, e-commerce website), it is also considered a CDE 

1.4.2 
Defined Approach Requirements: 
Inbound traffic from untrusted networks to trusted networks is restricted to: 

Customized Approach Objective:
Only traffic that is authorized or that is a response to a system component in the trusted network can enter a trusted network from an untrusted network. 

Applicability Notes:
The intent of this requirement is to address communication sessions between trusted and untrusted networks, rather than the specifics of protocols. This requirement does not limit the use of UDP or other connectionless network protocols if state is maintained by the NSC. 

Defined Approach Testing Procedures:

Purpose:
Ensuring that public access to a system component is specifically authorized reduces the risk of system components being unnecessarily exposed to untrusted networks. 

Good Practice:
System components that provide publicly accessible services, such as email, web, and DNS servers, are the most vulnerable to threats originating from untrusted networks. 
Ideally, such systems are placed within a dedicated trusted network that is public facing (for example, a DMZ) but that is separated via NSCs from more sensitive internal systems, which helps protect the rest of the network in the event these externally accessible systems are compromised. This functionality is intended to prevent malicious actors from accessing the organization's internal network from the Internet, or from using services, protocols, or ports in an unauthorized manner. 
Where this functionality is provided as a built-in feature of an NSC, the entity should ensure that its configurations do not result in the functionality being disabled or bypassed. 

Definitions:
Maintaining the "state" (or status) for each connection into a network means the NSC “knows” whether an apparent response to a previous connection is a valid, authorized response (since the NSC retains each connection’s status) or whether it is malicious traffic trying to fool the NSC into allowing the connection. 

1.4.3
Defined Approach Requirements: 
Anti-spoofing measures are implemented to detect and block forged source IP addresses from entering the trusted network. 

Customized Approach Objective:
Packets with forged IP source addresses cannot enter a trusted network. 

Defined Approach Testing Procedures:

Purpose:
Filtering packets coming into the trusted network helps to, among other things, ensure packets are not “spoofed” to appear as if they are coming from an organization’s own internal network. For example, anti-spoofing measures prevent internal addresses originating from the Internet from passing into the DMZ. 

Good Practice:
Products usually come with anti-spoofing set as a default and may not be configurable. Entities should consult the vendor's documentation for more information. 

Definitions:
Normally, a packet contains the IP address of the computer that originally sent it so other computers in the network know where the packet originated. 
Malicious individuals will often try to spoof (or imitate) the sending IP address to fool the target system into believing the packet is from a trusted source. 

1.4.4
Defined Approach Requirements: 
System components that store cardholder data are not directly accessible from untrusted networks. 

Customized Approach Objective:
Stored cardholder data cannot be accessed from untrusted networks. 

Applicability Notes:
This requirement is not intended to apply to storage of account data in volatile memory but does apply where memory is being treated as persistent storage (for example, RAM disk). Account data can only be stored in volatile memory during the time necessary to support the associated business process (for example, until completion of the related payment card transaction). 

Defined Approach Testing Procedures:

Purpose:
Cardholder data that is directly accessible from an untrusted network, for example, because it is stored on a system within the DMZ or in a cloud database service, is easier for an external attacker to access because there are fewer defensive layers to penetrate. Using NSCs to ensure that system components that store cardholder data (such as a database or a file) can only be directly accessed from trusted networks can prevent unauthorized network traffic from reaching the system component. 

1.4.5
Defined Approach Requirements: 
The disclosure of internal IP addresses and routing information is limited to only authorized parties. 

Customized Approach Objective:
Internal network information is protected from unauthorized disclosure. 

Defined Approach Testing Procedures:

Purpose:
Restricting the disclosure of internal, private, and local IP addresses is useful to prevent a hacker from obtaining knowledge of these IP addresses and using that information to access the network. 

Good Practice:
Methods used to meet the intent of this requirement may vary, depending on the specific networking technology being used. For example, the controls used to meet this requirement may be different for IPv4 networks than for IPv6 networks. 

Examples Methods to obscure IP addressing may include, but are not limited to:

1.5.1 
Defined Approach Requirements: 
Security controls are implemented on any computing devices, including company- and employee-owned devices, that connect to both untrusted networks (including the Internet) and the CDE as follows:

Customized Approach Objective:
Devices that connect to untrusted environments and also connect to the CDE cannot introduce threats to the entity’s CDE. 

Applicability Notes:
These security controls may be temporarily disabled only if there is legitimate technical need, as authorized by management on a case-by-case basis. If these security controls need to be disabled for a specific purpose, it must be formally authorized. Additional security measures may also need to be implemented for the period during which these security controls are not active.
This requirement applies to employee-owned and company-owned computing devices. Systems that cannot be managed by corporate policy introduce weaknesses and provide opportunities that malicious individuals may exploit 

Defined Approach Testing Procedures:

Purpose:
Computing devices that are allowed to connect to the Internet from outside the corporate environment—for example, desktops, laptops, tablets, smartphones, and other mobile computing devices used by employees—are more vulnerable to Internet-based threats. 
Use of security controls such as host-based controls (for example, personal firewall software or end-point protection solutions), network-based security controls (for example, firewalls, networkbased heuristics inspection, and malware simulation), or hardware, helps to protect devices from Internet-based attacks, which could use the device to gain access to the organization’s systems and data when the device reconnects to the network. 

Good Practice:
The specific configuration settings are determined by the entity and should be consistent with its network security policies and procedures. 
Where there is a legitimate need to temporarily disable security controls on a company-owned or employee-owned device that connects to both an untrusted network and the CDE—for example, to support a specific maintenance activity or investigation of a technical problem—the reason for taking such action is understood and approved by an appropriate management representative. Any disabling or altering of these security controls, including on administrators’ own devices, is performed by authorized personnel. 
It is recognized that administrators have privileges that may allow them to disable security controls on their own computers, but there should be alerting mechanisms in place when such controls are disabled and follow up that occurs to ensure processes were followed. 

Examples:
Practices include forbidding split-tunneling of VPNs for employee-owned or corporate-owned mobile devices and req 

2.1.1 
Defined Approach Requirements: 
All security policies and operational procedures that are identified in Requirement 2 are: 

Customized Approach Objective:
Expectations, controls, and oversight for meeting activities within Requirement 2 are defined and adhered to by affected personnel. All supporting activities are repeatable, consistently applied, and conform to management’s intent. 

Defined Approach Testing Procedures:

Purpose:
Requirement 2.1.1 is about effectively managing and maintaining the various policies and procedures specified throughout Requirement 2. While it is important to define the specific policies or procedures called out in Requirement 2, it is equally important to ensure they are properly documented, maintained, and disseminated. 

Good Practice:
It is important to update policies and procedures as needed to address changes in processes, technologies, and business objectives. For this reason, consider updating these documents as soon as possible after a change occurs and not only on a periodic cycle 

Definitions:
Security policies define the entity’s security objectives and principles. 
Operational procedures describe how to perform activities, and define the controls, methods, and processes that are followed to achieve the desired result in a consistent manner and in accordance with policy objectives. 

2.1.2
Defined Approach Requirements: 
Roles and responsibilities for performing activities in Requirement 2 are documented, assigned, and understood. 

Customized Approach Objective:
Day-to-day responsibilities for performing all the activities in Requirement 2 are allocated. Personnel are accountable for successful, continuous operation of these requirements. 

Defined Approach Testing Procedures:

Purpose:
If roles and responsibilities are not formally assigned, personnel may not be aware of their day-to-day responsibilities and critical activities may not occur. 

Good Practice:
Roles and responsibilities may be documented within policies and procedures or maintained within separate documents. 
As part of communicating roles and responsibilities, entities can consider having personnel acknowledge their acceptance and understanding of their assigned roles and responsibilities. 

Examples:
A method to document roles and responsibilities is a responsibility assignment matrix that includes who is responsible, accountable, consulted, and informed (also called a RACI matrix). 

2.2.1 
Defined Approach Requirements: 
Configuration standards are developed, implemented, and maintained to:

Customized Approach Objective:
All system components are configured securely and consistently and in accordance with industryaccepted hardening standards or vendor recommendations. 

Defined Approach Testing Procedures:

Purpose:
There are known weaknesses with many operating systems, databases, network devices, software, applications, container images, and other devices used by an entity or within an entity’s environment. There are also known ways to configure these system components to fix security vulnerabilities. Fixing security vulnerabilities reduces the opportunities available to an attacker. 
By developing standards, entities ensure their system components will be configured consistently and securely, and address the protection of devices for which full hardening may be more difficult. 

Good Practice:
Keeping up to date with current industry guidance will help the entity maintain secure configurations. 
The specific controls to be applied to a system will vary and should be appropriate for the type and function of the system. 
Numerous security organizations have established system-hardening guidelines and recommendations, which advise how to correct common, known weaknesses. 

Further:
Information Sources for guidance on configuration standards include but are not limited to: Center for Internet Security (CIS), International Organization for Standardization (ISO), National Institute of Standards and Technology (NIST), Cloud Security Alliance, and product vendors. 

2.2.2 
Defined Approach Requirements: 
Vendor default accounts are managed as follows:

Customized Approach Objective:
System components cannot be accessed using default passwords. 

Applicability Notes:
This applies to ALL vendor default accounts and passwords, including, but not limited to, those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, payment applications, and Simple Network Management Protocol (SNMP) defaults. 
This requirement also applies where a system component is not installed within an entity’s environment, for example, software and applications that are part of the CDE and are accessed via a cloud subscription service. 

Defined Approach Testing Procedures:

Purpose:
Malicious individuals often use vendor default account names and passwords to compromise operating systems, applications, and the systems on which they are installed. 
Because these default settings are often published and are well known, changing these settings will make systems less vulnerable to attack. 

Good Practice:
All vendor default accounts should be identified, and their purpose and use understood. It is important to establish controls for application and system accounts, including those used to deploy and maintain cloud services so that they do not use default passwords and are not usable by unauthorized individuals. 
Where a default account is not intended to be used, changing the default password to a unique password that meets PCI DSS Requirement 8.3.6, removing any access to the default account, and then disabling the account, will prevent a malicious individual from re-enabling the account and gaining access with the default password. 
Using an isolated staging network to install and configure new systems is recommended and can also be used to confirm that default credentials have not been introduced into production environments. 

Examples:
Defaults to be considered include user IDs, passwords, and other authentication credentials commonly used by vendors in their products. 

2.2.3 
Defined Approach Requirements: 
Primary functions requiring different security levels are managed as follows:

OR

OR

Customized Approach Objective:
Primary functions with lower security needs cannot affect the security of primary functions with higher security needs on the same system component. 
Defined Approach Testing Procedures:

Purpose:
Systems containing a combination of services, protocols, and daemons for their primary function will have a security profile appropriate to allow that function to operate effectively. For example, systems that need to be directly connected to the Internet would have a particular profile, like a DNS server, web server, or an e-commerce server. Conversely, other system components may operate a primary function comprising a different set of services, protocols, and daemons that performs functions that an entity does not want exposed to the Internet. This requirement aims to ensure that different functions do not impact the security profiles of other services in a way which may cause them to operate at a higher or lower security level. 

Good Practice:
Ideally, each function should be placed on different system components. This can be achieved by implementing only one primary function on each system component. Another option is to isolate primary functions on the same system component that have different security levels, for example, isolating web servers (which need to be directly connected to the Internet) from application and database servers. 
If a system component contains primary functions that need different security levels, a third option is to implement additional controls to ensure that the resultant security level of the primary function(s) with higher security needs is not reduced by the presence of the lower security primary functions. Additionally, the functions with a lower security level should be isolated and/or secured to ensure they cannot access or affect the resources of another system function, and do not introduce security weaknesses to other functions on the same server. 
Functions of differing security levels may be isolated by either physical or logical controls. For example, a database system should not also be hosting web services unless using controls like virtualization technologies to isolate and contain the functions into separate sub-systems. Another example is using virtual instances or providing dedicated memory access by system function. Where virtualization technologies are used, the security levels should be identified and managed for each virtual component. Examples of considerations for virtualized environments include:

2.2.4
Defined Approach Requirements: 
Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled. 

Customized Approach Objective:
System components cannot be compromised by exploiting unnecessary functionality present in the system component. 

Defined Approach Testing Procedures:

Purpose:
Unnecessary services and functions can provide additional opportunities for malicious individuals to gain access to a system. By removing or disabling all unnecessary services, protocols, daemons, and functions, organizations can focus on securing the functions that are required and reduce the risk that unknown or unnecessary functions will be exploited. 

Good Practice:
There are many protocols that could be enabled by default that are commonly used by malicious individuals to compromise a network. Disabling or removing all services, functions, and protocols that are not used minimizes the potential attack surface—for example, by removing or disabling an unused FTP or web server. 

Examples:
Unnecessary functionality may include, but is not limited to scripts, drivers, features, subsystems, file systems, interfaces (USB and Bluetooth), and unnecessary web servers. 

2.2.5
Defined Approach Requirements: 
If any insecure services, protocols, or daemons are present: 

Customized Approach Objective:
 System components cannot be compromised by exploiting insecure services, protocols, or daemons. 

Defined Approach Testing Procedures:

Purpose:
Ensuring that all insecure services, protocols, and daemons are adequately secured with appropriate security features makes it more difficult for malicious individuals to exploit common points of compromise within a network. 

Good Practice:
Enabling security features before new system components are deployed will prevent insecure configurations from being introduced into the environment. Some vendor solutions may provide additional security functions to assist with securing an insecure process. 

Further Information:
For guidance on services, protocols, or daemons considered to be insecure, refer to industry standards and guidance (for example, as published by NIST, ENISA, and OWASP). 

2.2.6
Defined Approach Requirements: 
System security parameters are configured to prevent misuse. 

Customized Approach Objective:
System components cannot be compromised because of incorrect security parameter configuration. 

Defined Approach Testing Procedures:

Purpose:
Correctly configuring security parameters provided in system components takes advantage of the capabilities of the system component to defeat malicious attacks. 

Good Practice:
System configuration standards and related processes should specifically address security settings and parameters that have known security implications for each type of system in use. 
For systems to be configured securely, personnel responsible for configuration and/or administering systems should be knowledgeable in the specific security parameters and settings that apply to the system. Considerations should also include secure settings for parameters used to access cloud portals. 

Further Information: 
Refer to vendor documentation and industry references noted in Requirement 2.2.1 for information about applicable security parameters for each type of system. 

2.2.7 
Defined Approach Requirements: 
All non-console administrative access is encrypted using strong cryptography. 

Customized Approach Objective:
Cleartext administrative authorization factors cannot be read or intercepted from any network transmissions. 

Applicability Notes:
This includes administrative access via browserbased interfaces and application programming interfaces (APIs). 

Defined Approach Testing Procedures:

rpose:
If non-console (including remote) administration does not use encrypted communications, administrative authorization factors (such as IDs and passwords) can be revealed to an eavesdropper. A malicious individual could use this information to access the network, become administrator, and steal data. 

Good Practice:
Whichever security protocol is used, it should be configured to use only secure versions and configurations to prevent use of an insecure connection—for example, by using only trusted certificates, supporting only strong encryption, and not supporting fallback to weaker, insecure protocols or methods. 

Examples:
Cleartext protocols (such as HTTP, telnet, etc.) do not encrypt traffic or logon details, making it easy for an eavesdropper to intercept this information. Non-console access may be facilitated by technologies that provide alternative access to systems, including but not limited to, out-of-band (OOB), lights-out management (LOM), Intelligent Platform Management Interface (IPMI), and keyboard, video, mouse (KVM) switches with remote capabilities. These and other non-console access technologies and methods must be secured with strong cryptography 

Further Information:
Refer to industry standards and best practices such as NIST SP 800-52 and SP 800-57. 

2.3.1 
Defined Approach Requirements: 
For wireless environments connected to the CDE or transmitting account data, all wireless vendor defaults are changed at installation or are confirmed to be secure, including but not limited to: 

Customized Approach Objective:
Wireless networks cannot be accessed using vendor default passwords or default configurations. 

Applicability Notes:
This includes, but is not limited to, default wireless encryption keys, passwords on wireless access points, SNMP defaults, and any other securityrelated wireless vendor defaults.
 
Defined Approach Testing Procedures:

Purpose:
If wireless networks are not implemented with sufficient security configurations (including changing default settings), wireless sniffers can eavesdrop on the traffic, easily capture data and passwords, and easily enter and attack the network. 

Good Practice:
Wireless passwords should be constructed so that they are resistant to offline brute force attacks. 

2.3.2
Defined Approach Requirements: 
For wireless environments connected to the CDE or transmitting account data, wireless encryption keys are changed as follows: 

Customized Approach Objective:
Knowledge of wireless encryption keys cannot allow unauthorized access to wireless networks. 

Defined Approach Testing Procedures:

Purpose:
Changing wireless encryption keys whenever someone with knowledge of the key leaves the organization or moves to a role that no longer requires knowledge of the key, helps keep knowledge of keys limited to only those with a business need to know. 
Also, changing wireless encryption keys whenever a key is suspected or known to be comprised makes a wireless network more resistant to compromise. 

Good Practice:
This goal can be accomplished in multiple ways, including periodic changes of keys, changing keys via a defined “joiners-movers-leavers” (JML) process, implementing additional technical controls, and not using fixed pre-shared keys. 
In addition, any keys that are known to be, or suspected of being, compromised should be managed in accordance with the entity’s incident response plan at Requirement 12.10.1. 

3.1.1 
Defined Approach Requirements: 
All security policies and operational procedures that are identified in Requirement 3 are:

Customized Approach Objective:
Expectations, controls, and oversight for meeting activities within Requirement 3 are defined and adhered to by affected personnel. All supporting activities are repeatable, consistently applied, and conform to management’s intent. 

Defined Approach Testing Procedures:

Purpose:
Requirement 3.1.1 is about effectively managing and maintaining the various policies and procedures specified throughout Requirement 3. While it is important to define the specific policies or procedures called out in Requirement 3, it is equally important to ensure they are properly documented, maintained, and disseminated. 

Good Practice:
It is important to update policies and procedures as needed to address changes in processes, technologies, and business objectives. For this reason, consider updating these documents as soon as possible after a change occurs and not only on a periodic cycle. 

Examples:
Security policies define the entity’s security objectives and principles. Operational procedures describe how to perform activities, and define the controls, methods, and processes that are followed to achieve the desired result in a consistent manner and in accordance with policy objectives. 

3.1.2 
Defined Approach Requirements: 
Roles and responsibilities for performing activities in Requirement 3 are documented, assigned, and understood. 

Customized Approach Objective:
Day-to-day responsibilities for performing all the activities in Requirement 3 are allocated. Personnel are accountable for successful, continuous operation of these requirements. 

Defined Approach Testing Procedures:

Purpose:
If roles and responsibilities are not formally assigned, personnel may not be aware of their day-to-day responsibilities, and critical activities may not occur. 

Good Practice:
Roles and responsibilities may be documented within policies and procedures or maintained within separate documents. 
As part of communicating roles and responsibilities, entities can consider having personnel acknowledge their acceptance and understanding of their assigned roles and responsibilities. 

Examples:
A method to document roles and responsibilities is a responsibility assignment matrix that includes who is responsible, accountable, consulted, and informed (also called a RACI matrix). 

3.2.1 
Defined Approach Requirements: 
Account data storage is kept to a minimum through implementation of data retention and disposal policies, procedures, and processes that include at least the following: 

Customized Approach Objective:
Account data is retained only where necessary and for the least amount of time needed and is securely deleted or rendered unrecoverable when no longer needed. 

Applicability Notes:
Where account data is stored by a TPSP (for example, in a cloud environment), entities are responsible for working with their service providers to understand how the TPSP meets this requirement for the entity. Considerations include ensuring that all geographic instances of a data element are securely deleted. The bullet above (for coverage of SAD stored prior to completion of authorization) is a best practice until 31 March 2025, after which it will be required as part of Requirement 3.2.1 and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
A formal data retention policy identifies what data needs to be retained, for how long, and where that data resides so it can be securely destroyed or deleted as soon as it is no longer needed. The only account data that may be stored after authorization is the primary account number or PAN (rendered unreadable), expiration date, cardholder name, and service code. 
The storage of SAD data prior to the completion of the authorization process is also included in the data retention and disposal policy so that storage of this sensitive data is kept to minimum, and only retained for the defined amount of time. 

Good Practice:
When identifying locations of stored account data, consider all processes and personnel with access to the data, as data could have been moved and stored in different locations than originally defined. Storage locations that are often overlooked include backup and archive systems, removable data storage devices, paper-based media, and audio recordings.
To define appropriate retention requirements, an entity first needs to understand its own business needs as well as any legal or regulatory obligations that apply to its industry or to the type of data being retained. Implementing an automated process to ensure data is automatically and securely deleted upon its defined retention limit can help ensure that account data is not retained beyond what is necessary for business, legal, or regulatory purposes. 
Methods of eliminating data when it exceeds the retention period include secure deletion to complete removal of the data or rendering it unrecoverable and unable to be reconstructed. Identifying and securely eliminating stored data that has exceeded its specified retention period prevents unnecessary retention of data that is no longer needed. This process may be automated, manual, or a combination of both. 
The deletion function in most operating systems is not “secure deletion” as it allows deleted data to be recovered, so instead, a dedicated secure deletion function or application must be used to make data unrecoverable. 
Remember, if you don't need it, don't store it! 

Examples:
An automated, programmatic procedure could be run to locate and remove data, or a manual review of data storage areas could be performed. Whichever method is used, it is a good idea to monitor the process to ensure it is completed successfully, and that the results are recorded and validated as being complete. Implementing secure deletion methods ensures that the data cannot be retrieved when it is no longer needed. 

Further Information:
See NIST SP 800-88 Rev. 1, Guidelines for Media Sanitization. 

3.3.1 
Defined Approach Requirements: 
SAD is not retained after authorization, even if encrypted. All sensitive authentication data received is rendered unrecoverable upon completion of the authorization process 

Customized Approach Objective:
This requirement is not eligible for the customized approach. 

Applicability Notes:
This requirement does not apply to issuers and companies that support issuing services (where SAD is needed for a legitimate issuing business need) and have a business justification to store the sensitive authentication data. 
Refer to Requirement 3.3.3 for additional requirements specifically for issuers. 
Sensitive authentication data includes the data cited in Requirements 3.3.1.1 through 3.3.1.3. 

Defined Approach Testing Procedures:

Purpose:
SAD is very valuable to malicious individuals as it allows them to generate counterfeit payment cards and create fraudulent transactions. Therefore, the storage of SAD upon completion of the authorization process is prohibited. 

Definitions:
The authorization process completes when a merchant receives a transaction response (for example, an approval or decline) 

3.3.1.1
Defined Approach Requirements: 
The full contents of any track are not retained upon completion of the authorization process. 

Customized Approach Objective:
This requirement is not eligible for the customized approach. 

Applicability Notes:
In the normal course of business, the following data elements from the track may need to be retained: 

To minimize risk, store securely only these data elements as needed for business. 

Defined Approach Testing Procedures:

Purpose:
If full contents of any track (from the magnetic stripe on the back of a card if present, equivalent data contained on a chip, or elsewhere) is stored, malicious individuals who obtain that data can use it to reproduce payment cards and complete fraudulent transactions. 

Definitions:
Full track data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data. Each track contains a number of data elements, and this requirement specifies only those that may be retained post-authorization. 

Examples:
Data sources to review to ensure that the full contents of any track are not retained upon completion of the authorization process include, but are not limited to:

3.3.1.2
Defined Approach Requirements: 
The card verification code is not retained upon completion of the authorization process. 

Customized Approach Objective:
This requirement is not eligible for the customized approach. 

Applicability Notes:
The card verification code is the three- or four-digit number printed on the front or back of a payment card used to verify card-not-present transactions. 

Defined Approach Testing Procedures:

Purpose:
If card verification code data is stolen, malicious individuals can execute fraudulent Internet and mail-order/telephone-order (MO/TO) transactions. Not storing this data reduces the probability of it being compromised. 

Examples:
If card verification codes are stored on paper media prior to completion of authorization, a method of erasing or covering the codes should prevent them from being read after authorization is complete. Example methods of rendering the codes unreadable include removing the code with scissors and applying a suitably opaque and unremovable marker over the code 
Data sources to review to ensure that the card verification code is not retained upon completion of the authorization process include, but are not limited to:

3.3.1.3
Defined Approach Requirements: 
The personal identification number (PIN) and the PIN block are not retained upon completion of the authorization process. 

Customized Approach Objective:
This requirement is not eligible for the customized approach. 

Applicability Notes:
PIN blocks are encrypted during the natural course of transaction processes, but even if an entity encrypts the PIN block again, it is still not allowed to be stored after the completion of the authorization process. 

Defined Approach Testing Procedures:

Purpose:
PIN and PIN blocks should be known only to the card owner or entity that issued the card. If this data is stolen, malicious individuals can execute fraudulent PIN-based transactions (for example, in-store purchases and ATM withdrawals). Not storing this data reduces the probability of it being compromised. 

Examples:
Data sources to review to ensure that PIN and PIN blocks are not retained upon completion of the authorization process include, but are not limited to: 

3.3.2 
Defined Approach Requirements: 
SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography. 

Customized Approach Objective:
This requirement is not eligible for the customized approach. 

Applicability Notes:
Whether SAD is permitted to be stored prior to authorization is determined by the organizations that manage compliance programs (for example, payment brands and acquirers). Contact the organizations of interest for any additional criteria.
This requirement applies to all storage of SAD, even if no PAN is present in the environment. 
Refer to Requirement 3.2.1 for an additional requirement that applies if SAD is stored prior to completion of authorization. 
This requirement does not apply to issuers and companies that support issuing services where there is a legitimate issuing business justification to store SAD). 
Refer to Requirement 3.3.3 for requirements specifically for issuers. 
This requirement does not replace how PIN blocks are required to be managed, nor does it mean that a properly encrypted PIN block needs to be encrypted again. 
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
SAD can be used by malicious individuals to increase the probability of successfully generating counterfeit payment cards and creating fraudulent transactions. 

Good Practice:
Entities should consider encrypting SAD with a different cryptographic key than is used to encrypt PAN. Note that this does not mean that PAN present in SAD (as part of track data) would need to be separately encrypted. 

Definitions:
The authorization process is completed as soon as the response to an authorization request response—that is, an approval or decline—is received. 

3.3.3 
Defined Approach Requirements: 
Additional requirement for issuers and companies that support issuing services and store sensitive authentication data: Any storage of sensitive authentication data is: • Limited to that which is needed for a legitimate issuing business need and is secured. • Encrypted using strong cryptography. This bullet is a best practice until its effective date; refer to Applicability Notes below for details. 

Customized Approach Objective:
Sensitive authentication data is retained only as required to support issuing functions and is secured from unauthorized access. 

Applicability Notes:
This requirement applies only to issuers and companies that support issuing services and store sensitive authentication data. 
Entities that issue payment cards or that perform or support issuing services will often create and control sensitive authentication data as part of the issuing function. It is allowable for companies that perform, facilitate, or support issuing services to store sensitive authentication data ONLY IF they have a legitimate business need to store such data. 
PCI DSS requirements are intended for all entities that store, process, or transmit account data, including issuers. The only exception for issuers and issuer processors is that sensitive authentication data may be retained if there is a legitimate reason to do so. Any such data must be stored securely and in accordance with all PCI DSS and specific payment brand requirements. 
The bullet above (for encrypting stored SAD with strong cryptography) is a best practice until 31 March 2025, after which it will be required as part of Requirement 3.3.3 and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
 SAD can be used by malicious individuals to increase the probability of successfully generating counterfeit payment cards and creating fraudulent transactions. 

Good Practice:
Entities should consider encrypting SAD with a different cryptographic key than is used to encrypt PAN. Note that this does not mean that PAN present in SAD (as part of track data) would need to be separately encrypted. 

Definitions:
Legitimate issuing business need means that the data is needed to facilitate the issuing business process. 

Further Information:
Refer to ISO/DIS 9564-5 Financial services — Personal Identification Number (PIN) 

3.4.1 
Defined Approach Requirements: 
PAN is masked when displayed (the BIN and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see more than the BIN and last four digits of the PAN. 

Customized Approach Objective:
PAN displays are restricted to the minimum number of digits necessary to meet a defined business need. 

Applicability Notes:
This requirement does not supersede stricter requirements in place for displays of cardholder data—for example, legal or payment brand requirements for point-of-sale (POS) receipts. 
This requirement relates to protection of PAN where it is displayed on screens, paper receipts, printouts, etc., and is not to be confused with Requirement 3.5.1 for protection of PAN when stored, processed, or transmitted. 

Defined Approach Testing Procedures:

Purpose:
The display of full PAN on computer screens, payment card receipts, paper reports, etc. can result in this data being obtained by unauthorized individuals and used fraudulently. Ensuring that the full PAN is displayed only for those with a legitimate business need minimizes the risk of unauthorized persons gaining access to PAN data. 

Good Practice:
Applying access controls according to defined roles is one way to limit access to viewing full PAN to only those individuals with a defined business need. 
The masking approach should always display only the number of digits needed to perform a specific business function. For example, if only the last four digits are needed to perform a business function, PAN should be masked to only show the last four digits. As another example, if a function needs to view to the bank identification number (BIN) for routing purposes, unmask only the BIN digits for that function. 

Definitions:
Masking is not synonymous with truncation and these terms cannot be used interchangeably. Masking refers to the concealment of certain digits during display or printing, even when the entire PAN is stored on a system. This is different from truncation, in which the truncated digits are removed and cannot be retrieved within the system. Masked PAN could be “unmasked”, but there is no "un-truncation" without recreating the PAN from another source. 

Further Information:
For more information about masking and truncation, see PCI SSC’s FAQs on these topics. 

3.4.2 
Defined Approach Requirements: 
When using remote-access technologies, technical controls prevent copy and/or relocation of PAN for all personnel, except for those with documented, explicit authorization and a legitimate, defined business need. 

Customized Approach Objective:
PAN cannot be copied or relocated by unauthorized personnel using remote-access technologies. 

Applicability Notes:
Storing or relocating PAN onto local hard drives, removable electronic media, and other storage devices brings these devices into scope for PCI DSS. 
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
Relocation of PAN to unauthorized storage devices is a common way for this data to be obtained and used fraudulently. 
Methods to ensure that only those with explicit authorization and a legitimate business reason can copy or relocate PAN minimizes the risk of unauthorized persons gaining access to PAN. 

Good Practice:
Copying and relocation of PAN should only be done to storage devices that are permissible and authorized for that individual. 

Definitions
A virtual desktop is an example of a remoteaccess technology. Storage devices include, but are not limited to, local hard drives, virtual drives, removable electronic media, network drives, and cloud storage. 

Further Information:
Vendor documentation for the remote-access technology in use will provide information about the system settings needed to implement this requirement. 

3.5.1 
Defined Approach Requirements: 
PAN is rendered unreadable anywhere it is stored by using any of the following approaches:

Customized Approach Objective:
Cleartext PAN cannot be read from storage media. 

Applicability Notes:
It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. 
This requirement applies to PANs stored in primary storage (databases, or flat files such as text files spreadsheets) as well as non-primary storage (backup, audit logs, exception, or troubleshooting logs) must all be protected. 
This requirement does not preclude the use of temporary files containing cleartext PAN while encrypting and decrypting PAN. 

Defined Approach Testing Procedures:

Purpose:
The removal of cleartext stored PAN is a defense in depth control designed to protect the data if an unauthorized individual gains access to stored data by taking advantage of a vulnerability or misconfiguration of an entity’s primary access control. 
Secondary independent control systems (for example governing access to, and use of, cryptography and decryption keys) prevent the failure of a primary access control system leading to a breach of confidentiality of stored PAN. If hashing is used to remove stored cleartext PAN, by correlating hashed and truncated versions of a given PAN, a malicious individual can easily derive the original PAN value. Controls that prevent the correlation of this data will help ensure that the original PAN remains unreadable. 

Further Informatio:
For information about truncation formats and truncation in general, see PCI SSC’s FAQs on the topic.
Sources for information about index tokens include: 

3.5.1.1
Defined Approach Requirements: 
Hashes used to render PAN unreadable (per the first bullet of Requirement 3.5.1) are keyed cryptographic hashes of the entire PAN, with associated key-management processes and procedures in accordance with Requirements 3.6 and 3.7. 

Applicability Notes:
This requirement applies to PANs stored in primary storage (databases, or flat files such as text files spreadsheets) as well as non-primary storage (backup, audit logs, exception, or troubleshooting logs) must all be protected. 
This requirement does not preclude the use of temporary files containing cleartext PAN while encrypting and decrypting PAN. 
This requirement is considered a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
The removal of cleartext stored PAN is a defense in depth control designed to protect the data if an unauthorized individual gains access to stored data by taking advantage of a vulnerability or misconfiguration of an entity’s primary access control. 
Secondary independent control systems (for example governing access to, and use of, cryptography and decryption keys) prevent the failure of a primary access control system leading to a breach of confidentiality of stored PAN. 

Good Practice:
A hashing function that incorporates a randomly generated secret key provides brute force attack resistance and secret authentication integrity. 

Further Information:
Appropriate keyed cryptographic hashing algorithms include but are not limited to: HMAC, CMAC, and GMAC, with an effective cryptographic strength of at least 128-bits (NIST SP 800-131Ar2). 
Refer to the following for more information about HMAC, CMAC, and GMAC, respectively: NIST SP 800-107r1, NIST SP 800-38B, and NIST SP 800-38D). 
See NIST SP 800-107 (Revision 1): Recommendation for Applications Using Approved Hash Algorithms §5.3. 

3.5.1.2
Defined Approach Requirements: 
 If disk-level or partition-level encryption (rather than file-, column-, or field-level database encryption) is used to render PAN unreadable, it is implemented only as follows: 

OR 

Customized Approach Objective:
This requirement is not eligible for the customized approach. 

Applicability Notes:
While disk encryption may still be present on these types of devices, it cannot be the only mechanism used to protect PAN stored on those systems. Any stored PAN must also be rendered unreadable per Requirement 3.5.1—for example, through truncation or a data-level encryption mechanism. Full disk encryption helps to protect data in the event of physical loss of a disk and therefore its use is appropriate only for removable electronic media storage devices. 
Media that is part of a data center architecture (for example, hot-swappable drives, bulk tape-backups) is considered non-removable electronic media to which Requirement 3.5.1 applies 
Disk or partition encryption implementations must also meet all other PCI DSS encryption and keymanagement requirements 

Defined Approach Testing Procedures:

Purpose:
Disk-level and partition-level encryption typically encrypts the entire disk or partition using the same key, with all data automatically decrypted when the system runs or when an authorized user requests it. For this reason, disk-level encryption is not appropriate to protect stored PAN on computers, laptops, servers, storage arrays, or any other system that provides transparent decryption upon user authentication. 

Further Information:
Where available, following vendors’ hardening and industry best practice guidelines can assist in securing PAN on these devices. 

3.5.1.3
Defined Approach Requirements: 
If disk-level or partition-level encryption is used (rather than file-, column-, or field--level database encryption) to render PAN unreadable, it is managed as follows:

Customized Approach Objective:
Disk encryption implementations are configured to require independent authentication and logical access controls for decryption. 

Applicability Notes:
Disk or partition encryption implementations must also meet all other PCI DSS encryption and keymanagement requirements. 

Defined Approach Testing Procedures:

Purpose:
Disk-level encryption typically encrypts the entire disk or partition using the same key, with all data automatically decrypted when the system runs or when an authorized user requests it. Many diskencryption solutions intercept operating system read/write operations and perform the appropriate cryptographic transformations without any special action by the user other than supplying a password or passphrase at system start-up or at the beginning of a session. This provides no protection from a malicious individual that has already managed to gain access to a valid user account. 

Good Practice:
Full disk encryption helps to protect data in the event of physical loss of a disk and therefore its use is best limited only to removable electronic media storage devices. 

3.6.1
Defined Approach Requirements: 
Procedures are defined and implemented to protect cryptographic keys used to protect stored account data against disclosure and misuse that include:

Customized Approach Objective:
Processes that protect cryptographic keys used to protect stored account data against disclosure and misuse are defined and implemented. 

Applicability Notes:
This requirement applies to keys used to encrypt stored account data and to key-encrypting keys used to protect data-encrypting keys. 
The requirement to protect keys used to protect stored account data from disclosure and misuse applies to both data-encrypting keys and keyencrypting keys. Because one key-encrypting key may grant access to many data-encrypting keys, the key-encrypting keys require strong protection measures. 

Defined Approach Testing Procedures:

Purpose:
 Cryptographic keys must be strongly protected because those who obtain access will be able to decrypt data. 

Good Practice:
 Having a centralized key management system based on industry standards is recommended for managing cryptographic keys. 

Further Information:
The entity’s key management procedures will benefit through alignment with industry requirements, Sources for information on cryptographic key management life cycles include: 

3.6.1.1
Defined Approach Requirements: 
Additional requirement for service providers only: A documented description of the cryptographic architecture is maintained that includes:

Customized Approach Objective:
Accurate details of the cryptographic architecture are maintained and available. 

Applicability Notes:
This requirement applies only when the entity being assessed is a service provider. 
In cloud HSM implementations, responsibility for the cryptographic architecture according to this Requirement will be shared between the cloud provider and the cloud customer. 
The bullet above (for including, in the cryptographic architecture, that the use of the same cryptographic keys in production and test is prevented) is a best practice until 31 March 2025, after which it will be required as part of Requirement 3.6.1.1 and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
Maintaining current documentation of the cryptographic architecture enables an entity to understand the algorithms, protocols, and cryptographic keys used to protect stored account data, as well as the devices that generate, use, and protect the keys. This allows an entity to keep pace with evolving threats to its architecture and plan for updates as the assurance level provided by different algorithms and key strengths changes. Maintaining such documentation also allows an entity to detect lost or missing keys or key-management devices and identify unauthorized additions to its cryptographic architecture. 
 The use of the same cryptographic keys in both production and test environments introduces a risk of exposing the key if the test environment is not at the same security level as the production environment. 

Good Practice:
Having an automated reporting mechanism can assist with maintenance of the cryptographic attributes. 

3.6.1.2
Defined Approach Requirements: 
Secret and private keys used to encrypt/decrypt stored account data are stored in one (or more) of the following forms at all times:

Customized Approach Objective:
Secret and private keys are stored in a secure form that prevents unauthorized retrieval or access. 

Applicability Notes:
It is not required that public keys be stored in one of these forms. 
Cryptographic keys stored as part of a key management system (KMS) that employs SCDs are acceptable. 
A cryptographic key that is split into two parts does not meet this requirement. Secret or private keys stored as key components or key shares must be generated via one of the following:

OR

Defined Approach Testing Procedures:

Purpose:
Storing cryptographic keys securely prevents unauthorized or unnecessary access that could result in the exposure of stored account data. Storing keys separately means they are stored such that if the location of one key is compromised, the second key is not also compromised. 

Good Practice:
Where data-encrypting keys are stored in an HSM, the HSM interaction channel should be protected to prevent interception of encryption or decryption operations. 

3.6.1.3
Defined Approach Requirements: 
Access to cleartext cryptographic key components is restricted to the fewest number of custodians necessary. 

Customized Approach Objective:
Access to cleartext cryptographic key components is restricted to necessary personnel. 

Defined Approach Testing Procedures:

Purpose:
Restricting the number of people who have access to cleartext cryptographic key components reduces the risk of stored account data being retrieved or rendered visible by unauthorized parties. 

Good Practice:
Only personnel with defined key custodian responsibilities (creating, altering, rotating, distributing, or otherwise maintaining encryption keys) should be granted access to key components. 
Ideally this will be a very small number of people. 

3.6.1.4
Defined Approach Requirements: 
Cryptographic keys are stored in the fewest possible locations. 

Customized Approach Objective:
Cryptographic keys are retained only where necessary. 

Defined Approach Testing Procedures:

Purpose:
Storing any cryptographic keys in the fewest locations helps an organization track and monitor all key locations and minimizes the potential for keys to be exposed to unauthorized parties. 

3.7.1
Defined Approach Requirements: 
Key-management policies and procedures are implemented to include generation of strong cryptographic keys used to protect stored account data. 

Customized Approach Objective:
Strong cryptographic keys are generated. 

Defined Approach Testing Procedures:

Purpose:
 Use of strong cryptographic keys significantly increases the level of security of encrypted account data. 

3.7.2
Defined Approach Requirements: 
Key-management policies and procedures are implemented to include secure distribution of cryptographic keys used to protect stored account data. 

Customized Approach Objective:
Cryptographic keys are secured during distribution 

Defined Approach Testing Procedures:

Purpose:
Secure distribution or conveyance of secret or private cryptographic keys means that keys are distributed only to authorized custodians, as identified in Requirement 3.6.1.2, and are never distributed insecurely. 

3.7.3
Defined Approach Requirements: 
Key-management policies and procedures are implemented to include secure storage of cryptographic keys used to protect stored account data. 

Customized Approach Objective:
Cryptographic keys are secured when stored. 

Defined Approach Testing Procedures:

Purpose:
Storing keys without proper protection could provide access to attackers, resulting in the decryption and exposure of account data. 

Good Practice:
Data encryption keys can be protected by encrypting them with a key-encrypting key. Keys can be stored in a Hardware Security Module (HSM). 
Secret or private keys that can decrypt data should never be present in source code. 

3.7.4
Defined Approach Requirements: 
Key management policies and procedures are implemented for cryptographic key changes for keys that have reached the end of their cryptoperiod, as defined by the associated application vendor or key owner, and based on industry best practices and guidelines, including the following:

Customized Approach Objective:
Cryptographic keys are not used beyond their defined cryptoperiod. 

Defined Approach Testing Procedures:

Purpose:
Changing encryption keys when they reach the end of their cryptoperiod is imperative to minimize the risk of someone obtaining the encryption keys and using them to decrypt data. 

Definitions:
A cryptoperiod is the time span during which a cryptographic key can be used for its defined purpose. Cryptoperiods are often defined in terms of the period for which the key is active and/or the amount of cipher-text that has been produced by the key. Considerations for defining the cryptoperiod include, but are not limited to, the strength of the underlying algorithm, size or length of the key, risk of key compromise, and the sensitivity of the data being encrypted. 

Further Information:
NIST SP 800-57 Part 1, Revision 5, Section 5.3 Cryptoperiods - provides guidance for establishing the time span during which a specific key is authorized for use by legitimate entities, or the keys for a given system will remain in effect. See Table 1 of SP 800-57 Part 1 for suggested cryptoperiods for different key types. 

3.7.5
Defined Approach Requirements: 
Key management policies procedures are implemented to include the retirement, replacement, or destruction of keys used to protect stored account data, as deemed necessary when:

Customized Approach Objective:
Keys are removed from active use when it is suspected or known that the integrity of the key is weakened. 

Applicability Notes:
If retired or replaced cryptographic keys need to be retained, these keys must be securely archived (for example, by using a key-encryption key). 

Defined Approach Testing Procedures:

Purpose:
Keys that are no longer required, keys with weakened integrity, and keys that are known or suspected to be compromised, should be archived, revoked, and/or destroyed to ensure that the keys can no longer be used. 
If such keys need to be kept (for example, to support archived encrypted data), they should be strongly protected. 

Good Practice:
Archived cryptographic keys should be used only for decryption/verification purposes. 
The encryption solution should provide for and facilitate a process to replace keys that are due for replacement or that are known to be, or suspected of being, compromised. In addition, any keys that are known to be, or suspected of being, compromised should be managed in accordance with the entity’s incident response plan per Requirement 12.10.1. 

Further Information:
Industry best practices for archiving retired keys are outlined in NIST SP 800-57 Part 1, Revision 5, Section 8.3.1, and includes maintaining the archive with a trusted third party and storing archived key information separately from operational data. 

3.7.6
Defined Approach Requirements: 
Where manual cleartext cryptographic keymanagement operations are performed by personnel, key-management policies and procedures are implemented include managing these operations using split knowledge and dual control. 

Customized Approach Objective:
Cleartext secret or private keys cannot be known by anyone. Operations involving cleartext keys cannot be carried out by a single person. 

Applicability Notes:
This control is applicable for manual keymanagement operations or where key management is not controlled by the encryption product. A cryptographic key that is simply split into two parts does not meet this requirement. Secret or private keys stored as key components or key shares must be generated via one of the following:

Defined Approach Testing Procedures:

Purpose:
Split knowledge and dual control of keys are used to eliminate the possibility of a single person having access to the whole key and therefore being able to gain unauthorized access to the data. 

Definitions:
Split knowledge is a method in which two or more people separately have key components, where each person knows only their own key component, and the individual key components convey no knowledge of other components or of the original cryptographic key. 
Dual control requires two or more people to authenticate the use of a cryptographic key or perform a key-management function. No single person can access or use the authentication factor (for example, the password, PIN, or key) of another. 

Good Practice:
Where key components or key shares are used, procedures should ensure that no single custodian ever has access to sufficient key components or shares to reconstruct the cryptographic key. For example, in an m-of-n scheme (for example, Shamir), where only two of any three components are required to reconstruct the cryptographic key, a custodian must not have current or prior knowledge of more than one component. If a custodian was previously assigned component A, which was then reassigned, the custodian should not then be assigned component B or C, as this would give the custodian knowledge of two components and the ability to recreate the key. 

Examples:
Key-management operations that might be performed manually include, but are not limited to, key generation, transmission, loading, storage, and destruction. 

Further Information:
Industry standards for managing key components include: 

3.7.7
Defined Approach Requirements: 
Key management policies and procedures are implemented to include the prevention of unauthorized substitution of cryptographic keys. 

Customized Approach Objective:
Cryptographic keys cannot be substituted by unauthorized personnel. 

Defined Approach Testing Procedures:

Purpose:
If an attacker is able to substitute an entity’s key with a key the attacker knows, the attacker will be able to decrypt all data encrypted with that key 

Good Practice:
The encryption solution should not allow for or accept substitution of keys from unauthorized sources or unexpected processes. 
Controls should include ensuring that individuals with access to key components or shares do not have access to other components or shares that form the necessary threshold to derive the key. 

3.7.8
Defined Approach Requirements: 
Key management policies and procedures are implemented to include that cryptographic key custodians formally acknowledge (in writing or electronically) that they understand and accept their key-custodian responsibilities. 

Customized Approach Objective:
Key custodians are knowledgeable about their responsibilities in relation to cryptographic operations and can access assistance and guidance when required. 

Defined Approach Testing Procedures:

Purpose:
This process will help ensure individuals that act as key custodians commit to the key-custodian role and understand and accept the responsibilities. An annual reaffirmation can help remind key custodians of their responsibilities. 

Further Information:
Industry guidance for key custodians and their roles and responsibilities includes: 

3.7.9
Defined Approach Requirements: 
Additional requirement for service providers only: Where a service provider shares cryptographic keys with its customers for transmission or storage of account data, guidance on secure transmission, storage and updating of such keys is documented and distributed to the service provider’s customers. 

Customized Approach Objective:
Customers are provided with appropriate key management guidance whenever they receive shared cryptographic keys. 

Applicability Notes:
This requirement applies only when the entity being assessed is a service provider. 

Defined Approach Testing Procedures:

Purpose:
Providing guidance to customers on how to securely transmit, store, and update cryptographic keys can help prevent keys from being mismanaged or disclosed to unauthorized entities. 

Further Information:
Numerous industry standards for key management are cited above in the Guidance for Requirements 3.7.1-3.7.8. 

4.1.1
Defined Approach Requirements: 
All security policies and operational procedures that are identified in Requirement 4 are:

Customized Approach Objective:
Expectations, controls, and oversight for meeting activities within Requirement 4 are defined and adhered to by affected personnel. All supporting activities are repeatable, consistently applied, and conform to management’s intent. 

Defined Approach Testing Procedures:

Purpose:
Requirement 4.1.1 is about effectively managing and maintaining the various policies and procedures specified throughout Requirement 4. While it is important to define the specific policies or procedures called out in Requirement 4, it is equally important to ensure they are properly documented, maintained, and disseminated. 

Good Practice:
It is important to update policies and procedures as needed to address changes in processes, technologies, and business objectives. For this reason, consider updating these documents as soon as possible after a change occurs and not only on a periodic cycle. 

Definitions:
ecurity policies define the entity’s security objectives and principles. Operational procedures describe how to perform activities, and define the controls, methods, and processes that are followed to achieve the desired result in a consistent manner and in accordance with policy objectives. Policies and procedures, including updates, are actively communicated to all affected personnel, and are supported by operating procedures describing how to perform activities. 

4.1.2
Defined Approach Requirements: 
Roles and responsibilities for performing activities in Requirement 4 are documented, assigned, and understood. 

Customized Approach Objective:
Day-to-day responsibilities for performing all the activities in Requirement 4 are allocated. Personnel are accountable for successful, continuous operation of these requirements. 

Defined Approach Testing Procedures:

Purpose:
If roles and responsibilities are not formally assigned, personnel may not be aware of their day-to-day responsibilities and critical activities may not occur. 

Good Practice:
Roles and responsibilities may be documented within policies and procedures or maintained within separate documents. 
As part of communicating roles and responsibilities, entities can consider having personnel acknowledge their acceptance and understanding of their assigned roles and responsibilities. 

Examples:
A method to document roles and responsibilities is a responsibility assignment matrix that includes who is responsible, accountable, consulted, and informed (also called a RACI matrix). 

4.2.1
Defined Approach Requirements: 
Strong cryptography and security protocols are implemented as follows to safeguard PAN during transmission over open, public networks:

Customized Approach Objective:
Cleartext PAN cannot be read or intercepted from any transmissions over open, public networks. 

Defined Approach Testing Procedures:

Purpose:
Sensitive information must be encrypted during transmission over public networks because it is easy and common for a malicious individual to intercept and/or divert data while in transit. 

Good Practice:
The network and data-flow diagrams defined in Requirement 1 are useful resources for identifying all connection points where account data is transmitted or received over open, public networks. 
While not required, it is considered a good practice for entities to also encrypt PAN over their internal networks, and for entities to establish any new network implementations with encrypted communications. 
PAN transmissions can be protected by encrypting the data before it is transmitted, or by encrypting the session over which the data is transmitted, or both. While it is not required that strong cryptography be applied at both the data level and the session level, it is strongly recommended. If encrypted at the data level, the cryptographic keys used for protecting the data can be managed in accordance with Requirements 3.6 and 3.7. If the data is encrypted at the session level, designated key custodians should be assigned responsibility for managing transmission keys and certificates. 
Some protocol implementations (such as SSL, SSH v1.0, and early TLS) have known vulnerabilities that an attacker can use to gain access to the cleartext data. It is critical that entities maintain awareness of industry-defined deprecation dates for the cipher suites they are using and are prepared to migrate to newer versions or protocols when older ones are no longer deemed secure. 
Verifying that certificates are trusted helps ensure the integrity of the secure connection. To be considered trusted, a certificate should be issued from a trusted source, such as a trusted certificate authority (CA), and not be expired. Up-to-date Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP) can be used to validate certificates. 
Techniques to validate certificates may include certificate and public key pinning, where the trusted certificate or a public key is pinned either during development or upon its first use. Entities can also confirm with developers or review source code to ensure that clients and servers reject connections if the certificate is bad. 
For browser-based TLS certificates, certificate trust can often be verified by clicking on the lock icon that appears next to the address bar. 

Examples:
 Open, public networks include, but are not limited to: 

Further Information:
Vendor recommendations and industry best practices can be consulted for information about the proper encryption strength specific to the encryption methodology in use. 
For more information about strong cryptography and secure protocols, see industry standards and best practices such as NIST SP 800-52 and SP 800-57. 
For more information about trusted keys and certificates, see NIST Cybersecurity Practice Guide Special Publication 1800-16, Securing Web Transactions: Transport Layer Security (TLS) Server Certificate Management. 

4.2.1.1
Defined Approach Requirements: 
An inventory of the entity’s trusted keys and certificates used to protect PAN during transmission is maintained. 

Customized Approach Objective:
All keys and certificates used to protect PAN during transmission are identified and confirmed as trusted. 

Applicability Notes:
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
The inventory of trusted keys helps the entity keep track of the algorithms, protocols, key strength, key custodians, and key expiry dates. This enables the entity to respond quickly to vulnerabilities discovered in encryption software, certificates, and cryptographic algorithms. 

Good Practice:
For certificates, the inventory should include the issuing CA and certification expiration date. 

4.2.1.2
Defined Approach Requirements: 
Wireless networks transmitting PAN or connected to the CDE use industry best practices to implement strong cryptography for authentication and transmission. 

Customized Approach Objective:
Cleartext PAN cannot be read or intercepted from wireless network transmissions. 

Defined Approach Testing Procedures:

Purpose:
Since wireless networks do not require physical media to connect, it is important to establish controls limiting who can connect and what transmission protocols will be used. Malicious users use free and widely available tools to eavesdrop on wireless communications. Use of strong cryptography can help limit disclosure of sensitive information across wireless networks. 
Wireless networks present unique risks to an organization; therefore, they must be identified and protected according to industry requirements. Strong cryptography for authentication and transmission of PAN is required to prevent malicious users from gaining access to the wireless network or utilizing wireless networks to access other internal networks or data. 

Good Practice:
Wireless networks should not permit fallback or downgrade to an insecure protocol or lower encryption strength that does not meet the intent of strong cryptography. 

Further Information:
Review the vendor’s specific documentation for more details on the choice of protocols, configurations, and settings related to cryptography 

4.2.2
Defined Approach Requirements: 
PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies. 

Customized Approach Objective:
Cleartext PAN cannot be read or intercepted from transmissions using end-user messaging technologies. 

Applicability Notes:
This requirement also applies if a customer, or other third-party, requests that PAN is sent to them via end-user messaging technologies. 
There could be occurrences where an entity receives unsolicited cardholder data via an insecure communication channel that was not intended for transmissions of sensitive data. In this situation, the entity can choose to either include the channel in the scope of their CDE and secure it according to PCI DSS or delete the cardholder data and implement measures to prevent the channel from being used for cardholder data. 

Defined Approach Testing Procedures:

Purpose:
End-user messaging technologies typically can be easily intercepted by packet-sniffing during delivery across internal and public networks. 

Good Practice:
The use of end-user messaging technology to send PAN should only be considered where there is a defined business need. 

Examples:
E-mail, instant messaging, SMS, and chat are examples of the type of end-user messaging technology that this requirement refers to. 

5.1.1
Defined Approach Requirements: 
All security policies and operational procedures that are identified in Requirement 5 are:

Customized Approach Objective:
Expectations, controls, and oversight for meeting activities within Requirement 5 are defined and adhered to by affected personnel. All supporting activities are repeatable, consistently applied, and conform to management’s intent. 

Defined Approach Testing Procedures:

Purpose:
Requirement 5.1.1 is about effectively managing and maintaining the various policies and procedures specified throughout Requirement 5. While it is important to define the specific policies or procedures called out in Requirement 5, it is equally important to ensure they are properly documented, maintained, and disseminated. 

Good Practice:
It is important to update policies and procedures as needed to address changes in processes, technologies, and business objectives. For this reason, consider updating these documents as soon as possible after a change occurs and not only on a periodic cycle. 

Definitions:
Security policies define the entity’s security objectives and principles. Operational procedures describe how to perform activities, and define the controls, methods, and processes that are followed to achieve the desired result in a consistent manner and in accordance with policy objectives. 

5.1.2
Defined Approach Requirements: 
Roles and responsibilities for performing activities in Requirement 5 are documented, assigned, and understood. 

Customized Approach Objective:
Day-to-day responsibilities for performing all the activities in Requirement 5 are allocated. Personnel are accountable for successful, continuous operation of these requirements. 

Defined Approach Testing Procedures:

Purpose:
If roles and responsibilities are not formally assigned, networks and systems may not be properly protected from malware. 

Good Practice:
Roles and responsibilities may be documented within policies and procedures or maintained within separate documents. 
As part of communicating roles and responsibilities, entities can consider having personnel acknowledge their acceptance and understanding of their assigned roles and responsibilities. 

Examples:
A method to document roles and responsibilities is a responsibility assignment matrix that includes who is responsible, accountable, consulted, and informed (also called a RACI matrix). 

5.2.1
Defined Approach Requirements: 
An anti-malware solution(s) is deployed on all system components, except for those system components identified in periodic evaluations per Requirement 5.2.3 that concludes the system components are not at risk from malware. 

Customized Approach Objective:
Automated mechanisms are implemented to prevent systems from becoming an attack vector for malware. 

Defined Approach Testing Procedures:

Purpose:
There is a constant stream of attacks targeting newly discovered vulnerabilities in systems previously regarded as secure. Without an antimalware solution that is updated regularly, new forms of malware can be used to attack systems, disable a network, or compromise data. 

Good Practice:
It is beneficial for entities to be aware of "zeroday" attacks (those that exploit a previously unknown vulnerability) and consider solutions that focus on behavioral characteristics and will alert and react to unexpected behavior. 

Definitions:
System components known to be affected by malware have active malware exploits available in the real world (not only theoretical exploits) 

5.2.2
Defined Approach Requirements: 
The deployed anti-malware solution(s):

Customized Approach Objective:
Malware cannot execute or infect other system components. 

Defined Approach Testing Procedures:

Purpose:
 It is important to protect against all types and forms of malware to prevent unauthorized access. 

Good Practice:
Anti-malware solutions may include a combination of network-based controls, host-based controls, and endpoint security solutions. In addition to signature-based tools, capabilities used by modern anti-malware solutions include sandboxing, privilege escalation controls, and machine learning. 
Solution techniques include preventing malware from getting into the network and removing or containing malware that does get into the network. 

Examples:
Types of malware include, but are not limited to, viruses, Trojans, worms, spyware, ransomware, keyloggers, rootkits, malicious code, scripts, and links. 

5.2.3
Defined Approach Requirements: 
Any system components that are not at risk for malware are evaluated periodically to include the following:

Customized Approach Objective:
The entity maintains awareness of evolving malware threats to ensure that any systems not protected from malware are not at risk of infection. 

Applicability Notes:
System components covered by this requirement are those for which there is no anti-malware solution deployed per Requirement 5.2.1. 

Defined Approach Testing Procedures:

Purpose:
Certain systems, at a given point in time, may not currently be commonly targeted or affected by malware. However, industry trends for malware can change quickly, so it is important for organizations to be aware of new malware that might affect their systems—for example, by monitoring vendor security notices and antimalware forums to determine whether its systems might be coming under threat from new and evolving malware. 

Good Practice:
If an entity determines that a particular system is not susceptible to any malware, the determination should be supported by industry evidence, vendor resources, and best practices. 
The following steps can help entities during their periodic evaluations: 

 Trends in malware should be included in the identification of new security vulnerabilities at Requirement 6.3.1, and methods to address new trends should be incorporated into the entity’s configuration standards and protection mechanisms as needed. 

5.2.3.1
Defined Approach Requirements: 
The frequency of periodic evaluations of system components identified as not at risk for malware is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1. 

Customized Approach Objective:
Systems not known to be at risk from malware are re-evaluated at a frequency that addresses the entity’s risk. 

Applicability Notes:
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
Entities determine the optimum period to undertake the evaluation based on criteria such as the complexity of each entity’s environment and the number of types of systems that are required to be evaluated. 

5.3.1
Defined Approach Requirements: 
The anti-malware solution(s) is kept current via automatic updates. 

Customized Approach Objective:
Anti-malware mechanisms can detect and address the latest malware threats. 

Defined Approach Testing Procedures:

Purpose:
For an anti-malware solution to remain effective, it needs to have the latest security updates, signatures, threat analysis engines, and any other malware protections on which the solution relies. 
Having an automated update process avoids burdening end users with responsibility for manually installing updates and provides greater assurance that anti-malware protection mechanisms are updated as quickly as possible after an update is released. 

Good Practice:
Anti-malware mechanisms should be updated via a trusted source as soon as possible after an update is available. Using a trusted common source to distribute updates to end-user systems helps ensure the integrity and consistency of the solution architecture. 
Updates may be automatically downloaded to a central location—for example, to allow for testing—prior to being deployed to individual system components. 

5.3.2
Defined Approach Requirements: 
The anti-malware solution(s):

OR

Customized Approach Objective:
Malware cannot complete execution. 

Defined Approach Testing Procedures:

Purpose:
Periodic scans can identify malware that is present, but currently inactive, within the environment. Some malware, such as zero-day malware, can enter an environment before the scan solution is capable of detecting it. Performing regular periodic scans or continuous behavioral analysis of systems or processes helps ensure that previously undetectable malware can be identified, removed, and investigated to determine how it gained access to the environment. 

Good Practice:
Using a combination of periodic scans (scheduled and on-demand) and active, real-time (on-access) scanning helps ensure that malware residing in both static and dynamic elements of the CDE is addressed. Users should also be able to run ondemand scans on their systems if suspicious activity is detected – this can be useful in the early detection of malware. 
Scans should include the entire file system, including all disks, memory, and start-up files and boot records (at system restart) to detect all malware upon file execution, including any software that may be resident on a system but not currently active. Scan scope should include all systems and software in the CDE, including those that are often overlooked such as email servers, web browsers, and instant messaging software. 

Definitions:
Active, or real-time, scanning checks files for malware upon any attempt to open, close, rename, or otherwise interact with a file, preventing the malware from being activated. 

5.3.2.1
Defined Approach Requirements: 
If periodic malware scans are performed to meet Requirement 5.3.2, the frequency of scans is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1. 

Customized Approach Objective:
Scans by the malware solution are performed at a frequency that addresses the entity’s risk. 

Applicability Notes:
This requirement applies to entities conducting periodic malware scans to meet Requirement 5.3.2. 
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
Entities can determine the optimum period to undertake periodic scans based on their own assessment of the risks posed to their environments. 

5.3.3
Defined Approach Requirements: 
For removable electronic media, the antimalware solution(s):

Customized Approach Objective:
Malware cannot be introduced to system components via external removable media. 

Applicability Notes:
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
Portable media devices are often overlooked as an entry method for malware. Attackers will often pre-load malware onto portable devices such as USB and flash drives; connecting an infected device to a computer then triggers the malware, introducing new threats within the environment. 

5.3.4
Defined Approach Requirements: 
Audit logs for the anti-malware solution(s) are enabled and retained in accordance with Requirement 10.5.1. 

Customized Approach Objective:
Historical records of anti-malware actions are immediately available and retained for at least 12 months. 

Defined Approach Testing Procedures:

Purpose:
It is important to track the effectiveness of the anti-malware mechanisms—for example, by confirming that updates and scans are being performed as expected, and that malware is identified and addressed. Audit logs also allow an entity to determine how malware entered the environment and track its activity when inside the entity’s network. 

5.3.5
Defined Approach Requirements: 
Anti-malware mechanisms cannot be disabled or altered by users, unless specifically documented, and authorized by management on a case-by-case basis for a limited time period. 

Customized Approach Objective:
Anti-malware mechanisms cannot be modified by unauthorized personnel. 

Applicability Notes:
Anti-malware solutions may be temporarily disabled only if there is a legitimate technical need, as authorized by management on a case-by-case basis. If anti-malware protection needs to be disabled for a specific purpose, it must be formally authorized. Additional security measures may also need to be implemented for the period during which anti-malware protection is not active. 

Defined Approach Testing Procedures:

Purpose:
It is important that defensive mechanisms are always running so that malware is detected in real time. Ad-hoc starting and stopping of antimalware solutions could allow malware to propagate unchecked and undetected. 

Good Practice:
Where there is a legitimate need to temporarily disable a system’s anti-malware protection—for example, to support a specific maintenance activity or investigation of a technical problem— the reason for taking such action should be understood and approved by an appropriate management representative. Any disabling or altering of anti-malware mechanisms, including on administrators’ own devices, should be performed by authorized personnel. It is recognized that administrators have privileges that may allow them to disable anti-malware on their own computers, but there should be alerting mechanisms in place when such software is disabled and then follow up that occurs to ensure correct processes were followed. 

Examples:
Additional security measures that may need to be implemented for the period during which antimalware protection is not active include disconnecting the unprotected system from the Internet while the anti-malware protection is disabled and running a full scan once it is reenabled. 

5.4.1
Defined Approach Requirements: 
Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks. 

Customized Approach Objective:
Mechanisms are in place to protect against and mitigate risk posed by phishing attacks. 

Applicability Notes:
This requirement applies to the automated mechanism. It is not intended that the systems and services providing such automated mechanisms (such as email servers) are brought into scope for PCI DSS. 
The focus of this requirement is on protecting personnel with access to system components inscope for PCI DSS. 
Meeting this requirement for technical and automated controls to detect and protect personnel against phishing is not the same as Requirement 12.6.3.1 for security awareness training. Meeting this requirement does not also meet the requirement for providing personnel with security awareness training, and vice versa. 
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
Technical controls can limit the number of occasions personnel have to evaluate the veracity of a communication and can also limit the effects of individual responses to phishing. 

Good Practice:
When developing anti-phishing controls, entities are encouraged to consider a combination of approaches. For example, using anti-spoofing controls such as Domain-based Message Authentication, Reporting & Conformance (DMARC), Sender Policy Framework (SPF), and Domain Keys Identified Mail (DKIM) will help stop phishers from spoofing the entity’s domain and impersonating personnel. 
The deployment of technologies for blocking phishing emails and malware before they reach personnel, such as link scrubbers and server-side anti-malware, can reduce incidents and decrease the time required by personnel to check and report phishing attacks. Additionally, training personnel to recognize and report phishing emails can allow similar emails to be identified and permit them to be removed before being opened. It is recommended (but not required) that antiphishing controls are applied across an entity’s entire organization. 

Definitions 
Phishing is a form of social engineering and describes the different methods used by attackers to trick personnel into disclosing sensitive information, such as user account names and passwords, and account data. Attackers will typically disguise themselves and attempt to appear as a genuine or trusted source, directing personnel to send an email response, click on a web link, or enter data into a compromised website. Mechanisms that can detect and prevent phishing attempts are often included in antimalware solutions.

Further Information:
See the following for more information about phishing: 

6.1.1
Defined Approach Requirements: 
All security policies and operational procedures that are identified in Requirement 6 are:

Customized Approach Objective:
Expectations, controls, and oversight for meeting activities within Requirement 6 are defined and adhered to by affected personnel. All supporting activities are repeatable, consistently applied, and conform to management’s intent. 

Defined Approach Testing Procedures:

Purpose:
Purpose Requirement 6.1.1 is about effectively managing and maintaining the various policies and procedures specified throughout Requirement 6. While it is important to define the specific policies or procedures called out in Requirement 6, it is equally important to ensure they are properly documented, maintained, and disseminated. 

Good Practice:
It is important to update policies and procedures as needed to address changes in processes, technologies, and business objectives. For this reason, consider updating these documents as soon as possible after a change occurs and not only on a periodic cycle. 

Definitions:
Security policies define the entity’s security objectives and principles. Operational procedures describe how to perform activities, and define the controls, methods, and processes that are followed to achieve the desired result in a consistent manner and in accordance with policy objectives. 

6.1.2
Defined Approach Requirements: 
Roles and responsibilities for performing activities in Requirement 6 are documented, assigned, and understood. 

Customized Approach Objective:
Day-to-day responsibilities for performing all the activities in Requirement 6 are allocated. Personnel are accountable for successful, continuous operation of these requirements. 

Defined Approach Testing Procedures:

Purpose:
If roles and responsibilities are not formally assigned, systems will not be securely maintained, and their security level will be reduced. 

Good Practice:
Roles and responsibilities may be documented within policies and procedures or maintained within separate documents. 
As part of communicating roles and responsibilities, entities can consider having personnel acknowledge their acceptance and understanding of their assigned roles and responsibilities. 

Examples:
A method to document roles and responsibilities is a responsibility assignment matrix that includes who is responsible, accountable, consulted, and informed (also called a RACI matrix). 

6.2.1
Defined Approach Requirements: 
Bespoke and custom software are developed securely, as follows:

Customized Approach Objective:
Bespoke and custom software is developed in accordance with PCI DSS and secure development processes throughout the software lifecycle. 

Applicability Notes:
This applies to all software developed for or by the entity for the entity’s own use. This includes both bespoke and custom software. This does not apply to third-party software. 

Defined Approach Testing Procedures:

Purpose:
Without the inclusion of security during the requirements definition, design, analysis, and testing phases of software development, security vulnerabilities can be inadvertently or maliciously introduced into the production environment. 

Good Practice:
Understanding how sensitive data is handled by the application—including when stored, transmitted, and in memory—can help identify where data needs to be protected. 
PCI DSS requirements must be considered when developing software to meet those requirements by design, rather than trying to retrofit the software later. 

Examples:
Secure software lifecycle management methodologies and frameworks include PCI Software Security Framework, BSIMM, OPENSAMM, and works from NIST, ISO, and SAFECode. 

6.2.2
Defined Approach Requirements: 
Software development personnel working on bespoke and custom software are trained at least once every 12 months as follows:

Customized Approach Objective:
Software development personnel remain knowledgeable about secure development practices; software security; and attacks against the languages, frameworks, or applications they develop. Personnel are able to access assistance and guidance when required. 

Defined Approach Testing Procedures:

Purpose:
Having staff knowledgeable in secure coding methods, including techniques defined in Requirement 6.2.4, will help minimize the number of security vulnerabilities introduced through poor coding practices. 

Good Practice:
Training for developers may be provided in-house or by third parties. 
Training should include, but is not limited to, development languages in use, secure software design, secure coding techniques, use of techniques/methods for finding vulnerabilities in code, processes to prevent reintroducing previously resolved vulnerabilities, and how to use any automated security testing tools for detecting vulnerabilities in software. 
As industry-accepted secure coding practices change, organizational coding practices and developer training may need to be updated to address new threats. 

6.2.3
Defined Approach Requirements: 
Bespoke and custom software is reviewed prior to being released into production or to customers, to identify and correct potential coding vulnerabilities, as follows: 

Customized Approach Objective:
Bespoke and custom software cannot be exploited via coding vulnerabilities. 

Applicability Notes:
This requirement for code reviews applies to all bespoke and custom software (both internal and public-facing), as part of the system development lifecycle. Public-facing web applications are also subject to additional controls, to address ongoing threats and vulnerabilities after implementation, as defined at PCI DSS Requirement 6.4. Code reviews may be performed using either manual or automated processes, or a combination of both. 

Defined Approach Testing Procedures:

Purpose:
Security vulnerabilities in bespoke and custom software are commonly exploited by malicious individuals to gain access to a network and compromise account data. 
Vulnerable code is far more difficult and expensive to address after it has been deployed or released into production environments. Requiring a formal review and signoff by management prior to release helps to ensure that code is approved and has been developed in accordance with policies and procedures. 

Good Practice:
The following items should be considered for inclusion in code reviews:

6.2.3.1
Defined Approach Requirements: 
If manual code reviews are performed for bespoke and custom software prior to release to production, code changes are: 

Customized Approach Objective:
The manual code review process cannot be bypassed and is effective at discovering security vulnerabilities. 

Applicability Notes:
Manual code reviews can be conducted by knowledgeable internal personnel or knowledgeable third-party personnel. 
An individual that has been formally granted accountability for release control and who is neither the original code author nor the code reviewer fulfills the criteria of being management. 

Defined Approach Testing Procedures:

Purpose:
Having code reviewed by someone other than the original author, who is both experienced in code reviews and knowledgeable about secure coding practices, minimizes the possibility that code containing security or logic errors that could affect the security of cardholder data is released into a production environment. Requiring management approval that the code was reviewed limits the ability for the process to be bypassed. 

Good Practice:
Having a formal review methodology and review checklists has been found to improve the quality of the code review process. 
Code review is a tiring process, and for this reason, it is most effective when reviewers only review small amounts of code at a time. 
To maintain the effectiveness of code reviews, it is beneficial to monitor the general workload of reviewers and to have them review applications they are familiar with. 
Code reviews may be performed using either manual or automated processes, or a combination of both. 
Entitles that rely solely on manual code review should ensure that reviewers maintain their skills through regular training as new vulnerabilities are found, and new secure coding methods are recommended. 

Further Information:
See the OWASP Code Review Guide. 

6.2.4
Defined Approach Requirements: 
Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to the following:

Customized Approach Objective:
Bespoke and custom software cannot be exploited via common attacks and related vulnerabilities. 

Applicability Notes:
This applies to all software developed for or by the entity for the entity’s own use. This includes both bespoke and custom sof 

Defined Approach Testing Procedures:

Purpose:
Detecting or preventing common errors that result in vulnerable code as early as possible in the software development process lowers the probability that such errors make it through to production and lead to a compromise. Having formal engineering techniques and tools embedded in the development process will catch these errors early. This philosophy is sometimes called “shifting security left.” 

Good Practice:
For both bespoke and custom software, the entity must ensure that code is developed focusing on the prevention or mitigation of common software attacks, including: 

Researching and documenting software engineering techniques or other methods helps to define how software developers prevent or mitigate various software attacks by features or countermeasures they build into software. This might include identification/authentication mechanisms, access control, input validation routines, etc. Developers should be familiar with different types of vulnerabilities and potential attacks and use measures to avoid potential attack vectors when developing code. 

Examples:
Techniques include automated processes and practices that scan code early in the development cycle when code is checked in to confirm the vulnerabilities are not present. 

6.3.1
Defined Approach Requirements: 
Security vulnerabilities are identified and managed as follows:

Customized Approach Objective:
New system and software vulnerabilities that may impact the security of account data or the CDE are monitored, cataloged, and risk assessed. 

Applicability Notes:
This requirement is not achieved by, nor is it the same as, vulnerability scans performed for Requirements 11.3.1 and 11.3.2. This requirement is for a process to actively monitor industry sources for vulnerability information and for the entity to determine the risk ranking to be associated with each vulnerability. 

Defined Approach Testing Procedures:

Purpose:
Classifying the risks (for example, as critical, high, medium, or low) allows organizations to identify, prioritize, and address the highest risk items more quickly and reduce the likelihood that vulnerabilities posing the greatest risk will be exploited 

Good Practice:
Methods for evaluating vulnerabilities and assigning risk ratings will vary based on an organization’s environment and risk-assessment strategy. 
When an entity is assigning its risk rankings, it should consider using a formal, objective, justifiable methodology that accurately portrays the risks of the vulnerabilities pertinent to the organization and translates to an appropriate entity-assigned priority for resolution. 
An organization’s processes for managing vulnerabilities should be integrated with other management processes—for example, risk management, change management, patch management, incident response, application security, as well as proper monitoring and logging of these processes. This will help to ensure all vulnerabilities are properly identified and addressed. Processes should support ongoing evaluation of vulnerabilities. For example, a vulnerability initially identified as low risk could become a higher risk later. Additionally, vulnerabilities, individually considered to be low or medium risk, could collectively pose a high or critical risk if present on the same system, or if exploited on a low-risk system that could result in access to the CDE. 

Examples:
Some organizations that issue alerts to advise entities about urgent vulnerabilities requiring immediate patches/updates are national Computer Emergency Readiness/Response Teams (CERTs) and vendors. 
Criteria for ranking vulnerabilities may include criticality of a vulnerability identified in an alert from Forum of Incident Response and Security Teams (FIRST) or a CERT, consideration of the CVSS score, the classification by the vendor, and/or type of systems affected. 

Further Information:
Trustworthy sources for vulnerability information include vendor websites, industry newsgroups, mailing lists, etc. If software is developed inhouse, the internal development team should also consider sources of information about new vulnerabilities that may affect internally developed applications. Other methods to ensure new vulnerabilities are identified include solutions that automatically recognize and alert upon detection of unusual behavior. Processes should account for widely published exploits as well as “zero-day” attacks, which target previously unknown vulnerabilities. 
For bespoke and custom software, the organization may obtain information about libraries, frameworks, compilers, programming languages, etc. from public trusted sources (for example, special resources and resources from component developers). The organization may also independently analyze third-party components and identify vulnerabilities. 
For control over in-house developed software, the organization may receive such information from external sources. The organization can consider using a “bug bounty” program where it posts information (for example, on its website) so third parties can contact the organization with vulnerability information. External sources may include independent investigators or companies that report to the organization about identified vulnerabilities and may include sources such as the Common Vulnerability Scoring System (CVSS) or the OWASP Risk Rating Methodology 

6.3.2
Defined Approach Requirements: 
An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management. 

Customized Approach Objective:
Known vulnerabilities in third-party software components cannot be exploited in bespoke and custom software. 

Applicability Notes:
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
Identifying and listing all the entity’s bespoke and custom software, and any third-party software that is incorporated into the entity’s bespoke and custom software enables the entity to manage vulnerabilities and patches. 
Vulnerabilities in third-party components (including libraries, APIs, etc.) embedded in an entity’s software also renders those applications vulnerable to attacks. Knowing which third-party components are used in the entity’s software and monitoring the availability of security patches to address known vulnerabilities is critical to ensuring the security of the software. 

Good Practice:
An entity’s inventory should cover all payment software components and dependencies, including supported execution platforms or environments, third-party libraries, services, and other required functionalities. 
There are many different types of solutions that can help with managing software inventories, such as software composition analysis tools, application discovery tools, and mobile device management. 

6.3.3
Defined Approach Requirements: 
All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows:

Customized Approach Objective:
System components cannot be compromised via the exploitation of a known vulnerability. 

Defined Approach Testing Procedures:

Purpose:
New exploits are constantly being discovered, and these can permit attacks against systems that have previously been considered secure. If the most recent security patches/updates are not implemented on critical systems as soon as possible, a malicious actor can use these exploits to attack or disable a system or gain access to sensitive data. 

Good Practice:
Prioritizing security patches/updates for critical infrastructure ensures that high-priority systems and devices are protected from vulnerabilities as soon as possible after a patch is released. 
An entity’s patching cadence should factor in any re-evaluation of vulnerabilities and subsequent changes in the criticality of a vulnerability per Requirement 6.3.1. For example, a vulnerability initially identified as low risk could become a higher risk later. Additionally, vulnerabilities individually considered to be low or medium risk could collectively pose a high or critical risk if present on the same system, or if exploited on a low-risk system that could result in access to the CDE. 

6.4.1
Defined Approach Requirements: 
For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks as follows: 

OR 

Customized Approach Objective:
Public-facing web applications are protected against malicious attacks. 

Applicability Notes:
This assessment is not the same as the vulnerability scans performed for Requirement 11.3.1 and 11.3.2. 
This requirement will be superseded by Requirement 6.4.2 after 31 March 2025 when Requirement 6.4.2 becomes effective. 

Defined Approach Testing Procedures:

Purpose:
Public-facing web applications are those that are available to the public (not only for internal use). These applications are primary targets for attackers, and poorly coded web applications provide an easy path for attackers to gain access to sensitive data and systems. 

Good Practice:
Manual or automated vulnerability security assessment tools or methods review and/or test the application for vulnerabilities. 
Common assessment tools include specialized web scanners that perform automatic analysis of web application protection. 
When using automated technical solutions, it is important to include processes that facilitate timely responses to alerts generated by the solutions so that any detected attacks can be mitigated. 

Examples:
A web application firewall (WAF) installed in front of public-facing web applications to check all traffic is an example of an automated technical solution that detects and prevents web-based attacks (for example, the attacks included in Requirement 6.2.4). WAFs filter and block nonessential traffic at the application layer. A properly configured WAF helps to prevent application-layer attacks on applications that are improperly coded or configured. 
Another example of an automated technical solution is Runtime Application Self-Protection (RASP) technologies. When implemented correctly, RASP solutions can detect and block anomalous behavior by the software during execution. While WAFs typically monitor the application perimeter, RASP solutions monitor and block behavior within the application. 

6.4.2
Defined Approach Requirements: 
For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks, with at least the following:

Customized Approach Objective:
Public-facing web applications are protected in real time against malicious attacks. 

Applicability Notes:
This new requirement will replace Requirement 6.4.1 once its effective date is reached. 
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
Public-facing web applications are primary targets for attackers, and poorly coded web applications provide an easy path for attackers to gain access to sensitive data and systems. 

Good Practice:
When using automated technical solutions, it is important to include processes that facilitate timely responses to alerts generated by the solutions so that any detected attacks can be mitigated. Such solutions may also be used to automate mitigation, for example rate-limiting controls, which can be implemented to mitigate against brute-force attacks and enumeration attacks. 

Examples:
A web application firewall (WAF), which can be either on-premise or cloud-based, installed in front of public-facing web applications to check all traffic, is an example of an automated technical solution that detects and prevents web-based attacks (for example, the attacks included in Requirement 6.2.4). WAFs filter and block nonessential traffic at the application layer. A properly configured WAF helps to prevent application-layer attacks on applications that are improperly coded or configured. 

6.4.3
Defined Approach Requirements: 
All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows:

Customized Approach Objective:
Unauthorized code cannot be present in the payment page as it is rendered in the consumer’s browser. 

Applicability Notes:
This requirement applies to all scripts loaded from the entity’s environment and scripts loaded from third and fourth parties. 
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
Scripts loaded and executed in the payment page can have their functionality altered without the entity’s knowledge and can also have the functionality to load additional external scripts (for example, advertising and tracking, tag management systems). 
Such seemingly harmless scripts can be used by potential attackers to upload malicious scripts that can read and exfiltrate cardholder data from the consumer browser. 
Ensuring that the functionality of all such scripts is understood to be necessary for the operation of the payment page minimizes the number of scripts that could be tampered with. 
Ensuring that scripts have been explicitly authorized reduces the probability of unnecessary scripts being added to the payment page without appropriate management approval. 
Using techniques to prevent tampering with the script will minimize the probability of the script being modified to carry out unauthorized behavior, such as skimming the cardholder data from the payment page. 

Good Practice:
Scripts may be authorized by manual or automated (e.g., workflow) processes. 
Where the payment page will be loaded into an inline frame (IFRAME), restricting the location that the payment page can be loaded from, using the parent page’s Content Security Policy (CSP) can help prevent unauthorized content being substituted for the payment page. 

Definitions:
“Necessary” for this requirement means that the entity’s review of each script justifies and confirms why it is needed for the functionality of the payment page to accept a payment transaction 

Examples:
The integrity of scripts can be enforced by several different mechanisms including, but not limited to:

6.5.1
Defined Approach Requirements: 
Changes to all system components in the production environment are made according to established procedures that include: 

Customized Approach Objective:
All changes are tracked, authorized, and evaluated for impact and security, and changes are managed to avoid unintended effects to the security of system components. 

Defined Approach Testing Procedures:

Purpose:
Change management procedures must be applied to all changes—including the addition, removal, or modification of any system component—in the production environment. It is important to document the reason for a change and the change description so that relevant parties understand and agree the change is needed. Likewise, documenting the impacts of the change allows all affected parties to plan appropriately for any processing changes. 

Good Practice:
Approval by authorized parties confirms that the change is legitimate and that the change is sanctioned by the organization. Changes should be approved by individuals with the appropriate authority and knowledge to understand the impact of the change. 
Thorough testing by the entity confirms that the security of the environment is not reduced by implementing a change and that all existing security controls either remain in place or are replaced with equal or stronger security controls after the change. The specific testing to be performed will vary according to the type of change and system component(s) affected.
For each change, it is important to have documented procedures that address any failures and provide instructions on how to return to a secure state in case the change fails or adversely affects the security of an application or system. These procedures will allow the application or system to be restored to its previous secure state. 

6.5.2
Defined Approach Requirements: 
Upon completion of a significant change, all applicable PCI DSS requirements are confirmed to be in place on all new or changed systems and networks, and documentation is updated as applicable. 

Customized Approach Objective:
All system components are verified after a significant change to be compliant with the applicable PCI DSS requirements. 

Applicability Notes:
These significant changes should also be captured and reflected in the entity’s annual PCI DSS scope confirmation activity per Requirement 12.5.2. 

Defined Approach Testing Procedures:

Purpose:
Having processes to analyze significant changes helps ensure that all appropriate PCI DSS controls are applied to any systems or networks added or changed within the in-scope environment, and that PCI DSS requirements continue to be met to secure the environment. 

Good Practice:
Building this validation into change management processes helps ensure that device inventories and configuration standards are kept up to date and security controls are applied where needed. 

Examples:
Applicable PCI DSS requirements that could be impacted include, but are not limited to:

6.5.3
Defined Approach Requirements: 
Pre-production environments are separated from production environments and the separation is enforced with access controls. 

Customized Approach Objective:
Pre-production environments cannot introduce risks and vulnerabilities into production environments. 

Defined Approach Testing Procedures:

Purpose:
Purpose Due to the constantly changing state of preproduction environments, they are often less secure than the production environment. 

Good Practice:
Organizations must clearly understand which environments are test environments or development environments and how these environments interact on the level of networks and applications. 

Definitions:
Pre-production environments include development, testing, user acceptance testing (UAT), etc. Even where production infrastructure is used to facilitate testing or development, production environments still need to be separated (logically or physically) from preproduction functionality such that vulnerabilities introduced as a result of pre-production activities do not adversely affect production systems. 

6.5.4
Defined Approach Requirements: 
Roles and functions are separated between production and pre-production environments to provide accountability such that only reviewed and approved changes are deployed. 

Customized Approach Objective:
Job roles and accountability that differentiate between pre-production and production activities are defined and managed to minimize the risk of unauthorized, unintentional, or inappropriate actions. 

Applicability Notes:
In environments with limited personnel where individuals perform multiple roles or functions, this same goal can be achieved with additional procedural controls that provide accountability. For example, a developer may also be an administrator that uses an administrator-level account with elevated privileges in the development environment and, for their developer role, they use a separate account with user-level access to the production environment. 

Defined Approach Testing Procedures:

Purpose:
The goal of separating roles and functions between production and pre-production environments is to reduce the number of personnel with access to the production environment and account data and thereby minimize risk of unauthorized, unintentional, or inappropriate access to data and system components and help ensure that access is limited to those individuals with a business need for such access. 
The intent of this control is to separate critical activities to provide oversight and review to catch errors and minimize the chances of fraud or theft (since two people would need to collude in order to hide an activity). 
Separating roles and functions, also referred to as separation or segregation of duties, is a key internal control concept to protect an entity’s assets. 

6.5.5
Defined Approach Requirements: 
Live PANs are not used in pre-production environments, except where those environments are included in the CDE and protected in accordance with all applicable PCI DSS requirements. 

Customized Approach Objective:
Live PANs cannot be present in pre-production environments outside the CDE. 

Defined Approach Testing Procedures:

Purpose:
Use of live PANs outside of protected CDEs provides malicious individuals with the opportunity to gain unauthorized access to cardholder data. 

Good Practice:
Entities can minimize their storage of live PANs by only storing them in pre-production when strictly necessary for a specific and defined testing purpose and securely deleting that data after use. 
If an entity requires PANs specifically designed for test purposes, these can be obtained from acquirers. 

Definitions:
Live PANs refer to valid PANs (not test PANs) that have the potential to be used to conduct payment transactions. Additionally, when payment cards expire, the same PAN is often reused with a different expiry date. All PANs must be verified as being unable to conduct payment transactions before they are excluded from PCI DSS scope. It is the responsibility of the entity to confirm that PANs are not live. 

6.5.6
Defined Approach Requirements: 
Test data and test accounts are removed from system components before the system goes into production. 

Customized Approach Objective:
Test data and test accounts cannot exist in production environments. 

Defined Approach Testing Procedures:

Purpose:
This data may give away information about the functioning of an application or system and is an easy target for unauthorized individuals to exploit to gain access to systems. Possession of such information could facilitate compromise of the system and related account data. 

7.1.1
Defined Approach Requirements: 
All security policies and operational procedures that are identified in Requirement 7 are:

Customized Approach Objective:
Expectations, controls, and oversight for meeting activities within Requirement 7 are defined and adhered to by affected personnel. All supporting activities are repeatable, consistently applied, and conform to management’s intent. 

Defined Approach Testing Procedures:

Purpose:
Requirement 7.1.1 is about effectively managing and maintaining the various policies and procedures specified throughout Requirement 7. While it is important to define the specific policies or procedures called out in Requirement 7, it is equally important to ensure they are properly documented, maintained, and disseminated. 

Good Practice:
It is important to update policies and procedures as needed to address changes in processes, technologies, and business objectives. For this reason, consider updating these documents as soon as possible after a change occurs and not only on a periodic cycle. 

Definitions:
Security policies define the entity’s security objectives and principles. Operational procedures describe how to perform activities, and define the controls, methods, and processes that are followed to achieve the desired result in a consistent manner and in accordance with policy objectives. 

7.1.2
Defined Approach Requirements: 
Roles and responsibilities for performing activities in Requirement 7 are documented, assigned, and understood. 

Customized Approach Objective:
Day-to-day responsibilities for performing all the activities in Requirement 7 are allocated. Personnel are accountable for successful, continuous operation of these requirements. 

Defined Approach Testing Procedures:

Purpose:
If roles and responsibilities are not formally assigned, personnel may not be aware of their day-to-day responsibilities, and critical activities may not occur. 

Good Practice:
Roles and responsibilities may be documented within policies and procedures or maintained within separate documents. 
As part of communicating roles and responsibilities, entities can consider having personnel acknowledge their acceptance and understanding of their assigned roles and responsibilities. 

Examples:
A method to document roles and responsibilities is a responsibility assignment matrix that includes who is responsible, accountable, consulted, and informed (also called a RACI matrix). 

7.2.1
Defined Approach Requirements: 
An access control model is defined and includes granting access as follows: 

Customized Approach Objective:
Access requirements are established according to job functions following least-privilege and need-toknow principles 

Defined Approach Testing Procedures:

Purpose:
Defining an access control model that is appropriate for the entity’s technology and access control philosophy supports a consistent and uniform way of allocating access and reduces the possibility of errors such as the granting of excessive rights. 

Good Practice:
A factor to consider when defining access needs is the separation of duties principle. This principle is intended to prevent fraud and misuse or theft of resources. For example, 1) dividing missioncritical functions and information system support functions among different individuals and/or functions, 2) establishing roles such that information system support activities are performed by different functions/individuals (for example, system management, programming, configuration management, quality assurance and testing, and network security), and 3) ensuring security personnel administering access control functions do not also administer audit functions. 
In environments where one individual performs multiple functions, such as administration and security operations, duties may be assigned so that no single individual has end-to-end control of a process without an independent checkpoint. For example, responsibility for configuration and responsibility for approving changes could be assigned to separate individuals. 

Definitions:
Key elements of an access control model include:

Once job functions, resources, and activities per job functions are defined, individuals can be granted access accordingly. 

Examples:
Access control models that entities can consider include role-based access control (RBAC) and attribute-based access control (ABAC). The access control model used by a given entity depends on their business and access needs. 

7.2.2
Defined Approach Requirements: 
Access is assigned to users, including privileged users, based on: 

Customized Approach Objective:
Access to systems and data is limited to only the access needed to perform job functions, as defined in the related access roles. 

Defined Approach Testing Procedures:

Purpose:
Assigning least privileges helps prevent users without sufficient knowledge about the application from incorrectly or accidentally changing application configuration or altering its security settings. Enforcing least privilege also helps to minimize the scope of damage if an unauthorized person gains access to a user ID. 

Good Practice:
Access rights are granted to a user by assignment to one or several functions. Assess is assigned depending on the specific user functions and with the minimum scope required for the job. 
When assigning privileged access, it is important to assign individuals only the privileges they need to perform their job (the “least privileges”). For example, the database administrator or backup administrator should not be assigned the same privileges as the overall systems administrator. 
Once needs are defined for user functions (per PCI DSS requirement 7.2.1), it is easy to grant individuals access according to their job classification and function by using the alreadycreated roles. 
Entities may wish to consider use of Privileged Access Management (PAM), which is a method to grant access to privileged accounts only when those privileges are required, immediately revoking that access once they are no longer needed. 

7.2.3
Defined Approach Requirements: 
Required privileges are approved by authorized personnel 

Customized Approach Objective:
Access privileges cannot be granted to users without appropriate, documented authorization. 

Defined Approach Testing Procedures:

Purpose:
Documented approval (for example, in writing or electronically) assures that those with access and privileges are known and authorized by management, and that their access is necessary for their job function. 

7.2.4
Defined Approach Requirements: 
All user accounts and related access privileges, including third-party/vendor accounts, are reviewed as follows:

Customized Approach Objective:
Account privilege assignments are verified periodically by management as correct, and nonconformities are remediated. 

Applicability Notes:
This requirement applies to all user accounts and related access privileges, including those used by personnel and third parties/vendors, and accounts used to access third-party cloud services. 
See Requirements 7.2.5 and 7.2.5.1 and 8.6.1 through 8.6.3 for controls for application and system accounts. 
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
Regular review of access rights helps to detect excessive access rights remaining after user job responsibilities change, system functions change, or other modifications. If excessive user rights are not revoked in due time, they may be used by malicious users for unauthorized access. 
This review provides another opportunity to ensure that accounts for all terminated users have been removed (if any were missed at the time of termination), as well as to ensure that any third parties that no longer need access have had their access terminated. 

Good Practice:
When a user transfers into a new role or a new department, typically the privileges and access associated with their former role are no longer required. Continued access to privileges or functions that are no longer required may introduce the risk of misuse or errors. Therefore, when responsibilities change, processes that revalidate access help to ensure user access is appropriate for the user’s new responsibilities. 
Entities can consider implementing a regular, repeatable process for conducting reviews of access rights, and assigning “data owners” that are responsible for managing and monitoring access to data related to their job function and that also ensure user access remains current and appropriate. As an example, a direct manager could review team access monthly, while the senior manager reviews their groups’ access quarterly, both making updates to access as needed. The intent of these best practices is to support and facilitate conducting the reviews at least once every 6 months. 

7.2.5
Defined Approach Requirements: 
All application and system accounts and related access privileges are assigned and managed as follows:

Customized Approach Objective:
Access rights granted to application and system accounts are limited to only the access needed for the operability of that application or system. 

Applicability Notes:
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 
Defined Approach Testing Procedures:

Purpose:
It is important to establish the appropriate access level for application or system accounts. If such accounts are compromised, malicious users will receive the same access level as that granted to the application or system. Therefore, it is important to ensure limited access is granted to system and application accounts on the same basis as to user accounts. 

Good Practice:
Entities may want to consider establishing a baseline when setting up these application and system accounts including the following as applicable to the organization:

7.2.5.1
Defined Approach Requirements: 
All access by application and system accounts and related access privileges are reviewed as follows:

Customized Approach Objective:
Application and system account privilege assignments are verified periodically by management as correct, and nonconformities are remediated. 

Applicability Notes:
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
Regular review of access rights helps to detect excessive access rights remaining after system functions change, or other application or system modifications occur. If excessive rights are not removed when no longer needed, they may be used by malicious users for unauthorized access. 

7.2.6
Defined Approach Requirements: 
All user access to query repositories of stored cardholder data is restricted as follows:

Customized Approach Objective:
Direct unfiltered (ad hoc) query access to cardholder data repositories is prohibited, unless performed by an authorized administrator. 

Applicability Notes:
This requirement applies to controls for user access to query repositories of stored cardholder data. 
See Requirements 7.2.5 and 7.2.5.1 and 8.6.1 through 8.6.3 for controls for application and system accounts. 

Defined Approach Testing Procedures:

Purpose:
The misuse of query access to repositories of cardholder data has been a regular cause of data breaches. Limiting such access to administrators reduces the risk of such access being abused by unauthorized users. 

Definitions:
“Programmatic methods” means granting access through means such as database stored procedures that allow users to perform controlled actions to data in a table, rather than via direct, unfiltered access to the data repository by end users (except for the responsible administrator(s), who need direct access to the database for their administrative duties). 

Good Practice:
Typical user actions include moving, copying, and deleting data. Also consider the scope of privilege needed when granting access. For example, access can be granted to specific objects such as data elements, files, tables, indexes, views, and stored routines. Granting access to repositories of cardholder data should follow the same process as all other granted access, meaning that it is based on roles, with only the privileges assigned to each user that are needed to perform their job functions. 

7.3.1
Defined Approach Requirements: 
An access control system(s) is in place that restricts access based on a user’s need to know and covers all system components. 

Customized Approach Objective:
Access rights and privileges are managed via mechanisms intended for that purpose. 

Defined Approach Testing Procedures:

Purpose:
Without a mechanism to restrict access based on user’s need to know, a user may unknowingly be granted access to cardholder data. Access control systems automate the process of restricting access and assigning privileges. 

7.3.2
Defined Approach Requirements: 
The access control system(s) is configured to enforce permissions assigned to individuals, applications, and systems based on job classification and function. 

Customized Approach Objective:
Individual account access rights and privileges to systems, applications, and data are only inherited from group membership. 

Defined Approach Testing Procedures:

Purpose:
Restricting privileged access with an access control system reduces the opportunity for errors in the assignment of permissions to individuals, applications, and systems. 

7.3.3
Defined Approach Requirements: 
The access control system(s) is set to “deny all” by default. 

Customized Approach Objective:
Access rights and privileges are prohibited unless expressly permitted. 

Defined Approach Testing Procedures:

Purpose:
A default setting of “deny all” ensures no one is granted access unless a rule is established specifically granting such access. 

Good Practice:
It is important to check the default configuration of access control systems because some are set by default to “allow all,” thereby permitting access unless/until a rule is written to specifically deny it. 

8.1.1
Defined Approach Requirements: 
All security policies and operational procedures that are identified in Requirement 8 are:

Customized Approach Objective:
Expectations, controls, and oversight for meeting activities within Requirement 8 are defined and adhered to by affected personnel. All supporting activities are repeatable, consistently applied, and conform to management’s intent. 

Defined Approach Testing Procedures:

Purpose:
Requirement 8.1.1 is about effectively managing and maintaining the various policies and procedures specified throughout Requirement 8. While it is important to define the specific policies or procedures called out in Requirement 8, it is equally important to ensure they are properly documented, maintained, and disseminated. 

Good Practice:
It is important to update policies and procedures as needed to address changes in processes, technologies, and business objectives. For this reason, consider updating these documents as soon as possible after a change occurs and not only on a periodic cycle. 

Definitions:
Security policies define the entity’s security objectives and principles. Operational procedures describe how to perform activities, and define the controls, methods, and processes that are followed to achieve the desired result in a consistent manner and in accordance with policy objectives. 

8.1.2
Defined Approach Requirements: 
Roles and responsibilities for performing activities in Requirement 8 are documented, assigned, and understood. 

Customized Approach Objective:
Day-to-day responsibilities for performing all the activities in Requirement 8 are allocated. Personnel are accountable for successful, continuous operation of these requirements. 

Defined Approach Testing Procedures:

Purpose:
If roles and responsibilities are not formally assigned, personnel may not be aware of their day-to-day responsibilities and critical activities may not occur. 

Good Practice:
Roles and responsibilities may be documented within policies and procedures or maintained within separate documents. 
As part of communicating roles and responsibilities, entities can consider having personnel acknowledge their acceptance and understanding of their assigned roles and responsibilities. 

Examples:
A method to document roles and responsibilities is a responsibility assignment matrix that includes who is responsible, accountable, consulted, and informed (also called a RACI matrix). 

8.2.1
Defined Approach Requirements: 
All users are assigned a unique ID before access to system components or cardholder data is allowed. 

Customized Approach Objective:
All actions by all users are attributable to an individual. 

Applicability Notes:
This requirement is not intended to apply to user accounts within point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction (such as IDs used by cashiers on point-of-sale terminals). 

Defined Approach Testing Procedures:

Purpose:
The ability to trace actions performed on a computer system to an individual establishes accountability and traceability and is fundamental to establishing effective access controls. 
By ensuring each user is uniquely identified, instead of using one ID for several employees, an organization can maintain individual responsibility for actions and an effective record in the audit log per employee. In addition, this will assist with issue resolution and containment when misuse or malicious intent occurs. 

8.2.2
Defined Approach Requirements: 
Group, shared, or generic accounts, or other shared authentication credentials are only used when necessary on an exception basis, and are managed as follows:

Customized Approach Objective:
All actions performed by users with generic, system, or shared IDs are attributable to an individual person. 

Applicability Notes:
This requirement is not intended to apply to user accounts within point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction (such as IDs used by cashiers on point-of-sale terminals). 

Defined Approach Testing Procedures:

Purpose:
Group, shared, or generic (or default) accounts are typically delivered with software or operating systems—for example, root or with privileges associated with a specific function, such as an administrator. 
If multiple users share the same authentication credentials (for example, user account and password), it becomes impossible to trace system access and activities to an individual. In turn, this prevents an entity from assigning accountability for, or having effective logging of, an individual’s actions since a given action could have been performed by anyone in the group with knowledge of the user ID and associated authentication factors. 
The ability to associate individuals to the actions performed with an account is essential to provide individual accountability and traceability regarding who performed an action, what action was performed, and when that action occurred. 

Good Practice:
If shared accounts are used for any reason, strong management controls need to be established to maintain individual accountability and traceability.

Examples:
Tools and techniques can facilitate both management and security of these types of accounts and confirm individual user identity before access to an account is granted. Entities can consider password vaults or other systemmanaged controls such as the sudo command. An example of an exceptional circumstance is where all other authentication methods have failed, and a shared account is needed for emergency use or “break the glass” administrator access. 

8.2.3
Defined Approach Requirements: 
Additional requirement for service providers only: Service providers with remote access to customer premises use unique authentication factors for each customer premises 

Customized Approach Objective:
A service provider’s credential used for one customer cannot be used for any other customer. 

Applicability Notes:
This requirement applies only when the entity being assessed is a service provider. 
This requirement is not intended to apply to service providers accessing their own shared services environments, where multiple customer environments are hosted. 
If service provider employees use shared authentication factors to remotely access customer premises, these factors must be unique per customer and managed in accordance with Requirement 8.2.2. 

Defined Approach Testing Procedures:

Purpose:
Service providers with remote access to customer premises typically use this access to support POS POI systems or provide other remote services. 
If a service provider uses the same authentication factors to access multiple customers, all the service provider’s customers can easily be compromised if an attacker compromises that one factor. 
Criminals know this and deliberately target service providers looking for a shared authentication factor that gives them remote access to many merchants via that single factor. 

Examples:
Technologies such as multi-factor mechanisms that provide a unique credential for each connection (such as a single-use password) could also meet the intent of this requirement. 

8.2.4
Defined Approach Requirements: 
Addition, deletion, and modification of user IDs, authentication factors, and other identifier objects are managed as follows:

Customized Approach Objective:
Lifecycle events for user IDs and authentication factors cannot occur without appropriate authorization. 

Applicability Notes:
This requirement applies to all user accounts, including employees, contractors, consultants, temporary workers, and third-party vendors. 

Defined Approach Testing Procedures:

Purpose:
It is imperative that the lifecycle of a user ID (additions, deletions, and modifications) is controlled so that only authorized accounts can perform functions, actions are auditable, and privileges are limited to only what is required. 
Attackers often compromise an existing account and then escalate the privileges of that account to perform unauthorized acts, or they may create new IDs to continue their activity in the background. It is essential to detect and respond when user accounts are created or changed outside the normal change process or without corresponding authorization. 

8.2.5
Defined Approach Requirements: 
Access for terminated users is immediately revoked. 

Customized Approach Objective:
The accounts of terminated users cannot be used. 

Defined Approach Testing Procedures:

Purpose:
If an employee or third party/vendor has left the company and still has access to the network via their user account, unnecessary or malicious access to cardholder data could occur—either by the former employee or by a malicious user who exploits the old and/or unused account. 

8.2.6
Defined Approach Requirements: 
Inactive user accounts are removed or disabled within 90 days of inactivity. 

Customized Approach Objective:
Inactive user accounts cannot be used 

Defined Approach Testing Procedures:

Purpose:
Accounts that are not used regularly are often targets of attack since it is less likely that any changes, such as a changed password, will be noticed. As such, these accounts may be more easily exploited and used to access cardholder data. 

Good Practice:
Where it may be reasonably anticipated that an account will not be used for an extended period of time, such as an extended leave of absence, the account should be disabled as soon as the leave begins, rather than waiting 90 days. 

8.2.7
Defined Approach Requirements: 
Accounts used by third parties to access, support, or maintain system components via remote access are managed as follows:

Customized Approach Objective:
Third party remote access cannot be used except where specifically authorized and use is overseen by management. 

Defined Approach Testing Procedures:

Purpose:
Allowing third parties to have 24/7 access into an entity’s systems and networks in case they need to provide support increases the chances of unauthorized access. This access could result in an unauthorized user in the third party’s environment or a malicious individual using the always-available external entry point into an entity’s network. Where third parties do need access 24/7, it should be documented, justified, monitored, and tied to specific service reasons. 

Good Practice:
Enabling access only for the time periods needed and disabling it as soon as it is no longer required helps prevent misuse of these connections. Additionally, consider assigning third parties a start and stop date for their access in accordance with their service contract. 
Monitoring third-party access helps ensure that third parties are accessing only the systems necessary and only during approved time frames. Any unusual activity using third-party accounts should be followed up and resolved. 

8.2.8
Defined Approach Requirements: 
If a user session has been idle for more than 15 minutes, the user is required to re-authenticate to re-activate the terminal or session. 

Customized Approach Objective:
A user session cannot be used except by the authorized user. 

Applicability Notes:
This requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction (such as IDs used by cashiers on point-of-sale terminals). 
This requirement is not meant to prevent legitimate activities from being performed while the console/PC is unattended. 

Defined Approach Testing Procedures:

Purpose:
When users walk away from an open machine with access to system components or cardholder data, there is a risk that the machine may be used by others in the user’s absence, resulting in unauthorized account access and/or misuse. 

Good Practice:
The re-authentication can be applied either at the system level to protect all sessions running on that machine or at the application level. 
Entities may also want to consider staging controls in succession to further restrict the access of an unattended session as time passes. For example, the screensaver may activate after 15 minutes and log off the user after an hour. 
However, timeout controls must balance the risk of access and exposure with the impact to the user and purpose of the access. 
If a user needs to run a program from an unattended computer, the user can log in to the computer to initiate the program, and then “lock” the computer so that no one else can use the user’s login while the computer is unattended. 

Examples:
One way to meet this requirement is to configure an automated screensaver to launch whenever the console is idle for 15 minutes and requiring the logged-in user to enter their password to unlock the screen. 

8.3.1
Defined Approach Requirements: 
All user access to system components for users and administrators is authenticated via at least one of the following authentication factors:

Customized Approach Objective:
An account cannot be accessed except with a combination of user identity and an authentication factor. 

Applicability Notes:
This requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction (such as IDs used by cashiers on point-of-sale terminals). 
This requirement does not supersede multi-factor authentication (MFA) requirements but applies to those in-scope systems not otherwise subject to MFA requirements. 
A digital certificate is a valid option for “something you have” if it is unique for a particular user. 

Defined Approach Testing Procedures:

Purpose:
When used in addition to unique IDs, an authentication factor helps protect user IDs from being compromised, since the attacker needs to have the unique ID and compromise the associated authentication factor(s). 

Good Practice:
A common approach for a malicious individual to compromise a system is to exploit weak or nonexistent authentication factors (for example, passwords/passphrases). Requiring strong authentication factors helps protect against this attack. 

Further Information:
See fidoalliance.org for more information about using tokens, smart cards, or biometrics as authentication factors. 

8.3.2
Defined Approach Requirements: 
Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components. 

Customized Approach Objective:
Cleartext authentication factors cannot be obtained, derived, or reused from the interception of communications or from stored data. 

Defined Approach Testing Procedures:

Purpose:
Network devices and applications have been known to transmit unencrypted, readable authentication factors (such as passwords and passphrases) across the network and/or store these values without encryption. As a result, a malicious individual can easily intercept this information during transmission using a “sniffer,” or directly access unencrypted authentication factors in files where they are stored, and then use this data to gain unauthorized access. 

8.3.3
Defined Approach Requirements: 
User identity is verified before modifying any authentication factor. 

Customized Approach Objective:
Unauthorized individuals cannot gain system access by impersonating the identity of an authorized user 

Defined Approach Testing Procedures:

Purpose:
Malicious individuals use "social engineering” techniques to impersonate a user of a system — for example, calling a help desk and acting as a legitimate user—to have an authentication factor changed so they can use a valid user ID. 
Requiring positive identification of a user reduces the probability of this type of attack succeeding. 

Good Practice:
Modifications to authentication factors for which user identity should be verified include but are not limited to performing password resets, provisioning new hardware or software tokens, and generating new keys. 

Examples:
Methods to verify a user’s identity include a secret question/answer, knowledge-based information, and calling the user back at a known and previously established phone number. 

8.3.4
Defined Approach Requirements: 
Invalid authentication attempts are limited by:

Customized Approach Objective:
An authentication factor cannot be guessed in a brute force, online attack. 

Applicability Notes:
This requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction (such as IDs used by cashiers on point-of-sale terminals). 

Defined Approach Testing Procedures:

Purpose:
Without account-lockout mechanisms in place, an attacker can continually try to guess a password through manual or automated tools (for example, password cracking) until the attacker succeeds and gains access to a user’s account.
If an account is locked out due to someone continually trying to guess a password, controls to delay reactivation of the locked account stop the malicious individual from guessing the password, as they will have to stop for a minimum of 30 minutes until the account is reactivated. 

Good Practice:
Before reactivating a locked account, the user’s identity should be confirmed. For example, the administrator or help desk personnel can validate that the actual account owner is requesting reactivation, or there may be password reset selfservice mechanisms that the account owner uses to verify their identity 

8.3.5
Defined Approach Requirements: 
If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user as follows:

Customized Approach Objective:
An initial or reset password/passphrase assigned to a user cannot be used by an unauthorized user. 

Defined Approach Testing Procedures:

Purpose:
If the same password/passphrase is used for every new user, an internal user, former employee, or malicious individual may know or easily discover the value and use it to gain access to accounts before the authorized user attempts to use the password. 

8.3.6
Defined Approach Requirements: 
 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity:

Customized Approach Objective:
A guessed password/passphrase cannot be verified by either an online or offline brute force attack. 

Applicability Notes:
This requirement is not intended to apply to:

This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 
Until 31 March 2025, passwords must be a minimum length of seven characters in accordance with PCI DSS v3.2.1 Requirement 8.2.3. 

Defined Approach Testing Procedures:

Purpose:
Strong passwords/passphrases may be the first line of defense into a network since a malicious individual will often first try to find accounts with weak, static, or non-existent passwords. If passwords are short or easily guessable, it is relatively easy for a malicious individual to find these weak accounts and compromise a network under the guise of a valid user ID. 

Good Practice:
Password/passphrase strength is dependent on password/passphrase complexity, length, and randomness. Passwords/passphrases should be sufficiently complex, so they are impractical for an attacker to guess or otherwise discover its value. Entities can consider adding increased complexity by requiring the use of special characters and upper- and lower-case characters, in addition to the minimum standards outlined by this requirement. Additional complexity increases the time required for offline brute force attacks of hashed passwords/passphrases. 
Another option for increasing the resistance of passwords to guessing attacks is by comparing proposed password/passphrases to a bad password list and having users provide new passwords for any passwords found on the list. 

8.3.7
Defined Approach Requirements: 
Individuals are not allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used. 

Customized Approach Objective:
A previously used password cannot be used to gain access to an account for at least 12 months. 

Applicability Notes:
This requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction (such as IDs used by cashiers on point-of-sale terminals). 

Defined Approach Testing Procedures:

Purpose:
If password history is not maintained, the effectiveness of changing passwords is reduced, as previous passwords can be reused over and over. Requiring that passwords cannot be reused for a period reduces the likelihood that passwords that have been guessed or brute-forced will be reused in the future. 
Passwords or passphrases may have previously been changed due to suspicion of compromise or because the password or passphrase exceeded its effective use period, both of which are reasons why previously used passwords should not be reused. 

8.3.8
Defined Approach Requirements: 
Authentication policies and procedures are documented and communicated to all users including:

Customized Approach Objective:
Users are knowledgeable about the correct use of authentication factors and can access assistance and guidance when required. 

Defined Approach Testing Procedures:

Purpose:
Communicating authentication policies and procedures to all users helps them to understand and abide by the policies. 

Good Practice:
Guidance on selecting strong passwords may include suggestions to help personnel select hard-to-guess passwords that do not contain dictionary words or information about the user, such as the user ID, names of family members, date of birth, etc. 
Guidance for protecting authentication factors may include not writing down passwords or not saving them in insecure files, and being alert to malicious individuals who may try to exploit their passwords (for example, by calling an employee and asking for their password so the caller can “troubleshoot a problem”). 
Alternatively, entities can implement processes to confirm passwords meet password policy, for example, by comparing password choices to a list of unacceptable passwords and having users choose a new password for any that match with one on the list. Instructing users to change passwords if there is a chance the password is no longer secure can prevent malicious users from using a legitimate password to gain unauthorized access. 

8.3.9
Defined Approach Requirements: 
If passwords/passphrases are used as the only authentication factor for user access (i.e., in any single-factor authentication implementation) then either:

OR

Customized Approach Objective:
An undetected compromised password/passphrase cannot be used indefinitely. 

Applicability Notes:
This requirement applies to in-scope system components that are not in the CDE because these components are not subject to MFA requirements. 
This requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction (such as IDs used by cashiers on point-of-sale terminals). 
This requirement does not apply to service providers’ customer accounts but does apply to accounts for service provider personnel. 

Defined Approach Testing Procedures:

Purpose:
Access to in-scope system components that are not in the CDE may be provided using a single authentication factor, such as a password/passphrase, token device or smart card, or biometric attribute. Where passwords/passphrases are employed as the only authentication factor for such access, additional controls are required to protect the integrity of the password/passphrase. 

Good Practice:
Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to break the password/phrase. Periodically changing passwords offers less time for a malicious individual to crack a password/passphrase and less time to use a compromised password. 
Using a password/passphrase as the only authentication factor provides a single point of failure if compromised. Therefore, in these implementations, controls are needed to minimize how long malicious activity could occur via a compromised password/passphrase. 
Dynamically analyzing an account’s security posture is another option that allows for more rapid detection and response to address potentially compromised credentials. Such analysis takes a number of data points, which may include device integrity, location, access times, and the resources accessed to determine in real time whether an account can be granted access to a requested resource. In this way, access can be denied and accounts blocked if it is suspected that authentication credentials have been compromised. 

Further Information:
For information about using dynamic analysis to manage user access to resources, see NIST SP 800-207 Zero Trust Architecture. 

8.3.10
Defined Approach Requirements: 
Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data (i.e., in any singlefactor authentication implementation), then guidance is provided to customer users including: 

Customized Approach Objective:
Passwords/passphrases for service providers’ customers cannot be used indefinitely. 

Applicability Notes:
This requirement applies only when the entity being assessed is a service provider. 
This requirement does not apply to accounts of consumer users accessing their own payment card information. 
This requirement for service providers will be superseded by Requirement 8.3.10.1 once 8.3.10.1 becomes effective. 

Defined Approach Testing Procedures:

Purpose:
Using a password/passphrase as the only authentication factor provides a single point of failure if compromised. Therefore, in these implementations, controls are needed to minimize how long malicious activity could occur via a compromised password/passphrase. 

Good Practice:
Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to break the password/phrase. Periodically changing passwords offers less time for a malicious individual to crack a password/passphrase and less time to use a compromised password. 

8.3.10.1
Defined Approach Requirements: 
Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access (i.e., in any single-factor authentication implementation) then either:

OR

Customized Approach Objective:
Passwords/passphrases for service providers’ customers cannot be used indefinitely. 

Applicability Notes:
This requirement applies only when the entity being assessed is a service provider. 
This requirement does not apply to accounts of consumer users accessing their own payment card information. 
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 
Until this requirement is effective on 31 March 2025, service providers may meet either Requirement 8.3.10 or 8.3.10.1. 

Defined Approach Testing Procedures:

Purpose:
Using a password/passphrase as the only authentication factor provides a single point of failure if compromised. Therefore, in these implementations, controls are needed to minimize how long malicious activity could occur via a compromised password/passphrase. 

Good Practice:
Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to break the password/phrase. Periodically changing passwords offers less time for a malicious individual to crack a password/passphrase and less time to use a compromised password. 
Dynamically analyzing an account’s security posture is another option that allows for more rapid detection and response to address potentially compromised credentials. Such analysis takes a number of data points which may include device integrity, location, access times, and the resources accessed to determine in real time whether an account can be granted access to a requested resource. In this way, access can be denied and accounts blocked if it is suspected that account credentials have been compromised. 

Further Information:
For information about using dynamic analysis to manage user access to resources, refer to NIST SP 800-207 Zero Trust Architecture. 

8.3.11
Defined Approach Requirements: 
Where authentication factors such as physical or logical security tokens, smart cards, or certificates are used:

Customized Approach Objective:
An authentication factor cannot be used by anyone other than the user to which it is assigned. 

Defined Approach Testing Procedures:

Purpose:
If multiple users can use authentication factors such as tokens, smart cards, and certificates, it may be impossible to identify the individual using the authentication mechanism. 

Good Practice:
Having physical and/or logical controls (for example, a PIN, biometric data, or a password) to uniquely authenticate the user of the account will prevent unauthorized users from gaining access to the user account through use of a shared authentication factor. 

8.4.1
Defined Approach Requirements: 
MFA is implemented for all non-console access into the CDE for personnel with administrative access. 

Customized Approach Objective:
Administrative access to the CDE cannot be obtained by the use of a single authentication factor. 

Applicability Notes:
The requirement for MFA for non-console administrative access applies to all personnel with elevated or increased privileges accessing the CDE via a non-console connection—that is, via logical access occurring over a network interface rather than via a direct, physical connection. 
MFA is considered a best practice for non-console administrative access to in-scope system components that are not part of the CDE. 

Defined Approach Testing Procedures:

Purpose:
Requiring more than one type of authentication factor reduces the probability that an attacker can gain access to a system by masquerading as a legitimate user, because the attacker would need to compromise multiple authentication factors. This is especially true in environments where traditionally the single authentication factor employed was something a user knows such as a password or passphrase. 

Definitions:
Using one factor twice (for example, using two separate passwords) is not considered multifactor authentication. 

8.4.2
Defined Approach Requirements: 
MFA is implemented for all access into the CDE. 

Customized Approach Objective:
Access into the CDE cannot be obtained by the use of a single authentication factor. 

Applicability Notes:
This requirement does not apply to:

 MFA is required for both types of access specified in Requirements 8.4.2 and 8.4.3. Therefore, applying MFA to one type of access does not replace the need to apply another instance of MFA to the other type of access. If an individual first connects to the entity’s network via remote access, and then later initiates a connection into the CDE from within the network, per this requirement the individual would authenticate using MFA twice, once when connecting via remote access to the entity’s network and once when connecting via non-console administrative access from the entity’s network into the CDE. 
The MFA requirements apply for all types of system components, including cloud, hosted systems, and on-premises applications, network security devices, workstations, servers, and endpoints, and includes access directly to an entity’s networks or systems as well as web-based access to an application or function. 
MFA for remote access into the CDE can be implemented at the network or system/application level; it does not have to be applied at both levels. For example, if MFA is used when a user connects to the CDE network, it does not have to be used when the user logs into each system or application within the CDE. 
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
Requiring more than one type of authentication factor reduces the probability that an attacker can gain access to a system by masquerading as a legitimate user, because the attacker would need to compromise multiple authentication factors. This is especially true in environments where traditionally the single authentication factor employed was something a user knows such as a password or passphrase. 

Definitions:
Using one factor twice (for example, using two separate passwords) is not considered multifactor authentication. 

8.4.3
Defined Approach Requirements: 
MFA is implemented for all remote network access originating from outside the entity’s network that could access or impact the CDE as follows: 

Customized Approach Objective:
Remote access to the entity’s network cannot be obtained by using a single authentication factor. 

Applicability Notes:
The requirement for MFA for remote access originating from outside the entity’s network applies to all user accounts that can access the network remotely, where that remote access leads to or could lead to access into the CDE. 
If remote access is to a part of the entity’s network that is properly segmented from the CDE, such that remote users cannot access or impact the CDE, MFA for remote access to that part of the network is not required. However, MFA is required for any remote access to networks with access to the CDE and is recommended for all remote access to the entity’s networks. 
The MFA requirements apply for all types of system components, including cloud, hosted systems, and on-premises applications, network security devices, workstations, servers, and endpoints, and includes access directly to an entity’s networks or systems as well as web-based access to an application or function. 

Defined Approach Testing Procedures:

Purpose:
Requiring more than one type of authentication factor reduces the probability that an attacker can gain access to a system by masquerading as a legitimate user, because the attacker would need to compromise multiple authentication factors. This is especially true in environments where traditionally the single authentication factor employed was something a user knows, such as a password or passphrase. 

Definitions:
Multi-factor authentication (MFA) requires an individual to present a minimum of two of the three authentication factors specified in Requirement 8.3.1 before access is granted. Using one factor twice (for example, using two separate passwords) is not considered multifactor authentication. 

8.5.1
Defined Approach Requirements: 
MFA systems are implemented as follows:

Customized Approach Objective:
MFA systems are resistant to attack and strictly control any administrative overrides. 

Applicability Notes:
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
Poorly configured MFA systems can be bypassed by attackers. This requirement therefore addresses configuration of MFA system(s) that provide MFA for users accessing system components in the CDE. 

Definitions: 
Using one type of factor twice (for example, using two separate passwords) is not considered multifactor authentication. 

Further Information:
For more information about MFA systems and features, refer to the following: 

8.6.1
Defined Approach Requirements: 
If accounts used by systems or applications can be used for interactive login, they are managed as follows: 

Customized Approach Objective:
When used interactively, all actions with accounts designated as system or application accounts are authorized and attributable to an individual person. 

Applicability Notes:
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
Like individual user accounts, system and application accounts require accountability and strict management to ensure they are used only for the intended purpose and are not misused. 
Attackers often compromise system or application accounts to gain access to cardholder data. 

Good Practice:
Where possible, configure system and application accounts to disallow interactive login to prevent unauthorized individuals from logging in and using the account with its associated system privileges, and to limit the machines and devices on which the account can be used. 

Definitions:
System or application accounts are those accounts that execute processes or perform tasks on a computer system or application and are not typically accounts that an individual logs into. These accounts usually have elevated privileges that are required to perform specialized tasks or functions. 
Interactive login is the ability for a person to log into a system or application account in the same manner as a normal user account. Using system and application accounts this way means there is no accountability and traceability of actions taken by the user. 

8.6.2
Defined Approach Requirements: 
Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded in scripts, configuration/property files, or bespoke and custom source code. 

Customized Approach Objective:
Passwords/passphrases used by application and system accounts cannot be used by unauthorized personnel. 

Applicability Notes:
Stored passwords/passphrases are required to be encrypted in accordance with PCI DSS Requirement 8.3.2. 
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
Not properly protecting passwords/passphrases used by application and system accounts, especially if those accounts can be used for interactive login, increases the risk and success of unauthorized use of those privileged accounts. 

Good Practice:
Changing these values due to suspected or confirmed disclosure can be particularly difficult to implement. 
Tools can facilitate both management and security of authentication factors for application and system accounts. For example, consider password vaults or other system-managed controls. 

8.6.3
Defined Approach Requirements: 
Passwords/passphrases for any application and system accounts are protected against misuse as follows:

Customized Approach Objective:
Passwords/passphrases used by application and system accounts cannot be used indefinitely and are structured to resist brute-force and guessing attacks. 

Applicability Notes:
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
Systems and application accounts pose more inherent security risk than user accounts because they often run in an elevated security context, with access to systems that may not be typically granted to user accounts, such as programmatic access to databases, etc. As a result, special consideration must be made to protect passwords/passphrases used for application and system accounts. 

Good Practice:
Entities should consider the following risk factors when determining how to protect application and system passwords/passphrases against misuse:

All these elements affect the level of risk for application and system accounts and might impact the security of systems accessed by the system and application accounts. 
Entities should correlate their selected change frequency for application and system passwords/passwords with their selected complexity for those passwords/passphrases – i.e., the complexity should be more rigorous when passwords/passphrases are changed infrequently and can be less rigorous when changed more frequently. For example, a longer change frequency is more justifiable when passwords/passphrases complexity is set to 36 alphanumeric characters with upper- and lowercase letters, numbers, and special characters. 
Best practices are to consider password changes at least once a year, a password/passphrase length of at least 15 characters, and complexity for the passwords/passphrase of alphanumeric characters, with upper- and lower-case letters, and special characters. 

Further Information:
For information about variability and equivalency of password strength for passwords/passphrases of different formats, see the industry standards (for example, the current version of NIST SP 800- 63 Digital Identity Guidelines). 

9.1.1
Defined Approach Requirements: 
All security policies and operational procedures that are identified in Requirement 9 are: 

Customized Approach Objective:
Expectations, controls, and oversight for meeting activities within Requirement 9 are defined and adhered to by affected personnel. All supporting activities are repeatable, consistently applied, and conform to management’s intent. 

Defined Approach Testing Procedures:

Purpose:
Requirement 9.1.1 is about effectively managing and maintaining the various policies and procedures specified throughout Requirement 9. While it is important to define the specific policies or procedures called out in Requirement 9, it is equally important to ensure they are properly documented, maintained, and disseminated. 

Good Practice:
It is important to update policies and procedures as needed to address changes in processes, technologies, and business objectives. For this reason, consider updating these documents as soon as possible after a change occurs and not only on a periodic cycle. 

Definitions:
Security policies define the entity’s security objectives and principles. Operational procedures describe how to perform activities, and define the controls, methods, and processes that are followed to achieve the desired result in a consistent manner and in accordance with policy objectives. 
Policies and procedures, including updates, are actively communicated to all affected personnel, and are supported by operating procedures describing how to perform activities. 

9.1.2
Defined Approach Requirements: 
Roles and responsibilities for performing activities in Requirement 9 are documented, assigned, and understood. 

Customized Approach Objective:
Day-to-day responsibilities for performing all the activities in Requirement 9 are allocated. Personnel are accountable for successful, continuous operation of these requirements. 

Defined Approach Testing Procedures:

Purpose:
If roles and responsibilities are not formally assigned, personnel may not be aware of their day-to-day responsibilities, and critical activities may not occur. 

Good Practice:
Roles and responsibilities may be documented within policies and procedures or maintained within separate documents. 
As part of communicating roles and responsibilities, entities can consider having personnel acknowledge their acceptance and understanding of their assigned roles and responsibilities. 
A method to document roles and responsibilities is a responsibility assignment matrix that includes who is responsible, accountable, consulted, and informed (also called a RACI matrix) 

9.2.1
Defined Approach Requirements: 
Appropriate facility entry controls are in place to restrict physical access to systems in the CDE. 

Customized Approach Objective:
System components in the CDE cannot be physically accessed by unauthorized personnel. 

Defined Approach Testing Procedures:

Purpose:
Without physical access controls, unauthorized persons could potentially gain access to the CDE and sensitive information, or could alter system configurations, introduce vulnerabilities into the network, or destroy or steal equipment. Therefore, the purpose of this requirement is that physical access to the CDE is controlled via physical security controls such as badge readers or other mechanisms such as lock and key. 

Good Practice:
Whichever mechanism meets this requirement, it must be sufficient for the organization to verify that only authorized personnel are granted access. 

Examples:
Facility entry controls include physical security controls at each computer room, data center, and other physical areas with systems in the CDE. It can also include badge readers or other devices that manage physical access controls, such as lock and key with a current list of all individuals holding the keys. 

9.2.1.1
Defined Approach Requirements: 
Individual physical access to sensitive areas within the CDE is monitored with either video cameras or physical access control mechanisms (or both) as follows: 

Customized Approach Objective:
Trusted, verifiable records are maintained of individual physical entry to, and exit from, sensitive areas. 

Defined Approach Testing Procedures:

Purpose:
Maintaining details of individuals entering and exiting the sensitive areas can help with investigations of physical breaches by identifying individuals that physically accessed the sensitive areas, as well as when they entered and exited. 

Good Practice:
Whichever mechanism meets this requirement, it should effectively monitor all entry and exit points to sensitive areas. 
Criminals attempting to gain physical access to sensitive areas will often try to disable or bypass the monitoring controls. To protect these controls from tampering, video cameras could be positioned so they are out of reach and/or be monitored to detect tampering. Similarly, physical access control mechanisms could be monitored or have physical protections installed to prevent them from being damaged or disabled by malicious individuals. 

9.2.2
Defined Approach Requirements: 
Physical and/or logical controls are implemented to restrict use of publicly accessible network jacks within the facility. 

Customized Approach Objective:
Unauthorized devices cannot connect to the entity’s network from public areas within the facility 

Defined Approach Testing Procedures:

Purpose:
Restricting access to network jacks (or network ports) will prevent malicious individuals from plugging into readily available network jacks and gaining access to the CDE or systems connected to the CDE. 

Good Practice:
Whether logical or physical controls, or a combination of both, are used, they should prevent an individual or device that is not explicitly authorized from being able to connect to the network. 

Examples:
Methods to meet this requirement include network jacks located in public areas and areas accessible to visitors could be disabled and only enabled when network access is explicitly authorized. Alternatively, processes could be implemented to ensure that visitors are escorted at all times in areas with active network jacks. 

9.2.3
Defined Approach Requirements: 
Physical access to wireless access points, gateways, networking/communications hardware, and telecommunication lines within the facility is restricted. 

Customized Approach Objective:
Physical networking equipment cannot be accessed by unauthorized personnel. 

Defined Approach Testing Procedures:

Purpose:
Without appropriate physical security over access to wireless components and devices, and computer networking and telecommunications equipment and lines, malicious users could gain access to the entity’s network resources. Additionally, they could connect their own devices to the network to gain unauthorized access to the CDE or systems connected to the CDE. 
Additionally, securing networking and communications hardware prevents malicious users from intercepting network traffic or physically connecting  their own devices to wired network resources. 

9.2.4
Defined Approach Requirements: 
Access to consoles in sensitive areas is restricted via locking when not in use. 

Customized Approach Objective:
Physical consoles within sensitive areas cannot be used by unauthorized personnel. 

Defined Approach Testing Procedures:

Purpose:
Locking console login screens prevents unauthorized persons from gaining access to sensitive information, altering system configurations, introducing vulnerabilities into the network, or destroying records. 

9.3.1
Defined Approach Requirements: 
Procedures are implemented for authorizing and managing physical access of personnel to the CDE, including:

Customized Approach Objective:
Requirements for access to the physical CDE are defined and enforced to identify and authorize personnel. 

Defined Approach Testing Procedures:

Purpose:
Establishing procedures for granting, managing, and removing access when it is no longer needed ensures non-authorized individuals are prevented from gaining access to areas containing cardholder data. In addition, it is important to limit access to the actual badging system and badging materials to prevent unauthorized personnel from making their own badges and/or setting up their own access rules. 

Good Practice:
It is important to visually identify the personnel that are physically present, and whether the individual is a visitor or an employee. 

Examples:
One way to identify personnel is to assign them badges. 

9.3.1.1
Defined Approach Requirements: 
 Physical access to sensitive areas within the CDE for personnel is controlled as follows: 

Customized Approach Objective:
Sensitive areas cannot be accessed by unauthorized personnel. 

Defined Approach Testing Procedures:

Purpose:
Controlling physical access to sensitive areas helps ensure that only authorized personnel with a legitimate business need are granted access. 

Good Practice:
Where possible, organizations should have policies and procedures to ensure that before personnel leaving the organization, all physical access mechanisms are returned, or disabled as soon as possible upon their departure. This will ensure personnel cannot gain physical access to sensitive areas once their employment has ended. 

9.3.2
Defined Approach Requirements: 
Procedures are implemented for authorizing and managing visitor access to the CDE, including:

Customized Approach Objective:
Requirements for visitor access to the CDE are defined and enforced. Visitors cannot exceed any authorized physical access allowed while in the CDE. 

Defined Approach Testing Procedures:

Purpose:
Visitor controls are important to reduce the ability of unauthorized and malicious persons to gain access to facilities and potentially to cardholder data. 
Visitor controls ensure visitors are identifiable as visitors so personnel can monitor their activities, and that their access is restricted to just the duration of their legitimate visit. 

9.3.3
Defined Approach Requirements: 
Visitor badges or identification are surrendered or deactivated before visitors leave the facility or at the date of expiration. 

Customized Approach Objective:
Visitor identification or badges cannot be reused after expiration. 

Defined Approach Testing Procedures:

Purpose:
Ensuring that visitor badges are returned or deactivated upon expiry or completion of the visit prevents malicious persons from using a previously authorized pass to gain physical access into the building after the visit has ended. 

9.3.4
Defined Approach Requirements: 
A visitor log is used to maintain a physical record of visitor activity within the facility and within sensitive areas, including:

Customized Approach Objective:
 Records of visitor access that enable the identification of individuals are maintained. 

Defined Approach Testing Procedures:

Purpose:
A visitor log documenting minimum information about the visitor is easy and inexpensive to maintain. It will assist in identifying historical physical access to a building or room and potential access to cardholder data. 

Good Practice:
When logging the date and time of visit, including both in and out times is considered a best practice, since it provides helpful tracking information and provides assurance that a visitor has left at the end of the day. It is also good to verify that a visitor’s ID (driver’s license, etc.) matches the name they put on the visitor log. 

9.4.1
Defined Approach Requirements: 
All media with cardholder data is physically secured. 

Customized Approach Objective:
Media with cardholder data cannot be accessed by unauthorized personnel. 

Defined Approach Testing Procedures:

Purpose:
Controls for physically securing media are intended to prevent unauthorized persons from gaining access to cardholder data on any media. Cardholder data is susceptible to unauthorized viewing, copying, or scanning if it is unprotected while it is on removable or portable media, printed out, or left on someone’s desk. 

9.4.1.1
Defined Approach Requirements: 
Offline media backups with cardholder data are stored in a secure location. 

Customized Approach Objective:
Offline backups cannot be accessed by unauthorized personnel. 

Defined Approach Testing Procedures:

Purpose:
If stored in a non-secured facility, backups containing cardholder data may easily be lost, stolen, or copied for malicious intent. 

Good Practice:
For secure storage of backup media, a good practice is to store media in an off-site facility, such as an alternate or backup site or commercial storage facility. 

9.4.1.2
Defined Approach Requirements: 
The security of the offline media backup location(s) with cardholder data is reviewed at least once every 12 months. 

Customized Approach Objective:
The security controls protecting offline backups are verified periodically by inspection. 

Defined Approach Testing Procedures:

Purpose:
Conducting regular reviews of the storage facility enables the organization to address identified security issues promptly, minimizing the potential risk. It is important for the entity to be aware of the security of the area where media is being stored. 

9.4.2
Defined Approach Requirements: 
All media with cardholder data is classified in accordance with the sensitivity of the data 

Customized Approach Objective:
Media are classified and protected appropriately. 

Defined Approach Testing Procedures:

Purpose:
Media not identified as confidential may not be adequately protected or may be lost or stolen. 

Good Practice:
It is important that media be identified such that its classification status is apparent. This does not mean however that the media needs to have a “confidential” label. 

9.4.3
Defined Approach Requirements: 
 Media with cardholder data sent outside the facility is secured as follows:

Customized Approach Objective:
Media is secured and tracked when transported outside the facility. 

Defined Approach Testing Procedures:

Purpose:
Media may be lost or stolen if sent via a nontrackable method such as regular postal mail. The use of secure couriers to deliver any media that contains cardholder data allows organizations to use their tracking systems to maintain inventory and location of shipments. 

9.4.4
Defined Approach Requirements: 
Management approves all media with cardholder data that is moved outside the facility (including when media is distributed to individuals). 

Customized Approach Objective:
Media cannot leave a facility without the approval of accountable personnel. 

Applicability Notes:
Individuals approving media movements should have the appropriate level of management authority to grant this approval. However, it is not specifically required that such individuals have “manager” as part of their title. 

Defined Approach Testing Procedures:

Purpose:
Without a firm process for ensuring that all media movements are approved before the media is removed from secure areas, the media would not be tracked or appropriately protected, and its location would be unknown, leading to lost or stolen media. 

9.4.5
Defined Approach Requirements: 
Inventory logs of all electronic media with cardholder data are maintained. 

Customized Approach Objective:
Accurate inventories of stored electronic media are maintained. 

Defined Approach Testing Procedures:

Purpose:
Without careful inventory methods and storage controls, stolen or missing electronic media could go unnoticed for an indefinite amount of time. 

9.4.5.1
Defined Approach Requirements: 
Inventories of electronic media with cardholder data are conducted at least once every 12 months. 

Customized Approach Objective:
Media inventories are verified periodically. 

Defined Approach Testing Procedures:

Purpose:
Without careful inventory methods and storage controls, stolen or missing electronic media could go unnoticed for an indefinite amount of time. 

9.4.6
Defined Approach Requirements: 
Hard-copy materials with cardholder data are destroyed when no longer needed for business or legal reasons, as follows:

Customized Approach Objective:
Cardholder data cannot be recovered from media that has been destroyed or which is pending destruction. 

Applicability Notes:
These requirements for media destruction when that media is no longer needed for business or legal reasons are separate and distinct from PCI DSS Requirement 3.2.1, which is for securely deleting cardholder data when no longer needed per the entity’s cardholder data retention policies. 

Defined Approach Testing Procedures:

Purpose:
If steps are not taken to destroy information contained on hard-copy media before disposal, malicious individuals may retrieve information from the disposed media, leading to a data compromise. For example, malicious individuals may use a technique known as “dumpster diving,” where they search through trashcans and recycle bins looking for hard-copy materials with information they can use to launch an attack. 
Securing storage containers used for materials that are going to be destroyed prevents sensitive information from being captured while the materials are being collected. 

Good Practice:
Consider “to-be-shredded” containers with a lock that prevents access to its contents or that physically prevent access to the inside of the container. 

Further Information:
See NIST Special Publication 800-88, Revision 1: Guidelines for Media Sanitization. 

9.4.7
Defined Approach Requirements: 
Electronic media with cardholder data is destroyed when no longer needed for business or legal reasons via one of the following:

Customized Approach Objective:
Cardholder data cannot be recovered from media that has been erased or destroyed. 

Applicability Notes:
These requirements for media destruction when that media is no longer needed for business or legal reasons are separate and distinct from PCI DSS Requirement 3.2.1, which is for 
securely deleting cardholder data when no longer needed per the entity’s cardholder data retention policies. 

Defined Approach Testing Procedures:

Purpose:
If steps are not taken to destroy information contained on electronic media when no longer needed, malicious individuals may retrieve information from the disposed media, leading to a data compromise. For example, malicious individuals may use a technique known as “dumpster diving,” where they search through trashcans and recycle bins looking for information they can use to launch an attack. 

Good Practice:
The deletion function in most operating systems allows deleted data to be recovered, so instead, a dedicated secure deletion function or application should be used to make data unrecoverable. 

Examples:
Methods for securely destroying electronic media include secure wiping in accordance with industry-accepted standards for secure deletion, degaussing, or physical destruction (such as grinding or shredding hard disks). 

Further Information:
See NIST Special Publication 800-88, Revision 1: Guidelines for Media Sanitization 

9.5.1
Defined Approach Requirements: 
POI devices that capture payment card data via direct physical interaction with the payment card form factor are protected from tampering and unauthorized substitution, including the following:

Customized Approach Objective:
The entity has defined procedures to protect and manage point of interaction devices. Expectations, controls, and oversight for the management and protection of POI devices are defined and adhered to by affected personnel. 

Applicability Notes:
These requirements apply to deployed POI devices used in card-present transactions (that is, a payment card form factor such as a card that is swiped, tapped, or dipped). 
This requirement is not intended to apply to manual PAN key-entry components such as computer keyboards. This requirement is recommended, but not required, for manual PAN key-entry components such as computer keyboards. 
This requirement does not apply to commercial offthe-shelf (COTS) devices (for example, smartphones or tablets), which are mobile merchant-owned devices designed for mass-market distribution. 

Defined Approach Testing Procedures:

Purpose:
riminals attempt to steal payment card data by stealing and/or manipulating card-reading devices and terminals. Criminals will try to steal devices so they can learn how to break into them, and they often try to replace legitimate devices with fraudulent devices that send them payment card data every time a card is entered. 
They will also try to add “skimming” components to the outside of devices, which are designed to capture payment card data before it enters the device—for example, by attaching an additional card reader on top of the legitimate card reader so that the payment card data is captured twice: once by the criminal’s component and then by the device’s legitimate component. In this way, transactions may still be completed without interruption while the criminal is “skimming” the payment card data during the process. 

Good Practice:
Additional best practices on skimming prevention are available on the PCI SSC website. 

9.5.1.1
Defined Approach Requirements: 
An up-to-date list of POI devices is maintained, including:

Customized Approach Objective:
The identity and location of POI devices is recorded and known at all times. 

Defined Approach Testing Procedures:

Purpose:
Keeping an up-to-date list of POI devices helps an organization track where devices are supposed to be and quickly identify if a device is missing or lost. 

Good Practice:
The method for maintaining a list of devices may be automated (for example, a devicemanagement system) or manual (for example, documented in electronic or paper records). For on-the-road devices, the location may include the name of the personnel to whom the device is assigned. 

Examples:
Methods to maintain device locations include identifying the address of the site or facility where the device is located. 

9.5.1.2
Defined Approach Requirements: 
POI device surfaces are periodically inspected to detect tampering and unauthorized substitution. 

Customized Approach Objective:
Point of Interaction Devices cannot be tampered with, substituted without authorization, or have skimming attachments installed without timely detection. 
Defined Approach Testing Procedures:

Purpose:
Regular inspections of devices will help organizations detect tampering more quickly via external evidence—for example, the addition of a card skimmer—or replacement of a device, thereby minimizing the potential impact of using fraudulent devices. 

Good Practice:
Methods for periodic inspection include checking the serial number or other device characteristics and comparing the information to the list of POI devices to verify the device has not been swapped with a fraudulent device. 

Examples:
The type of inspection will depend on the device. For instance, photographs of devices known to be secure can be used to compare a device’s current appearance with its original appearance to see whether it has changed. Another option may be to use a secure marker pen, such as a UV light marker, to mark device surfaces and device openings so any tampering or replacement will be apparent. Criminals will often replace the outer casing of a device to hide their tampering, and these methods may help to detect such activities. Device vendors may also provide security guidance and “how to” guides to help determine whether the device has been subject to tampering. 
Signs that a device might have been tampered with or substituted include:

9.5.1.2.1
Defined Approach Requirements: 
The frequency of periodic POI device inspections and the type of inspections performed is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1. 

Customized Approach Objective:
POI devices are inspected at a frequency that addresses the entity’s risk. 

Applicability Notes:
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
Entities are best placed to determine the frequency of POI device inspections based on the environment in which the device operates. 

Good Practice:
The frequency of inspections will depend on factors such as the location of a device and whether the device is attended or unattended. For example, devices left in public areas without supervision by the organization’s personnel might have more frequent inspections than devices kept in secure areas or supervised when accessible to the public. In addition, many POI vendors include guidance in their user documentation about how often POI devices should be checked, and for what – entities should consult their vendors’ documentation and incorporate those recommendations into their periodic inspections. 

9.5.1.3
Defined Approach Requirements: 
Training is provided for personnel in POI environments to be aware of attempted tampering or replacement of POI devices, and includes:

Customized Approach Objective:
Personnel are knowledgeable about the types of attacks against POI devices, the entity’s technical and procedural countermeasures, and can access assistance and guidance when required. 

Defined Approach Testing Procedures:

Purpose:
Criminals will often pose as authorized maintenance personnel to gain access to POI devices. 

Good Practice:
Personnel training should include being alert to and questioning anyone who shows up to do POI maintenance to ensure they are authorized and have a valid work order, including any agents, maintenance or repair personnel, technicians, service providers, or other third parties. All third parties requesting access to devices should always be verified before being provided access—for example, by checking with management or phoning the POI maintenance company, such as the vendor or acquirer, for verification. Many criminals will try to fool personnel by dressing for the part (for example, carrying toolboxes and dressed in work apparel), and could also be knowledgeable about locations of devices, so personnel should be trained to always follow procedures. 
Another trick that criminals use is to send a “new” POI device with instructions for swapping it with a legitimate device and “returning” the legitimate device. The criminals may even provide return postage to their specified address. Therefore, personnel should always verify with their manager or supplier that the device is legitimate and came from a trusted source before installing it or using it for business. 

Examples:
Suspicious behavior that personnel should be aware of includes attempts by unknown persons to unplug or open devices. 
Ensuring personnel are aware of mechanisms for reporting suspicious behavior and who to report such behavior to—for example, a manager or security officer—will help reduce the likelihood and potential impact of a device being tampered with or substituted. 

10.1.1
Defined Approach Requirements: 
All security policies and operational procedures that are identified in Requirement 10 are:

Customized Approach Objective:
Expectations, controls, and oversight for meeting activities within Requirement 10 are defined and adhered to by affected personnel. All supporting activities are repeatable, consistently applied, and conform to management’s intent 

Defined Approach Testing Procedures:

Purpose:
Requirement 10.1.1 is about effectively managing and maintaining the various policies and procedures specified throughout Requirement 10. While it is important to define the specific policies or procedures called out in Requirement 10, it is equally important to ensure they are properly documented, maintained, and disseminated. 

Good Practice:
It is important to update policies and procedures as needed to address changes in processes, technologies, and business objectives. For this reason, consider updating these documents as soon as possible after a change occurs and not only on a periodic cycle. 

Definitions:
Security policies define the entity’s security objectives and principles. Operational procedures describe how to perform activities, and define the controls, methods, and processes that are followed to achieve the desired result in a consistent manner and in accordance with policy objectives. 

10.1.2
Defined Approach Requirements: 
Roles and responsibilities for performing activities in Requirement 10 are documented, assigned, and understood. 

Customized Approach Objective:
Day-to-day responsibilities for performing all the activities in Requirement 10 are allocated. Personnel are accountable for successful, continuous operation of these requirements. 

Defined Approach Testing Procedures:

Purpose:
If roles and responsibilities are not formally assigned, personnel may not be aware of their day-to-day responsibilities and critical activities may not occur. 

Good Practice:
Roles and responsibilities may be documented within policies and procedures or maintained within separate documents. 
As part of communicating roles and responsibilities, entities can consider having personnel acknowledge their acceptance and understanding of their assigned roles and responsibilities. 

Examples:
A method to document roles and responsibilities is a responsibility assignment matrix that includes who is responsible, accountable, consulted, and informed (also called a RACI matrix). 

10.2.1
Defined Approach Requirements: 
Audit logs are enabled and active for all system components and cardholder data. 

Customized Approach Objective:
Records of all activities affecting system components and cardholder data are captured. 

Defined Approach Testing Procedures:

Purpose:
Audit logs must exist for all system components. Audit logs send alerts the system administrator, provides data to other monitoring mechanisms, such as intrusion-detection systems (IDS) and security information and event monitoring systems (SIEM) tools, and provide a history trail for post-incident investigation. 
Logging and analyzing security-relevant events enable an organization to identify and trace potentially malicious activities. 

Good Practice:
When an entity considers which information to record in their logs, it is important to remember that information stored in audit logs is sensitive and should be protected per requirements in this standard. Care should be taken to only store essential information in the audit logs to minimize risk.

10.2.1.1
Defined Approach Requirements: 
Audit logs capture all individual user access to cardholder data. 

Customized Approach Objective:
Records of all individual user access to cardholder data are captured. 

Defined Approach Testing Procedures:

Purpose:
It is critical to have a process or system that links user access to system components accessed. Malicious individuals could obtain knowledge of a user account with access to systems in the CDE, or they could create a new, unauthorized account to access cardholder data. 

Good Practice:
A record of all individual access to cardholder data can identify which accounts may have been compromised or misused. 

10.2.1.2
Defined Approach Requirements: 
Audit logs capture all actions taken by any individual with administrative access, including any interactive use of application or system accounts. 

Customized Approach Objective:
Records of all actions performed by individuals with elevated privileges are captured. 

Defined Approach Testing Procedures:

Purpose:
Accounts with increased access privileges, such as the “administrator” or “root” account, have the potential to significantly impact the security or operational functionality of a system. Without a log of the activities performed, an organization is cannot trace any issues resulting from an administrative mistake or misuse of privilege back to the specific action and account. 

Definitions:
Accounts with administrative access are those assigned with specific privileges or abilities for that account to manage systems, networks, and/or applications. The functions or activities considered to be administrative are beyond those performed by regular users as part of routine business functions 

10.2.1.3
Defined Approach Requirements: 
Audit logs capture all access to audit logs. 

Customized Approach Objective:
Records of all access to audit logs are captured 

Defined Approach Testing Procedures:

Purpose:
Malicious users often attempt to alter audit logs to hide their actions. A record of access allows an organization to trace any inconsistencies or potential tampering of the logs to an individual account. Having logs identify changes, additions, and deletions to the audit logs can help retrace steps made by unauthorized personnel. 

10.2.1.4
Defined Approach Requirements: 
Audit logs capture all invalid logical access attempts. 

Customized Approach Objective:
Records of all invalid access attempts are captured 

Defined Approach Testing Procedures:

Purpose:
Malicious individuals will often perform multiple access attempts on targeted systems. Multiple invalid login attempts may be an indication of an unauthorized user’s attempts to “brute force” or guess a password. 

10.2.1.5
Defined Approach Requirements: 
Audit logs capture all changes to identification and authentication credentials including, but not limited to:

Customized Approach Objective:
Records of all changes to identification and authentication credentials are captured. 

Defined Approach Testing Procedures:

Purpose:
Logging changes to authentication credentials (including elevation of privileges, additions, and deletions of accounts with administrative access) provides residual evidence of activities. 
Malicious users may attempt to manipulate authentication credentials to bypass them or impersonate a valid account. 

10.2.1.6
Defined Approach Requirements: 
Audit logs capture the following:

Customized Approach Objective:
Records of all changes to audit log activity status are captured. 

Defined Approach Testing Procedures:

Purpose:
Turning off or pausing audit logs before performing illicit activities is common practice for malicious users who want to avoid detection. Initialization of audit logs could indicate that that a user disabled the log function to hide their actions. 

10.2.1.7
Defined Approach Requirements: 
Audit logs capture all creation and deletion of system-level objects. 

Customized Approach Objective:
Records of alterations that indicate a system has been modified from its intended functionality are captured. 

Defined Approach Testing Procedures:

Purpose:
Malicious software, such as malware, often creates or replaces system-level objects on the target system to control a particular function or operation on that system. By logging when system-level objects are created or deleted, it will be easier to determine whether such modifications were authorized. 

10.2.2
Defined Approach Requirements: 
Audit logs record the following details for each auditable event:

Customized Approach Objective:
Sufficient data to be able to identify successful and failed attempts and who, what, when, where, and how for each event listed in requirement 10.2.1 are captured. 

Defined Approach Testing Procedures:

Purpose:
By recording these details for the auditable events at 10.2.1.1 through 10.2.1.7, a potential compromise can be quickly identified, with sufficient detail to facilitate following up on suspicious activities. 

10.3.1
Defined Approach Requirements: 
Read access to audit logs files is limited to those with a job-related need. 

Customized Approach Objective:
Stored activity records cannot be accessed by unauthorized personnel. 

Defined Approach Testing Procedures:

Purpose:
Audit log files contain sensitive information, and read access to the log files must be limited only to those with a valid business need. This access includes audit log files on the originating systems as well as anywhere else they are stored. 

Good Practice:
Adequate protection of the audit logs includes strong access control that limits access to logs based on “need to know” only and the use of physical or network segregation to make the logs harder to find and modify. 

10.3.2
Defined Approach Requirements: 
Audit log files are protected to prevent modifications by individuals. 

Customized Approach Objective:
Stored activity records cannot be modified by personnel. 

Defined Approach Testing Procedures:

Purpose:
Often a malicious individual who has entered the network will try to edit the audit logs to hide their activity. Without adequate protection of audit logs, their completeness, accuracy, and integrity cannot be guaranteed, and the audit logs can be rendered useless as an investigation tool after a compromise. Therefore, audit logs should be protected on the originating systems as well as anywhere else they are stored. 

Good Practice:
Entities should attempt to prevent logs from being exposed in public-accessible locations. 

10.3.3
Defined Approach Requirements: 
Audit log files, including those for externalfacing technologies, are promptly backed up to a secure, central, internal log server(s) or other media that is difficult to modify. 

Customized Approach Objective:
Stored activity records are secured and preserved in a central location to prevent unauthorized modification. 

Defined Approach Testing Procedures:

Purpose:
Promptly backing up the logs to a centralized log server or media that is difficult to alter keeps the logs protected, even if the system generating the logs becomes compromised. 
Writing logs from external-facing technologies such as wireless, network security controls, DNS, and mail servers, reduces the risk of those logs being lost or altered. 

Good Practice:
Each entity determines the best way to back up log files, whether via one or more centralized log servers or other secure media. Logs may be written directly, offloaded, or copied from external systems to the secure internal system or media. 

10.3.4
Defined Approach Requirements: 
File integrity monitoring or change-detection mechanisms is used on audit logs to ensure that existing log data cannot be changed without generating alerts. 

Customized Approach Objective:
Stored activity records cannot be modified without an alert being generated. 

Defined Approach Testing Procedures:

Purpose:
File integrity monitoring or change-detection systems check for changes to critical files and notify when such changes are identified. For file integrity monitoring purposes, an entity usually monitors files that do not regularly change, but when changed, indicate a possible compromise. 

Good Practice:
Software used to monitor changes to audit logs should be configured to provide alerts when existing log data or files are changed or deleted. However, new log data being added to an audit log should not generate an alert. 

10.4.1
Defined Approach Requirements: 
The following audit logs are reviewed at least once daily:

Customized Approach Objective:
Potentially suspicious or anomalous activities are quickly identified to minimize impact. 

Defined Approach Testing Procedures:

Purpose:
Many breaches occur months before being detected. Regular log reviews mean incidents can be quickly identified and proactively addressed. 

Good Practice:
Checking logs daily (7 days a week, 365 days a year, including holidays) minimizes the amount of time and exposure of a potential breach. Log harvesting, parsing, and alerting tools, centralized log management systems, event log analyzers, and security information and event management (SIEM) solutions are examples of automated tools that can be used to meet this requirement. 
Daily review of security events—for example, notifications or alerts that identify suspicious or anomalous activities—as well as logs from critical system components, and logs from systems that perform security functions, such as firewalls, IDS/IPS, file integrity monitoring (FIM) systems, etc., is necessary to identify potential issues. 
The determination of “security event” will vary for each organization and may include consideration for the type of technology, location, and function of the device. Organizations may also wish to maintain a baseline of “normal” traffic to help identify anomalous behavior. 
An entity that uses third-party service providers to perform log review services is responsible to provide context about the entity’s environment to the service providers, so it understands the entity’s environment, has a baseline of “normal” traffic for the entity, and can detect potential security issues and provide accurate exceptions and anomaly notifications. 

10.4.1.1
Defined Approach Requirements: 
Automated mechanisms are used to perform audit log reviews. 

Customized Approach Objective:
Potentially suspicious or anomalous activities are identified via a repeatable and consistent mechanism. 

Applicability Notes:
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
Manual log reviews are difficult to perform, even for one or two systems, due to the amount of log data that is generated. However, using log harvesting, parsing, and alerting tools, centralized log management systems, event log analyzers, and security information and event management (SIEM) solutions can help facilitate the process by identifying log events that need to be reviewed. 

Good Practice:
The entity should keep logging tools aligned with any changes in their environment by periodically reviewing tool settings and updating settings to reflect any changes. 

10.4.2
Defined Approach Requirements: 
Logs of all other system components (those not specified in Requirement 10.4.1) are reviewed periodically. 

Customized Approach Objective:
Potentially suspicious or anomalous activities for other system components (not included in 10.4.1) are reviewed in accordance with the entity’s identified risk.

Applicability Notes:
This requirement is applicable to all other in-scope system components not included in Requirement 10.4.1. 

Defined Approach Testing Procedures:

Purpose:
Periodic review of logs for all other system components (not specified in Requirement 10.4.1) helps to identify indications of potential issues or attempts to access critical systems via less-critical systems. 

10.4.2.1
Defined Approach Requirements: 
The frequency of periodic log reviews for all other system components (not defined in Requirement 10.4.1) is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1 

Customized Approach Objective:
Log reviews for lower-risk system components are performed at a frequency that addresses the entity’s risk. 

Applicability Notes:
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
Entities can determine the optimum period to review these logs based on criteria such as the complexity of each entity’s environment, the number of types of systems that are required to be evaluated, and the functions of such systems. 

10.4.3
Defined Approach Requirements: 
Exceptions and anomalies identified during the review process are addressed. 

Customized Approach Objective:
Suspicious or anomalous activities are addressed. 

Defined Approach Testing Procedures:

Purpose:
If exceptions and anomalies identified during the log-review process are not investigated, the entity may be unaware of unauthorized and potentially malicious activities occurring within their network. 

Good Practice:
Entities should consider how to address the following when developing their processes for defining and managing exceptions and anomalies:

10.5.1
Defined Approach Requirements: 
Retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis. 

Customized Approach Objective:
Historical records of activity are available immediately to support incident response and are retained for at least 12 months. 

Defined Approach Testing Procedures:

Good Practice:
Retaining historical audit logs for at least 12 months is necessary because compromises often go unnoticed for significant lengths of time. Having centrally stored log history allows investigators to better determine the length of time a potential breach was occurring, and the possible system(s) impacted. By having three months of logs immediately available, an entity can quickly identify and minimize impact of a data breach. 

Examples:
 Methods that allow logs to be immediately available include storing logs online, archiving logs, or restoring logs quickly from backups. 

10.6.1
Defined Approach Requirements: 
System clocks and time are synchronized using time-synchronization technology 

Customized Approach Objective:
Common time is established across all systems. 

Applicability Notes:
Keeping time-synchronization technology current includes managing vulnerabilities and patching the technology according to PCI DSS Requirements 6.3.1 and 6.3.3. 

Defined Approach Testing Procedures:

Purpose:
Time synchronization technology is used to synchronize clocks on multiple systems. When clocks are not properly synchronized, it can be difficult, if not impossible, to compare log files from different systems and establish an exact sequence of events, which is crucial for forensic analysis following a breach. 
For post-incident forensics teams, the accuracy and consistency of time across all systems and the time of each activity are critical in determining how the systems were compromised. 

Examples:
Network Time Protocol (NTP) is one example of time-synchronization technology. 

10.6.2
Defined Approach Requirements: 
Systems are configured to the correct and consistent time as follows:

Customized Approach Objective:
The time on all systems is accurate and consistent. 

Defined Approach Testing Procedures:

Purpose:
Using reputable time servers is a critical component of the time synchronization process. 
Accepting time updates from specific, industryaccepted external sources helps prevent a malicious individual from changing time settings on systems. 

Good Practice:
Another option to prevent unauthorized use of internal time servers is to encrypt updates with a symmetric key and create access control lists that specify the IP addresses of client machines that will be provided with the time updates. 

10.6.3
Defined Approach Requirements: 
Time synchronization settings and data are protected as follows:

Customized Approach Objective:
System time settings cannot be modified by unauthorized personnel. 

Defined Approach Testing Procedures:

Purpose:
Attackers will try to change time configurations to hide their activity. Therefore, restricting the ability to change or modify time synchronization configurations or the system time to administrators will lessen the probability of an attacker successfully changing time configurations. 

10.7.1
Defined Approach Requirements: 
Additional requirement for service providers only: Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems:

Customized Approach Objective:
Failures in critical security control systems are promptly identified and addressed. 

Applicability Notes:
This requirement applies only when the entity being assessed is a service provider. 
This requirement will be superseded by Requirement 10.7.2 as of 31 March 2025. 

Defined Approach Testing Procedures:

Purpose:
Without formal processes to detect and alert when critical security controls fail, failures may go undetected for extended periods and provide attackers ample time to compromise system components and steal account data from the CDE. 

Good Practice:
The specific types of failures may vary, depending on the function of the device system component and technology in use. Typical failures include a system ceasing to perform its security function or not functioning in its intended manner, such as a firewall erasing all its rules or going offline. 

10.7.2
Defined Approach Requirements: 
Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems:

Customized Approach Objective:
Failures in critical security control systems are promptly identified and addressed. 

Applicability Notes:
This requirement applies to all entities, including service providers, and will supersede Requirement 10.7.1 as of 31 March 2025. It includes two additional critical security control systems not in Requirement 10.7.1. 
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
Without formal processes to detect and alert when critical security controls fail, failures may go undetected for extended periods and provide attackers ample time to compromise system components and steal account data from the CDE. 

Good Practice:
The specific types of failures may vary, depending on the function of the device system component and technology in use. However, typical failures include a system no longer performing its security function or not functioning in its intended manner—for example, a firewall erasing its rules or going offline. 

10.7.3
Defined Approach Requirements: 
Failures of any critical security controls systems are responded to promptly, including but not limited to:

Customized Approach Objective:
Failures of critical security control systems are analyzed, contained, and resolved, and security controls restored to minimize impact. Resulting security issues are addressed, and measures taken to prevent reoccurrence. 

Applicability Notes:
This requirement applies only when the entity being assessed is a service provider until 31 March 2025, after which this requirement will apply to all entities. 
This is a current v3.2.1 requirement that applies to service providers only. However, this requirement is a best practice for all other entities until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
If alerts from failures of critical security control systems are not responded to quickly and effectively, attackers may use this time to insert malicious software, gain control of a system, or steal data from the entity’s environment. 

Good Practice:
Documented evidence (for example, records within a problem management system) should provide support that processes and procedures are in place to respond to security failures. In addition, personnel should be aware of their responsibilities in the event of a failure. Actions and responses to the failure should be captured in the documented evidence. 

11.1.1
Defined Approach Requirements: 
All security policies and operational procedures that are identified in Requirement 11 are:

Customized Approach Objective:
Expectations, controls, and oversight for meeting activities within Requirement 11 are defined and adhered to by affected personnel. All supporting activities are repeatable, consistently applied, and conform to management’s intent. 

Defined Approach Testing Procedures:

Purpose:
Requirement 11.1.1 is about effectively managing and maintaining the various policies and procedures specified throughout Requirement 11. While it is important to define the specific policies or procedures called out in Requirement 11, it is equally important to ensure they are properly documented, maintained, and disseminated. 

Good Practice:
It is important to update policies and procedures as needed to address changes in processes, technologies, and business objectives. For this reason, consider updating these documents as soon as possible after a change occurs and not only on a periodic cycle. 

Definitions:
Security policies define the entity’s security objectives and principles. Operational procedures describe how to perform activities, and define the controls, methods, and processes that are followed to achieve the desired result in a consistent manner and in accordance with policy objectives. 

11.1.2
Defined Approach Requirements: 
Roles and responsibilities for performing activities in Requirement 11 are documented, assigned, and understood. 

Customized Approach Objective:
Day-to-day responsibilities for performing all the activities in Requirement 11 are allocated. Personnel are accountable for successful, continuous operation of these requirements. 

Defined Approach Testing Procedures:

Purpose:
If roles and responsibilities are not formally assigned, personnel may not be aware of their day-to-day responsibilities and critical activities may not occur. 

Good Practice:
Roles and responsibilities may be documented within policies and procedures or maintained within separate documents. 
As part of communicating roles and responsibilities, entities can consider having personnel acknowledge their acceptance and understanding of their assigned roles and responsibilities. 

Examples:
A method to document roles and responsibilities is a responsibility assignment matrix that includes who is responsible, accountable, consulted, and informed (also called a RACI matrix). 

11.2.1
Defined Approach Requirements: 
 Authorized and unauthorized wireless access points are managed as follows:

Customized Approach Objective:
Unauthorized wireless access points are identified and addressed periodically. 

Applicability Notes:
The requirement applies even when a policy exists that prohibits the use of wireless technology since attackers do not read and follow company policy. 
Methods used to meet this requirement must be sufficient to detect and identify both authorized and unauthorized devices, including unauthorized devices attached to devices that themselves are authorized. 

Defined Approach Testing Procedures:

Purpose:
Implementation and/or exploitation of wireless technology within a network are common paths for malicious users to gain unauthorized access to the network and cardholder data. Unauthorized wireless devices could be hidden within or attached to a computer or other system component. These devices could also be attached directly to a network port, to a network device such as a switch or router, or inserted as a wireless interface card inside a system component. 
If a wireless device or network is installed without a company’s knowledge, it can allow an attacker to enter the network easily and “invisibly.” Detecting and removing such unauthorized access points reduces the duration and likelihood of such devices being leveraged for an attack. 

Good Practice:
The size and complexity of an environment will dictate the appropriate tools and processes to be used to provide sufficient assurance that a rogue wireless access point has not been installed in the environment. 
For example, performing a detailed physical inspection of a single stand-alone retail kiosk in a shopping mall, where all communication components are contained within tamper-resistant and tamper-evident casings, may be sufficient to provide assurance that a rogue wireless access point has not been attached or installed. However, in an environment with multiple nodes (such as in a large retail store, call center, server room or data center), detailed physical inspection can be difficult. In this case, multiple methods may be combined, such as performing physical system inspections in conjunction with the results of a wireless analyzer. 

Definitions:
This is also referred to as rogue access point detection. 

Examples:
Methods that may be used include but are not limited to wireless network scans, physical/logical inspections of system components and infrastructure, network access control (NAC), or wireless IDS/IPS. NAC and wireless IDS/IPS are examples of automated monitoring tools. 

11.2.2
Defined Approach Requirements: 
An inventory of authorized wireless access points is maintained, including a documented business justification. 

Customized Approach Objective:
Unauthorized wireless access points are not mistaken for authorized wireless access points. 

Defined Approach Testing Procedures:

Purpose:
An inventory of authorized wireless access points can help administrators quickly respond when unauthorized wireless access points are detected. This helps to proactively minimize the 
exposure of CDE to malicious individuals. 

Good Practice:
If using a wireless scanner, it is equally important to have a defined list of known access points which, while not attached to the company’s network, will usually be detected during a scan. These non-company devices are often found in multi-tenant buildings or businesses located near one another. However, it is important to verify that these devices are not connected to the entity’s network port or through another networkconnected device and given an SSID resembling a nearby business. Scan results should note such devices and how it was determined that these devices could be “ignored.” In addition, detection of any unauthorized wireless access points that are determined to be a threat to the CDE should be managed following the entity’s incident response plan per Requirement 12.10.1. 

11.3.1
Defined Approach Requirements: 
Internal vulnerability scans are performed as follows:

Customized Approach Objective:
The security posture of all system components is verified periodically using automated tools designed to detect vulnerabilities operating inside the network. Detected vulnerabilities are assessed and rectified based on a formal risk assessment framework 

Applicability Notes:
It is not required to use a QSA or ASV to conduct internal vulnerability scans. 
Internal vulnerability scans can be performed by qualified, internal staff that are reasonably independent of the system component(s) being scanned (for example, a network administrator should not be responsible for scanning the network), or an entity may choose to have internal vulnerability scans performed by a firm specializing in vulnerability scanning. 

Defined Approach Testing Procedures:

Purpose:
Identifying and addressing vulnerabilities promptly reduces the likelihood of a vulnerability being exploited and the potential compromise of a system component or cardholder data. Vulnerability scans conducted at least every three months provide this detection and identification. 

Good Practice:
Vulnerabilities posing the greatest risk to the environment (for example, ranked high or critical per Requirement 6.3.1) should be resolved with the highest priority. 
Multiple scan reports can be combined for the quarterly scan process to show that all systems were scanned and all applicable vulnerabilities were resolved as part of the three-month vulnerability scan cycle. However, additional, documentation may be required to verify nonremediated vulnerabilities are in the process of being resolved. 
While scans are required at least once every three months, more frequent scans are recommended depending on the network complexity, frequency of change, and types of devices, software, and operating systems used. 

Definitions: 
A vulnerability scan is a combination of automated tools, techniques, and/or methods run against external and internal devices and servers, designed to expose potential vulnerabilities in applications, operating systems, and network devices that could be found and exploited by malicious individuals. 

11.3.1.1
Defined Approach Requirements: 
All other applicable vulnerabilities (those not ranked as high-risk or critical per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are managed as follows:

Customized Approach Objective:
Lower ranked vulnerabilities (lower than high or critical) are addressed at a frequency in accordance with the entity’s risk. 

Applicability Notes:
The timeframe for addressing lower-risk vulnerabilities is subject to the results of a risk analysis per Requirement 12.3.1 that includes (minimally) identification of assets being protected, threats, and likelihood and/or impact of a threat being realized. 
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
All vulnerabilities, regardless of criticality, provide a potential avenue of attack and must therefore be addressed periodically, with the vulnerabilities that expose the most risk addressed more quickly to limit the potential window of attack. 

11.3.1.2
Defined Approach Requirements: 
Internal vulnerability scans are performed via authenticated scanning as follows:

Customized Approach Objective:
Automated tools used to detect vulnerabilities can detect vulnerabilities local to each system, which are not visible remotely. 

Applicability Notes:
The authenticated scanning tools can be either host-based or network-based. 
“Sufficient” privileges are those needed to access system resources such that a thorough scan can be conducted that detects known vulnerabilities. 
This requirement does not apply to system components that cannot accept credentials for scanning. Examples of systems that may not accept credentials for scanning include some network and security appliances, mainframes, and containers. 
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
Authenticated scanning provides greater insight into an entity’s vulnerability landscape since it can detect vulnerabilities that unauthenticated scans cannot detect. Attackers may leverage vulnerabilities that an entity is unaware of because certain vulnerabilities will only be detected with authenticated scanning. 
Authenticated scanning can yield significant additional information about an organization’s vulnerabilities. 

Good Practice:
The credentials used for these scans should be considered highly privileged. They should be protected and controlled as such, following PCI DSS Requirements 7 and 8 (except for those requirements for multi-factor authentication and application and system accounts). 

11.3.1.3
Defined Approach Requirements: 
Internal vulnerability scans are performed after any significant change as follows:

Customized Approach Objective:
The security posture of all system components is verified following significant changes to the network or systems, by using automated tools designed to detect vulnerabilities operating inside the network. Detected vulnerabilities are assessed and rectified based on a formal risk assessment framework. 

Applicability Notes:
Authenticated internal vulnerability scanning per Requirement 11.3.1.2 is not required for scans performed after significant changes. 

Defined Approach Testing Procedures:

Purpose:
Scanning an environment after any significant changes ensures that changes were completed appropriately such that the security of the environment was not compromised because of the change. 

Good Practice:
Entities should perform scans after significant changes as part of the change process per Requirement 6.5.2 and before considering the change complete. All system components affected by the change will need to be scanned. 

11.3.2
Defined Approach Requirements: 
External vulnerability scans are performed as follows:

Customized Approach Objective:
This requirement is not eligible for the customized approach. 

Applicability Notes:
For initial PCI DSS compliance, it is not required that four passing scans be completed within 12 months if the assessor verifies: 1) the most recent scan result was a passing scan, 2) the entity has documented policies and procedures requiring scanning at least once every three months, and 3) vulnerabilities noted in the scan results have been corrected as shown in a re-scan(s). 
However, for subsequent years after the initial PCI DSS assessment, passing scans at least every three months must have occurred. 
ASV scanning tools can scan a vast array of network types and topologies. Any specifics about the target environment (for example, load balancers, third-party providers, ISPs, specific configurations, protocols in use, scan interference) should be worked out between the ASV and scan customer. 
Refer to the ASV Program Guide published on the PCI SSC website for scan customer responsibilities, scan preparation, etc. 

Defined Approach Testing Procedures:

Purpose:
Attackers routinely look for unpatched or vulnerable externally facing servers, which can be leveraged to launch a directed attack. Organizations must ensure these externally facing devices are regularly scanned for weaknesses and that vulnerabilities are patched or remediated to protect the entity. 
Because external networks are at greater risk of compromise, external vulnerability scanning must be performed at least once every three months by a PCI SSC Approved Scanning Vendor (ASV). 

Good Practice:
While scans are required at least once every three months, more frequent scans are recommended depending on the network complexity, frequency of change, and types of devices, software, and operating systems used. 
Multiple scan reports can be combined to show that all systems were scanned and that all applicable vulnerabilities were resolved as part of the three-month vulnerability scan cycle. However, additional documentation may be required to verify non-remediated vulnerabilities are in the process of being resolved. 

11.3.2.1
Defined Approach Requirements: 
External vulnerability scans are performed after any significant change as follows:

Customized Approach Objective:
The security posture of all system components is verified following significant changes to the network or systems, by using tools designed to detect vulnerabilities operating from outside the network. Detected vulnerabilities are assessed and rectified based on a formal risk assessment framework. 

Defined Approach Testing Procedures:

Purpose:
Scanning an environment after any significant changes ensures that changes were completed appropriately such that the security of the environment was not compromised because of the change. 

Good Practice:
Entities should include the need to perform scans after significant changes as part of the change process and before the change is considered complete. All system components affected by the change will need to be scanned. 

11.4.1
Defined Approach Requirements: 
A penetration testing methodology is defined, documented, and implemented by the entity, and includes:

Customized Approach Objective:
A formal methodology is defined for thorough technical testing that attempts to exploit vulnerabilities and security weaknesses via simulated attack methods by a competent manual attacker. 

Applicability Notes:
Testing from inside the network (or “internal penetration testing”) means testing from both inside the CDE and into the CDE from trusted and untrusted internal networks. 
Testing from outside the network (or “external penetration testing”) means testing the exposed external perimeter of trusted networks, and critical systems connected to or accessible to public network infrastructures. 

Defined Approach Testing Procedures:

Purpose:
Attackers spend a lot of time finding external and internal vulnerabilities to leverage to obtain access to cardholder data and then to exfiltrate that data. As such, entities need to test their networks thoroughly, just as an attacker would do. This testing allows the entity to identify and remediate weakness that might be leveraged to compromise the entity’s network and data, and then to take appropriate actions to protect the network and system components from such attacks. 

Good Practice:
Penetration testing techniques will differ based on an organization’s needs and structure and should be suitable for the tested environment—for example, fuzzing, injection, and forgery tests might be appropriate. The type, depth, and complexity of the testing will depend on the specific environment and the needs of the organization. 

Definitions:
Penetration tests simulate a real-world attack situation intending to identify how far an attacker could penetrate an environment, given differing amounts of information provided to the tester. This allows an entity to better understand its potential exposure and develop a strategy to defend against attacks. A penetration test differs from a vulnerability scan, as a penetration test is an active process that usually includes exploiting identified vulnerabilities. 
Scanning for vulnerabilities alone is not a penetration test, nor is a penetration test adequate if the focus is solely on trying to exploit vulnerabilities found in a vulnerability scan. Conducting a vulnerability scan may be one of the first steps, but it is not the only step a penetration tester will perform to plan the testing strategy. Even if a vulnerability scan does not detect known vulnerabilities, the penetration tester will often gain enough knowledge about the system to identify possible security gaps. 
Penetration testing is a highly manual process. While some automated tools may be used, the tester uses their knowledge of systems to gain access into an environment. Often the tester will chain several types of exploits together with the goal of breaking through layers of defenses. For example, if the tester finds a way to gain access to an application server, the tester will then use the compromised server as a point to stage a new attack based on the resources to which the server has access. In this way, a tester can simulate the techniques used by an attacker to identify areas of potential weakness in the environment. The testing of security monitoring and detection methods—for example, to confirm the effectiveness of logging and file integrity monitoring mechanisms, should also be considered. 

Further Information:
Refer to the Information Supplement: Penetration Testing Guidance for additional guidance. 
Industry-accepted penetration testing approaches include: 

11.4.2
Defined Approach Requirements: 
Internal penetration testing is performed:

Customized Approach Objective:
Internal system defenses are verified by technical testing according to the entity’s defined methodology as frequently as needed to address evolving and new attacks and threats and ensure that significant changes do not introduce unknown vulnerabilities 

Defined Approach Testing Procedures:

Purpose:
Internal penetration testing serves two purposes. Firstly, just like an external penetration test, it discovers vulnerabilities and misconfigurations that could be used by an attacker that had managed to get some degree of access to the internal network, whether that is because the attacker is an authorized user conducting unauthorized activities, or an external attacker that had managed to penetrate the entity’s perimeter. 
Secondly, internal penetration testing also helps entities to discover where their change control process failed by detecting previously unknown systems. Additionally, it verifies the status of many of the controls operating within the CDE. 
A penetration test is not truly a “test” because the outcome of a penetration test is not something that can be classified as a “pass” or a “fail.” The best outcome of a test is a catalog of vulnerabilities and misconfigurations that an entity did not know about and the penetration tester found them before an attacker could. A penetration test that found nothing is typically indicative of shortcomings of the penetration tester, rather than being a positive reflection of the security posture of the entity. 

Good Practice:
Some considerations when choosing a qualified resource to perform penetration testing include: 

Further Information:
Refer to the Information Supplement: Penetration Testing Guidance on the PCI SSC website for additional guidance. 

11.4.3
Defined Approach Requirements: 
External penetration testing is performed: 

Customized Approach Objective:
External system defenses are verified by technical testing according to the entity’s defined methodology as frequently as needed to address evolving and new attacks and threats, and to ensure that significant changes do not introduce unknown vulnerabilities. 

Defined Approach Testing Procedures:

11.4.4
Defined Approach Requirements: 
 Exploitable vulnerabilities and security weaknesses found during penetration testing are corrected as follows: 

Customized Approach Objective:
Vulnerabilities and security weaknesses found while verifying system defenses are mitigated. 

Defined Approach Testing Procedures:

Purpose:
The results of a penetration test are usually a prioritized list of vulnerabilities discovered by the exercise. Often a tester will have chained a number of vulnerabilities together to compromise a system component. Remediating the vulnerabilities found by a penetration test significantly reduces the probability that the same vulnerabilities will be exploited by a malicious attacker. 
Using the entity’s own vulnerability risk assessment process (see requirement 6.3.1) ensures that the vulnerabilities that pose the highest risk to the entity will be remediated more quickly. 

Good Practice:
As part of the entity’s assessment of risk, entities should consider how likely the vulnerability is to be exploited and whether there are other controls present in the environment to reduce the risk. 
Any weaknesses that point to PCI DSS requirements not being met should be addressed. 

11.4.5
Defined Approach Requirements: 
If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls as follows:

Customized Approach Objective:
 If segmentation is used, it is verified periodically by technical testing to be continually effective, including after any changes, in isolating the CDE from all outof-scope systems. 

Defined Approach Testing Procedures:

Purpose:
When an entity uses segmentation controls to isolate the CDE from internal untrusted networks, the security of the CDE is dependent on that segmentation functioning. Many attacks have involved the attacker moving laterally from what an entity deemed an isolated network into the CDE. Using penetration testing tools and techniques to validate that an untrusted network is indeed isolated from the CDE can alert the entity to a failure or misconfiguration of the segmentation controls, which can then be rectified. 

Good Practice:
Techniques such as host discovery and port scanning can be used to verify out-of-scope segments have no access to the CDE. 

11.4.6
Defined Approach Requirements: 
Additional requirement for service providers only: If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls as follows: 

Customized Approach Objective:
If segmentation is used, it is verified by technical testing to be continually effective, including after any changes, in isolating the CDE from out-of-scope systems. 

Applicability Notes:
This requirement applies only when the entity being assessed is a service provider. 

Defined Approach Testing Procedures:

Purpose:
Service providers typically have access to greater volumes of cardholder data or can provide an entry point that can be exploited to then compromise multiple other entities. Service providers also typically have larger and more complex networks that are subject to more frequent change. The probability of segmentation controls failing in complex and dynamic networks is greater in service provider environments. 
Validating segmentation controls more frequently is likely to discover such failings before they can be exploited by an attacker attempting to pivot laterally from an out-of-scope untrusted network to the CDE. 

Good Practice:
Although the requirement specifies that this scope validation is carried out at least once every