Document Diff - PCI Watch

Added p. 5

Table 1 shows the 12 principal PCI DSS requirements.

Table 1. Principal PCI DSS Requirements

Protect Account Data 3. Protect Stored Account Data. 4. Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks.

Maintain a Vulnerability Management Program 5. Protect All Systems and Networks from Malicious Software. 6. Develop and Maintain Secure Systems and Software.

Implement Strong Access Control Measures 7. Restrict Access to System Components and Cardholder Data by Business Need to Know. 8. Identify Users and Authenticate Access to System Components. 9. Restrict Physical Access to Cardholder Data.

Regularly Monitor and Test Networks 10. Log and Monitor All Access to System Components and Cardholder Data. 11. Test Security of Systems and Networks Regularly.

Maintain an Information Security Policy 12. Support Information Security with Organizational Policies and Programs.

This document, the Payment Card Industry Data Security Standard Requirements and Testing Procedures, consists of the 12 PCI DSS principal requirements, detailed security requirements, corresponding …

Added p. 7

 Guidance for PCI DSS Scoping and Network Segmentation  PCI SSC Cloud Computing Guidelines  Multi-Factor Authentication Guidance  Third-Party Security Assurance  Effective Daily Log Monitoring  Penetration Testing Guidance  Best Practices for Implementing a Security Awareness Program  Best Practices for Maintaining PCI DSS Compliance  PCI DSS for Large Organizations  Use of SSL/Early TLS and Impact on ASV Scans  Use of SSL/Early TLS for POS POI Terminal Connections  Tokenization Product Security Guidelines  Protecting Telephone-Based Payment Card Data Refer to the Document Library at www.pcisecuritystandards.org for information about these and other resources.

In addition, refer to Appendix G for definitions of PCI DSS terms.

PCI DSS is intended for all entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD) or could impact the security of the cardholder data environment (CDE). This includes all entities involved in payment card account …

Added p. 9

If an entity stores, processes, or transmits PAN, then a CDE exists to which PCI DSS requirements will apply. Some requirements may not be applicable, for example if the entity does not store PAN, then the requirements relating to the protection of stored PAN in Requirement 3 will not be applicable to the entity.

Even if an entity does not store, process, or transmit PAN, some PCI DSS requirements may still apply. Consider the following:

 If the entity stores SAD, requirements specifically related to SAD storage in Requirement 3 will be applicable.

 If the entity engages third-party service providers to store, process or transmit PAN on its behalf, requirements related to the management of service providers in Requirement 12 will be applicable.

 If the entity can impact the security of a CDE because the security of an entity’s infrastructure can affect how cardholder data is processed (for example, via a web …

Added p. 10

Table 3 identifies the elements of cardholder and sensitive authentication data, whether storage of each data element is permitted or prohibited, and whether each data element must be rendered unreadable

•for example, with strong cryptography

•when stored. This table is not exhaustive and is presented to illustrate only how the stated requirements apply to the different data elements.

Table 3. Account Data Element Storage Requirements Data Elements Storage Restrictions Required to Render Stored Data Unreadable Account Data Cardholder Primary Account Number (PAN) Storage is kept to a minimum as defined in

Requirement 3.2 Yes, as defined in Requirement 3.5 Cardholder Name Storage is kept to a minimum as defined in Requirement 3.2 2 No Service Code Expiration Date Sensitive Authentication Full Track Data Cannot be stored after authorization as defined in Requirement 3.3.1 3 Yes, data stored until authorization is complete must be protected with strong cryptography as defined in Requirement 3.3.2 Card verification …

Added p. 11

PCI SSC supports the use of secure payment software within cardholder data environments (CDE) via the Payment Application Data Security Standard (PA-DSS) and the Software Security Framework (SSF), which consists of the Secure Software Standard and the Secure Software Lifecycle (Secure SLC) Standard. Software that is PCI SSC validated and listed provides assurance that the software has been developed using secure practices and has met a defined set of software security requirements.

The PCI SSC secure software programs include listings of payment software and software vendors that have been validated as meeting the applicable PCI SSC Software Standards.

 Validated Software: Payment software listed on the PCI SSC website as a Validated Payment Application (PA-DSS) or Validated Payment Software (the Secure Software Standard) has been evaluated by a qualified assessor to confirm the software meets the security requirements within that standard. The security requirements in these standards are focused on protecting the …

Added p. 12

PCI DSS may apply to a payment software vendor if the vendor is also a service provider that stores, processes, or transmits account data, or has access to their customers’ account data•for example, in the role of a payment service provider or via remote access to a customer environment. Software vendors to which PCI DSS may be applicable include those offering payment services, as well as cloud service providers offering payment terminals in the cloud, software as a service (SaaS), e-commerce in the cloud, and other cloud payment services.

Bespoke and Custom Software All bespoke and custom software that stores, processes, or transmits account data, or that could impact the security of account data or a CDE, is in scope for an entity’s PCI DSS assessment.

Bespoke and custom software that has been developed and maintained in accordance with one of PCI SSC’s Software Security Framework standards (the Secure Software Standard or …

Added p. 13

PCI DSS requirements apply to:

 The cardholder data environment (CDE), which is comprised of:

• System components, people, and processes that store, process, and transmit cardholder data and/or sensitive authentication data, and,

• System components that may not store, process, or transmit CHD/SAD but have unrestricted connectivity to system components that store, process, or transmit CHD/SAD.

 System components, people, and processes that could impact the security of the CDE. 4 “System components” include network devices, servers, computing devices, virtual components, cloud components, and software. Examples of system components include but are not limited to:

 Systems that store, process, or transmit account data (for example, payment terminals, authorization systems, clearing systems, payment middleware systems, payment back-office systems, shopping cart and store front systems, payment gateway/switch systems, fraud monitoring systems).

 Systems that provide security services (for example, authentication servers, access control servers, security information and event management (SIEM) systems, physical security systems (for example, …

Added p. 14

 End-user devices, such as computers, laptops, workstations, administrative workstations, tablets, and mobile devices.

 Printers, and multi-function devices that scan, print, and fax.

 Storage of account data in any format (for example, paper, data files, audio files, images, and video recordings).

 Tools, code repositories, and systems that implement software configuration management or for deployment of objects to the CDE or to systems that can impact the CDE.

Figure 1 shows considerations for scoping system components for PCI DSS.

Added p. 16

The minimum steps for an entity to confirm the accuracy of their PCI DSS scope are specified in PCI DSS Requirement 12.5.2. The entity is expected to retain documentation to show how PCI DSS scope was determined. The documentation is retained for assessor review and for reference during the entity’s next PCI DSS scope confirmation activity. For each PCI DSS assessment, the assessor validates that the entity accurately defined and documented the scope of the assessment.

Note: This annual confirmation of PCI DSS scope is defined at PCI DSS Requirement at 12.5.2 and is an activity expected to be performed by the entity. This activity is not the same, nor is it intended to be replaced by, the scoping confirmation performed by the entity’s assessor during the assessment.

Added p. 17

If segmentation is used to reduce the scope of the PCI DSS assessment, the assessor must verify that the segmentation is adequate to reduce the scope of the assessment, as illustrated in Figure 2. At a high level, adequate segmentation isolates systems that store, process, or transmit account data from those that do not. However, the adequacy of a specific segmentation implementation is highly variable and depends on several factors such as a given network's configuration, the technologies deployed, and other controls that may be implemented.

Added p. 18

Rogue wireless detection must be performed per PCI DSS Requirement 11.2.1 even when wireless is not used within the CDE and the entity has a policy that prohibits the use of wireless technology within its environment. This is because of the ease with which a wireless access point can be attached to a network, the difficulty in detecting its presence, and the increased risk presented by unauthorized wireless devices.

Before wireless technology is implemented, an entity should carefully evaluate the need for the technology against the risk. Consider deploying wireless technology only for non-sensitive data transmission.

Encrypted Cardholder Data and Impact on PCI DSS Scope Encryption of cardholder data with strong cryptography is an acceptable method of rendering the data unreadable according to PCI DSS Requirement 3.5. However, encryption alone is generally insufficient to render the cardholder data out of scope for PCI DSS and does not remove the need for PCI …

Added p. 19

Note: A PCI-listed P2PE solution can significantly reduce the number of PCI DSS requirements applicable to a merchant’s cardholder data environment. However, it does not completely remove the applicability of PCI DSS in the merchant environment.

Encrypted Cardholder Data and Impact to PCI DSS Scope for Third-Party Service Providers Where a third-party service provider (TPSP) receives and/or stores only data encrypted by another entity, and where they do not have the ability to decrypt the data, the TPSP may be able to consider the encrypted data out of scope if certain conditions are met. This is because responsibility for the data generally remains with the entity, or entities, with the ability to decrypt the data or impact the security of the encrypted data. Determining which party is responsible for specific PCI DSS controls will depend on several factors, including who has access to the decryption keys, the role performed by each …

Added p. 20

Note: Use of a PCI DSS compliant TPSP does not make a customer PCI DSS compliant, nor does it remove the customer’s responsibility for its own PCI DSS compliance. Even if a customer uses a TPSP to meet all account data functions, that customer remains responsible for confirming its own compliance as requested by organizations that manage compliance programs (for example, payment brands and acquirers). Customers should contact the organizations of interest for any requirements.

Using TPSPs and the Impact on Customers Meeting PCI DSS Requirement 12.8 There are many different scenarios where a customer might use one or more TPSPs for functions within or related to the customer’s CDE. In all scenarios where a TPSP is used, the customer must manage and oversee the PCI DSS compliance status of all their TPSPs in accordance with Requirement 12.8, including TPSPs that:

 Have access to the customer’s CDE,  Manage in-scope system …

Added p. 21

Importance of Understanding Responsibilities Between TPSP Customers and TPSPs Customers and TPSPs should clearly identify and understand the following:

 The services and system components included in the scope of the TPSP’s PCI DSS assessment,  The specific PCI DSS requirements and sub-requirements covered by the TPSP’s PCI DSS assessment,  Any requirements that are the responsibility of the TPSP’s customers to include in their own PCI DSS assessments, and  Any PCI DSS requirements for which the responsibility is shared between the TPSP and its customers.

For example, a cloud provider should clearly define which of its IP addresses are scanned as part of its quarterly vulnerability scan process and which IP addresses are their customers’ responsibility to scan.

Per Requirement 12.9.2, TPSPs are required to support their customers’ requests for information about the TPSP’s PCI DSS compliance status related to the services provided to customers, and about which PCI DSS requirements …

Added p. 22

If the TPSP does not undergo its own PCI DSS assessment and therefore does not have an AOC, the TPSP is expected to provide specific evidence related to the applicable PCI DSS requirements, so that the customer (or its assessor) is able to confirm the TPSP is meeting those PCI DSS requirements.

TPSPs Presence on a Payment Brand List(s) of PCI DSS Compliant Service Providers For a customer that is monitoring a TPSP’s compliance status in accordance with Requirement 12.8, the TPSP’s presence on a payment brand’s list of PCI DSS compliant service providers may be sufficient evidence of the TPSP’s compliance status if it is clear from the list that the services applicable to the customer were covered by the TPSP’s PCI DSS assessment. If it is not clear from the list, the customer should obtain other written confirmation that addresses the TPSP’s PCI DSS compliance status.

For a customer that …

Added p. 23

Some PCI DSS requirements are intended to act as BAU processes by monitoring security controls to ensure their effectiveness on an ongoing basis. This oversight by the entity assists with providing reasonable assurance that the compliance of its environment is preserved between PCI DSS assessments. While there are currently some BAU requirements defined within the standard, an entity should adopt additional BAU processes specific to their organization and environment when possible. BAU processes are a way to verify that automated and manual controls are performing as expected. Regardless of whether a PCI DSS requirement is automated or manual, it is important for BAU processes to detect anomalies, and alert and report so that responsible individuals address the situation in a timely manner.

Examples of how PCI DSS should be incorporated into BAU activities include but are not limited to:

 Assigning overall responsibility and accountability for PCI DSS compliance to an individual …

Added p. 27

The assessor is required to use professional judgment in the planning, performance, and evaluation of the sample to support their conclusion about whether and how the entity has met a requirement. The assessor’s goal in sampling is to obtain enough evidence to have a reasonable basis for their opinion. When independently selecting samples, assessors should consider the following:

 The assessor must select the sample from the complete population without influence from the assessed entity.

 If the entity has standardized processes and controls in place that ensure consistency and which is applied to each item in the population, the sample can be smaller than if the entity has no standardized processes/controls in place. The sample must be large enough to provide the assessor with reasonable assurance that items in the population adhere to the standardized processes that are applied to each item in the population. The assessor must verify that the …

Added p. 29

Table 4 outlines the frequency for the different time periods used in PCI DSS Requirements.

Table 4. PCI DSS Requirement Timeframes Timeframes in PCI DSS Requirements Descriptions and Examples Daily Every day of the year (not only on business days).

Weekly At least once every seven days.

Monthly At least once every 30 to 31 days, or on the nth day of the month.

Every three months (“quarterly”) At least once every 90 to 92 days, or on the nth day of each third month.

Every six months At least once every 180 to 184 days, or on the nth day of each sixth month.

Every 12 months (“annually”) At least once every 365 (or 366 for leap years) days or on the same date every year.

Periodically Frequency of occurrence is at the entity’s discretion and is documented and supported by the entity’s risk analysis. The entity must demonstrate that the frequency is appropriate for the …

Added p. 30

• New hardware, software, or networking equipment added to the CDE.

• Any replacement or major upgrades of hardware and software in the CDE.

• Any changes in the flow or storage of account data.

• Any changes to the boundary of the CDE and/or to the scope of the PCI DSS assessment.

• Any changes to the underlying supporting infrastructure of the CDE (including, but not limited to, changes to directory services, time servers, logging, and monitoring).

• Any changes to third party vendors/service providers (or services provided) that support the CDE or meet PCI DSS requirements on behalf of the entity.

For other PCI DSS requirements, where the standard does not define a minimum frequency for recurring activities but instead allows for the requirement to be met “periodically,” the entity is expected to define the frequency as appropriate for its business. The frequency defined by the entity must be supported by the entity’s security …

Added p. 31

Note: For an initial PCI DSS assessment (meaning an entity has never undergone a prior assessment), where a requirement has a defined timeframe within which an activity is to occur, it is not required that the activity has been performed for every such timeframe during the previous year, if the assessor verifies:

• The activity was performed in accordance with the applicable requirement within the most recent timeframe (for example, the most recent three-month or six-month period), and

• The entity has documented policies and procedures for continuing to perform the activity within the defined timeframe.

For subsequent years after the initial assessment, the activity must have been performed at least once within each required timeframe. For example, an activity required every three months must have been performed at least four times during the previous year at an interval that does not exceed 90-92 days.

Added p. 32

Defined Approach Follows the traditional method for implementing and validating PCI DSS and uses the Requirements and Testing Procedures defined within the standard. In the defined approach, the entity implements security controls to meet the stated requirements, and the assessor follows the defined testing procedures to verify that requirements have been met.

The defined approach supports entities with controls in place that meet PCI DSS requirements as stated. This approach may also suit entities that want more direction about how to meet security objectives, as well as entities new to information security or PCI DSS.

Compensating Controls As part of the defined approach, entities that cannot meet a PCI DSS requirement explicitly as stated due to a legitimate and documented technical or business constraint may implement other, or compensating, controls, that sufficiently mitigate the risk associated with the requirement. On an annual basis, any compensating controls must be documented by the entity …

Added p. 33

Entities can use both the defined and customized approaches within their environment. This means an entity could use the defined approach to meet some requirements and use the customized approach to meet other requirements. This also means that an entity could use the defined approach to meet a given PCI DSS requirement for one system component or within one environment and use the customized approach to meet that same PCI DSS requirement for a different system component or within a different environment. In this way, a PCI DSS assessment could include both defined and customized testing procedures.

Figure 4 shows the two validation options for PCI DSS v4.0.

Added p. 35

 The Report on Compliance or Self-Assessment Questionnaire (the associated Attestation of Compliance is not considered sensitive and third-party service providers (TPSPs) are expected to share their AOC with customers).

 Network diagrams and account data-flow diagrams, and security configurations and rules.

 System configuration standards.

 Cryptography and key management methods and protocols.

Entities should review all the artifacts related to PCI DSS controls or the assessment and protect them in accordance with the entity’s security policies for this type of information.

TPSPs are required (PCI DSS Requirement 12.9) to support their customers with the following:

 Information needed for customers to monitor the TPSPs’ PCI DSS compliance status (to enable the customer to comply with Requirement 12.8), and  Evidence that the TPSP is meeting applicable PCI DSS requirements where the TPSP’s services are intended to meet or facilitate meeting a customer’s PCI DSS requirements, or where those services may impact the security of …

Added p. 36

 Examine: The assessor critically evaluates data evidence. Common examples include documents (electronic or physical), screenshots, configuration files, audit logs, and data files.

 Observe: The assessor watches an action or views something in the environment. Examples of observation subjects include personnel performing a task or process, system components performing a function or responding to input, environmental conditions, and physical controls.

 Interview: The assessor converses with individual personnel. Interview objectives may include confirmation of whether an activity is performed, descriptions of how an activity is performed, and whether personnel have particular knowledge or understanding.

The testing methods are intended to allow the assessed entity to demonstrate how they have met a requirement. They also provide the assessed entity and the assessor with a common understanding of the assessment activities to be performed. The specific items to be examined or observed and personnel to be interviewed should be appropriate for both the requirement …

Added p. 39

Table 5 lists external organizations referenced within PCI DSS requirements or related guidance. These external organizations and their references are provided as information only and do not replace or extend any PCI DSS requirement.

Added p. 40

Table 6. PCI DSS Versions Version Published Retired

Figure 5 describes the column headings and content for the PCI DSS requirements.

Figure 5. Understanding the Parts of the Requirements Applicability Notes apply to both the Defined and Customized Approach. Includes information that affects how the requirement is interpreted in the context of the entity or in scoping. These notes are an integral part of PCI DSS and must be fully considered during an assessment.

Guidance provides information to understand how to meet a requirement. Guidance is not required to be followed

• it does not replace or extend any PCI DSS requirement. Not every Guidance section described here is present for each requirement. Not every section will be present for each requirement.

Purpose describes the goal, benefit, or threat to be avoided; why the requirement exists.

A Good Practice can be considered by the entity when meeting a requirement.

Definitions Terms that may help understand the requirement.

Examples …

Added p. 42

Appendices with Additional PCI DSS Requirements for Different Types of Entities In addition to the 12 principal requirements, PCI DSS Appendix A contains additional PCI DSS requirements for different types of entities. The sections within Appendix A include:

 Appendix A1: Additional PCI DSS Requirements for Multi-Tenant Service Providers.

 Appendix A2: Additional PCI DSS Requirements for Entities using SSL/Early TLS for Card-Present POS POI Terminal Connections.

 Appendix A3: Designated Entities Supplemental Validation (DESV).

Requirement 1: Install and Maintain Network Security Controls 1.1 Processes and mechanisms for installing and maintaining network security controls are defined and understood. 1.2 Network security controls (NSCs) are configured and maintained. 1.3 Network access to and from the cardholder data environment is restricted. 1.4 Network connections between trusted and untrusted networks are controlled. 1.5 Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.

Added p. 44

NSCs examine all network traffic entering (ingress) and leaving (egress) a segment and decide, based on the policies defined, whether the network traffic is allowed to pass or whether it should be rejected. Typically, NSCs are placed between environments with different security needs or levels of trust, however in some environments NSCs control the traffic to individual devices irrespective of trust boundaries. Policy enforcement generally occurs at layer 3 of the OSI model, but data present in higher layers is also frequently used to determine policy decisions.

Traditionally this function has been provided by physical firewalls; however, now this functionality may be provided by virtual devices, cloud access controls, virtualization/container systems, and other software-defined networking technology.

NSCs are used to control traffic within an entity’s own networks

•for example, between highly sensitive and less sensitive areas

•and also to protect the entity’s resources from exposure to untrusted networks. The cardholder data environment (CDE) is …

Added p. 45

Defined Approach Requirements 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.

Added p. 45

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.

Added p. 46

1.1.2.b Interview personnel responsible for performing activities in Requirement 1 to verify that roles and responsibilities are assigned as documented and are 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.

Added p. 47

Defined Approach Requirements 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.

Added p. 47

1.2.1.b Examine configuration settings for NSC rulesets to verify that rulesets are implemented according to the configuration standards. Customized Approach Objective The way that NSCs are configured and operate are defined and consistently applied.

Added p. 48

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.

Added p. 48

1.2.2.a Examine documented procedures to verify that changes to network connections and configurations of NSCs are included in the formal change control process in accordance with Requirement 6.5.1.

1.2.2.b Examine network configuration settings to identify changes made to network connections. Interview responsible personnel and examine change control records to verify that identified changes to network connections were approved and managed in accordance with Requirement 6.5.1.

1.2.2.c Examine network configuration settings to identify changes made to configurations of NSCs. Interview responsible personnel and examine change control records to verify that identified changes to configurations of NSCs were approved and managed in accordance with 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 …

Added p. 49

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:

• All locations, including retail locations, data centers, corporate locations, cloud providers, etc.

• Clear labeling of all network segments.

• All security controls providing segmentation, including unique identifiers for each control (for example, name of control, make, model, and version).

• All in-scope system components, including NSCs, web app firewalls, anti-malware solutions, change management solutions, IDS/IPS, log aggregation systems, payment terminals, payment applications, HSMs, etc.

• Clear labeling of any out-of-scope areas on the diagram via a shaded box or other mechanism.

• Date of last update, and names of people that made and approved the updates.

• A legend or …

Added p. 49

1.2.3.a Examine diagram(s) and network configurations to verify that an accurate network diagram(s) exists in accordance with all elements specified in this requirement.

1.2.3.b Examine documentation and interview responsible personnel to verify that the network diagram(s) is accurate and updated when there are changes to the environment. 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.

Added p. 50

• All processing flows of account data, including authorization, capture, settlement, chargeback, and refunds.

• All distinct acceptance channels, including card-present, card-not-present, and e- commerce.

• All types of data receipt or transmission, including any involving hard copy/paper media.

• The flow of account data from the point where it enters the environment, to its final disposition.

• Where account data is transmitted and processed, where it is stored, and whether storage is short term or long term. (continued on next page) 1.2.4 An accurate data-flow diagram(s) is maintained that meets the following:

• Shows all account data flows across systems and networks.

• Updated as needed upon changes to the environment.

1.2.4.a Examine data-flow diagram(s) and interview personnel to verify the diagram(s) show all account data flows in accordance with all elements specified in this requirement.

1.2.4.b Examine documentation and interview responsible personnel to verify that the data-flow diagram(s) is accurate and updated when there are changes …

Added p. 51

1.2.5.a Examine documentation to verify that a list exists of all allowed services, protocols, and ports, including business justification and approval for each.

1.2.5.b Examine configuration settings for NSCs to verify that only approved services, protocols, and ports are in use. Customized Approach Objective Unauthorized network traffic (services, protocols, or packets destined for specific ports) cannot enter or leave the network.

Added p. 52

1.2.6.a Examine documentation that identifies all insecure services, protocols, and ports in use to verify that for each, security features are defined to mitigate the risk.

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

Added p. 53

1.2.7.a Examine documentation to verify procedures are defined for reviewing configurations of NSCs at least once every six months.

1.2.7.b Examine documentation of reviews of configurations for NSCs and interview responsible personnel to verify that reviews occur at least once every six months.

1.2.7.c Examine configurations for NSCs to verify that configurations identified as no longer being supported by a business justification are removed or updated. 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.

Added p. 54

• Secured from unauthorized access.

• Kept consistent with active network configurations.

Added p. 54

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.

Added p. 55

Defined Approach Requirements 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.

Added p. 55

• To only traffic that is necessary.

• All other traffic is specifically denied.

1.3.1.a Examine configuration standards for NSCs to verify that they define restricting inbound traffic to the CDE is in accordance with all elements specified in this requirement.

1.3.1.b Examine configurations of NSCs to verify that inbound traffic to the CDE is restricted in accordance with all elements specified in this requirement. Customized Approach Objective Unauthorized traffic cannot enter the CDE.

• 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.

• To only traffic that is necessary.

• All other traffic is specifically denied.

Added p. 56

1.3.2.a Examine configuration standards for NSCs to verify that they define restricting outbound traffic from the CDE in accordance with all elements specified in this requirement.

1.3.2.b Examine configurations of NSCs to verify that outbound traffic from the CDE is restricted in accordance with all elements specified in this requirement. Customized Approach Objective Unauthorized traffic cannot leave the CDE.

Defined Approach Requirements 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.

Added p. 56

• All wireless traffic from wireless networks into the CDE is denied by default.

• Only wireless traffic with an authorized business purpose is allowed into the CDE.

Added p. 56

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

Added p. 57

Defined Approach Requirements 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.

Added p. 57

1.4.1.a Examine configuration standards and network diagrams to verify that NSCs are defined between trusted and untrusted networks.

1.4.1.b Examine network configurations to verify that NSCs are in place between trusted and untrusted networks, in accordance with the documented configuration standards and network diagrams.

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

Added p. 58

• Communications with system components that are authorized to provide publicly accessible services, protocols, and ports.

• Stateful responses to communications initiated by system components in a trusted network.

• All other traffic is denied.

Added p. 58

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.

Added p. 60

1.4.4.a Examine the data-flow diagram and network diagram to verify that it is documented that system components storing cardholder data are not directly accessible from the untrusted networks.

1.4.4.b Examine configurations of NSCs to verify that controls are implemented such that system components storing 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).

Added p. 61

• Placing system components behind proxy servers/NSCs.

• Removal or filtering of route advertisements for internal networks that use registered addressing.

• Internal use of RFC 1918 (IPv4) or use IPv6 privacy extension (RFC 4941) when initiating outgoing sessions to the internet.

Added p. 61

1.4.5.a Examine configurations of NSCs to verify that the disclosure of internal IP addresses and routing information is limited to only authorized parties.

1.4.5.b Interview personnel and examine documentation to verify that controls are implemented such that any 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.

Added p. 62

Defined Approach Requirements 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, network- based 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. (continued on next page) 1.5.1 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:

• Specific configuration settings are defined to prevent threats being introduced into the entity’s network.

• Security controls are …

Added p. 63

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.

Requirement 2: Apply Secure Configurations to All System Components 2.1 Processes and mechanisms for applying secure configurations to all system components are defined and understood. 2.2 System components are configured and managed securely. 2.3 Wireless environments are configured and managed securely.

Malicious individuals, both external and internal to an entity, often use default passwords and other vendor default settings to compromise systems. These passwords and settings …

Added p. 65

Defined Approach Requirements 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.

Added p. 67

Defined Approach Requirements 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 …

Added p. 67

• Cover all system components.

• Address all known security vulnerabilities.

• Be consistent with industry-accepted system hardening standards or vendor hardening recommendations.

• Be updated as new vulnerability issues are identified, as defined in Requirement 6.3.1.

• Be applied when new systems are configured and verified as in place before or immediately after a system component is connected to a production environment.

2.2.1.a Examine system configuration standards to verify they define processes that include all elements specified in this requirement.

2.2.1.b Examine policies and procedures and interview personnel to verify that system configuration standards are updated as new vulnerability issues are identified, as defined in Requirement 6.3.1.

2.2.1.c Examine configuration settings and interview personnel to verify that system configuration standards are applied when new systems are configured and verified as being in place before or immediately after a system component is connected to a production environment. Customized Approach Objective All system components are configured securely and …

Added p. 68

• If the vendor default account(s) will be used, the default password is changed per Requirement 8.3.6.

• If the vendor default account(s) will not be used, the account is removed or disabled.

2.2.2.a Examine system configuration standards to verify they include managing vendor default accounts in accordance with all elements specified in this requirement.

2.2.2.b Examine vendor documentation and observe a system administrator logging on using vendor default accounts to verify accounts are implemented in accordance with all elements specified in this requirement.

2.2.2.c Examine configuration files and interview personnel to verify that all vendor default accounts that will not be used are removed or disabled. 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 …

Added p. 69

• Only one primary function exists on a system component, OR

• Primary functions with differing security levels that exist on the same system component are isolated from each other, OR

• Primary functions with differing security levels on the same system component are all secured to the level required by the function with the highest security need.

2.2.3.a Examine system configuration standards to verify they include managing primary functions requiring different security levels as specified in this requirement.

2.2.3.b Examine system configurations to verify that primary functions requiring different security levels are managed per one of the ways specified in this requirement.

2.2.3.c Where virtualization technologies are used, examine the system configurations to verify that system functions requiring different security levels are managed in one of the following ways:

• Functions with differing security needs do not co-exist on the same system component.

• Functions with differing security needs that exist on the same system component …

Added p. 70

• The function of each application, container, or virtual server instance.

• How virtual machines (VMs) or containers are stored and secured.

Added p. 71

2.2.4.a Examine system configuration standards to verify necessary system services, protocols, and daemons are identified and documented.

2.2.4.b Examine system configurations to verify the following:

• All unnecessary functionality is removed or disabled.

• Only required functionality, as documented in the configuration standards, is enabled.

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

Added p. 72

• Additional security features are documented and implemented that reduce the risk of using insecure services, protocols, or daemons.

2.2.5.a If any insecure services, protocols, or daemons are present, examine system configuration standards and interview personnel to verify they are managed and implemented in accordance with all elements specified in this requirement.

2.2.5.b If any insecure services, protocols, or daemons, are present, examine configuration settings to verify that additional security features are implemented to reduce the risk of using insecure services, daemons, and protocols.

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

Added p. 73

2.2.6.a Examine system configuration standards to verify they include configuring system security parameters to prevent misuse.

2.2.6.b Interview system administrators and/or security managers to verify they have knowledge of common security parameter settings for system components.

2.2.6.c Examine system configurations to verify that common security parameters are set appropriately and in accordance with the system configuration standards. Customized Approach Objective System components cannot be compromised because of incorrect security parameter configuration.

Added p. 74

2.2.7.a Examine system configuration standards to verify they include encrypting all non-console administrative access using strong cryptography.

2.2.7.b Observe an administrator log on to system components and examine system configurations to verify that non-console administrative access is managed in accordance with this requirement.

2.2.7.c Examine settings for system components and authentication services to verify that insecure remote login services are not available for non- console administrative access.

2.2.7.d Examine vendor documentation and interview personnel to verify that strong cryptography for the technology in use is implemented according to industry best practices and/or vendor recommendations.

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

Applicability Notes This includes administrative access via browser- based interfaces and application programming interfaces (APIs).

Added p. 75

Defined Approach Requirements 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.

Added p. 75

• Default wireless encryption keys.

• Passwords on wireless access points.

• Any other security-related wireless vendor defaults.

2.3.1.a Examine policies and procedures and interview responsible personnel to verify that processes are defined for wireless vendor defaults to either change them upon installation or to confirm them to be secure in accordance with all elements of this requirement.

2.3.1.b Examine vendor documentation and observe a system administrator logging into wireless devices to verify:

• SNMP defaults are not used.

• Default passwords/passphrases on wireless access points are not used.

2.3.1.c Examine vendor documentation and wireless configuration settings to verify other security-related wireless vendor defaults were changed, if applicable. 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 security- related wireless vendor defaults.

Added p. 76

• Whenever personnel with knowledge of the key leave the company or the role for which the knowledge was necessary.

• Whenever a key is suspected of or known to be compromised.

Added p. 76

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

Requirement 3: Protect Stored Account Data 3.1 Processes and mechanisms for protecting stored account data are defined and understood. 3.2 Storage of account data is kept to a minimum. 3.3 Sensitive authentication data (SAD) is not stored after authorization. 3.4 Access to displays of full PAN and ability to copy cardholder data are restricted. 3.5 Primary account number (PAN) is secured wherever it is stored. 3.6 Cryptographic keys used to protect stored account data are secured. 3.7 Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.

If account data is present in non-persistent memory (for example, RAM, volatile memory), encryption of account data is not required. However, proper controls must be in place to ensure that memory maintains a non-persistent state. …

Added p. 79

3.1.2.a Examine documentation to verify that descriptions of roles and responsibilities performing activities in Requirement 3 are documented and assigned.

Added p. 80

Defined Approach Requirements 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 …

Added p. 81

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.

Added p. 82

Defined Approach Requirements 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.b If SAD is received, examine the documented procedures and observe the secure data deletion processes to verify the data is rendered unrecoverable upon completion of the authorization process.

Added p. 82

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.

Added p. 85

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.

Added p. 86

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 …

Added p. 87

• 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.

3.3.3.a Additional testing procedure for issuers and companies that support issuing services and store sensitive authentication data: Examine documented policies and interview personnel to verify there is a documented business justification for the storage of sensitive authentication data.

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

Added p. 89

Defined Approach Requirements 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 …

Added p. 90

3.4.2.a Examine documented policies and procedures and documented evidence for technical controls that prevent copy and/or relocation of PAN when using remote-access technologies onto local hard drives or removable electronic media to verify the following:

• Technical controls prevent all personnel not specifically authorized from copying and/or relocating PAN.

• A list of personnel with permission to copy and/or relocate PAN is maintained, together with the documented, explicit authorization and legitimate, defined business need.

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

Applicability Notes 3.4.2.b Examine configurations for remote-access technologies to verify that technical controls to prevent copy and/or relocation of PAN for all personnel, unless explicitly authorized. 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 …

Added p. 91

Defined Approach Requirements 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 Information For information about truncation formats and truncation in general, see PCI SSC’s FAQs on the topic. Sources for information about …

Added p. 92

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.

Added p. 92

3.5.1.1.a Examine documentation about the hashing method used to render PAN unreadable, including the vendor, type of system/process, and the encryption algorithms (as applicable) to verify that the hashing method results in keyed cryptographic hashes of the entire PAN, with associated key management processes and procedures.

Applicability Notes 3.5.1.1.b Examine documentation about the key management procedures and processes associated with the keyed cryptographic hashes to verify keys are managed in accordance with Requirements 3.6 and 3.7.

Added p. 93

• On removable electronic media

• If used for non-removable electronic media, PAN is also rendered unreadable via another mechanism that meets Requirement 3.5.1.

3.5.1.2.a Examine encryption processes to verify that, if disk-level or partition-level encryption is used to render PAN unreadable, it is implemented only as follows:

• On removable electronic media,

• If used for non-removable electronic media, examine encryption processes used to verify that PAN is also rendered unreadable via another method that meets Requirement 3.5.1.

3.5.1.2.b Examine configurations and/or vendor documentation and observe encryption processes to verify the system is configured according to vendor documentation the result is that the disk or the partition is rendered unreadable.

Added p. 95

• Logical access is managed separately and independently of native operating system authentication and access control mechanisms.

• Decryption keys are not associated with user accounts.

• Authentication factors (passwords, passphrases, or cryptographic keys) that allow access to unencrypted data are stored securely.

3.5.1.3.a If disk-level or partition-level encryption is used to render PAN unreadable, examine the system configuration and observe the authentication process to verify that logical access is implemented in accordance with all elements specified in this requirement.

3.5.1.3.b Examine files containing authentication factors (passwords, passphrases, or cryptographic keys) and interview personnel to verify that authentication factors that allow access to unencrypted data are stored securely and are independent from the native operating system’s authentication and access control methods.

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

Added p. 96

Defined Approach Requirements 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:

• ISO 11568-1 Banking

Added p. 96

• Part 1: Principles (specifically Chapter 10 and the referenced Parts 2 & 4)

• NIST SP 800-57 Part 1 Revision 5

• Recommendation for Key Management, Part 1: General.

Added p. 96

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

• Preventing the use of the same cryptographic keys in production and test environments. This bullet is a best practice until its effective date; refer to Applicability Notes below for details.

• Inventory of any hardware security modules (HSMs), key management systems (KMS), and other secure cryptographic devices (SCDs) used for key management, including type and location of devices, as outlined in Requirement 12.3.4.

Added p. 97

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.

Added p. 98

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:

• Using an approved random number generator and within an SCD, OR

• According to ISO 19592 or equivalent industry standard for generation of secret key shares.

Added p. 100

Defined Approach Requirements Defined Approach Testing Procedures Purpose Use of strong cryptographic keys significantly increases the level of security of encrypted account data. Further Information See the sources referenced at "Cryptographic Key Generation in Appendix G.

Added p. 100

3.7.1.a Examine the documented key-management policies and procedures for keys used for protection of stored account data to verify that they define generation of strong cryptographic keys.

Defined Approach Requirements 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.

Added p. 100

3.7.2.a Examine the documented key-management policies and procedures for keys used for protection of stored account data to verify that they define secure distribution of cryptographic keys.

3.7.2.b Observe the method for distributing keys to verify that keys are distributed securely. Customized Approach Objective Cryptographic keys are secured during distribution.

Added p. 101

3.7.3.a Examine the documented key-management policies and procedures for keys used for protection of stored account data to verify that they define secure storage of cryptographic keys.

Defined Approach Requirements 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 …

Added p. 101

• A defined cryptoperiod for each key type in use.

3.7.4.a Examine the documented key-management policies and procedures for keys used for protection of stored account data to verify that they define changes to cryptographic keys that have reached the end of their cryptoperiod and include all elements specified in this requirement.

3.7.4.b Interview personnel, examine documentation, and observe key storage locations to verify that keys are changed at the end of the defined cryptoperiod(s). Customized Approach Objective Cryptographic keys are not used beyond their defined cryptoperiod.

Added p. 102

• The key has reached the end of its defined cryptoperiod.

3.7.5.a Examine the documented key-management policies and procedures for keys used for protection of stored account data and verify that they define retirement, replacement, or destruction of keys in accordance with all elements specified in this requirement.

3.7.5.b Interview personnel to verify that processes are implemented in accordance with all elements specified in this requirement.

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

• According to ISO 19592 or equivalent industry standard for generation of secret key shares.

Added p. 103

3.7.6.b Interview personnel and/or observe processes to verify that manual cleartext keys are managed with 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 key- management 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:

• ISO 11568-2 Banking

Added p. 104

• NIST SP 800-57 Part 2, Revision 1 -- Recommendation for Key Management: Part 2

• Best Practices for Key Management Organizations [4.6 Keying Material Distribution]

• Part 2: Symmetric ciphers, their key management and life cycle [4.7.2.3 Key components and 4.9.3 Key components]

• European Payments Council EPC342-08 Guidelines on Cryptographic Algorithms Usage and Key Management [especially 4.1.4 Key installation].

Defined Approach Requirements 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.7.a Examine the documented key-management policies …

Added p. 105

• NIST SP 800-130 A Framework for Designing Cryptographic Key Management Systems [5. Roles and Responsibilities (especially) for Key Custodians]

• ISO 11568-1 Banking -- Key management (retail) -- Part 1: Principles [5 Principles of key management (especially b)] 3.7.8 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.

3.7.8.a Examine the documented key-management policies and procedures for keys used for protection of stored account data and verify that they define acknowledgments for key custodians in accordance with all elements specified in this requirement.

3.7.8.b Examine documentation or other evidence showing that key custodians have provided acknowledgments in accordance with all elements specified in this requirement. Customized Approach Objective Key custodians are knowledgeable about their responsibilities in relation to cryptographic operations and can access assistance and guidance when required.

Added p. 106

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks 4.1 Processes and mechanisms for protecting cardholder data with strong cryptography during transmission over open, public networks are defined and documented. 4.2 PAN is protected with strong cryptography during transmission The use of strong cryptography provides greater assurance in preserving data confidentiality, integrity, and non-repudiation.

To protect against compromise, PAN must be encrypted during transmission over networks that are easily accessed by malicious individuals, including untrusted and public networks. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be targeted by malicious individuals aiming to exploit these vulnerabilities to gain privileged access to cardholder data environments (CDE). Any transmissions of cardholder data over an entity’s internal network(s) will naturally bring that network into scope for PCI DSS since that network stores, processes, or transmits cardholder data. Any such networks must be evaluated and …

Added p. 107

Defined Approach Requirements 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 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 …

Added p. 109

Defined Approach Requirements 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 …

Added p. 111

• Wireless technologies, including Wi-Fi, Bluetooth, cellular technologies, and satellite communications. 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.

Added p. 112

4.2.1.1.b Examine the inventory of trusted keys and certificates to verify it is kept up to date. Customized Approach Objective All keys and certificates used to protect PAN during transmission are identified and confirmed as trusted.

Added p. 114

4.2.2.b Examine system configurations and vendor documentation to verify that 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.

Requirement 5: Protect All Systems and Networks from Malicious Software 5.1 Processes and mechanisms for protecting all systems and networks …

Added p. 117

Defined Approach Requirements Defined Approach Testing Procedures Purpose There is a constant stream of attacks targeting newly discovered vulnerabilities in systems previously regarded as secure. Without an anti- malware 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 "zero- day" 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).

Added p. 117

5.2.1.a Examine system components to verify that an anti-malware solution(s) is deployed on all system components, except for those determined to not be at risk from malware based on periodic evaluations per Requirement 5.2.3.

5.2.1.b For any system components without an anti-malware solution, examine the periodic evaluations to verify the component was evaluated and the evaluation concludes that the component is not at risk from malware.

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

Added p. 118

• Removes, blocks, or contains all known types of malware.

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

Added p. 119

• Identification of all system types previously determined to not require malware protection.

• Review of industry vulnerability alerts and notices to determine if new threats exist for any identified system.

• A documented conclusion about whether the system types remain not susceptible to malware.

Added p. 119

• A documented list of all system components not at risk for malware.

• Identification and evaluation of evolving malware threats for those system components.

• Confirmation whether such system components continue to not require anti-malware protection.

5.2.3.a Examine documented policies and procedures to verify that a process is defined for periodic evaluations of any system components that are not at risk for malware that includes all elements specified in this requirement.

5.2.3.b Interview personnel to verify that the evaluations include all elements specified in this requirement.

5.2.3.c Examine the list of system components identified as not at risk of malware and compare to the system components without an anti-malware solution deployed per Requirement 5.2.1 to verify that the system components match for both requirements. 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 …

Added p. 120

5.2.3.1.a Examine the entity’s targeted risk analysis for the frequency of periodic evaluations of system components identified as not at risk for malware to verify the risk analysis was performed in accordance with all elements specified in Requirement 12.3.1.

5.2.3.1.b Examine documented results of periodic evaluations of system components identified as not at risk for malware and interview personnel to verify that evaluations are performed at the frequency defined in the entity’s targeted risk analysis performed for this requirement.

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

Added p. 121

Defined Approach Requirements 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.

Added p. 121

5.3.1.b Examine system components and logs, to verify that the anti-malware solution(s) and definitions are current and have been promptly deployed Customized Approach Objective Anti-malware mechanisms can detect and address the latest malware threats.

Added p. 122

• Performs continuous behavioral analysis of systems or processes.

5.3.2.a Examine anti-malware solution(s) configurations, including any master installation of the software, to verify the solution(s) is configured to perform at least one of the elements specified in this requirement.

5.3.2.b Examine system components, including all operating system types identified as at risk for malware, to verify the solution(s) is enabled in accordance with at least one of the elements specified in this requirement.

5.3.2.c Examine logs and scan results to verify that the solution(s) is enabled in accordance with at least one of the elements specified in this requirement. Customized Approach Objective Malware cannot complete execution.

Added p. 123

5.3.2.1.a Examine the entity’s targeted risk analysis for the frequency of periodic malware scans to verify the risk analysis was performed in accordance with all elements specified in Requirement 12.3.1.

5.3.2.1.b Examine documented results of periodic malware scans and interview personnel to verify scans are performed at the frequency defined in the entity’s targeted risk analysis performed for this requirement.

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.

Added p. 124

• Performs automatic scans of when the media is inserted, connected, or logically mounted, OR

• Performs continuous behavioral analysis of systems or processes when the media is inserted, connected, or logically mounted.

5.3.3.a Examine anti-malware solution(s) configurations to verify that, for removable electronic media, the solution is configured to perform at least one of the elements specified in this requirement.

5.3.3.b Examine system components with removable electronic media connected to verify that the solution(s) is enabled in accordance with at least one of the elements as specified in this requirement.

5.3.3.c Examine logs and scan results to verify that the solution(s) is enabled in accordance with at least one of the elements specified in this requirement. Customized Approach Objective Malware cannot be introduced to system components via external removable media.

Defined Approach Requirements Defined Approach Testing Procedures Purpose It is important to track the effectiveness of the anti-malware mechanisms•for example, by confirming that updates …

Added p. 124

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

Added p. 125

• 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 anti- malware 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 re- enabled.

Customized Approach Objective 5.3.5.b Interview responsible personnel and observe processes to verify that any requests to disable or alter anti-malware mechanisms are specifically documented and authorized by management …

Added p. 126

Defined Approach Requirements 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 …

Added p. 126

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 in- scope 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.

Added p. 128

Requirement 6: Develop and Maintain Secure Systems and Software 6.1 Processes and mechanisms for developing and maintaining secure systems and software are defined and understood. 6.2 Bespoke and custom software are developed securely. 6.3 Security vulnerabilities are identified and addressed. 6.4 Public-facing web applications are protected against attacks. 6.5 Changes to all system components are managed securely.

Actors with bad intentions can use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor provided security patches, which must be installed by the entities that manage the systems. All system components must have all appropriate software patches to protect against the exploitation and compromise of account data by malicious individuals and malicious software.

Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with existing security configurations. For bespoke and custom software, numerous vulnerabilities can be …

Added p. 130

6.1.2.b Interview personnel responsible for performing activities in Requirement 6 to verify that roles and responsibilities are assigned as documented and are 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.

Added p. 131

Defined Approach Requirements 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.

Added p. 131

• Based on industry standards and/or best practices for secure development.

• Incorporating consideration of information security issues during each stage of the software development lifecycle.

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

Added p. 132

• On software security relevant to their job function and development languages.

• Including secure software design and secure coding techniques.

• Including, if security testing tools are used, how to use the tools for detecting vulnerabilities in software.

6.2.2.a Examine software development procedures to verify that processes are defined for training of software development personnel developing bespoke and custom software that includes all elements specified in this requirement.

6.2.2.b Examine training records and interview personnel to verify that software development personnel working on bespoke and custom software received software security training that is relevant to their job function and development languages in accordance with all elements specified in this requirement. 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.

Added p. 133

• Searching for undocumented features (implant tools, backdoors).

• Confirming that software securely uses external components’ functions (libraries, frameworks, APIs, etc.). For example, if a third-party library providing cryptographic functions is used, verify that it was integrated securely.

• Checking for correct use of logging to prevent sensitive data from getting into logs.

• Analysis of insecure code structures that may contain potential vulnerabilities related to common software attacks identified in Requirements 6.2.5.

• Checking the application’s behavior to detect logical vulnerabilities.

• Code reviews look for both existing and emerging software vulnerabilities.

6.2.3.a Examine documented software development procedures and interview responsible personnel to verify that processes are defined that require all bespoke and custom software to be reviewed in accordance with all elements specified in this requirement.

6.2.3.b Examine evidence of changes to bespoke and custom software to verify that the code changes were reviewed in accordance with all elements specified in this requirement.

Customized Approach Objective …

Added p. 134

6.2.3.1.a If manual code reviews are performed for bespoke and custom software prior to release to production, examine documented software development procedures and interview responsible personnel to verify that processes are defined for manual code reviews to be conducted in accordance with all elements specified in this requirement.

6.2.3.1.b Examine evidence of changes to bespoke and custom software and interview personnel to verify that manual code reviews were conducted in accordance with all elements specified in this requirement.

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.

Added p. 135

• Attempts to exploit common coding vulnerabilities (bugs).

• Attempts to exploit software design flaws.

• Attempts to exploit implementation/configuration flaws.

• Enumeration attacks

• automated attacks that are actively exploited in payments and abuse identification, authentication, or authorization mechanisms. See the PCI Perspectives blog article “Beware of Account Testing Attacks.” 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. (continued on next page) 6.2.4 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 …

Added p. 136

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 software. This does not apply to third-party software.

Added p. 137

Defined Approach Requirements 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 …

Added p. 138

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.

Added p. 140

6.3.2.a Examine documentation and interview personnel to verify that an inventory of bespoke and custom software and third-party software components incorporated into bespoke and custom software is maintained, and that the inventory is used to identify and address vulnerabilities.

6.3.2.b Examine software documentation, including for bespoke and custom software that integrates third-party software components, and compare it to the inventory to verify that the inventory includes the bespoke and custom software and third-party software components.

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

Added p. 141

• Critical or high-security patches/updates (identified according to the risk ranking process at Requirement 6.3.1) are installed within one month of release.

• All other applicable security patches/updates are installed within an appropriate time frame as determined by the entity (for example, within three months of release).

6.3.3.a Examine policies and procedures to verify processes are defined for addressing vulnerabilities by installing applicable security patches/updates in accordance with all elements specified in this requirement.

6.3.3.b Examine system components and related software and compare the list of installed security patches/updates to the most recent security patch/update information to verify vulnerabilities are addressed in accordance with all elements specified in this requirement.

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

Added p. 142

Defined Approach Requirements 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 …

Added p. 142

• If manual or automated vulnerability security assessment tools or methods are in use, examine documented processes, interview personnel, and examine records of application security assessments to verify that public-facing web applications are reviewed in accordance with all elements of this requirement specific to the tool/method. OR

• If an automated technical solution(s) is installed that continually detects and prevents web- based attacks, examine the system configuration settings and audit logs, and interview responsible personnel to verify that the automated technical solution(s) is installed in accordance with all elements of this requirement specific to the solution(s).

Added p. 143

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.

• Actively running and up to date as applicable.

• Generating audit logs.

• Configured to either block web-based attacks or generate an alert that is immediately investigated.

Added p. 144

• Is installed in front of public-facing web applications and is configured to detect and prevent web-based attacks.

Added p. 144

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.

Added p. 145

• A method is implemented to confirm that each script is authorized.

• A method is implemented to assure the integrity of each script.

• An inventory of all scripts is maintained with written justification as to why each is necessary.

6.4.3.a Examine policies and procedures to verify that processes are defined for managing all payment page scripts that are loaded and executed in the consumer’s browser, in accordance with all elements specified in this requirement.

6.4.3.b Interview responsible personnel and examine inventory records and system configurations to verify that all payment page scripts that are loaded and executed in the consumer’s browser are managed in accordance with all elements specified in this requirement.

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 …

Added p. 146

• Sub-resource integrity (SRI), which allows the consumer browser to validate that a script has not been tampered with.

• A CSP, which limits the locations the consumer browser can load a script from and transmit account data to.

• Proprietary script or tag-management systems, which can prevent malicious script execution.

Added p. 147

Defined Approach Requirements 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 …

Added p. 147

• Reason for, and description of, the change.

• Procedures to address failures and return to a secure state.

6.5.1.b Examine recent changes to system components and trace those changes back to related change control documentation. For each change examined, verify the change is implemented in accordance with all elements specified in this requirement.

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.

Added p. 148

• Sensitive authentication data is not stored, and all account data storage is documented and incorporated into data retention policy and procedures.

• Systems are scanned for internal and external vulnerabilities after significant changes per Requirements 11.3.1.3 and 11.3.2.1.

Added p. 148

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.

Added p. 149

6.5.3.a Examine policies and procedures to verify that processes are defined for separating the pre- production environment from the production environment via access controls that enforce the separation.

6.5.3.b Examine network documentation and configurations of network security controls to verify that the pre-production environment is separate from the production environment(s).

6.5.3.c Examine access control settings to verify that access controls are in place to enforce separation between the pre-production and production environment(s). Customized Approach Objective Pre-production environments cannot introduce risks and vulnerabilities into production environments.

Added p. 150

6.5.4.a Examine policies and procedures to verify that processes are defined for separating roles and functions to provide accountability such that only reviewed and approved changes are deployed.

6.5.4.b Observe processes and interview personnel to verify implemented controls separate roles and functions and 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.

Added p. 151

6.5.5.a Examine policies and procedures to verify that processes are defined for not using live PANs in pre-production environments, except where those environments are in a CDE and protected in accordance with all applicable PCI DSS requirements.

6.5.5.b Observe testing processes and interview personnel to verify procedures are in place to ensure live PANs are not used in pre-production environments, except where those environments are in a CDE and protected in accordance with all applicable PCI DSS requirements.

6.5.5.c Examine pre-production test data to verify live PANs are not used in pre-production environments, except where those environments are in a 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.

Added p. 152

6.5.6.a Examine policies and procedures to verify that processes are defined for removal of test data and test accounts from system components before the system goes into production.

6.5.6.b Observe testing processes for both off-the- shelf software and in-house applications, and interview personnel to verify test data and test accounts are removed before a system goes into production.

6.5.6.c Examine data and accounts for recently installed or updated off-the-shelf software and in- house applications to verify there is no test data or test accounts on systems in production. Customized Approach Objective Test data and test accounts cannot exist in production environments.

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know 7.1 Processes and mechanisms for restricting access to system components and cardholder data by business need to know are defined and understood. 7.2 Access to system components and data is appropriately defined and assigned. 7.3 Access to …

Added p. 155

7.1.2.b Interview personnel with responsibility for performing activities in Requirement 7 to verify that roles and responsibilities are assigned as and are 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.

Added p. 156

Defined Approach Requirements 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 mission- critical 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 …

Added p. 157

• Resources to be protected (the systems/devices/data to which access is needed),

• Job functions that need access to the resource (for example, system administrator, call-center personnel, store clerk), and

• Which activities each job function needs to perform (for example, read/write or query). 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.

Added p. 158

• Job classification and function.

7.2.2.a Examine policies and procedures to verify they cover assigning access to users in accordance with all elements specified in this requirement.

7.2.2.b Examine user access settings, including for privileged users, and interview responsible management personnel to verify that privileges assigned are in accordance with all elements specified in this requirement.

7.2.2.c Interview personnel responsible for assigning access to verify that privileged user access is assigned in accordance with all elements specified in this requirement. 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.

Added p. 159

7.2.3.a Examine policies and procedures to verify they define processes for approval of all privileges by authorized personnel.

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

Added p. 160

• At least once every six months.

• To ensure user accounts and access remain appropriate based on job function.

• Any inappropriate access is addressed.

• Management acknowledges that access remains appropriate.

7.2.4.a Examine policies and procedures to verify they define processes to review all user accounts and related access privileges, including third- party/vendor accounts, in accordance with all elements specified in this requirement.

7.2.4.b Interview responsible personnel and examine documented results of periodic reviews of user accounts to verify that all the results are in accordance with all elements specified in this requirement.

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. …

Added p. 161

• Making sure that the account is not a member of a privileged group such as domain administrators, local administrators, or root.

• Restricting which computers the account can be used on.

• Restricting hours of use.

• Removing any additional settings like VPN access and remote access.

Added p. 161

• Access is limited to the systems, applications, or processes that specifically require their use.

7.2.5.a Examine policies and procedures to verify they define processes to manage and assign application and system accounts and related access privileges in accordance with all elements specified in this requirement.

7.2.5.b Examine privileges associated with system and application accounts and interview responsible personnel to verify that application and system accounts and related access privileges are assigned and managed in accordance with all elements specified in this requirement. 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.

• Any inappropriate access is addressed.

• Management acknowledges that access remains appropriate.

Added p. 162

• Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).

• The application/system access remains appropriate for the function being performed.

7.2.5.1.a Examine policies and procedures to verify they define processes to review all application and system accounts and related access privileges in accordance with all elements specified in this requirement.

7.2.5.1.b Examine the entity’s targeted risk analysis for the frequency of periodic reviews of application and system accounts and related access privileges to verify the risk analysis was performed in accordance with all elements specified in Requirement 12.3.1.

7.2.5.1.c Interview responsible personnel and examine documented results of periodic reviews of system and application accounts and related privileges to verify that the reviews occur in accordance with all elements specified in this requirement.

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

Added p. 163

• Via applications or other programmatic methods, with access and allowed actions based on user roles and least privileges.

• Only the responsible administrator(s) can directly access or query repositories of stored CHD.

7.2.6.a Examine policies and procedures and interview personnel to verify processes are defined for granting user access to query repositories of stored cardholder data, in accordance with all elements specified in this requirement.

7.2.6.b Examine configuration settings for querying repositories of stored cardholder data to verify they are in accordance with all elements specified in this requirement. 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.

Added p. 164

Defined Approach Requirements 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.

Added p. 164

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

Defined Approach Requirements 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.

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

Requirement 8: Identify Users and Authenticate Access to System Components 8.1 Processes and mechanisms for identifying users and authenticating access to system components are defined and understood. 8.2 User identification and related accounts for users and administrators are strictly managed throughout an account’s lifecycle. 8.3 Strong authentication for users and administrators is established and managed. 8.4 Multi-factor …

Added p. 166

Note: Unless otherwise stated in the requirement, these requirements apply to all accounts on all system components, unless specifically called out in an individual requirement, including but not limited to:

• Point-of-sale accounts

• Accounts with administrative capabilities

• System and application accounts

• All accounts used to view or access cardholder data or to access systems with cardholder data. This includes accounts used by employees, contractors, consultants, internal and external vendors, and other third parties (for example, for providing support or maintenance services). Certain requirements are not intended to apply to user accounts 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). When items do not apply, they are noted directly within the specific requirement. These requirements do not apply to accounts used by consumers (cardholders). Refer to Appendix G for definitions of PCI DSS terms.

Added p. 169

Defined Approach Requirements 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.1.b Examine audit logs and other evidence to verify that access to system components and cardholder data can be uniquely identified and associated with individuals. 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 …

Added p. 170

• Account use is prevented unless needed for an exceptional circumstance.

• Use is limited to the time needed for the exceptional circumstance.

• Business justification for use is documented.

• Use is explicitly approved by management.

• Individual user identity is confirmed before access to an account is granted.

• Every action taken is attributable to an individual user.

8.2.2.a Examine user account lists on system components and applicable documentation to verify that shared authentication credentials are only used when necessary, on an exception basis, and are managed in accordance with all elements specified in this requirement.

8.2.2.b Examine authentication policies and procedures to verify processes are defined for shared authentication credentials such that they are only used when necessary, on an exception basis, and are managed in accordance with all elements specified in this requirement.

8.2.2.c Interview system administrators to verify that shared authentication credentials are only used when necessary, on an exception basis, and are …

Added p. 171

Defined Approach Requirements 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.

Added p. 171

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.

Added p. 172

• Authorized with the appropriate approval.

• Implemented with only the privileges specified on the documented approval.

Added p. 172

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.

Added p. 172

•have been returned or deactivated for terminated users. Customized Approach Objective The accounts of terminated users cannot be used.

Added p. 173

Defined Approach Requirements 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 …

Added p. 173

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

Added p. 174

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 Requirements 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 …

Added p. 175

• Something you have, such as a token device or smart card.

• Something you are, such as a biometric element.

8.3.1.a Examine documentation describing the authentication factor(s) used to verify that user access to system components is authenticated via at least one authentication factor specified in this requirement.

8.3.1.b For each type of authentication factor used with each type of system component, observe an authentication to verify that authentication is functioning consistently with documented authentication factor(s). 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 …

Added p. 177

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 Requirements 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.

Added p. 177

• Set to a unique value for first-time use and upon reset.

• Forced to be changed immediately after the first use.

Added p. 177

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

Added p. 178

• A minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters).

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:

• 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).

Added p. 179

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).

Added p. 180

• Instructions not to reuse previously used passwords/passphrases.

• Instructions to change passwords/passphrases if there is any suspicion or knowledge that the password/passphrases have been compromised and how to report the incident.

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

Added p. 181

• The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.

Added p. 181

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.

Added p. 182

Defined Approach Requirements 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.

Added p. 182

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.

• The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.

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

Added p. 183

• Passwords/passphrases are changed at least once every 90 days,

Added p. 183

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.

Added p. 184

• Factors are assigned to an individual user and not shared among multiple users.

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

Added p. 185

Defined Approach Requirements 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 multi- factor authentication.

8.4.1.b Observe administrator personnel logging into the CDE and verify that MFA is required. 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 …

Added p. 186

8.4.2.a Examine network and/or system configurations to verify MFA is implemented for all access into the CDE.

8.4.2.b Observe personnel logging in to the CDE and examine evidence to verify that MFA is required. 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:

• Application or system accounts performing automated functions.

Added p. 188

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 …

Added p. 189

Defined Approach Requirements 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 multi- factor authentication. Further Information For more information about MFA systems and features, refer to the following: PCI SSC’s Information Supplement: Multi-Factor Authentication PCI SSC’s Frequently Asked Questions (FAQs) on this topic.

Added p. 189

• The MFA system is not susceptible to replay attacks.

• MFA systems cannot be bypassed by any users, including administrative users unless specifically documented, and authorized by management on an exception basis, for a limited time period.

• At least two different types of authentication factors are used.

• Success of all authentication factors is required before access is granted.

8.5.1.a Examine vendor system documentation to verify that the MFA system is not susceptible to replay attacks.

8.5.1.b Examine system configurations for the MFA implementation to verify it is configured in accordance with all elements specified in this requirement.

8.5.1.c Interview responsible personnel and observe processes to verify that any requests to bypass MFA are specifically documented and authorized by management on an exception basis, for a limited time period.

8.5.1.d Observe personnel logging into system components in the CDE to verify that access is granted only after all authentication factors are successful.

8.5.1.e Observe personnel connecting …

Added p. 190

Defined Approach Requirements 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 …

Added p. 190

• Interactive use is prevented unless needed for an exceptional circumstance.

• Interactive use is limited to the time needed for the exceptional circumstance.

• Business justification for interactive use is documented.

• Interactive use is explicitly approved by management.

• Individual user identity is confirmed before access to account is granted.

Added p. 190

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

Added p. 191

8.6.2.a Interview personnel and examine system development procedures to verify that processes are defined for application and system accounts that can be used for interactive login, specifying that passwords/passphrases are not hard coded in scripts, configuration/property files, or bespoke and custom source code.

8.6.2.b Examine scripts, configuration/property files, and bespoke and custom source code for application and system accounts that can be used for interactive login, to verify passwords/passphrases for those accounts are not present.

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.

Added p. 192

• How securely the passwords/passphrases are stored (for example, whether they are stored in a password vault).

• The number of people with access to the authentication factor.

• Whether the account can be used for interactive login.

• Whether the security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly (see Requirement 8.3.9). 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. (continued on next page) 8.6.3 Passwords/passphrases for any application and system accounts are protected against misuse as follows:

• Passwords/passphrases are changed periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1) and upon suspicion or confirmation of compromise.

• Passwords/passphrases are constructed with sufficient complexity appropriate for how frequently the entity changes the passwords/passphrases.

8.6.3.a Examine …

Added p. 194

Requirement 9: Restrict Physical Access to Cardholder Data 9.1 Processes and mechanisms for restricting physical access to cardholder data are defined and understood. 9.2 Physical access controls manage entry into facilities and systems containing cardholder data. 9.3 Physical access for personnel and visitors is authorized and managed. 9.4 Media with cardholder data is securely stored, accessed, distributed, and destroyed. 9.5 Point of interaction (POI) devices are protected from tampering and unauthorized substitution.

Any physical access to cardholder data or systems that store, process, or transmit cardholder data provides the opportunity for individuals to access and/or remove systems or hardcopies containing cardholder data; therefore, physical access should be appropriately restricted.

There are three different areas mentioned in Requirement 9:

1. Requirements that specifically refer to sensitive areas are intended to apply to those areas only. 2. Requirements that specifically refer to the cardholder data environment (CDE) are intended to apply to the entire CDE, …

Added p. 197

Defined Approach Requirements 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.

Added p. 197

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

Added p. 198

• Entry and exit points to/from sensitive areas within the CDE are monitored.

• Monitoring devices or mechanisms are protected from tampering or disabling.

• Collected data is reviewed and correlated with other entries.

• Collected data is stored for at least three months, unless otherwise restricted by law.

9.2.1.1.c Observe the physical access control mechanisms and/or examine video cameras and interview responsible personnel to verify that:

• Collected data is stored for at least three months.

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

Added p. 199

Defined Approach Requirements 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.

Added p. 200

Defined Approach Requirements 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.

Added p. 200

• Identifying personnel.

9.3.1.a Examine documented procedures to verify that procedures to authorize and manage physical access of personnel to the CDE are defined in accordance with all elements specified in this requirement.

9.3.1.b Observe identification methods, such as ID badges, and processes to verify that personnel in the CDE are clearly identified.

9.3.1.c Observe processes to verify that access to the identification process, such as a badge system, is limited to authorized personnel. Customized Approach Objective Requirements for access to the physical CDE are defined and enforced to identify and authorize personnel.

Added p. 201

• Access is authorized and based on individual job function.

• Access is revoked immediately upon termination.

9.3.1.1.b Observe processes and interview personnel to verify that access of all personnel is revoked immediately upon termination.

9.3.1.1.c For terminated personnel, examine physical access controls lists and interview responsible personnel to verify that all physical access mechanisms (such as keys, access cards, etc.) were returned or disabled.

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

Added p. 202

• Visitors are authorized before entering.

• Visitors are escorted at all times.

• Visitors are clearly identified and given a badge or other identification that expires.

9.3.2.a Examine documented procedures and interview personnel to verify procedures are defined for authorizing and managing visitor access to the CDE in accordance with all elements specified in this requirement.

9.3.2.b Observe processes when visitors are present in the CDE and interview personnel to verify that visitors are:

• Authorized before entering the CDE.

• Escorted at all times within the CDE.

9.3.2.d Observe visitors in the CDE to verify that:

• Visitor badges or identification easily distinguish visitors from personnel.

9.3.2.e Examine visitor badges or other identification and observe evidence in the badging system to verify visitor badges or other identification expires. 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.

Added p. 203

Defined Approach Requirements 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.

• The visitor’s name and the organization represented.

• The visitor’s name and the organization represented.

• The date and time of the visit.

• Date and time of visit.

9.3.4.c Examine visitor log storage locations and interview responsible personnel to verify that the log is retained for at least …

Added p. 204

9.4.1. Examine documentation to verify that the procedures defined for protecting cardholder data include controls for physically securing all media.

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

Added p. 204

9.4.1.1.a Examine documentation to verify that procedures are defined for physically securing offline media backups with cardholder data in a secure location.

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.1.b Examine logs or other documentation and interview responsible personnel at the storage location to verify that offline media backups are stored in a secure location.

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

Defined Approach Requirements 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 …

Added p. 204

9.4.1.2.a Examine documentation to verify that procedures are defined for reviewing the security of the offline media backup location(s) with cardholder data at least once every 12 months.

9.4.1.2.b Examine documented procedures, logs, or other documentation, and interview responsible personnel at the storage location(s) to verify that the storage location’s security is reviewed at least once every 12 months.

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

Added p. 205

9.4.2.a Examine documentation to verify that procedures are defined for classifying media with cardholder data in accordance with the sensitivity of the data.

9.4.2.b Examine media logs or other documentation to verify that all media is classified in accordance with the sensitivity of the data. Customized Approach Objective Media are classified and protected appropriately.

Added p. 205

• Media sent outside the facility is logged.

• Offsite tracking logs include details about media location.

9.4.3.a Examine documentation to verify that procedures are defined for securing media sent outside the facility in accordance with all elements specified in this requirement.

9.4.3.c Examine offsite tracking logs for all media to verify tracking details are documented. Customized Approach Objective Media is secured and tracked when transported outside the facility.

9.4.4.a Examine documentation to verify that procedures are defined to ensure that media moved outside the facility is approved by management.

9.4.4.b Examine offsite media tracking logs and interview responsible personnel to verify that proper management authorization is obtained for all media moved outside the facility (including media 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 …

Added p. 207

9.4.5.1.a Examine documentation to verify that procedures are defined to conduct inventories of electronic media with cardholder data at least once every 12 months.

9.4.5.1.b Examine electronic media inventory logs and interview personnel to verify that electronic media inventories are performed at least once every 12 months. Customized Approach Objective Media inventories are verified periodically.

Added p. 208

• Materials are stored in secure storage containers prior to destruction.

9.4.6.a Examine the periodic media destruction policy to verify that procedures are defined to destroy hard-copy media with cardholder data when no longer needed for business or legal reasons in accordance with all elements specified in this requirement.

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.

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.

Added p. 209

• The electronic media is destroyed.

9.4.7.a Examine the periodic media destruction policy to verify that procedures are defined to destroy electronic media when no longer needed for business or legal reasons in accordance with all elements specified in this requirement.

9.4.7.b Observe the media destruction process and interview responsible personnel to verify that electronic media with cardholder data is destroyed via one of the methods specified in this requirement.

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

Added p. 210

Defined Approach Requirements Defined Approach Testing Procedures Purpose Criminals 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. Further Information Additional best practices on …

Added p. 212

• Unexpected attachments or cables plugged into the device.

• Missing or changed security labels.

• Broken or differently colored casing.

• Changes to the serial number or other external markings.

Added p. 212

9.5.1.2.a Examine documented procedures to verify processes are defined for periodic inspections of POI device surfaces 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.

Added p. 213

9.5.1.2.1.a Examine the entity’s targeted risk analysis for the frequency of periodic POI device inspections and type of inspections performed to verify the risk analysis was performed in accordance with all elements specified in Requirement 12.3.1.

9.5.1.2.1.b Examine documented results of periodic device inspections and interview personnel to verify that the frequency and type of POI device inspections performed match what is defined in the entity’s targeted risk analysis conducted for this requirement.

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

Added p. 214

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.

Added p. 216

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data 10.1 Processes and mechanisms for logging and monitoring all access to system components and cardholder data are defined and documented. 10.2 Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events. 10.3 Audit logs are protected from destruction and unauthorized modifications. 10.4 Audit logs are reviewed to identify anomalies or suspicious activity. 10.5 Audit log history is retained and available for analysis. 10.6 Time-synchronization mechanisms support consistent time settings across all systems. 10.7 Failures of critical security control systems are detected, reported, and responded to promptly.

Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs on all system components and in the cardholder data environment (CDE) allows thorough tracking, alerting, and analysis …

Added p. 218

10.1.2.b Interview personnel with responsibility for performing activities in Requirement 10 to verify that roles and responsibilities are assigned as defined and are 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.

Added p. 219

Defined Approach Requirements 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.

Customized Approach Objective Records of all activities affecting system components and cardholder data are captured.

Defined Approach Requirements Defined Approach Testing Procedures Purpose It is critical to have a process or system that links user …

Added p. 220

Defined Approach Requirements 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.

Added p. 220

Customized Approach Objective Records of all access to audit logs are captured.

Added p. 221

• Creation of new accounts.

Added p. 221

Customized Approach Objective Records of all changes to identification and authentication credentials are captured.

Added p. 221

Customized Approach Objective Records of all changes to audit log activity status are captured.

Added p. 221

Customized Approach Objective Records of alterations that indicate a system has been modified from its intended functionality are captured.

Added p. 222

• User identification.

• Success and failure indication.

• Origination of event.

Added p. 222

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 Requirements 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.

Added p. 222

Customized Approach Objective Stored activity records cannot be accessed by unauthorized personnel.

Added p. 223

Defined Approach Requirements 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.

Added p. 223

Customized Approach Objective Stored activity records are secured and preserved in a central location to prevent unauthorized modification.

Added p. 224

Customized Approach Objective Stored activity records cannot be modified without an alert being generated.

Added p. 225

10.4.1.b Observe processes and interview personnel to verify that all elements specified in this requirement are reviewed at least once daily Customized Approach Objective Potentially suspicious or anomalous activities are quickly identified to minimize impact.

Added p. 226

Defined Approach Requirements 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.

Added p. 226

10.4.2.b Examine documented results of log reviews and interview personnel to verify that log reviews are performed 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.

Added p. 227

10.4.2.1.b Examine documented results of periodic log reviews of all other system components (not defined in Requirement 10.4.1) and interview personnel to verify log reviews are performed at the frequency specified in the entity’s targeted risk analysis performed for this requirement.

Customized Approach Objective Log reviews for lower-risk system components are performed at a frequency that addresses the entity’s risk.

Added p. 228

• How log review activities are recorded,

• How to rank and prioritize exceptions and anomalies,

• What procedures should be in place to report and escalate exceptions and anomalies, and

• Who is responsible for investigating and for any remediation tasks.

10.4.3.b Observe processes and interview personnel to verify that, when exceptions and anomalies are identified, they are addressed. Customized Approach Objective Suspicious or anomalous activities are addressed.

Added p. 229

Defined Approach Requirements 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.

Added p. 230

Defined Approach Requirements 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.

Added p. 230

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.

Added p. 231

• The designated time server(s) accept time updates only from specific industry-accepted external sources.

Added p. 231

Customized Approach Objective The time on all systems is accurate and consistent.

Defined Approach Requirements 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.

Added p. 231

• Access to time data is restricted to only personnel with a business need.

10.6.3.b Examine system configurations and time synchronization settings and logs and observe processes to verify that any changes to time settings on critical systems are logged, monitored, and reviewed. Customized Approach Objective System time settings cannot be modified by unauthorized personnel.

Added p. 232

Defined Approach Requirements 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.

Added p. 232

• Anti-malware solutions.

• Segmentation controls (if used).

10.7.1.a Additional testing procedure for service provider assessments only: Examine documentation to verify that processes are defined for the prompt detection and addressing of failures of critical security control systems, including but not limited to failure of all elements specified in this requirement.

10.7.1.b Additional testing procedure for service provider assessments only: Observe detection and alerting processes and interview personnel to verify that failures of critical security control systems are detected and reported, and that failure of a critical security control results in the generation of an alert.

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.

• Anti-malware solutions.

• Segmentation controls (if used).

Customized Approach Objective Failures in critical security control systems are promptly identified …

Added p. 233

• Network security controls.

• Change-detection mechanisms.

• Physical access controls.

• Logical access controls.

• Audit logging mechanisms.

• Audit log review mechanisms.

• Automated security testing tools (if used).

10.7.2.a Examine documentation to verify that processes are defined for the prompt detection and addressing of failures of critical security control systems, including but not limited to failure of all elements specified in this requirement.

10.7.2.b Observe detection and alerting processes and interview personnel to verify that failures of critical security control systems are detected and reported, and that failure of a critical security control results in the generation of an alert.

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 …

Added p. 234

• Restoring security functions.

• Identifying and documenting the duration (date and time from start to end) of the security failure.

• Identifying and documenting the cause(s) of failure and documenting required remediation.

• Identifying and addressing any security issues that arose during the failure.

• Determining whether further actions are required as a result of the security failure.

• Implementing controls to prevent the cause of failure from reoccurring.

• Resuming monitoring of security controls.

10.7.3.a Examine documentation and interview personnel to verify that processes are defined and implemented to respond to a failure of any critical security control system and include at least all elements specified in this requirement.

10.7.3.b Examine records to verify that failures of critical security control systems are documented to include:

• Identification of cause(s) of the failure.

• Duration (date and time start and end) of the security failure.

• Details of the remediation required to address the root cause.

Customized Approach Objective Failures of …

Added p. 235

Requirement 11: Test Security of Systems and Networks Regularly 11.1 Processes and mechanisms for regularly testing security of systems and networks are defined and understood. 11.2 Wireless access points are identified and monitored, and unauthorized wireless access points are addressed. 11.3 External and internal vulnerabilities are regularly identified, prioritized, and addressed. 11.4 External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected. 11.5 Network intrusions and unexpected file changes are detected and responded to. 11.6 Unauthorized changes on payment pages are detected and responded to.

Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and bespoke and custom software should be tested frequently to ensure security controls continue to reflect a changing environment. Refer to Appendix G for definitions of PCI DSS terms.

Added p. 238

Defined Approach Requirements 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 …

Added p. 240

Customized Approach Objective Unauthorized wireless access points are not mistaken for authorized wireless access points.

Added p. 241

Defined Approach Requirements 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 non- remediated 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 …

Added p. 241

• High-risk and critical vulnerabilities (per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved.

• Rescans are performed that confirm all high- risk and critical vulnerabilities (as noted above) have been resolved.

• Scan tool is kept up to date with latest vulnerability information.

• Scans are performed by qualified personnel and organizational independence of the tester exists.

11.3.1.a Examine internal scan report results from the last 12 months to verify that internal scans occurred at least once every three months in the most recent 12-month period.

11.3.1.b Examine internal scan report results from each scan and rescan run in the last 12 months to verify that all high-risk and critical vulnerabilities (identified in PCI DSS Requirement 6.3.1) are resolved.

11.3.1.c Examine scan tool configurations and interview personnel to verify that the scan tool is kept up to date with the latest vulnerability information.

Added p. 243

• Addressed based on the risk defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.

Added p. 243

11.3.1.1.a Examine the entity’s targeted risk analysis that defines the risk for addressing all other applicable vulnerabilities (those not ranked as high-risk or critical per the entity’s vulnerability risk rankings at Requirement 6.3.1) to verify the risk analysis was performed in accordance with all elements specified at Requirement 12.3.1.

11.3.1.1.b Interview responsible personnel and examine internal scan report results or other documentation to verify that all other applicable vulnerabilities (those not ranked as high-risk or critical per the entity’s vulnerability risk rankings at Requirement 6.3.1) are addressed based on the risk defined in the entity’s targeted risk analysis, and that the scan process includes rescans as needed to confirm the vulnerabilities have been addressed.

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 …

Added p. 244

• Systems that are unable to accept credentials for authenticated scanning are documented.

• Sufficient privileges are used for those systems that accept credentials for scanning.

• If accounts used for authenticated scanning can be used for interactive login, they are managed in accordance with Requirement 8.2.2.

11.3.1.2.a Examine scan tool configurations to verify that authenticated scanning is used for internal scans, with sufficient privileges, for those systems that accept credentials for scanning.

11.3.1.2.c If accounts used for authenticated scanning can be used for interactive login, examine the accounts and interview personnel to verify the accounts are managed following all elements specified in Requirement 8.2.2. Customized Approach Objective Automated tools used to detect vulnerabilities can detect vulnerabilities local to each system, which are not visible remotely.

11.3.1.2.d Examine documentation to verify that systems that are unable to accept credentials for authenticated scanning are defined.

Applicability Notes The authenticated scanning tools can be either host-based or network-based. …

Added p. 245

• Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV).

11.3.1.3.a Examine change control documentation and internal scan reports to verify that system components were scanned after any significant changes.

11.3.1.3.b Interview personnel and examine internal scan and rescan reports to verify that internal scans were performed after significant changes and that high-risk and critical vulnerabilities as defined in Requirement 6.3.1 were resolved.

11.3.1.3.c Interview personnel to verify that internal scans are performed by a qualified internal resource(s) or qualified external third party and that organizational independence of the tester exists. 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 …

Added p. 246

• By a PCI SSC Approved Scanning Vendor (ASV).

• Vulnerabilities are resolved and ASV Program Guide requirements for a passing scan are met.

• Rescans are performed as needed to confirm that vulnerabilities are resolved per the ASV Program Guide requirements for a passing scan.

11.3.2.a Examine ASV scan reports from the last 12 months to verify that external vulnerability scans occurred at least once every three months in the most recent 12-month period.

11.3.2.b Examine the ASV scan report from each scan and rescan run in the last 12 months to verify that vulnerabilities are resolved and the ASV Program Guide requirements for a passing scan are met.

11.3.2.c Examine the ASV scan reports to verify that the scans were completed by a PCI SSC Approved Scanning Vendor (ASV). 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 …

Added p. 247

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.

• Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV).

Added p. 248

• Vulnerabilities that are scored 4.0 or higher by the CVSS are resolved.

11.3.2.1.a Examine change control documentation and external scan reports to verify that system components were scanned after any significant changes.

11.3.2.1.b Interview personnel and examine external scan and rescan reports to verify that external scans were performed after significant changes and that vulnerabilities scored 4.0 or higher by the CVSS were resolved.

11.3.2.1.c Interview personnel to verify that external scans are performed by a qualified internal resource(s) or qualified external third party and that organizational independence of the tester exists.

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.

Added p. 249

Defined Approach Requirements 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 …

Added p. 249

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.

Added p. 250

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.

Added p. 251

• Specific penetration testing certifications, which may be an indication of the tester’s skill level and competence. (continued on next page) 11.4.2 Internal penetration testing is performed:

• Per the entity’s defined methodology,

• At least once every 12 months

• At least once every 12 months

• After any significant infrastructure or application upgrade or change

• After any significant infrastructure or application upgrade or change

• By a qualified internal resource or qualified external third-party

Added p. 251

11.4.2.a Examine the scope of work and results from the most recent internal penetration test to verify that penetration testing is performed in accordance with all elements specified in this requirement.

11.4.2.b Interview personnel to verify that the internal penetration test was performed by a qualified internal resource or qualified external third-party and that organizational independence of the tester exists (not required to be a QSA or ASV).

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 Requirements Defined Approach Testing Procedures 11.4.3 External penetration testing is performed:

• Per the entity’s defined methodology

• By a qualified internal resource or qualified external third party

• Organizational independence of the tester exists (not required to be a QSA or ASV). (continued on next page) …

Added p. 252

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.

Added p. 253

• In accordance with the entity’s assessment of the risk posed by the security issue as defined in Requirement 6.3.1.

• Penetration testing is repeated to verify the corrections.

Added p. 253

Customized Approach Objective Vulnerabilities and security weaknesses found while verifying system defenses are mitigated.

Added p. 254

• At least once every 12 months and after any changes to segmentation controls/methods

• Covering all segmentation controls/methods in use.

• According to the entity’s defined penetration testing methodology.

• Confirming that the segmentation controls/methods are operational and effective, and isolate the CDE from all out-of-scope systems.

• Confirming effectiveness of any use of isolation to separate systems with differing security levels (see Requirement 2.2.3).

• Performed by a qualified internal resource or qualified external third party.

11.4.5.a Examine segmentation controls and review penetration-testing methodology to verify that penetration-testing procedures are defined to test all segmentation methods in accordance with all elements specified in this requirement.

11.4.5.b Examine the results from the most recent penetration test to verify the penetration test covers and addresses all elements specified in this requirement.

11.4.5.c Interview personnel to verify that the test was performed by a qualified internal resource or qualified external third party and that organizational independence of the tester …

Added p. 255

• At least once every six months and after any changes to segmentation controls/methods.

11.4.6.a Additional testing procedure for service provider assessments only: Examine the results from the most recent penetration test to verify that the penetration covers and addressed all elements specified in this requirement.

11.4.6.b Additional testing procedure for service provider assessments only: Interview personnel to verify that the test was performed by a qualified internal resource or qualified external third party and that organizational independence of the tester exists (not required to be a QSA or ASV).

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.

Added p. 256

Customized Approach Objective Multi-tenant service providers support their customers’ need for technical testing either by providing access or evidence that comparable technical testing has been undertaken.

Added p. 257

• Provide evidence to its customers to show that penetration testing has been performed according to Requirements 11.4.3 and 11.4.4 on the customers’ subscribed infrastructure, or

• Provide prompt access to each of its customers, so customers can perform their own penetration testing. Evidence provided to customers can include redacted penetration testing results but needs to include sufficient information to prove that all elements of Requirements 11.4.3 and 11.4.4 have been met on the customer’s behalf. Refer also to Appendix A1: Additional PCI DSS Requirements for Multi-Tenant Service Providers. 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.

Added p. 257

Defined Approach Requirements Defined Approach Testing Procedures Purpose Intrusion-detection and/or intrusion-prevention techniques (such as IDS/IPS) compare the traffic coming into the network with known “signatures” and/or behaviors of thousands of compromise types (hacker tools, Trojans, and other malware), and then send alerts and/or stop the attempt as it happens. Without a proactive approach to detect unauthorized activity, attacks on (or misuse of) computer resources could go unnoticed for long periods of time. The impact of an intrusion into the CDE is, in many ways, a factor of the time that an attacker has in the environment before being detected. (continued on next page) 11.5.1 Intrusion-detection and/or intrusion- prevention techniques are used to detect and/or prevent intrusions into the network as follows:

• All traffic is monitored at the perimeter of the CDE.

• All traffic is monitored at critical points in the CDE.

• Personnel are alerted to suspected compromises.

• All intrusion-detection and …

Added p. 258

Good Practice Security alerts generated by these techniques should be continually monitored, so that the attempted or actual intrusions can be stopped, and potential damage limited. Definitions Critical locations could include, but are not limited to, network security controls between network segments (for example, between a DMZ and an internal network or between an in-scope and out- of-scope network) and points protecting connections between a less trusted and a more trusted system component.

Mechanisms to detect real-time suspicious or anomalous network traffic that may be indicative of threat actor activity are implemented. Alerts generated by these mechanisms are responded to by personnel, or by automated means that ensure that system components cannot be compromised as a result of the detected activity.

Added p. 259

11.5.1.1.a Additional testing procedure for service provider assessments only: Examine documentation and configuration settings to verify that methods to detect and alert on/prevent covert malware communication channels are in place and operating.

11.5.1.1.b Additional testing procedure for service provider assessments only: Examine the entity’s incident-response plan (Requirement 12.10.1) to verify it requires and defines a response in the event that covert malware communication channels are detected.

11.5.1.1.c Additional testing procedure for service provider assessments only: Interview responsible personnel and observe processes to verify that personnel maintain knowledge of covert malware communication and control techniques and are knowledgeable about how to respond when malware is suspected.

Customized Approach Objective Mechanisms are in place to detect and alert/prevent covert communications with command-and-control systems. Alerts generated by these mechanisms are responded to by personnel, or by automated means that ensure that such communications are blocked.

Added p. 260

• System executables.

• Application executables.

• Configuration and parameter files.

• Centrally stored, historical, or archived audit logs.

• Additional critical files determined by entity (for example, through risk assessment or other means). Examples Change-detection solutions such as file integrity monitoring (FIM) tools check for changes, additions, and deletions to critical files, and notify when such changes are detected.

Added p. 260

• To alert personnel to unauthorized modification (including changes, additions, and deletions) of critical files.

• To perform critical file comparisons at least once weekly.

11.5.2.a Examine system settings, monitored files, and results from monitoring activities to verify the use of a change-detection mechanism.

11.5.2.b Examine settings for the change-detection mechanism to verify it is configured in accordance with all elements specified in this requirement.

Customized Approach Objective Critical files cannot be modified by unauthorized personnel without an alert being generated.

Applicability Notes For change-detection purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. Change- detection mechanisms such as file integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is, the merchant or service provider).

Added p. 261

Defined Approach Requirements Defined Approach Testing Procedures Purpose Many web pages now rely on assembling objects, including active content (primarily JavaScript), from multiple internet locations. Additionally, the content of many web pages is defined using content management and tag management systems that may not be possible to monitor using traditional change detection mechanisms. Therefore, the only place to detect changes or indicators of malicious activity is in the consumer browser as the page is constructed and all JavaScript interpreted. By comparing the current version of the HTTP header and the active content of payment pages as received by the consumer browser with prior or known versions, it is possible to detect unauthorized changes that may indicate a skimming attack. Additionally, by looking for known indicators of compromise and script elements or behavior typical of skimmers, suspicious alerts can be raised. (continued on next page) 11.6.1 A change- and tamper-detection mechanism …

Added p. 262

• Violations of the Content Security Policy (CSP) can be reported to the entity using the report- to or report-uri CSP directives.

• Changes to the CSP itself can indicate tampering.

• External monitoring by systems that request and analyze the received web pages (also known as synthetic user monitoring) can detect changes to JavaScript in payment pages and alert personnel.

• Embedding tamper-resistant, tamper-detection script in the payment page can alert and block when malicious script behavior is detected.

• Reverse proxies and Content Delivery Networks can detect changes in scripts and alert personnel. Often, these mechanisms are subscription or cloud-based, but can also be based on custom and bespoke solutions.

The intention of this requirement is not that an entity installs software in the systems or browsers of its consumers, but rather that the entity uses techniques such as those described under Examples in the Guidance column to prevent and detect unexpected script …

Added p. 264

Defined Approach Requirements Defined Approach Testing Procedures Purpose An organization’s overall information security policy ties to and governs all other policies and procedures that define protection of cardholder data. The information security policy communicates management’s intent and objectives regarding the protection of its most valuable assets, including cardholder data. Without an information security policy, individuals will make their own value decisions on the controls that are required within the organization which may result in the organization neither meeting its legal, regulatory, and contractual obligations, nor being able to adequately protect its assets in a consistent manner. To ensure the policy is implemented, it is important that all relevant personnel within the organization, as well as relevant third parties, vendors, and business partners are aware of the organization’s information security policy and their responsibilities for protecting information assets. (continued on next page) 12.1.1 An overall information security policy is:

• Disseminated to …

Added p. 264

Customized Approach Objective The strategic objectives and principles of information security are defined, adopted, and known to all personnel.

Added p. 265

Defined Approach Requirements Defined Approach Testing Procedures Purpose Security threats and associated protection methods evolve rapidly. Without updating the information security policy to reflect relevant changes, new measures to defend against these threats may not be addressed.

Added p. 265

• Reviewed at least once every 12 months.

• Updated as needed to reflect changes to business objectives or risks to the environment.

Added p. 265

Customized Approach Objective The information security policy continues to reflect the organization’s strategic objectives and principles.

Added p. 266

12.1.3.a Examine the information security policy to verify that they clearly define information security roles and responsibilities for all personnel.

12.1.3.b Interview personnel in various roles to verify they understand their information security responsibilities.

12.1.3.c Examine documented evidence to verify personnel acknowledge their information security responsibilities. Customized Approach Objective Personnel understand their role in protecting the entity’s cardholder data.

Defined Approach Requirements Defined Approach Testing Procedures Purpose To ensure someone with sufficient authority and responsibility is actively managing and championing the organization’s information security program, accountability and responsibility for information security needs to be assigned at the executive level within an organization. Common executive management titles for this role include Chief Information Security Officer (CISO) and Chief Security Officer (CSO

• to meet this requirement, the CSO role must be responsible for information security). These positions are often at the most senior level of management and are part of the chief executive level or …

Added p. 266

Customized Approach Objective A designated member of executive management is responsible for information security.

Added p. 267

Defined Approach Requirements Defined Approach Testing Procedures Purpose End-user technologies are a significant investment and may pose significant risk to an organization if not managed properly. Acceptable use policies outline the expected behavior from personnel when using the organization’s information technology and reflect the organization’s risk tolerance These policies instruct personnel on what they can and cannot do with company equipment and instruct personnel on correct and incorrect uses of company Internet and email resources. Such policies can legally protect an organization and allow it to act when the policies are violated. Good Practice It is important that usage policies are supported by technical controls to manage the enforcement of the policies. Structuring polices as simple “do” and “do not” requirements that are linked to a purpose can help remove ambiguity and provide personnel with the context for the requirement.

Added p. 267

• Explicit approval by authorized parties.

• Acceptable uses of the technology.

• List of products approved by the company for employee use, including hardware and software.

Added p. 267

Customized Approach Objective The use of end-user technologies is defined and managed to ensure authorized usage.

Applicability Notes Examples of end-user technologies for which acceptable use policies are expected include, but are not limited to, remote access and wireless technologies, laptops, tablets, mobile phones, and removable electronic media, email usage, and Internet usage.

Added p. 268

Defined Approach Requirements Defined Approach Testing Procedures Purpose Some PCI DSS requirements allow an entity to define how frequently an activity is performed based on the risk to environment. Performing this risk analysis according to a methodology ensures validity and consistency with policies and procedures. This targeted risk analysis (as opposed to a traditional enterprise-wide risk assessment) focuses on those PCI DSS requirements that allow an entity flexibility about how frequently an entity performs a given control. For this risk analysis, the entity carefully evaluates each PCI DSS requirement that provides this flexibility and determines the frequency that supports adequate security for the entity, and the level of risk the entity is willing to accept. The risk analysis identifies the specific assets, such as the system components and data

•for example, log files, or credentials

•that the requirement is intended to protect, as well as the threat(s) or outcomes that the requirement …

Added p. 268

Customized Approach Objective Up to date knowledge and assessment of risks to the CDE are maintained.

Added p. 270

• Documented evidence detailing each element specified in Appendix D: Customized Approach (including, at a minimum, a controls matrix and risk analysis).

• Approval of documented evidence by senior management.

• Performance of the targeted analysis of risk at least once every 12 months.

Added p. 270

Customized Approach Objective This requirement is part of the customized approach and must be met for those using the customized approach.

Applicability Notes This requirement only applies to entities using a Customized Approach.

Added p. 271

• An up-to-date inventory of all cryptographic cipher suites and protocols in use, including purpose and where used.

• Active monitoring of industry trends regarding continued viability of all cryptographic cipher suites and protocols in use.

• A documented strategy to respond to anticipated changes in cryptographic vulnerabilities.

Added p. 271

Customized Approach Objective The entity is able to respond quickly to any vulnerabilities in cryptographic protocols or algorithms, where those vulnerabilities affect protection of cardholder data.

Applicability Notes The requirement applies to all cryptographic suites and protocols used to meet PCI DSS requirements. 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.

Added p. 272

• Analysis that the technologies continue to receive security fixes from vendors promptly.

• Analysis that the technologies continue to support (and do not preclude) the entity’s PCI DSS compliance.

• Documentation of any industry announcements or trends related to a technology, such as when a vendor has announced “end of life” plans for a technology.

• Documentation of a plan, approved by senior management, to remediate outdated technologies, including those for which vendors have announced “end of life” plans.

Added p. 272

Customized Approach Objective The entity’s hardware and software technologies are up to date and supported by the vendor. Plans to remove or replace all unsupported system components are reviewed periodically.

Added p. 273

Defined Approach Requirements Defined Approach Testing Procedures Purpose Executive management assignment of PCI DSS compliance responsibilities ensures executive- level visibility into the PCI DSS compliance program and allows for the opportunity to ask appropriate questions to determine the effectiveness of the program and influence strategic priorities.

Added p. 273

• Overall accountability for maintaining PCI DSS compliance.

• Defining a charter for a PCI DSS compliance program and communication to executive management.

Added p. 273

Customized Approach Objective Executives are responsible and accountable for security of cardholder data.

Applicability Notes This requirement applies only when the entity being assessed is a service provider. Executive management may include C-level positions, board of directors, or equivalent. The specific titles will depend on the particular organizational structure. Responsibility for the PCI DSS compliance program may be assigned to individual roles and/or to business units within the organization.

Added p. 274

• Configuration reviews for network security controls.

• Applying configuration standards to new systems.

• Responding to security alerts.

• Change-management processes.

12.4.2.a Additional testing procedure for service provider assessments only: Examine policies and procedures to verify that processes are defined for conducting reviews to confirm that personnel are performing their tasks in accordance with all security policies and all operational procedures, including but not limited to the tasks specified in this requirement.

12.4.2.b Additional testing procedure for service provider assessments only: Interview responsible personnel and examine records of reviews to verify that reviews are performed:

• By personnel other than those responsible for performing the given task.

Customized Approach Objective The operational effectiveness of critical PCI DSS controls is verified periodically by manual inspection of records.

Added p. 275

• Results of the reviews.

• Documented remediation actions taken for any tasks that were found to not be performed at Requirement 12.4.2.

• Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program.

Added p. 275

Customized Approach Objective Findings from operational effectiveness reviews are evaluated by management; appropriate remediation activities are implemented.

Added p. 276

Defined Approach Requirements Defined Approach Testing Procedures Purpose Maintaining a current list of all system components will enable an organization to define the scope of its environment and implement PCI DSS requirements accurately and efficiently. Without an inventory, some system components could be overlooked and be inadvertently excluded from the organization’s configuration standards. Good Practice If an entity keeps an inventory of all assets, those system components in scope for PCI DSS should be clearly identifiable among the other assets. Inventories should include containers or images that may be instantiated. Assigning an owner to the inventory helps to ensure the inventory stays current. Examples Methods to maintain an inventory include as a database, as a series of files, or in an inventory- management tool.

Added p. 276

12.5.1.a Examine the inventory to verify it includes all in-scope system components and a description of function/use for each.

12.5.1.b Interview personnel to verify the inventory is kept current.

Customized Approach Objective All system components in scope for PCI DSS are identified and known.

Added p. 277

• Data stores (databases, files, cloud, etc.), including the purpose of data storage and the retention period,

• Which CHD elements are stored (PAN, expiry date, cardholder name, and/or any elements of SAD prior to completion of authorization),

• How data is secured (type of encryption and strength, hashing algorithm and strength, truncation, tokenization),

• How access to data stores is logged, including a description of logging mechanism(s) in use (enterprise solution, application level, operating system level, etc.). (continued on next page) 12.5.2 PCI DSS scope is documented and confirmed by the entity at least once every 12 months and upon significant change to the in-scope environment. At a minimum, the scoping validation includes:

• Identifying all data flows for the various payment stages (for example, authorization, capture settlement, chargebacks, and refunds) and acceptance channels (for example, card-present, card-not-present, and e-commerce).

• Updating all data-flow diagrams per Requirement 1.2.4.

• Identifying all locations where account data …

Added p. 278

• for example, in an error log or memory dump file. This approach can help ensure that previously unknown locations of PAN are detected and that the PAN is either eliminated or properly secured. Further Information For additional guidance, refer to Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation.

PCI DSS scope is verified periodically, and after significant changes, by comprehensive analysis and appropriate technical measures.

Applicability Notes This annual confirmation of PCI DSS scope is an activity expected to be performed by the entity under assessment, and is not the same, nor is it intended to be replaced by, the scoping confirmation performed by the entity’s assessor during the annual assessment.

Added p. 279

12.5.2.1.a Additional testing procedure for service provider assessments only: Examine documented results of scope reviews and interview personnel to verify that reviews per Requirement 12.5.2 are performed:

• At least once every six months, and

• After significant changes 12.5.2.1.b Additional testing procedure for service provider assessments only: Examine documented results of scope reviews to verify that scoping validation includes all elements specified in Requirement 12.5.2.

Customized Approach Objective The accuracy of PCI DSS scope is verified to be continuously accurate by comprehensive analysis and appropriate technical measures.

Added p. 280

12.5.3.a Additional testing procedure for service provider assessments only: Examine policies and procedures to verify that processes are defined such that a significant change to organizational structure results in documented review of the impact to PCI DSS scope and applicability of controls.

12.5.3.b Additional testing procedure for service provider assessments only: Examine documentation (for example, meeting minutes) and interview responsible personnel to verify that significant changes to organizational structure resulted in documented reviews that included all elements specified in this requirement, with results communicated to executive management.

Customized Approach Objective

PCI DSS scope is confirmed after significant organizational change.

Added p. 281

Defined Approach Requirements Defined Approach Testing Procedures Purpose If personnel are not educated about their company’s information security policies and procedures and their own security responsibilities, security safeguards and processes that have been implemented may become ineffective through unintentional errors or intentional actions.

Added p. 281

Customized Approach Objective Personnel are knowledgeable about the threat landscape, their responsibility for the operation of relevant security controls, and are able to access assistance and guidance when required.

Defined Approach Requirements Defined Approach Testing Procedures Purpose The threat environment and an entity’s defenses are not static. As such, the security awareness program materials must be updated as frequently as needed to ensure that the education received by personnel is up to date and represents the current threat environment.

Added p. 281

• Reviewed at least once every 12 months, and

• Updated as needed to address any new threats and vulnerabilities that may impact the security of the entity’s CDE, or the information provided to personnel about their role in protecting cardholder data.

Added p. 281

Customized Approach Objective The content of security awareness material is reviewed and updated periodically.

Added p. 282

• Upon hire and at least once every 12 months.

• Multiple methods of communication are used.

• Personnel acknowledge at least once every 12 months that they have read and understood the information security policy and procedures.

12.6.3.a Examine security awareness program records to verify that personnel attend security awareness training upon hire and at least once every 12 months.

12.6.3.b Examine security awareness program materials to verify the program includes multiple methods of communicating awareness and educating personnel.

12.6.3.c Interview personnel to verify they have completed awareness training and are aware of their role in protecting cardholder data.

12.6.3.d Examine security awareness program materials and personnel acknowledgments to verify that personnel acknowledge at least once every 12 months that they have read and understand the information security policy and procedures.

Customized Approach Objective Personnel remain knowledgeable about the threat landscape, their responsibility for the operation of relevant security controls, and are able to access assistance …

Added p. 283

• How to identify phishing and other social engineering attacks.

• How to react to suspected phishing and social engineering.

• Where and how to report suspected phishing and social engineering activity. An emphasis on reporting allows the organization to reward positive behavior, to optimize technical defenses (see Requirement 5.4.1), and to take immediate action to remove similar phishing emails that evaded technical defenses from recipient inboxes.

Added p. 283

• Phishing and related attacks.

• Social engineering.

Added p. 283

Customized Approach Objective Personnel are knowledgeable about their own human vulnerabilities and how threat actors will attempt to exploit such vulnerabilities. Personnel are able to access assistance and guidance when required.

Applicability Notes See Requirement 5.4.1 for guidance on the difference between technical and automated controls to detect and protect users from phishing attacks, and this requirement for providing users security awareness training about phishing and social engineering. These are two separate and distinct requirements, and one is not met by implementing controls required by the other one. 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.

Added p. 284

Customized Approach Objective Personnel are knowledgeable about their responsibility for the security and operation of end- user technologies and are able to access assistance and guidance when required.

Added p. 285

Defined Approach Requirements Defined Approach Testing Procedures Purpose Performing thorough screening prior to hiring potential personnel who are expected to be given access to the CDE provides entities with the information necessary to make informed risk decisions regarding personnel they hire that will have access to the CDE. Other benefits of screening potential personnel include helping to ensure workplace safety and confirming information provided by prospective employees on their resumes. Good Practice Entities should consider screening for existing personnel anytime they transfer into roles where they have access to the CDE from roles where they did not have this access. To be effective, the level of screening should be appropriate for the position. For example, positions requiring greater responsibility or that have administrative access to critical data or systems may warrant more detailed or more frequent screening than positions with less responsibility and access. Examples Screening options can include, as …

Added p. 285

Customized Approach Objective The risk related to allowing new members of staff access to the CDE is understood and managed.

Applicability Notes For those potential personnel to be hired for positions such as store cashiers, who only have access to one card number at a time when facilitating a transaction, this requirement is a recommendation only.

Added p. 286

Defined Approach Requirements Defined Approach Testing Procedures Purpose Maintaining a list of all TPSPs identifies where potential risk extends outside the organization and defines the organization’s extended attack surface. Examples Different types of TPSPs include those that:

• Store, process, or transmit account data on the entity’s behalf (such as payment gateways, payment processors, payment service providers (PSPs), and off-site storage providers).

• Manage system components included in the entity’s PCI DSS assessment (such as providers of network security control services, anti-malware services, and security incident and event management (SIEM); contact and call centers; web-hosting companies; and IaaS, PaaS, SaaS, and FaaS cloud providers).

• Could impact the security of the entity’s CDE (such as vendors providing support via remote access, and bespoke software developers).

Added p. 286

12.8.1.a Examine policies and procedures to verify that processes are defined to maintain a list of TPSPs, including a description for each of the services provided, for all TPSPs with whom account data is shared or that could affect the security of account data.

12.8.1.b Examine documentation to verify that a list of all TPSPs is maintained that includes a description of the services provided. Customized Approach Objective Records are maintained of TPSPs and the services provided.

Applicability Notes The use of a PCI DSS compliant TPSP does not make an entity PCI DSS compliant, nor does it remove the entity’s responsibility for its own PCI DSS compliance.

Added p. 287

• Written agreements are maintained with all TPSPs with which account data is shared or that could affect the security of the CDE.

• Written agreements include acknowledgments from TPSPs that they are responsible for the security of account data the TPSPs possess or otherwise store, process, or transmit on behalf of the entity, or to the extent that they could impact the security of the entity’s CDE.

12.8.2.a Examine policies and procedures to verify that processes are defined to maintain written agreements with all TPSPs in accordance with all elements specified in this requirement.

12.8.2.b Examine written agreements with TPSPs to verify they are maintained in accordance with all elements as specified in this requirement.

Customized Approach Objective Records are maintained of each TPSP’s acknowledgment of its responsibility to protect account data.

Applicability Notes The exact wording of an acknowledgment will depend on the agreement between the two parties, the details of the service …

Added p. 288

12.8.3.b Examine evidence and interview responsible personnel to verify the process for engaging TPSPs includes proper due diligence prior to engagement. Customized Approach Objective The capability, intent, and resources of a prospective TPSP to adequately protect account data are assessed before the TPSP is engaged.

Added p. 289

• PCI DSS section: Use of Third-Party Service Providers.

• Information Supplement: Third-Party Security Assurance.

Added p. 289

12.8.4.a Examine policies and procedures to verify that processes are defined to monitor TPSPs’ PCI DSS compliance status at least once every 12 months.

12.8.4.b Examine documentation and interview responsible personnel to verify that the PCI DSS compliance status of each TPSP is monitored at least once every 12 months. Customized Approach Objective The PCI DSS compliance status of TPSPs is verified periodically.

Applicability Notes Where an entity has an agreement with a TPSP for meeting PCI DSS requirements on behalf of the entity (for example, via a firewall service), the entity must work with the TPSP to make sure the applicable PCI DSS requirements are met. If the TPSP does not meet those applicable PCI DSS requirements, then those requirements are also “not in place” for the entity.

Added p. 290

12.8.5.a Examine policies and procedures to verify that processes are defined to maintain information about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between both the TPSP and the entity.

12.8.5.b Examine documentation and interview personnel to verify the entity maintains information about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between both entities.

Customized Approach Objective Records detailing the PCI DSS requirements and related system components for which each TPSP is solely or jointly responsible, are maintained and reviewed periodically.

Added p. 292

Defined Approach Requirements Defined Approach Testing Procedures Purpose In conjunction with Requirement 12.8.2, this requirement is intended to promote a consistent level of understanding between TPSPs and their customers about their applicable PCI DSS responsibilities. The acknowledgment of the TPSPs evidences their commitment to maintaining proper security of account data that it obtains from its clients. The method by which the TPSP provides written acknowledgment should be agreed between the provider and its customers.

Added p. 292

Customized Approach Objective TPSPs formally acknowledge their security responsibilities to their customers.

Applicability Notes This requirement applies only when the entity being assessed is a service provider. The exact wording of an acknowledgment will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgment does not have to include the exact wording provided in this requirement.

Added p. 293

• PCI DSS compliance status information for any service the TPSP performs on behalf of customers (Requirement 12.8.4).

• Information about which PCI DSS requirements are the responsibility of the TPSP and which are the responsibility of the customer, including any shared responsibilities (Requirement 12.8.5).

Added p. 293

Customized Approach Objective TPSPs provide information as needed to support their customers’ PCI DSS compliance efforts.

• PCI DSS section: Use of Third-Party Service Providers.

Added p. 294

• Information Supplement: Third-Party Security Assurance (includes a sample responsibility matrix template).

Added p. 295

Defined Approach Requirements Defined Approach Testing Procedures Purpose Without a comprehensive incident response plan that is properly disseminated, read, and understood by the parties responsible, confusion and lack of a unified response could create further downtime for the business, unnecessary public media exposure, as well as risk of financial and/or reputational loss and legal liabilities. Good Practice The incident response plan should be thorough and contain all the key elements for stakeholders (for example, legal, communications) to allow the entity to respond effectively in the event of a breach that could impact account data. It is important to keep the plan up to date with current contact information of all individuals designated as having a role in incident response. Other relevant parties for notifications may include customers, financial institutions (acquirers and issuers), and business partners. Entities should consider how to address all compromises of data within the CDE in their …

Added p. 295

• Roles, responsibilities, and communication and contact strategies in the event of a suspected or confirmed security incident, including notification of payment brands and acquirers, at a minimum.

• Incident response procedures with specific containment and mitigation activities for different types of incidents.

• Business recovery and continuity procedures.

• Data backup processes.

• Analysis of legal requirements for reporting compromises.

12.10.1.a Examine the incident response plan to verify that the plan exists and includes at least the elements specified in this requirement.

12.10.1.b Interview personnel and examine documentation from previously reported incidents or alerts to verify that the documented incident response plan and procedures were followed.

Customized Approach Objective A comprehensive incident response plan that meets card brand expectations is maintained.

Added p. 296

• Reviewed and the content is updated as needed.

• Tested, including all elements listed in Requirement 12.10.1.

Added p. 296

• Reviewed and updated as needed.

• Tested, including all elements listed in Requirement 12.10.1. Customized Approach Objective The incident response plan is kept current and tested periodically.

Added p. 298

Customized Approach Objective Personnel are knowledgeable about their role and responsibilities in incident response and are able to access assistance and guidance when required.

Defined Approach Requirements Defined Approach Testing Procedures Purpose Each entity’s environment and incident response plan are different and the approach will depend on a number of factors, including the size and complexity of the entity, the degree of change in the environment, the size of the incident response team, and the turnover in personnel. Performing a risk analysis will allow the entity to determine the optimum frequency for training personnel with incident response responsibilities.

Added p. 298

12.10.4.1.a Examine the entity’s targeted risk analysis for the frequency of training for incident response personnel to verify the risk analysis was performed in accordance with all elements specified in Requirement 12.3.1.

12.10.4.1.b Examine documented results of periodic training of incident response personnel and interview personnel to verify training is performed at the frequency defined in the entity’s targeted risk analysis performed for this requirement.

Customized Approach Objective Incident response personnel are trained at a frequency that addresses the entity’s risk.

• Network security controls.

Added p. 299

• Intrusion-detection and intrusion-prevention systems.

• Change-detection mechanisms for critical files.

• The change-and tamper-detection mechanism for payment pages. This bullet is a best practice until its effective date; refer to Applicability Notes below for details.

• Detection of unauthorized wireless access points.

Added p. 299

Customized Approach Objective Alerts generated by monitoring and detection technologies are responded to in a structured, repeatable manner.

Applicability Notes The bullet above (for monitoring and responding to alerts from a change- and tamper-detection mechanism for payment pages) is a best practice until 31 March 2025, after which it will be required as part of Requirement 12.10.5 and must be fully considered during a PCI DSS assessment.

Added p. 300

12.10.6.a Examine policies and procedures to verify that processes are defined to modify and evolve the security incident response plan according to lessons learned and to incorporate industry developments.

12.10.6.b Examine the security incident response plan and interview responsible personnel to verify that the incident response plan is modified and evolved according to lessons learned and to incorporate industry developments.

Customized Approach Objective The effectiveness and accuracy of the incident response plan is reviewed and updated after each invocation.

Added p. 301

• Determining what to do if PAN is discovered outside the CDE, including its retrieval, secure deletion, and/or migration into the currently defined CDE, as applicable.

• Identifying whether sensitive authentication data is stored with PAN.

• Determining where the account data came from and how it ended up where it was not expected.

• Remediating data leaks or process gaps that resulted in the account data being where it was not expected.

12.10.7.a Examine documented incident response procedures to verify that procedures for responding to the detection of stored PAN anywhere it is not expected to exist, ready to be initiated, and include all elements specified in this requirement.

12.10.7.b Interview personnel and examine records of response actions to verify that incident response procedures are performed upon detection of stored PAN anywhere it is not expected.

Customized Approach Objective Processes are in place to quickly respond, analyze, and address situations in the event that cleartext …

Added p. 302

 Appendix A1: Additional PCI DSS Requirements for Multi-Tenant Service Providers  Appendix A2: Additional PCI DSS Requirements for Entities Using SSL/early TLS for Card-Present POS POI Terminal Connections  Appendix A3: Designated Entities Supplemental Validation (DESV) Guidance and applicability information is provided in each section.

Appendix A1: Additional PCI DSS Requirements for Multi-Tenant Service Providers A1.1 Multi-tenant service providers protect and separate all customer environments and data. A1.2 Multi-tenant service providers facilitate logging and incident response for all customers.

All service providers are responsible for meeting PCI DSS requirements for their own environments as applicable to the services offered to their customers. In addition, multi-tenant service providers must meet the requirements in this Appendix. Multi-tenant service providers are a type of third-party service provider that offers various shared services to merchants and other service providers, where customers share system resources (such as physical or virtual servers), infrastructure, applications (including Software as …

Added p. 303

Defined Approach Requirements Defined Approach Testing Procedures Purpose Without controls between the provider’s environment and the customer’s environment, a malicious actor within the provider’s environment could compromise the customer’s environment, and similarly, a malicious actor in a customer environment could compromise the provider and potentially other of the provider’s customers. Multi-tenant environments should be isolated from each other and from the provider’s infrastructure such that they can be separately managed entities with no connectivity between them. Good Practice Providers should ensure strong separation between the environments that are designed for customer access, for example, configuration and billing portals, and the provider’s private environment that should only be accessed by authorized provider personnel. Service provider access to customer environments is performed in accordance with requirement 8.2.3. Further Information Refer to the Information Supplement: PCI SSC Cloud Computing Guidelines for further guidance on cloud environments.

A1.1.1 Logical separation is implemented as follows:

• The …

Added p. 304

A1.1.2 Controls are implemented such that each customer only has permission to access its own cardholder data and CDE.

A1.1.2.a Examine documentation to verify controls are defined such that each customer only has permission to access its own cardholder data and CDE.

A1.1.2.b Examine system configurations to verify that customers have privileges established to only access their own account data and CDE. Customized Approach Objective Customers cannot access other customers’ environments.

Defined Approach Requirements Defined Approach Testing Procedures Purpose To prevent any inadvertent or intentional impact to other customers’ environments or account data, it is important that each customer can access only resources allocated to that customer.

A1.1.3 Controls are implemented such that each customer can only access resources allocated to them.

A1.1.3 Examine customer privileges to verify each customer can only access resources allocated to them.

Customized Approach Objective Customers cannot impact resources allocated to other customers.

Added p. 305

A1.1.4 The effectiveness of logical separation controls used to separate customer environments is confirmed at least once every six months via penetration testing.

A1.1.4 Examine the results from the most recent penetration test to verify that testing confirmed the effectiveness of logical separation controls used to separate customer environments.

Customized Approach Objective Segmentation of customer environments from other environments is periodically validated to be effective.

Applicability Notes The testing of adequate separation between customers in a multi-tenant service provider environment is in addition to the penetration tests specified in Requirement 11.4.6. 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.

Added p. 306

Defined Approach Requirements Defined Approach Testing Procedures Purpose Log information is useful for detecting and troubleshooting security incidents and is invaluable for forensic investigations. Customers therefore need to have access to these logs. However, log information can also be used by an attacker for reconnaissance, and so a customer’s log information must only be accessible by the customer that the log relates to.

A1.2.1 Audit log capability is enabled for each customer’s environment that is consistent with PCI DSS Requirement 10, including:

• Logs are available for review only by the owning customer.

• Log locations are clearly communicated to the owning customer.

• Log data and availability is consistent with PCI DSS Requirement 10.

A1.2.1 Examine documentation and system configuration settings to verify the provider has enabled audit log capability for each customer environment in accordance with all elements specified in this requirement.

Customized Approach Objective Log capability is available to all customers without affecting …

Added p. 307

A1.2.3 Processes or mechanisms are implemented for reporting and addressing suspected or confirmed security incidents and vulnerabilities, including:

• Customers can securely report security incidents and vulnerabilities to the provider.

• The provider addresses and remediates suspected or confirmed security incidents and vulnerabilities according to Requirement 6.3.1.

A1.2.3 Examine documented procedures and interview personnel to verify that the provider has a mechanism for reporting and addressing suspected or confirmed security incidents and vulnerabilities, in accordance with all elements specified in this requirement.

Customized Approach Objective Suspected or confirmed security incidents or vulnerabilities are discovered and addressed. Customers are informed where appropriate.

Added p. 308

This Appendix applies only to entities using SSL/early TLS as a security control to protect POS POI terminals, including service providers that provide connections into POS POI terminals.

Entities using SSL and early TLS for POS POI terminal connections must work toward upgrading to a strong cryptographic protocol as soon as possible. Additionally, SSL and/or early TLS must not be introduced into environments where those protocols don’t already exist. At the time of publication, the known vulnerabilities are difficult to exploit in POS POI payment terminals. However, new vulnerabilities could emerge at any time, and it is up to the organization to remain up to date with vulnerability trends and determine whether it is susceptible to any known exploits.

• Requirement 2.2.5: Where any insecure services, protocols, or daemons are present; business justification is documented, and additional security features are documented and implemented that reduce the risk of using insecure services, protocols, …

Added p. 309

Defined Approach Requirements Defined Approach Testing Procedures Purpose POS POI terminals used in card-present environments can continue using SSL/early TLS when it can be shown that the POS POI terminal is not susceptible to the currently known exploits. Good Practice However, SSL is outdated technology and could be susceptible to additional security vulnerabilities in the future; it is therefore strongly recommended that POS POI terminals be upgraded to a secure protocol as soon as possible. If SSL/early TLS is not needed in the environment, use of, and fallback to these versions should be disabled. Further Information Refer to the current PCI SSC Information Supplements on SSL/Early TLS for further guidance.

A2.1.1 Where POS POI terminals at the merchant or payment acceptance location use SSL and/or early TLS, the entity confirms the devices are not susceptible to any known exploits for those protocols.

A2.1.1 For POS POI terminals using SSL and/or early TLS, …

Added p. 310

A2.1.2 Additional requirement for service providers only: All service providers with existing connection points to POS POI terminals that use SSL and/or early TLS as defined in A2.1 have a formal Risk Mitigation and Migration Plan in place that includes:

• Description of usage, including what data is being transmitted, types and number of systems that use and/or support SSL/early TLS, and type of environment.

• Risk-assessment results and risk-reduction controls in place.

• Description of processes to monitor for new vulnerabilities associated with SSL/early TLS.

• Description of change control processes that are implemented to ensure SSL/early TLS is not implemented into new environments.

A2.1.2 Additional testing procedure for service provider assessments only: Review the documented Risk Mitigation and Migration Plan to verify it includes all elements specified in this requirement.

Added p. 311

A2.1.3 Additional requirement for service providers only: All service providers provide a secure service offering.

A2.1.3 Additional testing procedure for service provider assessments only: Examine system configurations and supporting documentation to verify the service provider offers a secure protocol option for its service. Customized Approach Objective This requirement is not eligible for the customized approach.

• The activity was performed in accordance with the applicable requirement within the most recent timeframe (for example, the most recent three-month or six-month period), and

• The entity has documented policies and procedures for continuing to perform the activity within the defined timeframe.

Added p. 312

This Appendix applies only to entities designated by a payment brand(s) or acquirer as requiring additional validation of existing PCI DSS requirements. An entity is required to undergo an assessment according to this Appendix ONLY if instructed to do so by an acquirer or a payment brand. Examples of entities that this Appendix could apply to include:

• Those storing, processing, and/or transmitting large volumes of account data,

• Those providing aggregation points for account data, or

• Those that have suffered significant or repeated breaches of account data.

Additionally, other PCI standards may reference completion of this Appendix.

These supplemental validation steps are intended to provide greater assurance that PCI DSS controls are maintained effectively and on a continuous basis through validation of business-as-usual (BAU) processes and increased validation and scoping consideration.

Note: Some requirements have defined timeframes (for example, at least once every three months or at least once every six months) within which …

Added p. 313

Defined Approach Requirements Defined Approach Testing Procedures Purpose Executive management assignment of PCI DSS compliance responsibilities ensures executive- level visibility into the PCI DSS compliance program and allows for the opportunity to ask appropriate questions to determine the effectiveness of the program and influence strategic priorities. Good Practice Executive management may include C-level positions, board of directors, or equivalent. The specific titles will depend on the particular organizational structure. Responsibility for the PCI DSS compliance program may be assigned to individual roles and/or to business units within the organization.

A3.1.1 Responsibility is established by executive management for the protection of account data and a PCI DSS compliance program that includes:

• Defining a charter for a PCI DSS compliance program.

• Providing updates to executive management and board of directors on PCI DSS compliance initiatives and issues, including remediation activities, at least once every 12 months. PCI DSS Reference: Requirement 12 A3.1.1.a Examine …

Added p. 314

A3.1.2 A formal PCI DSS compliance program is in place that includes:

• Definition of activities for maintaining and monitoring overall PCI DSS compliance, including business-as-usual activities.

• Annual PCI DSS assessment processes.

• Processes for the continuous validation of PCI DSS requirements (for example, daily, weekly, every three months, as applicable per the requirement).

• A process for performing business-impact analysis to determine potential PCI DSS impacts for strategic business decisions. PCI DSS Reference: Requirements 1-12 A3.1.2.a Examine information security policies and procedures to verify that processes are defined for a formal PCI DSS compliance program that includes all elements specified in this requirement.

A3.1.2.b Interview personnel and observe compliance activities to verify that a formal PCI DSS compliance program is implemented in accordance with all elements specified in this requirement.

Added p. 315

A3.1.3 PCI DSS compliance roles and responsibilities are specifically defined and formally assigned to one or more personnel, including:

• Managing PCI DSS business-as-usual activities.

• Managing annual PCI DSS assessments.

• Managing continuous validation of PCI DSS requirements (for example, daily, weekly, every three months, as applicable per the requirement).

• Managing business-impact analysis to determine potential PCI DSS impacts for strategic business decisions. PCI DSS Reference: Requirement 12 A3.1.3.a Examine information security policies and procedures and interview personnel to verify that PCI DSS compliance roles and responsibilities are specifically defined and formally assigned to one or more personnel in accordance with all elements of this requirement.

Added p. 316

A3.1.4 Up-to-date PCI DSS and/or information security training is provided at least once every 12 months to personnel with PCI DSS compliance responsibilities (as identified in A3.1.3). PCI DSS Reference: Requirement 12 A3.1.4.a Examine information security policies and procedures to verify that PCI DSS and/or information security training is required at least once every 12 months for each role with PCI DSS compliance responsibilities.

A3.1.4.b Interview personnel and examine certificates of attendance or other records to verify that personnel with PCI DSS compliance responsibility receive up-to-date PCI DSS and/or similar information security training at least once every 12 months.

• Which CHD elements are stored (PAN, expiry date, cardholder name, and/or any elements of SAD prior to completion of authorization),

• How data is secured (type of encryption and strength, hashing algorithm and strength, truncation, tokenization),

• Updating all data-flow diagrams per Requirement 1.2.4.

• Identifying all system components in the CDE, connected to the …

Added p. 317

Defined Approach Requirements Defined Approach Testing Procedures Purpose Frequent validation of PCI DSS scope helps to ensure PCI DSS scope remains up to date and aligned with changing business objectives, and therefore that security controls are protecting all appropriate system components. Good Practice Accurate scoping involves critically evaluating the CDE and all connected system components to determine the necessary coverage for PCI DSS requirements. Scoping activities, including careful analysis and ongoing monitoring, help to ensure that in-scope systems are appropriately secured. When documenting account data locations, the entity can consider creating a table or spreadsheet that includes the following information:

• Data stores (databases, files, cloud, etc.), including purpose of data storage and the retention period,

• How access to data stores is logged, including a description of logging mechanism(s) in use (enterprise solution, application level, operating system level, etc.). (continued on next page) A3.2.1 PCI DSS scope is documented and confirmed …

Added p. 319

A3.2.2 PCI DSS scope impact for all changes to systems or networks is determined, including additions of new systems and new network connections. Processes include:

• Performing a formal PCI DSS impact assessment.

• Identifying applicable PCI DSS requirements to the system or network.

• Updating PCI DSS scope as appropriate.

• Documented sign-off of the results of the impact assessment by responsible personnel (as defined in A3.1.3). PCI DSS Reference: Scope of PCI DSS Requirements; Requirements 1-12 A3.2.2 Examine change documentation and interview personnel to verify that for each change to systems or networks the PCI DSS scope impact is determined, and includes all elements specified in this requirement.

Added p. 320

• Network diagrams are updated to reflect changes.

• for example, file integrity monitoring, anti-malware, patches, and audit logging.

• Sensitive authentication data is not stored, and that all account data storage is documented and incorporated into data-retention policy and procedures.

A3.2.2.1 Upon completion of a change, all relevant PCI DSS requirements are confirmed to be implemented on all new or changed systems and networks, and documentation is updated as applicable. PCI DSS Reference: Scope of PCI DSS Requirements; Requirement 1-12 A3.2.2.1 Examine change records and the affected systems/networks, and interview personnel to verify that all relevant PCI DSS requirements were confirmed to be implemented and documentation updated as part of the change.

Added p. 321

A3.2.3 Changes to organizational structure result in a formal (internal) review of the impact to PCI DSS scope and applicability of controls. PCI DSS Reference: Requirement 12 A3.2.3 Examine policies and procedures to verify that a change to organizational structure results in formal a review of the impact on PCI DSS scope and applicability of controls.

Added p. 322

A3.2.4 If segmentation is used, PCI DSS scope is confirmed as follows:

• Per the entity’s methodology defined at Requirement 11.4.1.

• Penetration testing is performed on segmentation controls at least once every six months and after any changes to segmentation controls/methods.

• The penetration testing verifies that segmentation controls/methods are operational and effective, and isolate the CDE from all out- of-scope systems. PCI DSS Reference: Requirement 11 A3.2.4 Examine the results from the most recent penetration test to verify that the test was conducted in accordance with all elements specified in this requirement.

Added p. 323

• helps to ensure that previously unknown locations of cleartext PAN are detected and properly secured. Examples A data-discovery process can be performed via a variety of methods, including, but not limited to 1) commercially available data-discovery software, 2) an in-house developed data-discovery program, or 3) a manual search. A combination of methodologies may also be used as needed. Regardless of the method used, the goal of the effort is to find all sources and locations of cleartext PAN (not just in the defined CDE).

A3.2.5 A data-discovery methodology is implemented that:

• Confirms PCI DSS scope.

• Locates all sources and locations of cleartext PAN at least once every three months and upon significant changes to the CDE or processes.

• Addresses the potential for cleartext PAN to reside on systems and networks outside the currently defined CDE. PCI DSS Reference: Scope of PCI DSS Requirements A3.2.5.a Examine the documented data-discovery methodology to …

Added p. 324

A3.2.5.1 Data discovery methods are confirmed as follows:

• Effectiveness of methods is tested.

• Methods are able to discover cleartext PAN on all types of system components and file formats in use.

• The effectiveness of data-discovery methods is confirmed at least once every 12 months. PCI DSS Reference: Scope of PCI DSS Requirements A3.2.5.1.a Interview personnel and review documentation to verify:

• The process includes verifying the methods are able to discover cleartext PAN on all types of system components and file formats in use.

A3.2.5.1.b Examine the results of effectiveness tests to verify that the effectiveness of data- discovery methods is confirmed at least once every 12 months. Customized Approach Objective This requirement is not eligible for the customized approach.

Added p. 325

A3.2.5.2 Response procedures are implemented to be initiated upon the detection of cleartext PAN outside the CDE to include:

• Determining what to do if cleartext PAN is discovered outside the CDE, including its retrieval, secure deletion, and/or migration into the currently defined CDE, as applicable.

• Determining how the data ended up outside the CDE.

• Remediating data leaks or process gaps that resulted in the data being outside the CDE.

• Identifying the source of the data.

• Identifying whether any track data is stored with the PANs.

A3.2.5.2.a Examine documented response procedures to verify that procedures for responding to the detection of cleartext PAN outside the CDE are defined and include all elements specified in this requirement.

A3.2.5.2.b Interview personnel and examine records of response actions to verify that remediation activities are performed when cleartext PAN is detected outside the CDE.

Added p. 326

A3.2.6 Mechanisms are implemented for detecting and preventing cleartext PAN from leaving the CDE via an unauthorized channel, method, or process, including mechanisms that are:

• Configured to detect and prevent cleartext PAN leaving the CDE via an unauthorized channel, method, or process.

• Generating audit logs and alerts upon detection of cleartext PAN leaving the CDE via an unauthorized channel, method, or process. PCI DSS Reference: Scope of PCI DSS Requirements, Requirement 12 A3.2.6.a Examine documentation and observe implemented mechanisms to verify that the mechanisms are in accordance with all elements specified in this requirement.

Added p. 327

A3.2.6.1 Response procedures are implemented to be initiated upon the detection of attempts to remove cleartext PAN from the CDE via an unauthorized channel, method, or process. Response procedures include:

• Procedures for the prompt investigation of alerts by responsible personnel.

• Procedures for the prompt investigation of alerts by responsible personnel.

• Procedures for remediating data leaks or process gaps, as necessary, to prevent any data loss. PCI DSS Reference: Requirement 12 A3.2.6.1.a Examine documented response procedures to verify that procedures for responding to the attempted removal of cleartext PAN from the CDE via an unauthorized channel, method, or process include all elements specified in this requirement:

• Procedures for remediating data leaks or process gaps, as necessary, to prevent any data loss.

A3.2.6.1.b Interview personnel and examine records of actions taken when cleartext PAN is detected leaving the CDE via an unauthorized channel, method, or process and verify that remediation activities were performed.

Added p. 328

Defined Approach Requirements Defined Approach Testing Procedures Purpose Without formal processes for the prompt (as soon as possible) detection, alerting, and addressing of critical security control failures, failures may go undetected or remain unresolved for extended periods. In addition, without formalized time- bound processes, attackers will have ample time to compromise systems 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.

A3.3.1 Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of:

• Anti-malware solutions

• Automated audit log review mechanisms. This bullet is a best practice until its effective date; refer to Applicability Notes …

Added p. 330

A3.3.2 Hardware and software technologies are reviewed at least once every 12 months to confirm whether they continue to meet the organization’s PCI DSS requirements. PCI DSS Reference: Requirements 2, 6, 12.

Applicability Notes The process includes a plan for remediating technologies that no longer meet the organization’s PCI DSS requirements, up to and including replacement of the technology, as appropriate.

Added p. 332

Defined Approach Requirements 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.

A3.4.1 User accounts and access privileges to in- scope system components are reviewed at least once every six months to ensure user accounts and access privileges remain appropriate based on job function, and that all access is authorized. PCI DSS Reference: Requirement 7 A3.4.1 Interview responsible personnel and examine supporting documentation to verify that:

Added p. 333

Defined Approach Requirements Defined Approach Testing Procedures Purpose The ability to identify attack patterns and undesirable behavior across systems

•for example, using centrally managed or automated log-correlation tools

A3.5.1 A methodology is implemented for the prompt identification of attack patterns and undesirable behavior across systems that includes:

4. When evaluating “above and beyond” for compensating controls, consider the following:

Added p. 335

5. Address the additional risk imposed by not adhering to the PCI DSS requirement.

6. Address the requirement currently and in the future. A compensating control cannot address a requirement that was missed in the past (for example, where performance of a task was required two quarters ago, but that task was not performed).

The assessor is required to thoroughly evaluate compensating controls during each annual PCI DSS assessment to confirm that each compensating control adequately addresses the risk that the original PCI DSS requirement was designed to address, per items 1-6 above.

To maintain compliance, processes and controls must be in place to ensure compensating controls remain effective after the assessment is complete. Additionally, compensating control results must be documented in the applicable report for the assessment (for example, a Report on Compliance or a Self-Assessment Questionnaire) in the corresponding PCI DSS requirement section, and included when the applicable report is submitted …

Added p. 336

Identify the objective met by the compensating control (note: this can be, but is not required to be, the stated Customized Approach Objective for the PCI DSS requirement).

Added p. 337

The entity implementing a customized approach must satisfy the following criteria:

 Document and maintain evidence about each customized control, including all information specified in the Controls Matrix Template in Appendix E1.

 Perform and document a targeted risk analysis (PCI DSS Requirement 12.3.2) for each customized control, including all information specified in the Targeted Risk Analysis Template in Appendix E2.

 Perform testing of each customized control to prove effectiveness, and document testing performed, methods used, what was tested, when testing was performed, and results of testing in the controls matrix.

 Monitor and maintain evidence about the effectiveness of each customized control.

 Provide completed controls matrix(es), targeted risk analysis, testing evidence, and evidence of customized control effectiveness to its assessor.

The assessor performing an assessment of customized controls must satisfy the following criteria:

 Review the entity’s controls matrix(es), targeted risk analysis, and evidence of control effectiveness to fully understand the customized control(s) and …

Added p. 338

Entities that complete a Self-Assessment Questionnaire are not eligible to use a customized approach; however, these entities may elect to have a QSA or ISA perform their assessment and document it in a ROC Template.

The use of the customized approach may be regulated by organizations that manage compliance programs (for example, payment brands and acquirers). Therefore, questions about use of a customized approach must be referred to those organizations, including, for example, whether an entity is required to use a QSA, or may use an ISA to complete an assessment using the customized approach.

Note: Compensating controls are not an option with the customized approach. Because the customized approach allows an entity to determine and design the controls needed to meet a requirement’s Customized Approach Objective, the entity is expected to effectively implement the controls it designed for that requirement without needing to also implement alternate, compensating controls.

Added p. 339

E1 Sample Controls Matrix Template The following is a sample controls matrix template that an entity may use to document their customized implementation.

As described in Appendix D: Customized Approach, entities using the customized approach must complete a controls matrix to provide details for each implemented control that explain what is implemented, how the entity has determined that the controls meet the stated objective of a PCI DSS requirement, how the control provides at least the equivalent level of protection as would be achieved by meeting the defined requirement, and how the entity has assurance about the effectiveness of the control on an ongoing basis.

The assessor uses the information within each controls matrix to plan and prepare for the assessment.

This sample controls matrix template includes the minimum information to be documented by the entity and provided to the assessor for a customized validation. While it is not required that this specific …

Added p. 340

Entity describes how the implemented control(s) meets the stated Customized Approach Objective of the PCI DSS requirement.

<Entity describes how the control meets the stated customized approach objective of the PCI DSS requirement, and summarizes related results> Entity describes testing it performed and the results of that testing that demonstrates the control(s) meets the objective of the applicable requirement.

<Entity describes the testing it performed to prove the control meets the stated objective of the PCI DSS requirement, and summarizes related results> Entity briefly describes the results of the separate targeted risk analysis it performed that explains the control(s) implemented and describes how the results verify the control(s) provides at least an equivalent level of protection as the defined approach for the applicable PCI DSS requirement. See the separate Targeted Risk Analysis Template for details on how to document this risk analysis.

Added p. 341

<Entity describes how it ensures the control is maintained and how the control's effectiveness is assured.> E2 Sample Targeted Risk Analysis Template The following is a sample targeted risk analysis template an entity may use for their customized implementation. While it is not required that an entity follow this specific format, its customized approach documentation must include all the information defined in this template.

As described in Appendix D: Customized Approach and in accordance with PCI DSS Requirement 12.3.2, an entity using the customized approach must provide a detailed targeted risk analysis for each requirement the entity is meeting with the customized approach. The risk analysis defines the risk, evaluates the effect on security if the defined requirement is not met, and describes how the entity has determined that the controls provide at least an equivalent level of protection as provided by the defined PCI DSS requirement.

The assessor uses the information …

Added p. 342

The targeted risk analysis must include at least the information in the following table.

Sample Targeted Risk Analysis for PCI DSS Requirements met via the Customized Approach To be completed by the entity being assessed Item Details

1. Identify the requirement 1.1 Identify the PCI DSS requirement as written. <Entity identifies the requirement> 1.2 Identify the objective of the PCI DSS requirement as written.

<Entity identifies the objective of the requirement> 1.3 Describe the mischief that the requirement was designed to prevent <Entity describes the mischief> <Entity describes the effect on its security if the objective is not successfully met by the entity.> <Entity describes which security fundamentals would not be in place, or what a threat actor may be able to do if the objective is not successfully met by the entity.>

Added p. 343

3. Analyze any changes to the LIKELIHOOD of the mischief occurring, leading to a breach in confidentiality of cardholder data 3.1 Describe the factors detailed in the Control Matrix that affect the likelihood of the mischief occurring.

• How successful the controls will be at preventing the mischief

• How the controls detailed in the Control Matrix reduce the likelihood of the mischief occurring 3.2 Describe the reasons the mischief may still occur after the application of the customized control.

• The typical reasons for the control to fail, the likelihood of this, and how could it be prevented

• How resilient the entity’s processes and systems are for detecting that the control(s) are not operating normally?

• How a threat actor could bypass this control

• what steps would they need to take, how hard is it, would the threat actor be detected before the control failed? How has this been determined?

Added p. 343

• The justification for the assessment documented at 3.3.

• The criteria and values used for the assessment documented at 3.3.

Added p. 344

4. Analyze any changes to the IMPACT of unauthorized access to account data 4.1 For the scope of system components that this solution covers what volume of account data would be at risk of unauthorized access if the solution failed? 4.1.1 Number of stored PANs Maximum at any one time 4.1.2 Number of PANs processed or transmitted over a 12-month period 4.2 Description of how the customized controls will directly:

• Reduce the number of individual PANs compromised if a threat actor is successful, and/or

• Allow quicker notification of the PANs compromised to the card brands.

Impact to the payment ecosystem is directly related to the number of accounts compromised and how quickly any compromised PANs can be blocked by the card issuer. Entity describes how the customized controls achieve the following if any of the customized controls:

• Reduce the volume of cardholder data that is stored, processed, or transmitted and therefore …

Added p. 345

PCI DSS Requirement 6 defines requirements for the development and maintenance of secure systems and software. Because the PCI SSC Secure Software Standard and the Secure SLC Standard (collectively, the Software Security Framework) include rigorous software security requirements, the use of bespoke and custom software that is developed and maintained in accordance with either standard can help the entity to meet several requirements in PCI DSS Requirement 6 without having to perform additional detailed testing, and may also support use of the Customized Approach for other requirements. For details, see Table 7.

Note: This support for meeting Requirement 6 applies only to software that is specifically developed and maintained in accordance with the Secure Software Standard or the Secure SLC Standard; it does not extend to other software or system components in scope for Requirement 6.

Table 7. Leveraging the PCI Software Security Framework to Support Requirement 6

PCI DSS Requirements How PCI …

Added p. 345

PCI DSS Requirement 6.2.4 can be considered in place for software that is developed and maintained in accordance with the Secure Software Standard.

PCI DSS Requirement 6.2 can be considered in place for software that is developed and maintained in accordance with the Secure SLC Standard.

Added p. 345

PCI DSS requirements/objectives apply as usual. Software developed and maintained in accordance with the Secure SLC Standard may support the customized approach for Requirement 6.3 objectives. While use of software developed and maintained in accordance with the Secure SLC Standard provides assurance that the vendor makes security patches and software updates available in a timely manner, the entity retains responsibility for ensuring that patches and updates are installed in accordance with PCI DSS requirements.

PCI DSS requirements/objectives apply as usual.

PCI DSS Requirements How PCI DSS Requirements Apply to Software Developed and Maintained in Accordance with the Secure Software How PCI DSS Requirements Apply to Software Developed and Maintained in Accordance with the Secure SLC Standard 6.4 Public-facing web applications are protected against attacks.

Added p. 346

PCI DSS requirements/objectives apply as usual. Software developed and maintained in accordance with the Secure SLC Standard may support the customized approach for Requirement 6.5 objectives. While use of software developed and maintained in accordance with the Secure SLC Standard provides assurance that the vendor follows change management procedures during development of software and related updates, the entity retains responsibility for ensuring that software and other changes to system components are implemented into its production environment in accordance with PCI DSS requirements.

Use of Bespoke and Custom Software Developed and Maintained by a Secure SLC Qualified Vendor When validating the use of software developed and maintained by a Secure SLC Qualified Vendor to meet PCI DSS Requirement 6.2 and support the Customized Approach for Requirements 6.3 and 6.5, the assessor must confirm that the following is met:

 The software vendor has a current listing on the PCI SSC List of Secure …

Added p. 347

 The software lifecycle management practices were assessed by a Secure SLC Assessor and confirmed to meet all Secure SLC Standard requirements with the results documented in a Secure SLC Report on Compliance (ROC) and Secure SLC Attestation of Compliance (AOC).

 The software was developed and maintained using the software lifecycle management practices covered by the Secure SLC assessment.

 A full Secure SLC assessment of the software lifecycle management practices was completed within the previous 36 months. Additionally, if the most recent full Secure SLC assessment occurred more than 12 months ago, an Annual Attestation was provided by the developer/vendor within the previous 12 months that confirms continued adherence to Secure SLC Standard for the software lifecycle management practices in use.

Validating the Use of the Secure Software Standard When validating the use of software developed and maintained in accordance with the Secure Software Standard to meet PCI DSS Requirement 6.2.4 …

Added p. 348

Account Data Account data consists of cardholder data and/or sensitive authentication data. See Cardholder Data and Sensitive Authentication Data.

Acquirer Also referred to as “merchant bank,” “acquiring bank,” or “acquiring financial institution.” Entity, typically a financial institution, that processes payment card transactions for merchants and is defined by a payment brand as an acquirer. Acquirers are subject to payment brand rules and procedures regarding merchant compliance. See Payment Processor.

Administrative Access Elevated or increased privileges granted to an account for that account to manage systems, networks, and/or applications. Administrative access can be assigned to an individual’s account or a built-in system account. Accounts with administrative access are often referred to as “superuser,” “root,” “administrator,” “admin,” “sysadmin,” or “supervisor-state,” depending on the particular operating system and organizational structure.

AES Acronym for “Advanced Encryption Standard.” See Strong Cryptography.

ANSI Acronym for “American National Standards Institute.” Anti-Malware Software that is designed to detect, and remove, block, or …

Added p. 349

Authentication Credential Combination of the user ID or account ID plus the authentication factor(s) used to authenticate an individual, device, or process. See Account and Authentication Factor.

Authentication Factor The element used to prove or verify the identity of an individual or process on a computer system. Authentication typically occurs with one or more of the following authentication factors:

• Something you are, such as a biometric element. The ID (or account) and authentication factor together are considered authentication credentials.” See Account and Authentication Credential.

Authorization In the context of access control, authorization is the granting of access or other rights to a user, program, or process. Authorization defines what an individual or program can do after successful authentication. In the context of a payment card transaction, authorization refers to the authorization process, which completes when a merchant receives a transaction response (for example, an approval or decline).

BAU Acronym for “Business as Usual.” …

Added p. 350

• The system components, people, and processes that store, process, or transmit cardholder data or sensitive authentication data and/or

CERT Acronym for “Computer Emergency Response Team.” Change Control Processes and procedures to review, test, and approve changes to systems and software for impact before implementation.

CIS Acronym for “Center for Internet Security.” Cleartext Data Unencrypted data.

Column-Level Database Encryption Technique or technology (either software or hardware) for encrypting contents of a specific column in a database versus the full contents of the entire database. Alternatively, see Disk Encryption and File-Level Encryption.

Commercial Off-the- Shelf (COTS) Description of products that are stock items not specifically customized or designed for a specific customer or user and are readily available for use.

Compensating Controls See PCI DSS Appendices B and C.

Compromise Also referred to as “data compromise” or “data breach.” Intrusion into a computer system where unauthorized disclosure/theft, modification, or destruction of cardholder data is suspected.

Console Directly connected …

Added p. 351

• Transforming cleartext data into ciphertext data,

• Transforming ciphertext data into cleartext data,

• A digital signature computed from data,

• Verifying a digital signature computed from data,

• An authentication code computed from data, or

• An exchange agreement of a shared secret. See Strong Cryptography.

Cryptographic Key Generation Key generation is one of the functions within key management. The following documents provide recognized guidance on proper key generation:

• NIST Special Publication 800-133: Recommendation for Cryptographic Key Generation

• ISO 11568-2 Financial services

• ISO 11568-4 Financial services

• Part 2: Symmetric ciphers, their key management and life cycle

• Part 4: Asymmetric cryptosystems

• Key management and life cycle

• 6.2 Key life cycle stages

• European Payments Council EPC 342-08 Guidelines on Algorithms Usage and Key Management

• 4.1.1 Key generation [for symmetric algorithms]

• 4.2.1 Key generation [for asymmetric algorithms].

Cryptographic Key Management The set of processes and mechanisms which support cryptographic key establishment and maintenance, including replacing older keys with …

Added p. 352

Defined Approach See PCI DSS section: 8 Approaches for Implementing and Validating PCI DSS.

Disk Encryption Technique or technology (either software or hardware) for encrypting all stored data on a device (for example, a hard disk or flash drive). Alternatively, File-Level Encryption or Column-Level Database Encryption is used to encrypt contents of specific files or columns.

DMZ Abbreviation for “demilitarized zone.” Physical or logical sub-network that provides an additional layer of security to an organization’s internal private network.

DNS Acronym for “Domain Name System.” Dual Control Process of using two or more separate entities (usually persons) operating in concert to protect sensitive functions or information. Both entities are equally responsible for the physical protection of materials involved in vulnerable transactions. No single person is permitted to access or use the materials (for example, the cryptographic key). For manual key generation, conveyance, loading, storage, and retrieval, dual control requires dividing knowledge of the key …

Added p. 353

FTP Acronym for “File Transfer Protocol.” Network protocol used to transfer data from one computer to another through a public network such as the Internet. FTP is widely viewed as an insecure protocol because passwords and file contents are sent unprotected and in clear text. FTP can be implemented securely via SSH or other technology.

Hashing A method to protect data that converts data into a fixed-length message digest. Hashing is a one-way (mathematical) function in which a non-secret algorithm takes any arbitrary length message as input and produces a fixed length output (usually called a “hash code” or “message digest”). Hash functions are required to have the following properties:

• It is computationally infeasible to determine the original input given only the hash code,

• It is computationally infeasible to find two inputs that give the same hash code.

HSM Acronym for “hardware security module” or “host security module.” A physically and logically …

Added p. 354

Key Management System A combination of hardware and software that provides an integrated approach for generating, distributing, and/or managing cryptographic keys for devices and applications.

LAN Acronym for “local area network.” LDAP Acronym for “Lightweight Directory Access Protocol.” Least Privileges The minimum level of privileges necessary to perform the roles and responsibilities of the job function.

Logical Access Control Mechanisms that limit the availability of information or information-processing resources only to authorized persons or applications. See Physical Access Control.

MAC In cryptography, an acronym for “message authentication code.” See Strong Cryptography.

Magnetic-Stripe Data See Track Data.

Masking Method of concealing a segment of PAN when displayed or printed. Masking is used when there is no business need to view the entire PAN. Masking relates to protection of PAN when displayed on screens, paper receipts, printouts, etc. See Truncation for protection of PAN when electronically stored, processed, or transmitted.

Media Physical material, including but not limited to, …

Added p. 355

NAC Acronym for “Network Access Control.” NAT Acronym for “Network Address Translation.” Network Connection A logical, physical, or virtual communication path between devices that allows the transmission and reception of network layer packets.

Network Diagram A diagram showing system components and connections within a networked environment.

Network Security Controls (NSC) Firewalls and other network security technologies that act as network policy enforcement points. NSCs typically control network traffic between two or more logical or physical network segments (or subnets) based on pre-defined policies or rules.

NIST Acronym for “National Institute of Standards and Technology.” Non-regulatory federal agency within U.S. Commerce Department's Technology Administration.

Non-Console Access Logical access to a system component that occurs over a network interface rather than via a direct, physical connection to the system component. Non-console access includes access from within local/internal networks as well as access from external or remote networks.

NTP Acronym for “Network Time Protocol.” Organizational Independence An organizational …

Added p. 356

Payment Brand An organization with branded payment cards or other payment card form factors. Payment brands regulate where and how the payment cards or other form factors carrying its brand or logo are used. A payment brand may be a PCI SSC Participating Payment Brand or other global or regional payment brand, scheme, or network.

Payment Card Form Factor Includes physical payment cards as well as devices with functionality that emulates a payment card to initiate a payment transaction. Examples of such devices include, but are not limited to, smartphones, smartwatches, fitness bands, key tags, and wearables such as jewelry.

Payment Cards For purposes of PCI DSS, any payment card form factor that bears the logo of any PCI SSC Participating Payment Brand.

Payment Channel Methods used by merchants to accept payments from customers. Common payment channels include card present (in person) and card not present (e-commerce and MO/TO).

Payment Page A web-based user …

Added p. 357

POI Acronym for “Point of Interaction,” the initial point where data is read from a card.

Point of Sale System (POS) Hardware and software used by merchants to accept payments from customers. May include POI devices, PIN pads, electronic cash registers, etc.

Privileged User Any user account with greater than basic access privileges. Typically, these accounts have elevated or increased privileges with more rights than a standard user account. However, the extent of privileges across different privileged accounts can vary greatly depending on the organization, job function or role, and the technology in use.

QIR Acronym for “Qualified Integrator or Reseller.” Refer to the QIR Program Guide on the PCI SSC website for more information.

QSA Acronym for “Qualified Security Assessor.” QSAs are qualified by PCI SSC to perform PCI DSS on-site assessments. Refer to the QSA Qualification Requirements for details about requirements for QSA Companies and Employees.

Remote Access Access to an entity’s network …

Added p. 358

Security Officer Primary person responsible for an entity’s security.

Segmentation Also referred to as “network segmentation” or “isolation.” Segmentation isolates system components that store, process, or transmit cardholder data from systems that do not. See “Segmentation” in PCI DSS section: 4 Scope of PCI DSS Requirements.

Sensitive Area A sensitive area is typically a subset of the CDE and is any area that houses systems considered critical to the CDE. This includes data centers, server rooms, back-office rooms at retail locations, and any area that concentrates or aggregates cardholder data storage, processing, or transmission. Sensitive areas also include areas housing systems that manage or maintain the security of the CDE (for example, those providing network security controls or that manage physical or logical security). This excludes the areas where only point-of-sale terminals are present, such as the cashier areas in a retail store or call centers where agents are taking payments.

Sensitive Authentication …

Added p. 359

• NIST Special Publication 800-57 Part 1,

• ECRYPT-CSA D5.4 Algorithms, Key Size and Protocols Report (2018), and

• ISO/IEC 18033 Encryption algorithms, and

• ISO/IEC 14888-3:2-81 IT Security techniques

• Digital signatures with appendix

• Part 3: Discrete logarithm based mechanisms.

System Components Any network devices, servers, computing devices, virtual components, or software included in or connected to the CDE, or that could impact the security of the CDE.

System-level object Anything on a system component that is required for its operation, including but not limited to application executables and configuration files, system configuration files, static and shared libraries and DLLs, system executables, device drivers and device configuration files, and third-party components.

Targeted Risk Analysis For PCI DSS purposes, a risk analysis that focuses on a specific PCI DSS requirement(s) of interest, either because the requirement allows flexibility (for example, as to frequency) or, for the Customized Approach, to explain how the entity assessed the risk and …

Added p. 360

Truncation Method of rendering a full PAN unreadable by removing a segment of PAN data. Truncation relates to protection of PAN when electronically stored, processed, or transmitted. See Masking for protection of PAN when displayed on screens, paper receipts, etc.

Trusted Network Network of an entity that is within the entity’s ability to control or manage and that meets applicable PCI DSS requirements.

Untrusted Network Any network that does not meet the definition of a “trusted network.” Virtual Payment Terminal In the context of Self-Assessment Questionnaire (SAQ) C-VT, a virtual payment terminal is web-browser-based access to an acquirer, processor, or third-party service provider website to authorize payment card transactions, where the merchant manually enters payment card data through a web browser. Unlike physical terminals, virtual payment terminals do not read data directly from a payment card. Because payment card transactions are entered manually, virtual payment terminals are typically used instead of physical …

Modified p. 1

Payment Card Industry ~~(PCI)~~ Data Security Standard Requirements and ~~Security Assessment~~ Procedures Version ~~3.2.1 Revision 1~~

Payment Card Industry Data Security Standard Requirements and Testing Procedures Version 4.0

Removed p. 5

1. Install and maintain a firewall configuration to protect cardholder data 2. Do not use vendor-supplied defaults for system passwords and other security parameters Protect Cardholder Data 3. Protect stored cardholder data 4. Encrypt transmission of cardholder data across open, public networks Maintain a Vulnerability Management Program

5. Protect all systems against malware and regularly update anti-virus software or programs 6. Develop and maintain secure systems and applications Implement Strong Access Control Measures

7. Restrict access to cardholder data by business need to know 8. Identify and authenticate access to system components 9. Restrict physical access to cardholder data Regularly Monitor and Test Networks

10. Track and monitor all access to network resources and cardholder data 11. Regularly test security systems and processes Maintain an Information Security Policy 12. Maintain a policy that addresses information security for all personnel This document, PCI Data Security Standard Requirements and Security Assessment Procedures, combines the 12 …

Modified p. 5

PCI Data Security Standard

• High Level Overview Build and Maintain a Secure Network and Systems

PCI Data Security Standard

• High Level Overview Build and Maintain a Secure Network and Systems 1. Install and Maintain Network Security Controls. 2. Apply Secure Configurations to All System Components.

Modified p. 5 → 6

PCI DSS comprises a minimum set of requirements for protecting account ~~data,~~ and may be enhanced by additional controls and practices to further mitigate risks, ~~as well as~~ local, ~~regional~~ and sector laws and regulations. Additionally, legislation or regulatory requirements may require specific protection of personal information or other data elements (for example, cardholder name). ~~PCI DSS does not supersede local or regional laws, government regulations, or other legal requirements.~~

PCI DSS comprises a minimum set of requirements for protecting account data and may be enhanced by additional controls and practices to further mitigate risks, and to incorporate local, regional, and sector laws and regulations. Additionally, legislation or regulatory requirements may require specific protection of personal information or other data elements (for example, cardholder name).

Removed p. 6

• Frequently Asked Questions (FAQs)

• PCI for Small Merchants website

• PCI training courses and informational webinars

• List of Qualified Security Assessors (QSAs) and Approved Scanning Vendors (ASVs)

• List of PTS approved devices and PA-DSS validated payment applications Please refer to www.pcisecuritystandards.org for information about these and other resources.

Modified p. 6

PCI DSS Resources The PCI Security Standards Council (PCI SSC) website (www.pcisecuritystandards.org) ~~contains a number of~~ additional resources to assist organizations with their PCI DSS assessments and ~~validations, including:~~

PCI DSS Resources The PCI Security Standards Council (PCI SSC) website (www.pcisecuritystandards.org) provides the following additional resources to assist organizations with their PCI DSS assessments and validations:

Modified p. 6 → 7

Note: Information Supplements complement ~~the~~ PCI DSS and identify additional considerations and recommendations for meeting PCI DSS ~~requirements•they~~ do not supersede, ~~replace~~ or extend ~~the~~ PCI DSS or any of its requirements.

Note: Information Supplements complement PCI DSS and identify additional considerations and recommendations for meeting PCI DSS requirements. Information Supplements do not supersede, replace, or extend PCI DSS or any of its requirements.

Removed p. 7

PCI DSS applies to all entities involved in payment card processing•including merchants, processors, acquirers, issuers, and service providers. PCI DSS also applies to all other entities that store, process, or transmit cardholder data and/or sensitive authentication data.

• CAV2/CVC2/CVN2/CVV2/CID

• PINs/PIN blocks The primary account number is the defining factor for cardholder data. If cardholder name, service code, and/or expiration date are stored, processed or transmitted with the PAN, or are otherwise present in the cardholder data environment (CDE), they must be protected in accordance with applicable PCI DSS requirements.

PCI DSS requirements apply to organizations where account data (cardholder data and/or sensitive authentication data) is stored, processed or transmitted. Some PCI DSS requirements may also be applicable to organizations that have outsourced their payment operations or management of their CDE.1 Additionally, organizations that outsource their CDE or payment operations to third parties are responsible for ensuring that the account data is protected …

Modified p. 7 → 8

Cardholder data and sensitive authentication data are defined as follows:

Defining Account Data, Cardholder Data, and Sensitive Authentication Data Cardholder data and sensitive authentication data are considered account data and are defined as follows:

Modified p. 7 → 8

Account Data Cardholder Data includes: Sensitive Authentication Data includes:

Table 2. Account Data Account Data Cardholder Data includes: Sensitive Authentication Data includes:

Removed p. 8

Requirement 3.4 Account Data Cardholder Primary Account Number (PAN) Yes Yes Cardholder Name Yes No Service Code Yes No Expiration Date Yes No Sensitive Authentication Full Track Data3 No Cannot store per Requirement 3.2 CAV2/CVC2/CVN2/CVV2/CID4 No Cannot store per Requirement 3.2 PIN/PIN Block5 No Cannot store per Requirement 3.2

PCI DSS Requirements 3.3 and 3.4 apply only to PAN. If PAN is stored with other elements of cardholder data, only the PAN must be rendered unreadable according to PCI DSS Requirement 3.4.

Modified p. 8 → 10

Sensitive authentication data must not be stored after authorization, even if encrypted. This applies even where there is no PAN in the environment. Organizations should contact their acquirer or the individual payment brands directly to understand whether SAD is permitted to be stored prior to authorization, for how long, and any related usage and protection requirements.

Sensitive authentication data must not be stored after authorization, even if encrypted. This applies even for environments where there is no PAN present.

Removed p. 9

All applications that store, process, or transmit cardholder data are in scope for an entity’s PCI DSS assessment, including applications that have been validated to PA-DSS. The PCI DSS assessment should verify the PA-DSS validated payment application is properly configured and securely implemented per PCI DSS requirements. If the payment application has undergone any customization, a more in-depth review will be required during the PCI DSS assessment, as the application may no longer be representative of the version that was validated to PA-DSS.

The PA-DSS requirements are derived from the PCI DSS Requirements and Security Assessment Procedures (defined in this document). The PA-DSS details the requirements a payment application must meet in order to facilitate a customer’s PCI DSS compliance. As security threats are constantly evolving, applications that are no longer supported by the vendor (e.g., identified by the vendor as “end of life”) may not offer the same level of …

Modified p. 9 → 11

~~To determine whether PA-DSS applies to a given payment application, please~~ refer to the ~~PA-DSS~~ Program ~~Guide, which can be found~~ at www.pcisecuritystandards.org.

For more information about the SSF or PA-DSS, refer to the respective Program Guides at www.pcisecuritystandards.org.

Removed p. 10

• Systems that provide security services (for example, authentication servers), facilitate segmentation (for example, internal firewalls), or may impact the security of (for example, name resolution or web redirection servers) the CDE.

• Network components including but not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances.

• Any other component or device located within or connected to the CDE.

The first step of a PCI DSS assessment is to accurately determine the scope of the review. At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of their PCI DSS scope by identifying all locations and flows of cardholder data, and identify all systems that are connected to or, if compromised, could impact the CDE (for example, authentication servers) to ensure they are included in the PCI DSS scope. All types of systems and locations should be considered as part of …

Modified p. 10 → 13

• Virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors.

 Virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors.

Modified p. 10 → 14

• Server ~~types~~ including but not limited to web, application, database, authentication, mail, proxy, Network Time Protocol (NTP), and Domain Name System (DNS).

 Server types, including but not limited to web, application, database, authentication, mail, proxy, Network Time Protocol (NTP), and Domain Name System (DNS).

Modified p. 10 → 14

~~• Applications~~ including all ~~purchased~~ and custom ~~applications,~~ including internal and external (for example, Internet) applications.

 Applications, software, and software components, serverless applications, including all purchased, subscribed (for example, Software- as-a-Service), bespoke and custom software, including internal and external (for example, Internet) applications.

Removed p. 11

• The scope of the PCI DSS assessment

• The cost of the PCI DSS assessment

• The cost and difficulty of implementing and maintaining PCI DSS controls

Documenting cardholder data flows via a dataflow diagram helps fully understand all cardholder data flows and ensures that any network segmentation is effective at isolating the cardholder data environment.

If network segmentation is in place and being used to reduce the scope of the PCI DSS assessment, the assessor must verify that the segmentation is adequate to reduce the scope of the assessment. At a high level, adequate network segmentation isolates systems that store, process, or transmit cardholder data from those that do not. However, the adequacy of a specific implementation of network segmentation is highly variable and dependent upon a number of factors, such as a given network's configuration, the technologies deployed, and other controls that may be implemented.

Appendix D: Segmentation and Sampling of Business …

Modified p. 11 → 16

~~• The risk~~ to an organization (reduced by consolidating ~~cardholder~~ data into fewer, more controlled locations) Without adequate ~~network~~ segmentation (sometimes called a "flat ~~network")~~ the entire network is in scope of the PCI DSS assessment. ~~Network segmentation~~ can be achieved ~~through~~ a number of physical or logical ~~means,~~ such as properly configured internal network ~~firewalls,~~ routers with strong access control lists, or other technologies that restrict access to a particular segment of a network. To be considered out of …

 Scope of the PCI DSS assessment  Cost of the PCI DSS assessment  Cost and difficulty of implementing and maintaining PCI DSS controls  Risk to an organization relative to payment card account data (reduced by consolidating that data into fewer, more controlled locations) Without adequate segmentation (sometimes called a "flat network"), the entire network is in scope for the PCI DSS assessment. Segmentation can be achieved using a number of physical or logical methods, such as properly …

Modified p. 11 → 16

An important prerequisite to reduce the scope of the ~~cardholder data environment~~ is a clear understanding of business needs and processes related to the storage, ~~processing or~~ transmission of ~~cardholder~~ data. Restricting ~~cardholder~~ data to as few locations as possible by ~~elimination of~~ unnecessary ~~data,~~ and ~~consolidation of~~ necessary ~~data,~~ may require reengineering of long-standing business practices.

An important prerequisite to reduce the scope of the CDE is a clear understanding of business needs and processes related to the storage, processing, and transmission of account data. Restricting account data to as few locations as possible by eliminating unnecessary data and consolidating necessary data may require reengineering of long-standing business practices.

Removed p. 12

Parties should clearly identify the services and system components which are included in the scope of the service provider’s PCI DSS assessment, the specific PCI DSS requirements covered by the service provider, and any requirements which are the responsibility of the service provider’s customers to include in their own PCI DSS reviews. For example, a managed hosting provider should clearly define which of their IP addresses are scanned as part of their quarterly vulnerability scan process and which IP addresses are their customer’s responsibility to include in their own quarterly scans.

Service providers are responsible for demonstrating their PCI DSS compliance, and may be required to do so by the payment brands. Service providers should contact their acquirer and/or payment brand to determine the appropriate compliance validation.

There are two options for third-party service providers to validate compliance:

1) Annual assessment: Service providers can undergo an annual PCI DSS assessment(s) on their own …

Removed p. 13

1. Monitoring of security controls•such as firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), file-integrity monitoring (FIM), anti-virus, access controls, etc.•to ensure they are operating effectively and as intended.

4. Changes to organizational structure (for example, a company merger or acquisition) resulting in formal review of the impact to PCI DSS scope and requirements.

5. Performing periodic reviews and communications to confirm that PCI DSS requirements continue to be in place and personnel are following secure processes. These periodic reviews should cover all facilities and locations, including retail outlets, data centers, etc., and include reviewing system components (or samples of system components), to verify that PCI DSS requirements continue to be in place•for example, configuration standards have been applied, patches and AV are up to date, audit logs are being reviewed, and so on. The frequency of periodic reviews should be determined by the entity as appropriate for the size and complexity of their environment.

•to …

Modified p. 13 → 23

2. Ensuring that all failures in security controls are detected and responded to ~~in a timely manner.~~ Processes to respond to security control failures should include:

 Ensuring that all failures in security controls are detected and responded to promptly. Processes to respond to security control failures should include:

Modified p. 13 → 23

• Restoring the security ~~control~~

• Restoring the security control.

Modified p. 13 → 23

• Identifying the cause of ~~failure~~

• Identifying the cause of failure.

Modified p. 13 → 23

• Identifying and addressing any security issues that arose during the failure of the security ~~control~~

• Identifying and addressing any security issues that arose during the failure of the security control.

Modified p. 13 → 23

• Implementing ~~mitigation (such~~ as process or technical ~~controls)~~ to prevent the cause of the failure ~~recurring~~

• Implementing mitigation, such as process or technical controls, to prevent the cause of the failure from recurring.

Modified p. 13 → 23

• Resuming monitoring of the security control, perhaps with enhanced monitoring for a period of time, to verify the control is operating ~~effectively~~

• Resuming monitoring of the security control, perhaps with enhanced monitoring for a period of time, to verify the control is operating effectively.

Modified p. 13 → 23

3. Reviewing changes to the environment (for example, addition of new systems, changes in system or network configurations) prior to ~~completion of~~ the change, and ~~perform~~ the following:

 Reviewing changes that could introduce security risks to the environment (for example, addition of new systems, changes in system or network configurations) prior to completing the change, and including the following:

Modified p. 13 → 24

• ~~Determine~~ the potential impact to PCI DSS scope (for example, a new ~~firewall~~ rule that permits connectivity between a system in the CDE and another system could bring additional systems or networks into scope for PCI DSS).

• Perform a risk assessment to determine the potential impact to PCI DSS scope (for example, a new network security control rule that permits connectivity between a system in the CDE and another system could bring additional systems or networks into scope for PCI DSS).

Modified p. 13 → 24

• Identify PCI DSS requirements applicable to systems and networks affected by the changes (for example, if a new system is in scope for PCI DSS, it would need to be configured per system configuration standards, including ~~FIM, AV,~~ patches, audit ~~logging, etc.,~~ and would need to be added to the quarterly vulnerability scan schedule).

• Identify PCI DSS requirements applicable to systems and networks affected by the changes (for example, if a new system is in scope for PCI DSS, it would need to be configured per system configuration standards, including change-detection mechanisms, anti-malware software, patches, and audit logging. These new systems and networks would need to be added to the inventory of in- scope system components and to the quarterly vulnerability scan schedule).

Modified p. 13 → 24

These reviews can also be used to verify that ~~appropriate~~ evidence is being maintained

•for example, audit logs, vulnerability scan reports, ~~firewall reviews, etc.~~

These reviews can also be used to verify that required evidence for a PCI DSS assessment is being maintained. For example, evidence of audit logs, vulnerability scan reports, and reviews of network security control rulesets are necessary to assist the entity in preparing for its next PCI DSS assessment.

Removed p. 14

In addition to the above practices, organizations may also wish to consider implementing separation of duties for their security functions so that security and/or audit functions are separated from operational functions. In environments where one individual performs multiple roles (for example, administration and security operations), duties may be assigned such 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.

Note: For some entities, these best practices are also requirements to ensure ongoing PCI DSS compliance.

For example, PCI DSS includes these principles in some requirements, and the Designated Entities Supplemental Validation (PCI DSS Appendix A3) requires designated entities to validate to these principles.

Modified p. 14 → 24

6. Reviewing hardware and software technologies at least ~~annually~~ to confirm that they continue to be supported by the vendor and can meet the entity’s security requirements, including PCI DSS. If ~~it is discovered that~~ technologies are no longer supported by the vendor or cannot meet the entity’s security needs, the entity should prepare a remediation plan, ~~up to and~~ including replacement of the technology, as necessary.

 Reviewing hardware and software technologies at least once every 12 months to confirm that they continue to be supported by the vendor and can meet the entity’s security requirements, including PCI DSS. If technologies are no longer supported by the vendor or cannot meet the entity’s security needs, the entity should prepare a remediation plan, including replacement of the technology, as necessary.

Modified p. 14 → 25

~~All organizations~~ should consider implementing these best practices into their environment, even ~~where~~ the ~~organization~~ is not required to validate to ~~them.~~

Each entity should consider implementing these best practices into their environment, even if the entity is not required to validate to them (for example, merchants undergoing self-assessment).

Removed p. 15

After considering the overall scope and complexity of the environment being assessed, the assessor may independently select representative samples of business facilities/system components in order to assess the entity’s compliance with PCI DSS requirements. These samples must be defined first for business facilities and then for system components within each selected business facility. Samples must be a representative selection of all of the types and locations of business facilities, as well as all of the types of system components within selected business facilities. Samples must be sufficiently large to provide the assessor with assurance that controls are implemented as expected.

Examples of business facilities include but are not limited to: corporate offices, stores, franchise locations, processing facilities, data centers, and other facility types in different locations. Sampling should include system components within each selected business facility. For example, for each business facility selected, include a variety of operating systems, functions, and …

Modified p. 15 → 26

While it is acceptable for an assessor to sample ~~business facilities/system components~~ as part of ~~their~~ review of an entity’s PCI DSS compliance, it is not acceptable for an entity to apply PCI DSS requirements to only a sample of ~~their~~ environment (for example, requirements for quarterly vulnerability scans apply to all system components). Similarly, it is not acceptable for an assessor to only ~~review~~ a sample of PCI DSS requirements for compliance.

While it is acceptable for an assessor to sample from similar items in a population being tested as part of its review of an entity’s PCI DSS compliance, it is not acceptable for an entity to apply PCI DSS requirements to only a sample of its environment (for example, requirements for quarterly vulnerability scans apply to all system components). Similarly, it is not acceptable for an assessor to review only a sample of PCI DSS requirements for compliance.

Removed p. 16

Assessors must revalidate the sampling rationale for each assessment. If sampling is to be used, different samples of business facilities and system components must be selected for each assessment.

Compensating Controls On an annual basis, any compensating controls must be documented, reviewed and validated by the assessor and included with the Report on Compliance submission, per Appendix B: Compensating Controls and Appendix C: Compensating Controls Worksheet.

For each and every compensating control, the Compensating Controls Worksheet (Appendix C) must be completed. Additionally, compensating control results should be documented in the ROC in the corresponding PCI DSS requirement section.

See the above-mentioned Appendices B and C for more details on “compensating controls.” Please also refer to: Appendix D: Segmentation and Sampling of Business Facilities/System Components.

Modified p. 16 → 27

• Samples of system components must include every type and combination ~~that is in use.~~ For example, where applications are sampled, the sample must include all versions and platforms for each type of application.

 Samples of system components must include every type and combination being used. When an entity has more than one CDE, samples must include populations across all in-scope system components. For example, where applications are sampled, the sample must include all versions and platforms for each type of application.

Modified p. 16 → 27

• Document the rationale behind the sampling technique and sample ~~size,~~

 Document the rationale behind the sampling technique and sample size.

Modified p. 16 → 27

~~• Document~~ and ~~validate~~ the standardized ~~PCI DSS~~ processes and controls used to determine sample ~~size, and~~

 Validate and document the standardized processes and controls used to determine sample size.

Modified p. 16 → 27

• Explain how the sample is appropriate and representative of the overall population.

 Explain how the sample is appropriate and representative of the overall population.

Removed p. 17

The PCI DSS ROC Reporting Template must be used as the template for creating the Report on Compliance. The assessed entity should follow each payment brand’s respective reporting requirements to ensure each payment brand acknowledges the entity’s compliance status. Contact each payment brand or the acquirer to determine reporting requirements and instructions.

PCI DSS Assessment Process The PCI DSS assessment process includes completion of the following steps:

Modified p. 17 → 38

2. Perform the PCI DSS assessment of the ~~environment, following the testing procedures for each requirement.~~

2. Perform the PCI DSS assessment of the environment.

Modified p. 17 → 38

3. Complete the applicable report for the assessment ~~(i.e., Self-Assessment Questionnaire (SAQ) or Report on Compliance (ROC)), including documentation of all compensating controls,~~ according to ~~the applicable~~ PCI guidance and instructions.

3. Complete the applicable report for the assessment according to PCI DSS guidance and instructions.

Modified p. 17 → 38

4. Complete the Attestation of Compliance for Service Providers or Merchants, as applicable, in its entirety. Attestations of Compliance are available on the PCI SSC website.

4. Complete the Attestation of Compliance for Service Providers or Merchants, as applicable, in its entirety. Official Attestations of Compliance are only available on the PCI SSC website.

Modified p. 17 → 38

5. Submit the ~~SAQ or ROC,~~ and the Attestation of Compliance, along with any other requested documentation

•such as ASV scan reports to the ~~acquirer~~ (for ~~merchants) or to the payment brand~~ or other ~~requester~~ (for service ~~providers).~~

5. Submit the applicable PCI SSC documentation and the Attestation of Compliance, along with any other requested documentation

•such as ASV scan reports •to the requesting organization (those that manage compliance programs such as payment brands and acquirers (for merchants), or other requesters (for service providers)).

Modified p. 17 → 38

6. If required, perform remediation to address requirements that are not in ~~place,~~ and provide an updated report.

6. If required, perform remediation to address requirements that are not in place and provide an updated report.

Removed p. 18

PCI DSS Versions As of the published date of this document, PCI DSS v3.2 is valid through December 31, 2018, after which it is retired. All PCI DSS validations after this date must be to PCI DSS v3.2.1 or later.

Modified p. 18 → 40

~~The following table provides a summary of~~ PCI DSS versions and their relevant ~~dates.6 Version Published Retired~~

Table 6 summarizes PCI DSS versions and their relevant dates. 6

Removed p. 19

• PCI DSS Requirements

• This column defines the Data Security Standard requirements; PCI DSS compliance is validated against these requirements.

• This column shows processes to be followed by the assessor to validate that PCI DSS requirements have been met and are “in place.”

• This column describes the intent or security objective behind each of the PCI DSS requirements. This column contains guidance only, and is intended to assist understanding of the intent of each requirement. The guidance in this column does not replace or extend the PCI DSS Requirements and Testing Procedures.

Please refer to the following resources (available on the PCI SSC website) to document the PCI DSS assessment:

Modified p. 19 → 38

Note: PCI DSS requirements are not considered to be in place if controls are not yet implemented or are scheduled to be completed at a future date. After any open or not-in-place items are addressed by the entity, the assessor will ~~then~~ reassess to validate that the remediation is completed and that all requirements are satisfied.

Note: PCI DSS requirements are not considered to be in place if controls are not yet implemented or are scheduled to be completed at a future date. After any open or not-in-place items are addressed by the entity, the assessor will reassess to validate that the remediation is completed and that all requirements are satisfied. Refer to the following resources (available on the PCI SSC website) to document the PCI DSS assessment:

Modified p. 19 → 38

• For instructions on completing reports on compliance (ROC), refer to the PCI DSS ~~ROC Reporting~~ Template.

• For instructions about completing reports on compliance (ROC), refer to the PCI DSS Report on Compliance (ROC) Template.

Modified p. 19 → 38

• For instructions on completing self-assessment questionnaires (SAQ), refer to the PCI DSS SAQ Instructions and Guidelines.

• For instructions about completing self-assessment questionnaires (SAQ), refer to the PCI DSS SAQ Instructions and Guidelines.

Modified p. 19 → 38

• For instructions on submitting PCI DSS compliance validation reports, refer to the PCI DSS ~~Attestations~~ of Compliance.

• For instructions about submitting PCI DSS compliance validation reports, refer to the PCI DSS Attestation of Compliance.

Removed p. 20

Requirement 1: Install and maintain a firewall configuration to protect cardholder data Firewalls are devices that control computer traffic allowed between an entity’s networks (internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas within an entity’s internal trusted networks. The cardholder data environment is an example of a more sensitive area within an entity’s trusted network.

A firewall examines all network traffic and blocks those transmissions that do not meet the specified security criteria.

All systems must be protected from unauthorized access from untrusted networks, whether entering the system via the Internet as e-commerce, employee Internet access through desktop browsers, employee e-mail access, dedicated connections such as business-to-business connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.

Other system components may …

Removed p. 20

Firewalls and routers are key components of the architecture that controls entry to and exit from the network. These devices are software or hardware devices that block unwanted access and manage authorized access into and out of the network.

Configuration standards and procedures will help to ensure that the organization’s first line of defense in the protection of its data remains strong.

Removed p. 20

• Network connections and

• Changes to firewall and router configurations A documented and implemented process for approving and testing all connections and changes to the firewalls and routers will help prevent security problems caused by misconfiguration of the network, router, or firewall.

Without formal approval and testing of changes, records of the changes might not be updated, which could lead to inconsistencies between network documentation and the actual configuration.

1.1.1.b For a sample of network connections, interview responsible personnel and examine records to verify that network connections were approved and tested.

Removed p. 21

PCI DSS Requirements Testing Procedures Guidance 1.1.1.c Identify a sample of actual changes made to firewall and router configurations, compare to the change records, and interview responsible personnel to verify the changes were approved and tested.

Removed p. 21

Network diagrams describe how networks are configured, and identify the location of all network devices.

Without current network diagrams, devices could be overlooked and be unknowingly left out of the security controls implemented for PCI DSS and thus be vulnerable to compromise.

1.1.2.b Interview responsible personnel to verify that the diagram is kept current.

Removed p. 21

• Shows all cardholder data flows across systems and networks.

• Is kept current and updated as needed upon changes to the environment.

Cardholder data-flow diagrams identify the location of all cardholder data that is stored, processed, or transmitted within the network.

Network and cardholder data-flow diagrams help an organization to understand and keep track of the scope of their environment, by showing how cardholder data flows across networks and between individual systems and devices.

Removed p. 21

Using a firewall on every Internet connection coming into (and out of) the network, and between any DMZ and the internal network, allows the organization to monitor and control access and minimizes the chances of a malicious individual obtaining access to the internal network via an unprotected connection.

1.1.4.b Verify that the current network diagram is consistent with the firewall configuration standards.

1.1.4.c Observe network configurations to verify that a firewall is in place at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone, per the documented configuration standards and network diagrams.

Removed p. 22

PCI DSS Requirements Testing Procedures Guidance 1.1.5 Description of groups, roles, and responsibilities for management of network components 1.1.5.a Verify that firewall and router configuration standards include a description of groups, roles, and responsibilities for management of network components.

This description of roles and assignment of responsibilities ensures that personnel are aware of who is responsible for the security of all network components, and that those assigned to manage components are aware of their responsibilities. If roles and responsibilities are not formally assigned, devices could be left unmanaged.

1.1.5.b Interview personnel responsible for management of network components to confirm that roles and responsibilities are assigned as documented.

Removed p. 22

1.1.6.a Verify that firewall and router configuration standards include a documented list of all services, protocols and ports, including business justification and approval for each.

Compromises often happen due to unused or insecure service and ports, since these often have known vulnerabilities and many organizations don’t patch vulnerabilities for the services, protocols, and ports they don't use (even though the vulnerabilities are still present). By clearly defining and documenting the services, protocols, and ports that are necessary for business, organizations can ensure that all other services, protocols, and ports are disabled or removed.

Approvals should be granted by personnel independent of the personnel managing the configuration.

If insecure services, protocols, or ports are necessary for business, the risk posed by use of these protocols should be clearly understood and accepted by the organization, the use of the protocol should be justified, and the security features that allow these protocols to be used securely …

Removed p. 23

Note: An “untrusted network” is any network that is external to the networks belonging to the entity under review, and/or which is out of the entity's ability to control or manage.

Removed p. 23

It is essential to install network protection between the internal, trusted network and any untrusted network that is external and/or out of the entity’s ability to control or manage. Failure to implement this measure correctly results in the entity being vulnerable to unauthorized access by malicious individuals or software.

For firewall functionality to be effective, it must be properly configured to control and/or limit traffic into and out of the entity’s network.

Removed p. 23

1.2.1.a Examine firewall and router configuration standards to verify that they identify inbound and outbound traffic necessary for the cardholder data environment.

Examination of all inbound and outbound connections allows for inspection and restriction of traffic based on the source and/or destination address, thus preventing unfiltered access between untrusted and trusted environments. This prevents malicious individuals from accessing the entity’s network via unauthorized IP addresses or from using services, protocols, or ports in an unauthorized manner (for example, to send data they've obtained from within the entity’s network out to an untrusted server).

Implementing a rule that denies all inbound and outbound traffic that is not specifically needed helps to prevent inadvertent holes that would allow unintended and potentially harmful traffic in or out.

1.2.1.b Examine firewall and router configurations to verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment.

1.2.1.c Examine firewall and router …

Removed p. 24

1.2.3.a Examine firewall and router configurations to verify that there are perimeter firewalls installed between all wireless networks and the cardholder data environment.

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 cardholder 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 firewalls 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.

Firewalls must be installed between all wireless networks and the CDE, regardless of the purpose of the environment to which the wireless network is connected. This may include, but is not limited to, corporate networks, retail stores, guest networks, warehouse environments, etc.

1.2.3.b Verify that the firewalls …

Removed p. 25

While there may be legitimate reasons for untrusted connections to be permitted to DMZ systems (e.g., to allow public access to a web server), such connections should never be granted to systems in the internal network. A firewall's intent is to manage and control all connections between public systems and internal systems, especially those that store, process or transmit cardholder data. If direct access is allowed between public systems and the CDE, the protections offered by the firewall are bypassed, and system components storing cardholder data may be exposed to compromise.

Removed p. 25

The DMZ is that part of the network that manages connections between the Internet (or other untrusted networks), and services that an organization needs to have available to the public (like a web server).

This functionality is intended to prevent malicious individuals from accessing the organization's internal network from the Internet, or from using services, protocols, or ports in an unauthorized manner.

Removed p. 25

(For example, block traffic originating from the Internet with an internal source address.) 1.3.3 Examine firewall and router configurations to verify that anti-spoofing measures are implemented, for example internal addresses cannot pass from the Internet into the DMZ.

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

Filtering packets coming into the network helps to, among other things, ensure packets are not “spoofed” to look like they are coming from an organization’s own internal network.

PCI DSS Requirements Testing Procedures Guidance 1.3.4 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.

Removed p. 26

All traffic outbound from the cardholder data environment should be evaluated to ensure that it follows established, authorized rules. Connections should be inspected to restrict traffic to only authorized communications (for example by restricting source/destination addresses/ports, and/or blocking of content).

Removed p. 26

A firewall that maintains the "state" (or the status) for each connection through the firewall knows whether an apparent response to a previous connection is actually a valid, authorized response (since it retains each connection’s status) or is malicious traffic trying to trick the firewall into allowing the connection.

Removed p. 26

If cardholder data is located within the DMZ, it is easier for an external attacker to access this information, since there are fewer layers to penetrate. Securing system components that store cardholder data in an internal network zone that is segregated from the DMZ and other untrusted networks by a firewall can prevent unauthorized network traffic from reaching the system component.

Note: This requirement is not intended to apply to temporary storage of cardholder data in volatile memory.

PCI DSS Requirements Testing Procedures Guidance 1.3.7 Do not disclose private IP addresses and routing information to unauthorized parties.

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

• Network Address Translation (NAT)

• Placing servers containing cardholder data behind proxy servers/firewalls,

• Removal or filtering of route advertisements for private networks that employ registered addressing,

• Internal use of RFC1918 address space instead of registered addresses.

1.3.7.a Examine firewall and router configurations to verify that …

Removed p. 28

Personnel need to be aware of and following security policies and operational procedures to ensure firewalls and routers are continuously managed to prevent unauthorized access to the network.

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters Malicious individuals (external and internal to an entity) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily determined via public information.

PCI DSS Requirements Testing Procedures Guidance 2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.

This applies to ALL default 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, Simple Network Management Protocol (SNMP) community strings, etc.).

2.1.a Choose a sample of system components, and attempt to log …

Removed p. 31

PCI DSS Requirements Testing Procedures Guidance 2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.

Sources of industry-accepted system hardening standards may include, but are not limited to:

• Center for Internet Security (CIS)

• International Organization for Standardization (ISO)

• SysAdmin Audit Network Security (SANS) Institute

• National Institute of Standards Technology (NIST).

There are known weaknesses with many operating systems, databases, and enterprise applications, and there are also known ways to configure these systems to fix security vulnerabilities. To help those that are not security experts, a number of security organizations have established system-hardening guidelines and recommendations, which advise how to correct these weaknesses.

Examples of sources for guidance on configuration standards include, but are not limited to: www.nist.gov, www.sans.org, and www.cisecurity.org, www.iso.org, and product vendors.

System configuration standards must be kept up to date to ensure that newly identified …

Modified p. 31 → 47

~~2.2.a~~ Examine the ~~organization’s system~~ configuration standards for ~~all types of system components and~~ verify the ~~system configuration~~ standards are ~~consistent~~ with ~~industry- accepted hardening standards.~~

1.2.1.a Examine the configuration standards for NSC rulesets to verify the standards are in accordance with all elements specified in this requirement.

Removed p. 32

PCI DSS Requirements Testing Procedures Guidance 2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)

Note: Where virtualization technologies are in use, implement only one primary function per virtual system component.

2.2.1.a Select a sample of system components and inspect the system configurations to verify that only one primary function is implemented per server.

If server functions that need different security levels are located on the same server, the security level of the functions with higher security needs would be reduced due to the presence of the lower-security functions. Additionally, the server functions with a lower security level may introduce security weaknesses to other functions on the same server. By considering the security needs of different server functions as part of the system configuration standards and …

Removed p. 32

2.2.2.a Select a sample of system components and inspect enabled system services, daemons, and protocols to verify that only necessary services or protocols are enabled.

As stated in Requirement 1.1.6, there are many protocols that a business may need (or have enabled by default) that are commonly used by malicious individuals to compromise a network. Including this requirement as part of an organization's configuration standards and related processes ensures that only the necessary services and protocols are enabled.

2.2.2.b Identify any enabled insecure services, daemons, or protocols and interview personnel to verify they are justified per documented configuration standards.

Enabling security features before new servers are deployed will prevent servers being installed into the environment with insecure configurations.

Ensuring that all insecure services, protocols, and daemons are adequately secured with appropriate security features makes it more difficult for malicious individuals to take advantage of commonly used points of compromise within a network.

Refer to industry …

Removed p. 33

PCI DSS Requirements Testing Procedures Guidance 2.2.4 Configure system security parameters to prevent misuse.

2.2.4.a Interview system administrators and/or security managers to verify that they have knowledge of common security parameter settings for system components.

In order for systems to be configured securely, personnel responsible for configuration and/or administering systems must be knowledgeable in the specific security parameters and settings that apply to the system.

2.2.4.b Examine the system configuration standards to verify that common security parameter settings are included.

2.2.4.c Select a sample of system components and inspect the common security parameters to verify that they are set appropriately and in accordance with the configuration standards.

Removed p. 33

2.2.5.a Select a sample of system components and inspect the configurations to verify that all unnecessary functionality (for example, scripts, drivers, features, subsystems, file systems, etc.) is removed.

Unnecessary functions can provide additional opportunities for malicious individuals to gain access to a system. By removing unnecessary functionality, organizations can focus on securing the functions that are required and reduce the risk that unknown functions will be exploited.

Including this in server-hardening standards and processes addresses the specific security implications associated with unnecessary functions (for example, by removing/disabling FTP or the web server if the server will not be performing those functions).

2.2.5.b. Examine the documentation and security parameters to verify enabled functions are documented and support secure configuration.

2.2.5.c. Examine the documentation and security parameters to verify that only documented functionality is present on the sampled system components.

Removed p. 33

If non-console (including remote) administration does not use secure authentication and encrypted communications, sensitive administrative or operational level information (like administrator’s 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.

Clear-text protocols (such as HTTP, telnet, etc.) do not encrypt traffic or logon details, making it easy for an eavesdropper to intercept this information.

(Continued on next page) 2.3.a Observe an administrator log on to each system and examine system configurations to verify that a strong encryption method is invoked before the administrator’s password is requested.

2.3.b Review services and parameter files on systems to determine that Telnet and other insecure remote-login commands are not available for non-console access.

PCI DSS Requirements Testing Procedures Guidance 2.3.c Observe an administrator log on to each system to verify that administrator access to any web-based management interfaces is encrypted with strong …

Removed p. 34

2.4.a Examine system inventory to verify that a list of hardware and software components is maintained and includes a description of function/use for each.

Maintaining a current list of all system components will enable an organization to accurately and efficiently define the scope of their environment for implementing PCI DSS controls. Without an inventory, some system components could be forgotten, and be inadvertently excluded from the organization’s configuration standards.

2.4.b Interview personnel to verify the documented inventory is kept current.

PCI DSS Requirements Testing Procedures Guidance 2.5 Ensure that security policies and operational procedures for managing vendor defaults and other security parameters are documented, in use, and known to all affected parties.

Personnel need to be aware of and following security policies and daily operational procedures to ensure vendor defaults and other security parameters are continuously managed to prevent insecure configurations.

Removed p. 35

This is intended for hosting providers that provide shared hosting environments for multiple clients on the same server. When all data is on the same server and under control of a single environment, often the settings on these shared servers are not manageable by individual clients. This allows clients to add insecure functions and scripts that impact the security of all other client environments; and thereby make it easy for a malicious individual to compromise one client's data and thereby gain access to all other clients' data. See Appendix A1 for details of requirements.

Removed p. 36

PCI DSS Requirements Testing Procedures Guidance 3.1 Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes that include at least the following for all cardholder data (CHD) storage:

• Limiting data storage amount and retention time to that which is required for legal, regulatory, and/or business requirements.

• Specific requirements for retention of cardholder data (for example, cardholder data needs to be held for X period for Y business reasons).

• A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements.

A formal data retention policy identifies what data needs to be retained, and where that data resides so it can be securely destroyed or deleted as soon as it is no longer needed.

The only cardholder data that may be stored after authorization is the primary account number or PAN (rendered unreadable), expiration date, cardholder name, and service code.

Understanding where …

Modified p. 36 → 77

~~Requirement 3: Protect stored cardholder data~~ Protection methods such as encryption, truncation, masking, and hashing are critical components of ~~cardholder~~ data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic ~~keys, the data~~ is ~~unreadable and~~ unusable to that ~~person.~~ Other effective methods of protecting stored data should also be considered as potential ~~risk mitigation~~ opportunities. For example, methods for minimizing risk include not storing ~~cardholder~~ data unless ~~absolutely~~ necessary, truncating …

Protection methods such as encryption, truncation, masking, and hashing are critical components of account data protection. If an intruder circumvents other security controls and gains access to encrypted account data, the data is unreadable without the proper cryptographic keys and is unusable to that intruder. Other effective methods of protecting stored data should also be considered as potential risk-mitigation opportunities. For example, methods for minimizing risk include not storing account data unless necessary, truncating cardholder data if full PAN is …

Modified p. 36 → 77

~~Please refer~~ to ~~the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms~~ for definitions of “strong cryptography” and other PCI DSS terms.

Refer to Appendix G for definitions of “strong cryptography” and other PCI DSS terms.

Modified p. 36 → 80

• Limiting data storage amount and retention time to that which is required for ~~legal,~~ regulatory, and/or business requirements

• Specific retention requirements for cardholder data

• Processes for secure deletion of data when no longer needed

• A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention.

• Limiting data storage amount and retention time to that which is required for legal or regulatory, and/or business requirements.

Modified p. 36 → 80

~~3.1.a~~ Examine the data retention and disposal policies, ~~procedures~~ and processes to verify ~~they~~ include ~~the following for~~ all ~~cardholder data (CHD) storage:~~

3.2.1.a Examine the data retention and disposal policies, procedures, and processes and interview personnel to verify processes are defined to include all elements specified in this requirement.

Modified p. 36 → 80

• Processes for secure deletion ~~of cardholder~~ data when no longer needed ~~for legal, regulatory, or business reasons.~~

• Processes for secure deletion or rendering account data unrecoverable when no longer needed per the retention policy.

Removed p. 37

PCI DSS Requirements Testing Procedures Guidance 3.1.c For a sample of system components that store cardholder data:

Identifying and deleting stored data that has exceeded its specified retention period prevents unnecessary retention of data that is no longer needed. This process may be automated or manual or a combination of both. For example, a programmatic procedure (automatic or manual) to locate and remove data and/or a manual review of data storage areas could be performed.

Implementing secure deletion methods ensure that the data cannot be retrieved when it is no longer needed.

It is permissible for issuers and companies that support issuing services to store sensitive authentication data if:

• The data is stored securely.

Sensitive authentication data includes the data as cited in the following Requirements 3.2.1 through 3.2.3:

3.2.a For issuers and/or companies that support issuing services and store sensitive authentication data, review policies and interview personnel to verify there is a documented business …

Modified p. 37 → 72

• ~~There~~ is ~~a business justification and~~

• Business justification is documented.

Modified p. 37 → 80

• Examine files and system records to verify that the data ~~stored~~ does not exceed the requirements defined in the data retention policy

• Observe the deletion mechanism to verify data is deleted securely.

3.2.1.b Examine files and system records on system components where account data is stored to verify that the data storage amount and retention time does not exceed the requirements defined in the data retention policy.

Modified p. 37 → 82

~~3.2.c For all other entities, if sensitive authentication data~~ is received, ~~review policies and~~ procedures, and ~~examine~~ system configurations to verify the data is not retained after authorization.

3.3.1.a If SAD is received, examine documented policies, procedures, and system configurations to verify the data is not retained after authorization.

Modified p. 37 → 87

~~(Continued on next page) 3.2.b For~~ issuers ~~and/or~~ companies that support issuing services and store sensitive authentication ~~data, examine~~ data stores and system configurations to verify that the sensitive authentication data is ~~secured.~~

3.3.3.b Additional testing procedure for issuers and companies that support issuing services and store sensitive authentication data: Examine data stores and system configurations to verify that the sensitive authentication data is stored securely.

Removed p. 38

PCI DSS Requirements Testing Procedures Guidance 3.2.d For all other entities, if sensitive authentication data is received, review procedures and examine the processes for securely deleting the data to verify that the data is unrecoverable.

For non-issuing entities, retaining sensitive authentication data post-authorization is not permitted.

Removed p. 38

• The cardholder’s name

Removed p. 38

If full track data is stored, malicious individuals who obtain that data can use it to reproduce payment cards and complete fraudulent transactions.

Removed p. 38

The purpose of the card validation code is to protect "card-not-present" transactions

•Internet or mail order/telephone order (MO/TO) transactions

•where the consumer and the card are not present.

If this data is stolen, malicious individuals can execute fraudulent Internet and MO/TO transactions.

Modified p. 38 → 83

~~Note:~~ In the normal course of business, the following data elements from the ~~magnetic stripe~~ may need to be retained:

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

Modified p. 38 → 83

• Primary account number ~~(PAN)~~

• Primary account number (PAN).

Modified p. 38 → 83

• Service ~~code~~ To minimize risk, store only these data elements as needed for business.

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

Removed p. 39

These values should be known only to the card owner or bank that issued the card. If this data is stolen, malicious individuals can execute fraudulent PIN-based debit transactions (for example, ATM withdrawals).

Note: This requirement does not supersede stricter requirements in place for displays of cardholder data•for example, legal or payment card brand requirements for point- of-sale (POS) receipts.

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

The masking approach should always ensure that only the minimum number of digits is displayed as necessary to perform a specific business function. For example, if only the last four digits are …

Modified p. 39 → 89

~~3.3.a~~ Examine ~~written~~ policies and procedures for masking the display of PANs to verify:

3.4.1.a Examine documented policies and procedures for masking the display of PANs to verify:

Modified p. 39 → 89

• A list of roles that need access to ~~displays of~~ more than the ~~first six/last~~ four (includes full PAN) is documented, together with a legitimate business need for each role to have such access.

• A list of roles that need access to more than the BIN and last four digits of the PAN (includes full PAN) is documented, together with a legitimate business need for each role to have such access.

Modified p. 39 → 89

• PAN ~~must be~~ masked when displayed such that only personnel with a legitimate business need can see more than the ~~first six/last~~ four digits of the PAN.

• PAN is masked when displayed such that only personnel with a legitimate business need can see more than the BIN and last four digits of the PAN.

Modified p. 39 → 89

~~3.3.c~~ Examine displays of PAN (for example, on screen, on paper receipts) to verify that PANs are masked when ~~displaying cardholder data,~~ and that only those with a legitimate business need are able to see more than the ~~first six/last~~ four digits of the PAN.

3.4.1.c Examine displays of PAN (for example, on screen, on paper receipts) to verify that PANs are masked when displayed, and that only those with a legitimate business need are able to see more than the BIN and/or last four digits of the PAN.

Removed p. 40

PCI DSS Requirements Testing Procedures Guidance 3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:

• One-way hashes based on strong cryptography, (hash must be of the entire PAN)

• Truncation (hashing cannot be used to replace the truncated segment of PAN)

• Index tokens and pads (pads must be securely stored)

• Strong cryptography with associated key-management processes and procedures.

Note: 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. Where hashed and truncated versions of the same PAN are present in an entity’s environment, additional controls must be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.

• Index tokens and pads, with the pads being securely stored

One-way hash …

Modified p. 40 → 91

~~3.4.a~~ Examine documentation about the system used to ~~protect the PAN,~~ including the vendor, type of system/process, and the encryption algorithms (if applicable) to verify that the PAN is rendered unreadable using any of the ~~following methods:~~

3.5.1.a Examine documentation about the system used to render PAN unreadable, including the vendor, type of system/process, and the encryption algorithms (if applicable) to verify that the PAN is rendered unreadable using any of the methods specified in this requirement.

Modified p. 40 → 91

• One-way hashes based on strong ~~cryptography,~~

• One-way hashes based on strong cryptography of the entire PAN.

Modified p. 40 → 91

• Strong ~~cryptography,~~ with associated ~~key-management~~ processes and procedures.

• Strong cryptography with associated key- management processes and procedures.

Modified p. 40 → 91

~~3.4.e~~ If hashed and truncated versions of the same PAN are present in the environment, examine implemented controls to verify that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.

3.5.1.c If hashed and truncated versions of the same PAN are present in the environment, examine implemented controls to verify that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.

Modified p. 40 → 92

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 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.

Modified p. 40 → 92

~~3.4.b~~ Examine ~~several tables or files from a sample of~~ data repositories to verify the PAN is rendered ~~unreadable (that is, not stored in plain-text).~~

3.5.1.1.c Examine data repositories to verify the PAN is rendered unreadable.

Modified p. 40 → 92

~~3.4.d~~ Examine ~~a sample of~~ audit logs, including payment application logs, to ~~confirm that~~ PAN is rendered ~~unreadable or is not present in the logs.~~

3.5.1.1.d Examine audit logs, including payment application logs, to verify the PAN is rendered unreadable.

Removed p. 41

PCI DSS Requirements Testing Procedures Guidance 3.4.1 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed separately and independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials). Decryption keys must not be associated with user accounts.

3.4.1.a If disk encryption is used, inspect the configuration and observe the authentication process to verify that logical access to encrypted file systems is implemented via a mechanism that is separate from the native operating system’s authentication mechanism (for example, not using local user account databases or general network login credentials).

The intent of this requirement is to address the acceptability of disk-level encryption for rendering cardholder data unreadable. Disk-level encryption encrypts the entire disk/partition on a computer and automatically decrypts the information when an authorized user requests it. Many disk- encryption solutions …

Removed p. 41

Cryptographic keys must be strongly protected because those who obtain access will be able to decrypt data. Key-encrypting keys, if used, must be at least as strong as the data-encrypting key in order to ensure proper protection of the key that encrypts the data as well as the data encrypted with that key.

Modified p. 41 → 95

~~Note: This requirement applies in addition to~~ all other PCI DSS encryption and key- management requirements.

Applicability Notes Disk or partition encryption implementations must also meet all other PCI DSS encryption and key- management requirements.

Modified p. 41 → 96

• Key-encrypting keys are at least as strong as the ~~data- encrypting~~ keys they protect.

• Key-encrypting keys are at least as strong as the data-encrypting keys they protect.

Modified p. 41 → 96

• Key-encrypting keys are stored separately from ~~data- encrypting~~ keys.

• Key-encrypting keys are stored separately from data-encrypting keys.

Modified p. 41 → 96

The requirement to protect keys from disclosure and misuse applies to both data-encrypting keys and ~~key-encrypting~~ keys. Because one ~~key- encrypting~~ key may grant access to many ~~data- encrypting~~ keys, the key-encrypting keys require strong protection measures.

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 key- encrypting keys. Because one key-encrypting key may grant access to many data-encrypting keys, the key-encrypting keys require strong protection measures.

Removed p. 42

• Inventory of any HSMs and other SCDs used for key management 3.5.1 Interview responsible personnel and review documentation to verify that a document exists to describe the cryptographic architecture, including:

• Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date

• Inventory of any HSMs and other SCDs used for key management

There should be very few who have access to cryptographic keys (reducing the potential for rending cardholder data visible by unauthorized parties), usually only those who have key custodian responsibilities.

Modified p. 42 → 97

• Details of all algorithms, protocols, and keys used for the protection of ~~cardholder~~ data, including key strength and expiry ~~date~~

• Details of all algorithms, protocols, and keys used for the protection of stored account data, including key strength and expiry date.

Modified p. 42 → 97

• Description of the key usage for each

• Description of the key usage for each key.

Modified p. 42 → 105

~~Note:~~ This requirement applies only when the entity being assessed is a service provider.

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

Removed p. 43

Note: It is not required that public keys be stored in one of these forms.

• As key components or key shares, in accordance with an industry-accepted method Cryptographic keys must be stored securely to prevent unauthorized or unnecessary access that could result in the exposure of cardholder data.

It is not intended that the key-encrypting keys be encrypted, however they are to be protected against disclosure and misuse as defined in Requirement 3.5. If key-encrypting keys are used, storing the key-encrypting keys in physically and/or logically separate locations from the data- encrypting keys reduces the risk of unauthorized access to both keys.

• Encrypted with a key-encrypting key.

• Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS-approved point-of-interaction device).

• As key components or key shares, in accordance with an industry-accepted method.

• Key-encrypting keys are stored separately from data- encrypting keys.

Modified p. 43 → 98

• Encrypted with a key-encrypting key that is at least as strong as the ~~data- encrypting~~ key, and that is stored separately from the ~~data-encrypting key~~

• Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data- encrypting key.

Modified p. 43 → 98

• Within a secure cryptographic device ~~(such~~ as a hardware ~~(host)~~ security module (HSM) or PTS-approved point-of-interaction ~~device)~~

• Within a secure cryptographic device (SCD), such as a hardware security module (HSM) or PTS-approved point-of-interaction device.

Modified p. 43 → 98

• As at least two full-length key components or key shares, in accordance with an ~~industry- accepted method~~

• As at least two full-length key components or key shares, in accordance with an industry-accepted method.

Modified p. 43 → 98

~~3.5.3.a~~ Examine documented procedures to verify that cryptographic keys used to encrypt/decrypt ~~cardholder~~ data must only ~~exist~~ in one (or more) of the ~~following~~ forms ~~at all times.~~

3.6.1.2.a Examine documented procedures to verify it is defined that cryptographic keys used to encrypt/decrypt stored account data must exist only in one (or more) of the forms specified in this requirement.

Modified p. 43 → 98

• ~~Encrypted with a key-encrypting key that is~~ at least as strong as the data-encrypting ~~key, and that is stored separately from the data-encrypting key~~

• Key-encrypting keys are at least as strong as the data-encrypting keys they protect.

Modified p. 43 → 98

~~3.5.3.b~~ Examine system configurations and key storage locations to verify that cryptographic keys used to encrypt/decrypt ~~cardholder~~ data exist in one (or more) of the ~~following form at all times.~~

3.6.1.2.b Examine system configurations and key storage locations to verify that cryptographic keys used to encrypt/decrypt stored account data exist in one (or more) of the forms specified in this requirement.

Modified p. 43 → 98

~~3.5.3.c~~ Wherever key-encrypting keys are used, examine system configurations and key storage locations to verify:

3.6.1.2.c Wherever key-encrypting keys are used, examine system configurations and key storage locations to verify:

Modified p. 43 → 98

• Key-encrypting keys are ~~at least as strong as the data- encrypting keys they protect.~~

• Key-encrypting keys are stored separately from data-encrypting keys.

Modified p. 43 → 99

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

Defined Approach Requirements 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.

Modified p. 43 → 103

• ~~Within~~ a secure cryptographic device ~~(such~~ as a hardware ~~(host)~~ security module (HSM) or PTS-approved point-of-interaction ~~device)~~

• Using an approved random number generator and within a secure cryptographic device (SCD), such as a hardware security module (HSM) or PTS-approved point-of-interaction device, OR

Removed p. 44

PCI DSS Requirements Testing Procedures Guidance 3.6 Fully document and implement all key- management processes and procedures for cryptographic keys used for encryption of cardholder data, including the following:

Note: Numerous industry standards for key management are available from various resources including NIST, which can be found at http://csrc.nist.gov.

The manner in which cryptographic keys are managed is a critical part of the continued security of the encryption solution. A good key- management process, whether it is manual or automated as part of the encryption product, is based on industry standards and addresses all key elements at 3.6.1 through 3.6.8.

This requirement applies to keys used to encrypt stored cardholder data, and any respective key- encrypting keys.

Note: Testing Procedure 3.6.a is an additional procedure that only applies if the entity being assessed is a service provider.

Removed p. 44

The encryption solution must generate strong keys, as defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms under "Cryptographic Key Generation." Use of strong cryptographic keys significantly increases the level of security of encrypted cardholder data.

Removed p. 44

The encryption solution must distribute keys securely, meaning the keys are distributed only to custodians identified in Requirement 3.5.2, and are never distributed in the clear. 3.6.2.b Observe the method for distributing keys to verify that keys are distributed securely.

Removed p. 44

The encryption solution must store keys securely, for example, by encrypting them with a key- encrypting key. Storing keys without proper protection could provide access to attackers, resulting in the decryption and exposure of cardholder data.

Modified p. 44 → 100

~~3.6.1.b~~ Observe the ~~procedures~~ for generating keys to verify that strong keys are generated.

3.7.1.b Observe the method for generating keys to verify that strong keys are generated. Customized Approach Objective Strong cryptographic keys are generated.

Modified p. 44 → 101

~~3.6.3.b~~ Observe the method for storing keys to verify that keys are stored securely.

3.7.3.b Observe the method for storing keys to verify that keys are stored securely. Customized Approach Objective Cryptographic keys are secured when stored.

Modified p. 44 → 103

~~3.6.b~~ Examine the key-management procedures ~~and processes~~ for keys used for ~~encryption~~ of ~~cardholder~~ data and ~~perform the following:~~

3.7.6.a Examine the documented key-management policies and procedures for keys used for protection of stored account data and verify that they define using split knowledge and dual control.

Modified p. 44 → 105

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.

Defined Approach Requirements 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.

Removed p. 45

PCI DSS Requirements Testing Procedures Guidance 3.6.4 Cryptographic key changes for keys that have reached the end of their cryptoperiod (for example, after a defined period of time has passed and/or after a certain amount of cipher-text has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines (for example, NIST Special Publication 800-57).

3.6.4.a Verify that key-management procedures include a defined cryptoperiod for each key type in use and define a process for key changes at the end of the defined cryptoperiod(s).

A cryptoperiod is the time span during which a particular cryptographic key can be used for its defined purpose. 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.

Periodic changing …

Removed p. 45

3.6.5.a Verify that key-management procedures specify processes for the following:

• The retirement or replacement of keys when the integrity of the key has been weakened.

• The replacement of known or suspected compromised keys.

Keys that are no longer used or needed, or keys that are known or suspected to be compromised, should be 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.

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. 3.6.5.b Interview personnel to verify the following processes are implemented:

• Keys are replaced if known or suspected to be compromised.

• Any keys retained after retiring or replacing are not used for encryption operations.

Modified p. 45 → 101

~~3.6.4.b Interview personnel to verify that keys are changed~~ at the end of the defined ~~cryptoperiod(s).~~

• A process for key changes at the end of the defined cryptoperiod.

Modified p. 45 → 102

~~Note:~~ If retired or replaced cryptographic keys need to be retained, these keys must be securely archived (for example, by using a key-encryption key). ~~Archived cryptographic keys should only be used for decryption/verification purposes.~~

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).

Modified p. 45 → 102

• ~~Any~~ keys ~~retained after retiring or replacing~~ are not used for encryption operations.

• The key is suspected of or known to be compromised. Retired or replaced keys are not used for encryption operations.

Modified p. 45 → 102

• ~~Keys are retired or replaced as necessary when the~~ integrity of the key has been weakened, including when ~~someone~~ with knowledge of the key ~~leaves the company.~~

• The integrity of the key has been weakened, including when personnel with knowledge of a cleartext key component leaves the company, or the role for which the key component was known.

Removed p. 46

PCI DSS Requirements Testing Procedures Guidance 3.6.6 If manual clear-text cryptographic key-management operations are used, these operations must be managed using split knowledge and dual control.

Note: Examples of manual key- management operations include, but are not limited to: key generation, transmission, loading, storage and destruction.

3.6.6.a Verify that manual clear-text key-management procedures specify processes for the use of the following:

• Split knowledge of keys, such that key components are under the control of at least two people who only have knowledge of their own key components; AND

• Dual control of keys, such that at least two people are required to perform any key-management operations and no one person has access to the authentication materials (for example, passwords or keys) of another.

Split knowledge and dual control of keys are used to eliminate the possibility of one person having access to the whole key. This control is applicable for manual key-management operations, or …

Removed p. 46

• Split knowledge, AND

3.6.7.a Verify that key-management procedures specify processes to prevent unauthorized substitution of keys.

The encryption solution should not allow for or accept substitution of keys coming from unauthorized sources or unexpected processes. 3.6.7.b Interview personnel and/or observe processes to verify that unauthorized substitution of keys is prevented.

Removed p. 46

3.6.8.a Verify that key-management procedures specify processes for key custodians to acknowledge (in writing or electronically) that they understand and accept their key- custodian responsibilities.

3.6.8.b Observe documentation or other evidence showing that key custodians have acknowledged (in writing or electronically) that they understand and accept their key- custodian responsibilities.

Removed p. 46

Personnel need to be aware of and following security policies and documented operational procedures for managing the secure storage of cardholder data on a continuous basis.

Removed p. 47

Requirement 4: Encrypt transmission of cardholder data across open, public networks Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardholder data environments.

PCI DSS Requirements Testing Procedures Guidance 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks, including the following:

• The protocol in use only supports secure versions or configurations.

Examples of open, public networks include but are not limited to:

• Wireless technologies, including 802.11 and Bluetooth

• Cellular technologies, for example, Global System for Mobile communications (GSM), Code division multiple access (CDMA)

• General Packet Radio Service (GPRS)

• Satellite communications 4.1.a Identify all locations where cardholder data is transmitted or received over open, public networks. Examine documented standards and …

Modified p. 47 → 109

~~4.1.d~~ Examine ~~keys and certificates~~ to verify that ~~only trusted~~ keys and/or certificates are ~~accepted.~~

4.2.1.d Examine system configurations to verify that keys and/or certificates that cannot be verified as trusted are rejected.

Modified p. 47 → 109

~~4.1.e~~ Examine system configurations to verify that ~~the protocol is~~ implemented ~~to use only secure configurations and does not support insecure versions or configurations.~~

4.2.1.b Examine system configurations to verify that strong cryptography and security protocols are implemented in accordance with all elements specified in this requirement.

Modified p. 47 → 112

~~(Continued on next page) 4.1.b Review~~ documented policies and procedures to verify processes are ~~specified~~ for the ~~following:~~

4.2.1.1.a Examine documented policies and procedures to verify processes are defined for the entity to maintain an inventory of its trusted keys and certificates.

Removed p. 48

PCI DSS Requirements Testing Procedures Guidance 4.1.g For TLS implementations, examine system configurations to verify that TLS is enabled whenever cardholder data is transmitted or received.

For example, for browser-based implementations:

• “HTTPS” appears as the browser Universal Record Locator (URL) protocol, and

• Cardholder data is only requested if “HTTPS” appears as part of the URL.

Generally, the web page URL should begin with "HTTPS" and/or the web browser display a padlock icon somewhere in the window of the browser. Many TLS certificate vendors also provide a highly visible verification seal

• sometimes referred to as a “security seal,” "secure site seal," or “secure trust seal”)

•which may provide the ability to click on the seal to reveal information about the website.

Refer to industry standards and best practices for information on strong cryptography and secure protocols (e.g., NIST SP 800-52 and SP 800-57, OWASP, etc.)

Removed p. 48

• Industry best practices are used to implement strong encryption for authentication and transmission.

• Weak encryption (for example, WEP, SSL) is not used as a security control for authentication or transmission.

Strong cryptography for authentication and transmission of cardholder data is required to prevent malicious users from gaining access to the wireless network or utilizing wireless networks to access other internal networks or data.

Removed p. 49

PCI DSS Requirements Testing Procedures Guidance 4.2 Never send unprotected PANs by end- user messaging technologies (for example, e- mail, instant messaging, SMS, chat, etc.).

4.2.a If end-user messaging technologies are used to send cardholder data, observe processes for sending PAN and examine a sample of outbound transmissions as they occur to verify that PAN is rendered unreadable or secured with strong cryptography whenever it is sent via end-user messaging technologies.

E-mail, instant messaging, SMS, and chat can be easily intercepted by packet-sniffing during delivery across internal and public networks. Do not utilize these messaging tools to send PAN unless they are configured to provide strong encryption.

Additionally, if an entity requests PAN via end- user messaging technologies, the entity should provide a tool or method to protect these PANs using strong cryptography or render PANs unreadable before transmission.

Removed p. 49

Personnel need to be aware of and following security policies and operational procedures for managing the secure transmission of cardholder data on a continuous basis.

Modified p. 49 → 114

~~4.2.b Review written~~ policies to verify ~~the existence of a policy stating~~ that ~~unprotected PANs~~ are ~~not~~ to be sent ~~via~~ end-user messaging technologies.

4.2.2.a Examine documented policies and procedures to verify that processes are defined to secure PAN with strong cryptography whenever sent over end-user messaging technologies.

Removed p. 50

Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs Malicious software, commonly referred to as “malware”

•including viruses, worms, and Trojans

•enters the network during many business- approved activities including employee e-mail and use of the Internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats. Additional anti-malware solutions may be considered as a supplement to the anti-virus software; however, such additional solutions do not replace the need for anti-virus software to be in place.

PCI DSS Requirements Testing Procedures Guidance 5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).

Removed p. 50

There is a constant stream of attacks using widely published exploits, often called "zero day" (an attack that exploits a previously unknown vulnerability), against otherwise secured systems. Without an anti-virus solution that is updated regularly, these new forms of malicious software can attack systems, disable a network, or lead to compromise of data.

Removed p. 50

Examples of types of malicious software include viruses, Trojans, worms, spyware, adware, and rootkits.

It is important to protect against ALL types and forms of malicious software.

Modified p. 50 → 118

• ~~Detect~~ all known types of ~~malicious software,~~

• Detects all known types of malware.

Modified p. 50 → 118

• ~~Remove~~ all known types of ~~malicious software, and~~

• Detects all known types of malware.

Modified p. 50 → 118

• ~~Protect against~~ all known types of ~~malicious software.~~

• Removes, blocks, or contains all known types of malware.

Removed p. 51

PCI DSS Requirements Testing Procedures Guidance 5.1.2 For systems considered to be not commonly affected by malicious software, perform periodic evaluations to identify and evaluate evolving malware threats in order to confirm whether such systems continue to not require anti-virus software.

Removed p. 51

Typically, mainframes, mid-range computers (such as AS/400) and similar systems may not currently be commonly targeted or affected by malware. However, industry trends for malicious software 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 anti-virus news groups to determine whether their systems might be coming under threat from new and evolving malware.

• Generate audit logs which are retained per PCI DSS Requirement 10.7.

5.2.a Examine policies and procedures to verify that anti-virus software and definitions are required to be kept up to date.

Even the best anti-virus solutions are limited in effectiveness if they are not maintained and kept current with the latest security updates, signature files, or malware protections.

Audit logs provide the ability to monitor virus and malware activity and anti-malware reactions. Thus, it is imperative that anti-malware solutions be configured to …

Modified p. 51 → 119

Trends in ~~malicious software~~ should be included in the identification of new security ~~vulnerabilities,~~ and methods to address new trends should be incorporated into the ~~company's~~ configuration standards and protection mechanisms as ~~needed 5.2 Ensure that all anti-virus mechanisms are maintained as follows:~~

• A strategy to add malware protection for any system types for which malware protection has become necessary. 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.

Modified p. 51 → 121

~~5.2.b~~ Examine ~~anti-virus~~ configurations, including ~~the~~ master installation of the ~~software~~ to verify ~~anti-virus mechanisms are:~~

5.3.1.a Examine anti-malware solution(s) configurations, including any master installation of the software, to verify the solution is configured to perform automatic updates.

Modified p. 51 → 122

• ~~Perform~~ periodic scans

• Performs periodic scans and active or real-time scans.

Removed p. 52

Note: Anti-virus solutions may be temporarily disabled only if there is legitimate technical need, as authorized by management on a case-by-case basis. If anti-virus 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 of time during which anti-virus protection is not active.

5.3.a Examine anti-virus configurations, including the master installation of the software and a sample of system components, to verify the anti-virus software is actively running.

Anti-virus that continually runs and is unable to be altered will provide persistent security against malware.

Use of policy-based controls on all systems to ensure anti-malware protections cannot be altered or disabled will help prevent system weaknesses from being exploited by malicious software.

Additional security measures may also need to be implemented for the period of time during which anti-virus protection is not active•for example, disconnecting the unprotected system from …

Removed p. 52

Personnel need to be aware of and following security policies and operational procedures to ensure systems are protected from malware on a continuous basis.

Modified p. 52 → 125

~~5.3.b~~ Examine ~~anti-virus~~ configurations, ~~including the master installation of the software and a sample of system components,~~ to verify that the ~~anti-virus software~~ cannot be disabled or altered by users.

5.3.5.a Examine anti-malware configurations, to verify that the anti-malware mechanisms cannot be disabled or altered by users.

Removed p. 53

Requirement 6: Develop and maintain secure systems and applications Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor- provided security patches, which must be installed by the entities that manage the systems. All systems must have all appropriate software patches to protect against the exploitation and compromise of cardholder data by malicious individuals and malicious software.

Note: Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with existing security configurations. For in-house developed applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.

PCI DSS Requirements Testing Procedures Guidance 6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities.

Note: Risk rankings …

Removed p. 54

PCI DSS Requirements Testing Procedures Guidance 6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor- supplied security patches. Install critical security patches within one month of release.

Note: Critical security patches should be identified according to the risk ranking process defined in Requirement 6.1.

6.2.a Examine policies and procedures related to security- patch installation to verify processes are defined for:

• Installation of applicable critical vendor-supplied security patches within one month of release.

• Installation of all applicable vendor-supplied security patches within an appropriate time frame (for example, within three months).

There is a constant stream of attacks using widely published exploits, often called "zero day" (an attack that exploits a previously unknown vulnerability), against otherwise secured systems. If the most recent patches are not implemented on critical systems as soon as possible, a malicious individual can use these exploits to attack or disable a system, or …

Removed p. 54

6.3.a Examine written software-development processes to verify that the processes are based on industry standards and/or best practices.

Understanding how sensitive data is handled by the application

•including when stored, transmitted, and when in memory

•can help identify where data needs to be protected.

6.3.b Examine written software-development processes to verify that information security is included throughout the life cycle.

6.3.c Examine written software-development processes to verify that software applications are developed in accordance with PCI DSS.

6.3.d Interview software developers to verify that written software-development processes are implemented.

Modified p. 54 → 131

• In accordance with PCI DSS (for example, secure authentication and logging)

• Based on industry standards and/or best practices.

• Incorporating information security throughout the software-development life cycle

• In accordance with PCI DSS (for example, secure authentication and logging).

Modified p. 54 → 131

~~Note: this~~ applies to all software developed ~~internally as well as~~ bespoke or custom ~~software developed by a third party.~~

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.

Removed p. 55

PCI DSS Requirements Testing Procedures Guidance 6.3.1 Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers.

Removed p. 55

Development, test and/or custom application accounts, user IDs, and passwords should be removed from production code before the application becomes active or is released to customers, since these items may give away information about the functioning of the application. Possession of such information could facilitate compromise of the application and related cardholder data.

• Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code-review techniques and secure coding practices.

(Continued on next page) 6.3.2.a Examine written software-development procedures and interview responsible personnel to verify that all custom application code changes must be reviewed (using either manual or automated processes) as follows:

• Code reviews ensure code is developed according to secure coding guidelines (see PCI DSS Requirement 6.5).

• Appropriate corrections are implemented prior to release.

• Code-review results are reviewed and approved by management prior to release.

Security vulnerabilities in custom code are commonly exploited by malicious …

Modified p. 55 → 133

• Code reviews ensure code is developed according to secure coding ~~guidelines~~

• Code reviews ensure code is developed according to secure coding guidelines.

Modified p. 55 → 134

• ~~Code-review results are reviewed~~ and approved by management prior to release.

• Reviewed and approved by management prior to release.

Modified p. 55 → 134

• ~~Code changes are reviewed~~ by individuals other than the originating code author, and ~~by individuals~~ who are knowledgeable in code-review techniques and secure coding practices.

• Reviewed by individuals other than the originating code author, and who are knowledgeable about code-review techniques and secure coding practices.

Removed p. 56

PCI DSS Requirements Testing Procedures Guidance

Note: This requirement for code reviews applies to all custom code (both internal and public-facing), as part of the system development life cycle.

Code reviews can be conducted by knowledgeable internal personnel or third parties. 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.6.

6.3.2.b Select a sample of recent custom application changes and verify that custom application code is reviewed according to 6.3.2.a, above.

Removed p. 56

• Development/test environments are separate from production environments with access control in place to enforce separation.

• A separation of duties between personnel assigned to the development/test environments and those assigned to the production environment.

• Production data (live PANs) are not used for testing or development.

• Test data and accounts are removed before a production system becomes active.

• Change control procedures related to implementing security patches and software modifications are documented.

Without properly documented and implemented change controls, security features could be inadvertently or deliberately omitted or rendered inoperable, processing irregularities could occur, or malicious code could be introduced.

Removed p. 56

6.4.1.a Examine network documentation and network device configurations to verify that the development/test environments are separate from the production environment(s).

Due to the constantly changing state of development and test environments, they tend to be less secure than the production environment. Without adequate separation between environments, it may be possible for the production environment, and cardholder data, to be compromised due to less- stringent security configurations and possible vulnerabilities in a test or development environment.

6.4.1.b Examine access controls settings to verify that access controls are in place to enforce separation between the development/test environments and the production environment(s).

PCI DSS Requirements Testing Procedures Guidance 6.4.2 Separation of duties between development/test and production environments 6.4.2 Observe processes and interview personnel assigned to development/test environments and personnel assigned to production environments to verify that separation of duties is in place between development/test environments and the production environment.

Reducing the number of personnel with access to …

Removed p. 57

Security controls are usually not as stringent in test or development environments. Use of production data provides malicious individuals with the opportunity to gain unauthorized access to production data (cardholder data). 6.4.3.b Examine a sample of test data to verify production data (live PANs) is not used for testing or development.

Removed p. 57

6.4.4.a Observe testing processes and interview personnel to verify test data and accounts are removed before a production system becomes active.

Test data and accounts should be removed before the system component becomes active (in production), since these items may give away information about the functioning of the application or system. Possession of such information could facilitate compromise of the system and related cardholder data.

6.4.4.b Examine a sample of data and accounts from production systems recently installed or updated to verify test data and accounts are removed before the system becomes active.

PCI DSS Requirements Testing Procedures Guidance 6.4.5 Change control procedures must include the following:

• Back-out procedures If not properly managed, the impact of system changes

•such as hardware or software updates and installation of security patches

•might not be fully realized and could have unintended consequences.

6.4.5.b For a sample of system components, interview responsible personnel to determine recent changes. Trace those changes …

Removed p. 58

The impact of the change should be documented so that all affected parties can plan appropriately for any processing changes.

Removed p. 58

Approval by authorized parties indicates that the change is a legitimate and approved change sanctioned by the organization.

Removed p. 58

6.4.5.3.a For each sampled change, verify that functionality testing is performed to verify that the change does not adversely impact the security of the system.

Thorough testing should be performed to verify that the security of the environment is not reduced by implementing a change. Testing should validate that all existing security controls remain in place, are replaced with equally strong controls, or are strengthened after any change to the environment.

Removed p. 58

For each change, there should be documented back-out procedures in case the change fails or adversely affects the security of an application or system, to allow the system to be restored back to its previous state.

Modified p. 58 → 147

~~6.4.5.a~~ Examine documented change control procedures ~~and~~ verify procedures are defined ~~for:~~

6.5.1.a Examine documented change control procedures to verify procedures are defined for changes to all system components in the production environment to include all elements specified in this requirement.

Modified p. 58 → 147

• Documentation of ~~impact~~

• Documentation of security impact.

Modified p. 58 → 147

• Documented change approval by authorized ~~parties~~

• Documented change approval by authorized parties.

Modified p. 58 → 147

• ~~Functionality testing~~ to verify that the change does not adversely impact ~~the security of the~~ system

• Testing to verify that the change does not adversely impact system security.

Modified p. 58 → 147

~~6.4.5.3.b~~ For custom ~~code~~ changes, ~~verify that~~ all updates are tested for compliance with ~~PCI DSS~~ Requirement ~~6.5~~ before being deployed into production.

• For bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production.

Removed p. 59

PCI DSS Requirements Testing Procedures Guidance 6.4.6 Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable.

Removed p. 59

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.

A change management process should include supporting evidence that PCI DSS requirements are implemented or preserved through the iterative process. Examples of PCI DSS requirements that could be impacted include, but are not limited to:

Removed p. 59

• Train developers at least annually in up- to-date secure coding techniques, 6.5.a Examine software-development policies and procedures to verify that up-to-date training in secure coding techniques is required for developers at least annually, based on industry best practices and guidance.

The application layer is high-risk and may be targeted by both internal and external threats.

Requirements 6.5.1 through 6.5.10 are the minimum controls that should be in place, and organizations should incorporate the relevant secure coding 6.5.b Examine records of training to verify that software developers receive up-to-date training on secure coding techniques at least annually, including how to avoid common coding vulnerabilities.

Modified p. 59 → 148

• Network ~~diagram is~~ updated to reflect changes.

• Network and data-flow diagrams are updated to reflect changes.

Modified p. 59 → 148

• Systems are protected with required controls ~~e.g., file-integrity~~ monitoring (FIM), ~~anti-virus,~~ patches, audit logging. • Sensitive authentication data (SAD) is not stored and all cardholder data (CHD) storage is documented and incorporated into data- retention policy and procedures

• New systems are included in the quarterly vulnerability scanning process.

• Systems are protected with required controls •for example, file integrity monitoring (FIM), anti-malware, patches, and audit logging.

Removed p. 60

PCI DSS Requirements Testing Procedures Guidance including how to avoid common coding vulnerabilities.

• Develop applications based on secure coding guidelines.

Note: The vulnerabilities listed at 6.5.1 through 6.5.10 were current with industry best practices when this version of PCI DSS was published. However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements.

6.5.c Verify that processes are in place to protect applications from, at a minimum, the following vulnerabilities: practices as applicable to the particular technology in their environment.

Application developers should be properly trained to identify and resolve issues related to these (and other) common coding vulnerabilities. Having staff knowledgeable of secure coding guidelines should minimize the number of security vulnerabilities introduced through poor coding practices. Training for developers may be provided in-house or by third parties and should …

Removed p. 60

• Validating input to verify user data cannot modify meaning of commands and queries.

• Utilizing parameterized queries.

Injection flaws, particularly SQL injection, are a commonly used method for compromising applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data, and allows the attacker to attack components inside the network through the application, to initiate attacks such as buffer overflows, or to reveal both confidential information and server application functionality.

Information should be validated before being sent to the application•for example, by checking for all alpha characters, mix of alpha and numeric characters, etc.

Removed p. 61

PCI DSS Requirements Testing Procedures Guidance 6.5.2 Buffer overflows 6.5.2 Examine software-development policies and procedures and interview responsible personnel to verify that buffer overflows are addressed by coding techniques that include:

• Validating buffer boundaries.

• Truncating input strings.

Buffer overflows occur when an application does not have appropriate bounds checking on its buffer space. This can cause the information in the buffer to be pushed out of the buffer’s memory space and into executable memory space. When this occurs, the attacker has the ability to insert malicious code at the end of the buffer and then push that malicious code into executable memory space by overflowing the buffer. The malicious code is then executed and often enables the attacker remote access to the application and/or infected system.

Removed p. 61

• Prevent cryptographic flaws.

• Use strong cryptographic algorithms and keys.

Applications that do not utilize strong cryptographic functions properly to store data are at increased risk of being compromised, and exposing authentication credentials and/or cardholder data. If an attacker is able to exploit weak cryptographic processes, they may be able to gain clear-text access to encrypted data.

Removed p. 61

Applications that fail to adequately encrypt network traffic using strong cryptography are at increased risk of being compromised and exposing cardholder data. If an attacker is able to exploit weak cryptographic processes, they may be able to gain control of an application or even gain clear-text access to encrypted data.

PCI DSS Requirements Testing Procedures Guidance 6.5.5 Improper error handling 6.5.5 Examine software-development policies and procedures and interview responsible personnel to verify that improper error handling is addressed by coding techniques that do not leak information via error messages (for example, by returning generic rather than specific error details).

Applications can unintentionally leak information about their configuration or internal workings, or expose privileged information through improper error handling methods. Attackers use this weakness to steal sensitive data or compromise the system altogether. If a malicious individual can create errors that the application does not handle properly, they can gain detailed system information, …

Removed p. 62

All vulnerabilities identified by an organization’s vulnerability risk-ranking process (defined in Requirement 6.1) to be “high risk” and that could affect the application should be identified and addressed during application development.

Note: Requirements 6.5.7 through 6.5.10, below, apply to web applications and application interfaces (internal or external):

Web applications, both internally and externally (public) facing, have unique security risks based upon their architecture as well as the relative ease and occurrence of compromise.

Removed p. 62

• Validating all parameters before inclusion

• Utilizing context-sensitive escaping.

XSS flaws occur whenever an application takes user-supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim's browser, which can hijack user sessions, deface web sites, possibly introduce worms, etc.

PCI DSS Requirements Testing Procedures Guidance 6.5.8 Improper access control (such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions).

Removed p. 63

• Proper authentication of users

• Not exposing internal object references to users

• User interfaces that do not permit access to unauthorized functions.

A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.

Consistently enforce access control in presentation layer and business logic for all URLs. Frequently, the only way an application protects sensitive functionality is by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.

An attacker may be able to enumerate and navigate the directory structure of a website (directory traversal) thus gaining access to unauthorized information as well as gaining further insight into the workings of the site for later exploitation.

If user …

Removed p. 63

A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then enables the attacker to perform any state-changing operations the victim is authorized to perform (such as updating account details, making purchases, or even authenticating to the application).

PCI DSS Requirements Testing Procedures Guidance 6.5.10 Broken authentication and session management.

Removed p. 64

• Flagging session tokens (for example cookies) as

• Not exposing session IDs in the URL

• Incorporating appropriate time-outs and rotation of session IDs after a successful login.

Secure authentication and session management prevents unauthorized individuals from compromising legitimate account credentials, keys, or session tokens that would otherwise enable the intruder to assume the identity of an authorized user.

Removed p. 64

• Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes

Note: This assessment is not the same as the vulnerability scans performed for Requirement 11.2.

• Installing an automated technical solution that detects and prevents web- based attacks (for example, a web- application firewall) in front of public- facing web applications, to continually check all traffic.

Removed p. 64

• Examine documented processes, interview personnel, and examine records of application security assessments to verify that public-facing web applications are reviewed

•using either manual or automated vulnerability security assessment tools or methods

•as follows:

- At least annually - After any changes - By an organization that specializes in application security - That, at a minimum, all vulnerabilities in

Requirement 6.5 are included in the assessment - That all vulnerabilities are corrected - That the application is re-evaluated after the corrections.

• Examine the system configuration settings and interview responsible personnel to verify that an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) is in place as follows:

- Is situated in front of public-facing web applications to detect and prevent web-based attacks. - Is actively running and up to date as applicable. - Is generating audit logs. - Is configured to either block web-based attacks, or generate an alert …

Removed p. 65

Personnel need to be aware of and following security policies and operational procedures to ensure systems and applications are securely developed and protected from vulnerabilities on a continuous basis.

Requirement 7: Restrict access to cardholder data by business need to know To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities.

“Need to know” is when access rights are granted to only the least amount of data and privileges needed to perform a job.

PCI DSS Requirements Testing Procedures Guidance 7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access.

Removed p. 66

• Defining access needs and privilege assignments for each role

• Documented approval (electronically or in writing) by authorized parties for all access, including listing of specific privileges approved.

The more people who have access to cardholder data, the more risk there is that a user’s account will be used maliciously. Limiting access to those with a legitimate business reason for the access helps an organization prevent mishandling of cardholder data through inexperience or malice.

Removed p. 66

• System components and data resources that each role needs to access for their job function

• System components and data resources that each role needs to access for their job function

Removed p. 66

In order to limit access to cardholder data to only those individuals who need such access, first it is necessary to define access needs for each role (for example, system administrator, call center personnel, store clerk), the systems/devices/data each role needs access to, and the level of privilege each role needs to effectively perform assigned tasks. Once roles and corresponding access needs are defined, individuals can be granted access accordingly.

Removed p. 66

7.1.2.a Interview personnel responsible for assigning access to verify that access to privileged user IDs is:

• Assigned only to roles that specifically require such privileged access

• Restricted to least privileges necessary to perform job responsibilities.

When assigning privileged IDs, 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.

Modified p. 66 → 156

• ~~Assignment of access~~ based on ~~individual personnel’s~~ job classification and ~~function~~

• Access to system components and data resources that is based on users’ job classification and functions.

Modified p. 66 → 156

• ~~Level of privilege~~ required (for example, user, ~~administrator, etc.) for accessing resources.~~

• The least privileges required (for example, user, administrator) to perform a job function.

Modified p. 66 → 158

• ~~Restriction of access to privileged user IDs to least~~ privileges necessary to perform job ~~responsibilities~~

• Least privileges necessary to perform job responsibilities.

Modified p. 66 → 161

• ~~Identification of privilege~~ necessary for ~~each role to perform their job function.~~

• Based on the least privileges necessary for the operability of the system or application.

Removed p. 67

• Restricted to least privileges necessary to perform job responsibilities.

PCI DSS Requirements Testing Procedures Guidance 7.1.2.b Select a sample of user IDs with privileged access and interview responsible management personnel to verify that privileges assigned are:

• Necessary for that individual’s job function

Removed p. 67

Once needs are defined for user roles (per PCI DSS requirement 7.1.1), it is easy to grant individuals access according to their job classification and function by using the already-created roles.

Removed p. 67

Note: Some access control systems are set by default to “allow-all,” thereby permitting access unless/until a rule is written to specifically deny it.

Modified p. 67 → 159

• Documented approval exists for the assigned ~~privileges~~

• Documented approval exists for the assigned privileges.

Modified p. 67 → 159

• The approval was by authorized ~~parties~~

• The approval was by authorized personnel.

Modified p. 67 → 159

• ~~That specified~~ privileges match the roles assigned to the individual.

• Specified privileges match the roles assigned to the individual.

Modified p. 67 → 164

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. Additionally, a default “deny-all” setting ensures no one is granted access until and unless a rule is established specifically granting such access. Entities may have one or more access controls systems to manage user access.

Defined Approach Requirements 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.

Removed p. 68

PCI DSS Requirements Testing Procedures Guidance 7.3 Ensure that security policies and operational procedures for restricting access to cardholder data are documented, in use, and known to all affected parties.

Personnel need to be aware of and following security policies and operational procedures to ensure that access is controlled and based on need- to-know and least privilege, on a continuous basis.

Removed p. 69

Requirement 8: Identify and authenticate access to system components Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for their actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users and processes.

The effectiveness of a password is largely determined by the design and implementation of the authentication system•particularly, how frequently password attempts can be made by an attacker, and the security methods to protect user passwords at the point of entry, during transmission, and while in storage.

Note: These requirements are applicable for all accounts, including point-of-sale accounts, with administrative capabilities and all accounts used to view or access cardholder data or to access systems with cardholder data. This includes accounts used by vendors and other third parties (for example, for support or maintenance). These requirements do …

Removed p. 69

To ensure that user accounts granted access to systems are all valid and recognized users, strong processes must manage all changes to user IDs and other authentication credentials, including adding new ones and modifying or deleting existing ones.

Removed p. 69

•have been returned or deactivated.

Modified p. 69 → 172

~~8.1.3.a Select a sample of~~ users ~~terminated in the past six months,~~ and review current user access lists

•for both local and remote access

•to verify that ~~their~~ IDs have been deactivated or removed from the access lists.

8.2.5.a Examine information sources for terminated users and review current user access lists

•for both local and remote access

•to verify that terminated user IDs have been deactivated or removed from the access lists.

Modified p. 69 → 172

If an employee 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. ~~To prevent unauthorized access, user credentials and other authentication methods therefore need to be revoked promptly (as soon as possible) upon the employee’s departure.~~

Defined Approach Requirements 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.

Modified p. 69 → 172

~~8.1.3.b Verify~~ all physical authentication ~~methods~~

•such as, smart cards, tokens, etc.

8.2.5.b Interview responsible personnel to verify that all physical authentication factors

•such as, smart cards, tokens, etc.

Removed p. 70

PCI DSS Requirements Testing Procedures Guidance 8.1.4 Remove/disable inactive user accounts within 90 days.

Removed p. 70

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.

• Monitored when in use.

8.1.5.a Interview personnel and observe processes for managing accounts used by third parties to access, support, or maintain system components to verify that accounts used for remote access are:

• Disabled when not in use

• Enabled only when needed by the third party, and disabled when not in use.

Allowing vendors to have 24/7 access into your network in case they need to support your systems increases the chances of unauthorized access, either from a user in the vendor’s environment or from a malicious individual who finds and uses this always-available external entry point into your network. Enabling access only for the time periods needed, and disabling …

Removed p. 70

8.1.6.b Additional testing procedure for service provider assessments only: Review internal processes and customer/user documentation, and observe implemented processes to verify that non-consumer customer user accounts are temporarily locked-out after not more than six invalid access attempts.

If an account is locked out due to someone continually trying to guess a password, controls to delay reactivation of these locked accounts stops the malicious individual from continually guessing the password (they will have to stop for a minimum of 30 minutes until the account is reactivated). Additionally, if reactivation must be requested, the admin or help desk can validate that it is the actual account owner requesting reactivation.

Modified p. 70 → 177

~~8.1.6.a For a sample of system components, inspect~~ system configuration settings to verify that authentication parameters are set to require that user accounts be locked out after not more than ~~six~~ invalid logon attempts.

8.3.4.a Examine system configuration settings to verify that authentication parameters are set to require that user accounts be locked out after not more than 10 invalid logon attempts.

Removed p. 71

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

The re-authentication can be applied either at the system level to protect all sessions running on that machine, or at the application level.

Removed p. 71

• Examine documentation describing the authentication method(s) used.

• For each type of authentication method used and for each type of system component, observe an authentication to verify authentication is functioning consistent with documented authentication method(s).

These authentication methods, when used in addition to unique IDs, help protect users’ IDs from being compromised, since the one attempting the compromise needs to know both the unique ID and the password (or other authentication used). Note that a digital certificate is a valid option for “something you have” as long as it is unique for a particular user.

Since one of the first steps a malicious individual will take to compromise a system is to exploit weak or nonexistent passwords, it is important to implement good processes for authentication management.

Modified p. 71 → 175

• Something you know, such as a password or passphrase

• Something you have, such as a token device or smart card

• Something you are, such as a biometric.

• Something you know, such as a password or passphrase.

Removed p. 72

Note: Testing Procedures 8.2.1.d and 8.2.1.e are additional procedures that only apply if the entity being assessed is a service provider.

8.2.1.c For a sample of system components, examine data transmissions to verify that passwords are unreadable during transmission.

8.2.1.d Additional testing procedure for service provider assessments only: Observe password files to verify that non- consumer customer passwords are unreadable during storage.

8.2.1.e Additional testing procedure for service provider assessments only: Observe data transmissions to verify that non-consumer customer passwords are unreadable during transmission.

Removed p. 72

Many malicious individuals use "social engineering”

•for example, calling a help desk and acting as a legitimate user

•to have a password changed so they can utilize a user ID. Consider use of a “secret question” that only the proper user can answer to help administrators identify the user prior to re-setting or modifying authentication credentials.

Modified p. 72 → 176

~~8.2.1.a~~ Examine vendor documentation and system configuration settings to verify that ~~passwords~~ are ~~protected~~ with strong cryptography during transmission and storage.

8.3.2.a Examine vendor documentation and system configuration settings to verify that authentication factors are rendered unreadable with strong cryptography during transmission and storage.

Modified p. 72 → 176

~~8.2.1.b For a sample~~ of ~~system components, examine password files~~ to verify that ~~passwords~~ are unreadable during storage.

8.3.2.b Examine repositories of authentication factors to verify that they are unreadable during storage.

Removed p. 73

PCI DSS Requirements Testing Procedures Guidance 8.2.3 Passwords/passphrases must meet the following:

Removed p. 73

Alternatively, the passwords/ passphrases must have complexity and strength at least equivalent to the parameters specified above.

• Contain both numeric and alphabetic characters.

• Contain both numeric and alphabetic characters.

Strong passwords/passphrases are the first line of defense into a network since a malicious individual will often first try to find accounts with weak or non- existent passwords. If passwords are short or simple to guess, 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.

This requirement specifies that a minimum of seven characters and both numeric and alphabetic characters should be used for passwords/ passphrases. For cases where this minimum cannot be met due to technical limitations, entities can use “equivalent strength” to evaluate their alternative. For information on variability and equivalency of password strength (also referred to as entropy) for passwords/passphrases of different formats, refer …

Modified p. 73 → 182

• ~~Non-consumer customer~~ user passwords/passphrases ~~are required to change periodically; and~~

• Guidance for customers to change their user passwords/passphrases periodically.

Modified p. 73 → 182

• ~~Non-consumer customer users are given guidance~~ as to when, and under what circumstances, passwords/passphrases ~~must change.~~

• Guidance as to when, and under what circumstances, passwords/passphrases are to be changed.

Removed p. 74

If password history isn’t 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 of time reduces the likelihood that passwords that have been guessed or brute-forced will be used in the future.

8.2.5.b Additional testing procedure for service provider assessments only: Review internal processes and customer/user documentation to verify that new non-consumer customer user passwords/passphrase cannot be the same as the previous four passwords.

Removed p. 74

If the same password is used for every new user, an internal user, former employee, or malicious individual may know or easily discover this password, and use it to gain access to accounts.

Removed p. 74

Multi-factor authentication requires an individual to present a minimum of two separate forms of authentication (as described in Requirement 8.2), before access is granted.

Multi-factor authentication provides additional assurance that the individual attempting to gain access is who they claim to be. With multi-factor authentication, an attacker would need to compromise at least two different authentication mechanisms, increasing the difficulty of compromise and thus reducing the risk.

Multi-factor authentication is not required at both the system-level and application-level for a particular system component. Multi-factor authentication can be performed either upon authentication to the particular network or to the system component.

Examples of multi-factor technologies include but are not limited to remote authentication and dial-in service (RADIUS) with tokens; terminal access controller access control system (TACACS) with tokens; and other technologies that facilitate multi- factor authentication.

Removed p. 75

This requirement is intended to apply to all personnel with administrative access to the CDE. This requirement applies only to personnel with administrative access and only for non-console access to the CDE; it does not apply to application or system accounts performing automated functions.

If the entity does not use segmentation to separate the CDE from the rest of their network, an administrator could use multi-factor authentication either when logging onto the CDE network or when logging onto a system.

If the CDE is segmented from the rest of the entity’s network, an administrator would need to use multi- factor authentication when connecting to a CDE system from a non-CDE network. Multi-factor authentication can be implemented at network level or at system/application level; it does not have to be both. If the administrator uses MFA when logging into the CDE network, they do not also need to use MFA to log into …

Modified p. 75 → 185

~~8.3.1.a~~ Examine network and/or system ~~configurations, as applicable,~~ to verify ~~multi-factor authentication~~ is required for all ~~non-console administrative access~~ into the ~~CDE.~~

8.4.1.a Examine network and/or system configurations to verify MFA is required for all non- console into the CDE for personnel with administrative access.

Modified p. 75 → 188

~~8.3.1.b~~ Observe ~~a sample of administrator~~ personnel ~~login~~ to the ~~CDE~~ and verify that ~~at least two of the three~~ authentication ~~methods are used.~~

8.4.3.b Observe personnel (for example, users and administrators) connecting remotely to the network and verify that multi-factor authentication is required.

Modified p. 75 → 188

~~8.3.2.a~~ Examine system configurations for remote access servers and systems to verify ~~multi-factor authentication~~ is required ~~for:~~

8.4.3.a Examine network and/or system configurations for remote access servers and systems to verify MFA is required in accordance with all elements specified in this requirement.

Modified p. 75 → 188

• All remote access by ~~personnel, both user~~ and ~~administrator, and~~

• All remote access by third parties and vendors.

Removed p. 76

• Guidance on selecting strong authentication credentials

• Guidance for how users should protect their authentication credentials

• Instructions not to reuse previously used passwords

• Instructions to change passwords if there is any suspicion the password could be compromised.

Communicating password/authentication policies and procedures to all users helps those users understand and abide by the policies.

For example, guidance on selecting strong passwords may include suggestions to help personnel select hard-to-guess passwords that don’t contain dictionary words, and that don’t contain information about the user (such as the user ID, names of family members, date of birth, etc.). Guidance for protecting authentication credentials may include not writing down passwords or saving them in insecure files, and being alert for malicious individuals who may attempt to exploit their passwords (for example, by calling an employee and asking for their password so the caller can “troubleshoot a problem”).

8.4.c Interview a sample of users to verify that …

Removed p. 76

• Generic user IDs are disabled or removed.

• Shared user IDs do not exist for system administration and other critical functions.

• Shared and generic user IDs are not used to administer any system components.

8.5.a For a sample of system components, examine user ID lists to verify the following:

• Generic user IDs are disabled or removed.

• Shared user IDs for system administration activities and other critical functions do not exist.

• Shared and generic user IDs are not used to administer any system components.

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. This in turn 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 that has knowledge of the authentication credentials. 8.5.b Examine authentication policies and …

Modified p. 76 → 180

~~PCI DSS Requirements Testing Procedures Guidance 8.4 Document~~ and ~~communicate~~ authentication policies and procedures to all ~~users including:~~

8.3.8.a Examine procedures and interview personnel to verify that authentication policies and procedures are distributed to all users.

Modified p. 76 → 180

~~8.4.a Examine procedures and interview personnel~~ to verify that authentication policies and ~~procedures are distributed to all users.~~

8.3.8.c Interview users to verify that they are familiar with authentication policies and procedures.

Modified p. 76 → 180

~~8.4.b~~ Review authentication policies and procedures that are distributed to users and verify they ~~include:~~

8.3.8.b Review authentication policies and procedures that are distributed to users and verify they include the elements specified in this requirement.

Modified p. 76 → 180

• Guidance on selecting strong authentication ~~credentials~~

• Guidance on selecting strong authentication factors.

Modified p. 76 → 180

• Guidance for how users should protect their authentication credentials.

• Instructions for users not to reuse previously used passwords

• Instructions to change passwords if there is any suspicion the password could be compromised.

• Guidance for how users should protect their authentication factors.

Removed p. 77

PCI DSS Requirements Testing Procedures Guidance 8.5.1 Additional requirement for service providers only: Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer.

Note: This requirement is not intended to apply to shared hosting providers accessing their own hosting environment, where multiple customer environments are hosted.

Removed p. 77

To prevent the compromise of multiple customers through the use of a single set of credentials, vendors with remote access accounts to customer environments should use a different authentication credential for each customer.

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

• Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts.

• Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.

If user authentication mechanisms such as tokens, smart cards, and certificates can be used by multiple accounts, it may be impossible to identify the individual using the authentication mechanism. Having physical and/or logical controls (for example, a PIN, biometric data, or a password) to uniquely identify the user of the account will prevent unauthorized users from …

Modified p. 77 → 184

~~8.6.a~~ Examine authentication policies and procedures to verify that procedures for using authentication ~~mechanisms~~ such as physical security tokens, smart cards, and certificates are defined and ~~include:~~

8.3.11.a Examine authentication policies and procedures to verify that procedures for using authentication factors such as physical security tokens, smart cards, and certificates are defined and include all elements specified in this requirement.

Modified p. 77 → 184

~~• Authentication mechanisms are assigned to an individual account and not shared among multiple accounts.~~

• Physical and/or logical controls ~~are defined to~~ ensure only the intended ~~account~~ can use that ~~mechanism~~ to gain access.

• Physical and/or logical controls ensure only the intended user can use that factor to gain access.

Modified p. 77 → 184

~~8.6.b~~ Interview security personnel to verify authentication ~~mechanisms~~ are assigned to an ~~account~~ and not shared among multiple ~~accounts.~~

8.3.11.b Interview security personnel to verify authentication factors are assigned to an individual user and not shared among multiple users.

Modified p. 77 → 184

~~8.6.c~~ Examine system configuration settings and/or physical controls, as applicable, to verify that controls are implemented to ensure only the intended ~~account~~ can use that ~~mechanism~~ to gain access.

8.3.11.c Examine system configuration settings and/or observe physical controls, as applicable, to verify that controls are implemented to ensure only the intended user can use that factor to gain access.

Removed p. 78

PCI DSS Requirements Testing Procedures Guidance 8.7 All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted as follows:

• All user access to, user queries of, and user actions on databases are through programmatic methods.

• Only database administrators have the ability to directly access or query databases.

• Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes).

8.7.a Review database and application configuration settings and verify that all users are authenticated prior to access.

Without user authentication for access to databases and applications, the potential for unauthorized or malicious access increases, and such access cannot be logged since the user has not been authenticated and is therefore not known to the system. Also, database access should be granted through programmatic methods only (for example, through stored procedures), rather than via direct access …

Removed p. 78

Personnel need to be aware of and following security policies and operational procedures for managing identification and authorization on a continuous basis.

Removed p. 79

Requirement 9: Restrict physical access to cardholder data Any physical access to data or systems that house cardholder data provides the opportunity for individuals to access devices or data and to remove systems or hardcopies, and should be appropriately restricted. For the purposes of Requirement 9, “onsite personnel” refers to full-time and part-time employees, temporary employees, contractors and consultants who are physically present on the entity’s premises. A “visitor” refers to a vendor, guest of any onsite personnel, service workers, or anyone who needs to enter the facility for a short duration, usually not more than one day. “Media” refers to all paper and electronic media containing cardholder data.

Removed p. 79

• Verify that access is controlled with badge readers or other devices including authorized badges and lock and key.

• Observe a system administrator’s attempt to log into consoles for randomly selected systems in the cardholder data environment and verify that they are “locked” to prevent unauthorized use.

Without physical access controls, such as badge systems and door controls, unauthorized persons could potentially gain access to the facility to steal, disable, disrupt, or destroy critical systems and cardholder data.

Removed p. 79

Note: “Sensitive areas” refers to any data center, server room or any area that houses systems that store, process, or transmit cardholder data. This excludes public-facing areas where only point-of- sale terminals are present, such as the cashier areas in a retail store.

When investigating physical breaches, these controls can help identify the individuals that physically accessed the sensitive areas, as well as when they entered and exited.

Criminals attempting to gain physical access to sensitive areas will often attempt 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, access control mechanisms could be monitored or have physical protections installed to prevent them being damaged or disabled by malicious individuals.

Modified p. 79 → 198

~~9.1.1.a Verify~~ that either video cameras or access control mechanisms (or both) are in place to monitor the ~~entry/exit points to sensitive areas.~~

9.2.1.1.a Observe locations where individual physical access to sensitive areas within the CDE occurs to verify that either video cameras or physical access control mechanisms (or both) are in place to monitor the entry and exit points.

Modified p. 79 → 198

~~(Continued on next page) 9.1.1.b Verify~~ that either video cameras or access control mechanisms (or both) are protected from tampering or disabling.

9.2.1.1.b Observe locations where individual physical access to sensitive areas within the CDE occurs to verify that either video cameras or physical access control mechanisms (or both) are protected from tampering or disabling.

Removed p. 80

Examples of sensitive areas include corporate database server rooms, back-office rooms at retail locations that store cardholder data, and storage areas for large quantities of cardholder data. Sensitive areas should be identified by each organization to ensure the appropriate physical monitoring controls are implemented.

For example, 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.

Restricting access to network jacks (or network ports) will prevent malicious individuals from plugging into readily available network jacks and gain access into internal network resources.

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

Removed p. 80

Without security over access to wireless components and devices, malicious users could use an organization’s unattended wireless devices to access network resources, or even connect their own devices to the wireless network to gain unauthorized access. Additionally, securing networking and communications hardware prevents malicious users from intercepting network traffic or physically connecting their own devices to wired network resources.

Modified p. 80 → 198

~~PCI DSS Requirements Testing Procedures Guidance 9.1.1.c Verify that~~ data from video cameras and/or access control mechanisms is ~~reviewed,~~ and ~~that data is stored for at least three months.~~

• Collected data from video cameras and/or physical access control mechanisms is reviewed and correlated with other entries.

Removed p. 81

PCI DSS Requirements Testing Procedures Guidance 9.2 Develop procedures to easily distinguish between onsite personnel and visitors, to include:

• Identifying onsite personnel and visitors (for example, assigning badges)

9.2.a Review documented processes to verify that procedures are defined for identifying and distinguishing between onsite personnel and visitors.

• Verify procedures include the following:

• Identifying onsite personnel and visitors (for example, assigning badges),

• Changing access requirements, and

• Revoking terminated onsite personnel and expired visitor identification (such as ID badges) Identifying authorized visitors so they are easily distinguished from onsite personnel prevents unauthorized visitors from being granted access to areas containing cardholder data.

9.2.b Examine identification methods (such as ID badges) and observe processes for identifying and distinguishing between onsite personnel and visitors to verify that:

• Visitors are clearly identified, and

• It is easy to distinguish between onsite personnel and visitors.

When personnel leave the organization, all physical access mechanisms should be returned or disabled promptly …

Modified p. 81 → 200

• ~~Changes~~ to access ~~requirements~~

• Managing changes to an individual’s physical access requirements.

Modified p. 81 → 200

• Revoking or terminating ~~onsite~~ personnel ~~and expired visitor identification (such as ID badges).~~

• Revoking or terminating personnel identification.

Modified p. 81 → 200

~~9.2.c Verify that~~ access to the identification process ~~(such as a badge system) is limited~~ to authorized personnel.

• Limiting access to the identification process or system to authorized personnel.

Modified p. 81 → 201

• Access must be authorized and based on individual job function.

• Access is revoked immediately upon termination, and all physical access mechanisms, such as keys, access cards, etc., are returned or ~~disabled.~~

• All physical access mechanisms, such as keys, access cards, etc., are returned or disabled upon termination.

Modified p. 81 → 201

~~9.3.a For a sample of onsite~~ personnel ~~with physical access to~~ sensitive ~~areas,~~ interview responsible ~~personnel~~ and ~~observe~~ access control lists to verify that:

9.3.1.1.a Observe personnel in sensitive areas within the CDE, interview responsible personnel, and examine physical access control lists to verify that:

Removed p. 82

PCI DSS Requirements Testing Procedures Guidance 9.4 Implement procedures to identify and authorize visitors.

Procedures should include the following:

Removed p. 82

Visitor controls are important to reduce the ability of unauthorized and malicious persons to gain access to facilities (and potentially, to cardholder data).

A visitor log documenting minimum information on the visitor is easy and inexpensive to maintain and will assist in identifying physical access to a building or room, and potential access to cardholder data.

Removed p. 82

9.4.2.a Observe people within the facility to verify the use of visitor badges or other identification, and that visitors are easily distinguishable from onsite personnel.

Removed p. 82

• The visitor’s name,

• The firm represented, and

9.4.4.c Verify that the log is retained for at least three months.

Modified p. 82 → 202

~~9.4.1.b~~ Observe the use of visitor badges or other identification to verify that ~~a physical token~~ badge does not permit unescorted access to ~~physical areas where cardholder data is processed or maintained.~~

9.3.2.c Observe the use of visitor badges or other identification to verify that the badge or other identification does not permit unescorted access to the CDE.

Modified p. 82 → 202

~~9.4.2.b Verify that visitor~~ badges or other identification ~~expire.~~

• Visitor badges or other identification are being used for all visitors.

Modified p. 82 → 203

~~Document~~ the ~~visitor’s name, the firm represented, and the onsite~~ personnel authorizing physical ~~access on the log.~~

• The name of the personnel authorizing physical access.

Modified p. 82 → 203

~~Retain this~~ log for ~~a minimum of~~ three months, unless otherwise restricted by law.

• Retaining the log for at least three months, unless otherwise restricted by law.

Modified p. 82 → 203

~~9.4.4.a Verify~~ that a visitor log is ~~in use~~ to record physical access to the facility ~~as well as computer rooms~~ and ~~data centers where cardholder data is stored or transmitted.~~

9.3.4.a Examine the visitor log and interview responsible personnel to verify that a visitor log is used to record physical access to the facility and sensitive areas.

Modified p. 82 → 203

~~9.4.4.b Verify~~ that the log contains:

9.3.4.b Examine the visitor log and verify that the log contains:

Modified p. 82 → 203

• The ~~onsite~~ personnel authorizing physical access.

• The personnel authorizing physical access.

Modified p. 82 → 208

~~9.4.1.a~~ Observe ~~procedures~~ and interview personnel to verify that ~~visitors must be authorized before they~~ are ~~granted access to, and escorted at all times within, areas where~~ cardholder data ~~is processed or maintained.~~

9.4.6.b Observe processes and interview personnel to verify that hard-copy materials are cross-cut shredded, incinerated, or pulped such that cardholder data cannot be reconstructed.

Removed p. 83

PCI DSS Requirements Testing Procedures Guidance 9.5 Physically secure all media. 9.5 Verify that procedures for protecting cardholder data include controls for physically securing all media (including but not limited to computers, removable electronic media, paper receipts, paper reports, and faxes).

Removed p. 83

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

Periodically reviewing the storage facility enables the organization to address identified security issues in a timely manner, minimizing the potential risk.

Removed p. 83

Procedures and processes help protect cardholder data on media distributed to internal and/or external users. Without such procedures data can be lost or stolen and used for fraudulent purposes.

Removed p. 83

It is important that media be identified such that its classification status can be easily discernible. Media not identified as confidential may not be adequately protected or may be lost or stolen.

Note: This does not mean the media needs to have a “Confidential” label attached; the intent is that the organization has identified media that contains sensitive data so it can protect it.

9.6.2.b Select a recent sample of several days of offsite tracking logs for all media, and verify tracking details are documented.

Modified p. 83 → 204

Controls for physically securing media are intended to prevent unauthorized persons from gaining access to cardholder data on any ~~type of~~ 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.

Defined Approach Requirements 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.

Modified p. 83 → 205

~~9.6.2.a~~ Interview personnel and examine records to verify that all media sent outside the facility is logged and sent via secured courier or other delivery method that can be tracked.

9.4.3.b Interview personnel and examine records to verify that all media sent outside the facility is logged and sent via secured courier or other delivery method that can be tracked.

Modified p. 83 → 205

Media may be lost or stolen if sent via a non- trackable method such as regular postal mail. ~~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.

Defined Approach Requirements Defined Approach Testing Procedures Purpose Media may be lost or stolen if sent via a non- trackable 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.

Removed p. 84

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

If media is not inventoried, stolen or lost media may not be noticed for a long time or at all. 9.7.1 Properly maintain inventory logs of all media and conduct media inventories at least annually.

Removed p. 84

• Hard-copy materials must be crosscut shredded, incinerated, or pulped such that there is reasonable assurance the hard- copy materials cannot be reconstructed.

• Storage containers used for materials that are to be destroyed must be secured.

• Cardholder data on electronic media must be rendered unrecoverable (e.g., via a secure wipe program in accordance with industry-accepted standards for secure deletion, or by physically destroying the media).

If steps are not taken to destroy information contained on hard disks, portable drives, CD/DVDs, or paper prior to disposal, malicious individuals may be able to 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.

Securing storage containers used for materials that are going to be destroyed prevents sensitive information from being captured while the …

Modified p. 84 → 208

~~9.8.1.a Interview personnel and examine procedures to verify that hard-copy materials~~ are ~~crosscut~~ shredded, incinerated, or pulped ~~such~~ that ~~there is reasonable assurance the hard-copy materials~~ cannot be reconstructed.

• Materials are cross-cut shredded, incinerated, or pulped so that cardholder data cannot be reconstructed.

Modified p. 84 → 208

~~9.8.1.b Examine~~ storage containers used for materials that contain information to be destroyed to verify that the containers are ~~secured.~~

9.4.6.c Observe storage containers used for materials that contain information to be destroyed to verify that the containers are secure. Customized Approach Objective Cardholder data cannot be recovered from media that has been destroyed or which is pending destruction.

Removed p. 85

Note: These requirements apply to card- reading devices used in card-present transactions (that is, card swipe or dip) at the point of sale. This requirement is not intended to apply to manual key-entry components such as computer keyboards and POS keypads.

Criminals attempt to steal cardholder data by stealing and/or manipulating card-reading devices and terminals. For example, they 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 information every time a card is entered. Criminals will also try to add “skimming” components to the outside of devices, which are designed to capture payment card details before they even enter the device•for example, by attaching an additional card reader on top of the legitimate card reader so that the payment card details are captured twice: once by the criminal’s component and …

Modified p. 85 → 210

• Maintaining a list of ~~devices~~

• Maintaining a list of POI devices.

Modified p. 85 → 210

• Periodically inspecting devices to look for tampering or ~~substitution~~

• Periodically inspecting POI devices to look for tampering or unauthorized substitution.

Modified p. 85 → 210

• Training personnel to be aware of suspicious behavior and to report tampering or substitution of devices.

• Training personnel to be aware of suspicious behavior and to report tampering or unauthorized substitution of devices.

Modified p. 85 → 211

• ~~Make,~~ model of ~~device~~

• Make and model of the device.

Modified p. 85 → 211

• Device serial number or other ~~method~~ of unique identification.

• Device serial number or other methods of unique identification.

Modified p. 85 → 211

~~9.9.1.a~~ Examine the list of devices to verify it ~~includes:~~

9.5.1.1.a Examine the list of POI devices to verify it includes all elements specified in this requirement.

Modified p. 85 → 211

• ~~Make, model~~ of ~~device~~

• Location of device.

Modified p. 85 → 211

~~9.9.1.b Select a sample of devices from the list and observe~~ devices and device locations to verify that the list is accurate and up to date.

9.5.1.1.b Observe POI devices and device locations and compare to devices in the list to verify that the list is accurate and up to date.

Modified p. 85 → 211

~~9.9.1.c~~ Interview personnel to verify the list of devices is updated when devices are added, relocated, decommissioned, etc.

9.5.1.1.c Interview personnel to verify the list of POI devices is updated when devices are added, relocated, decommissioned, etc. Customized Approach Objective The identity and location of POI devices is recorded and known at all times.

Removed p. 86

PCI DSS Requirements Testing Procedures Guidance 9.9.2 Periodically inspect device surfaces to detect tampering (for example, addition of card skimmers to devices), or substitution (for example, by checking the serial number or other device characteristics to verify it has not been swapped with a fraudulent device).

Note: Examples of signs that a device might have been tampered with or substituted include unexpected attachments or cables plugged into the device, missing or changed security labels, broken or differently colored casing, or changes to the serial number or other external markings.

• Procedures for inspecting devices

• Frequency of inspections.

Regular inspections of devices will help organizations to more quickly detect tampering or replacement of a device, and thereby minimize the potential impact of using fraudulent devices.

The type of inspection will depend on the device• for example, photographs of devices that are known to be secure can be used to compare a device’s current appearance with …

Modified p. 86 → 206

~~9.9.2.a~~ Examine ~~documented procedures~~ to verify ~~processes~~ are defined to ~~include the following:~~

9.4.5.a Examine documentation to verify that procedures are defined to maintain electronic media inventory logs.

Modified p. 86 → 212

~~9.9.2.b~~ Interview responsible personnel and observe inspection processes to verify:

9.5.1.2.b Interview responsible personnel and observe inspection processes to verify:

Modified p. 86 → 212

• All devices are periodically inspected for evidence of tampering and substitution.

• All devices are periodically inspected for evidence of tampering and unauthorized substitution.

Removed p. 87

PCI DSS Requirements Testing Procedures Guidance 9.9.3 Provide training for personnel to be aware of attempted tampering or replacement of devices. Training should include the following:

• Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices

• Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices

• Not to install, replace, or return devices without verification

• Not to install, replace, or return devices without verification

• Being aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices)

• Being aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices)

• Reporting suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer).

• Reporting …

Removed p. 87

Personnel need to be aware of and following security policies and operational procedures for restricting physical access to cardholder data and CDE systems on a continuous basis.

Modified p. 87 → 214

• ~~Verify~~ the identity of any third-party persons claiming to be repair or maintenance personnel, ~~prior to~~ granting them access to modify or troubleshoot devices.

• Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, before granting them access to modify or troubleshoot devices.

Modified p. 87 → 214

• Do not ~~install, replace,~~ or ~~return devices~~ without verification.

• Procedures to ensure devices are not installed, replaced, or returned without verification.

Modified p. 87 → 214

• Be aware of suspicious behavior around ~~devices (for example, attempts by unknown persons to unplug or open devices).~~

• Being aware of suspicious behavior around devices.

Modified p. 87 → 214

• ~~Report~~ suspicious behavior and indications of device tampering or substitution to appropriate ~~personnel (for example, to a manager or security officer).~~

• Reporting suspicious behavior and indications of device tampering or substitution to appropriate personnel.

Modified p. 87 → 214

~~9.9.3.a~~ Review training materials for personnel ~~at point-of-sale locations~~ to verify they include ~~training~~ in ~~the following:~~

9.5.1.3.a Review training materials for personnel in POI environments to verify they include all elements specified in this requirement.

Modified p. 87 → 214

~~9.9.3.b~~ Interview ~~a sample of~~ personnel ~~at point-of-sale locations~~ to verify they have received training and ~~are aware of~~ the procedures for ~~the following:~~

9.5.1.3.b Interview personnel in POI environments to verify they have received training and know the procedures for all elements specified in this requirement.

Removed p. 88

Requirement 10: Track and monitor all access to network resources and cardholder data Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system activity logs.

PCI DSS Requirements Testing Procedures Guidance 10.1 Implement audit trails to link all access to system components to each individual user.

Removed p. 88

• Access to system components is linked to individual users.

It is critical to have a process or system that links user access to system components accessed. This system generates audit logs and provides the ability to trace back suspicious activity to a specific user.

Removed p. 88

Generating audit trails of suspect activities alerts the system administrator, sends data to other monitoring mechanisms (like intrusion detection systems), and provides a history trail for post- incident follow-up. Logging of the following events enables an organization to identify and trace potentially malicious activities 10.2.1 All individual user accesses to cardholder data 10.2.1 Verify all individual access to cardholder data is logged. Malicious individuals could obtain knowledge of a user account with access to systems in the CDE, or they could create a new, unauthorized account in order to access cardholder data. A record of all individual accesses to cardholder data can identify which accounts may have been compromised or misused.

Removed p. 88

Accounts with increased privileges, such as the “administrator” or “root” account, have the potential to greatly impact the security or operational functionality of a system. Without a log of the activities performed, an organization is unable to trace any issues resulting from an administrative mistake or misuse of privilege back to the specific action and individual.

Removed p. 89

PCI DSS Requirements Testing Procedures Guidance 10.2.3 Access to all audit trails 10.2.3 Verify access to all audit trails is logged. Malicious users often attempt to alter audit logs to hide their actions, and a record of access allows an organization to trace any inconsistencies or potential tampering of the logs to an individual account. Having access to logs identifying changes, additions, and deletions can help retrace steps made by unauthorized personnel.

Removed p. 89

Without knowing who was logged on at the time of an incident, it is impossible to identify the accounts that may have been used. Additionally, malicious users may attempt to manipulate the authentication controls with the intent of bypassing them or impersonating a valid account.

Modified p. 89 → 221

~~10.2.5.b Verify all elevation~~ of ~~privileges is logged.~~

• Elevation of privileges.

Modified p. 89 → 221

~~10.2.5.c Verify all~~ changes, additions, or deletions to ~~any account~~ with ~~root or~~ administrative ~~privileges are logged.~~

• All changes, additions, or deletions to accounts with administrative access.

Modified p. 89 → 221

• ~~Initialization~~ of audit ~~logs~~

• All initialization of new audit logs, and

Modified p. 89 → 221

• ~~Stopping~~ or pausing of audit logs.

• All starting, stopping, or pausing of the existing audit logs.

Modified p. 89 → 221

Turning ~~the~~ audit logs ~~off (or pausing them) prior to~~ performing illicit activities is a common practice for malicious users ~~wishing~~ to avoid detection. Initialization of audit logs could indicate that the log function ~~was disabled by a user~~ to hide their actions.

Defined Approach Requirements 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.

Modified p. 89 → 221

Malicious software, such as malware, often creates or replaces ~~system level~~ objects on the target system ~~in order~~ to control a particular function or operation on that system. By logging when system-level ~~objects, such as database tables or stored procedures,~~ are created or deleted, it will be easier to determine whether such modifications were authorized.

Defined Approach Requirements 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.

Removed p. 90

PCI DSS Requirements Testing Procedures Guidance 10.3 Record at least the following audit trail entries for all system components for each event:

Removed p. 90

By recording these details for the auditable events at 10.2, a potential compromise can be quickly identified, and with sufficient detail to know who, what, where, when, and how. 10.3.1 User identification 10.3.1 Verify user identification is included in log entries.

Removed p. 90

Note: One example of time synchronization technology is Network Time Protocol (NTP).

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 event (crucial for forensic analysis in the event of a breach). For post-incident forensics teams, the accuracy and consistency of time across all systems and the time of each activity is critical in determining how the systems were compromised. 10.4.1 Critical systems have the correct and consistent time.

10.4.1.a Examine the process for acquiring, distributing and storing the correct time within the organization to verify that:

Modified p. 90 → 231

• Only the designated central time server(s) receives time ~~signals~~ from external ~~sources, and time signals from external sources are based on International Atomic Time or UTC.~~

• Only the designated central time server(s) receives time from external sources.

Modified p. 90 → 231

• Where there is more than one designated time server, the time servers peer with one another to keep accurate ~~time,~~

• Where there is more than one designated time server, the time servers peer with one another to keep accurate time.

Modified p. 90 → 231

• ~~Systems~~ receive time information only from designated central time server(s).

• Internal systems receive time information only from designated central time server(s).

Removed p. 91

PCI DSS Requirements Testing Procedures Guidance 10.4.1.b Observe the time-related system-parameter settings for a sample of system components to verify:

• Where there is more than one designated time server, the designated central time server(s) peer with one another to keep accurate time.

Removed p. 91

Often a malicious individual who has entered the network will attempt to edit the audit logs in order 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.

Modified p. 91 → 231

• ~~Only the designated central time server(s) receives time signals from external sources, and time signals~~ from external sources ~~are~~ based on International Atomic Time or ~~UTC.~~

• Time received from external sources is based on International Atomic Time or Coordinated Universal Time (UTC).

Modified p. 91 → 231

• ~~Systems receive~~ time ~~only from designated central time server(s).~~

• One or more designated time servers are in use.

Modified p. 91 → 231

~~10.4.2.b Examine system configurations, time synchronization settings and logs, and processes to verify that any~~ changes to time settings on critical systems are logged, monitored, and reviewed.

• Any changes to time settings on critical systems are logged, monitored, and reviewed.

Removed p. 92

PCI DSS Requirements Testing Procedures Guidance 10.5.1 Limit viewing of audit trails to those with a job-related need.

Removed p. 92

Adequate protection of the audit logs includes strong access control (limit access to logs based on “need to know” only), and use of physical or network segregation to make the logs harder to find and modify.

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.

Removed p. 92

By writing logs from external-facing technologies such as wireless, firewalls, DNS, and mail servers, the risk of those logs being lost or altered is lowered, as they are more secure within the internal network.

Logs may be written directly, or offloaded or copied from external systems, to the secure internal system or media.

File-integrity monitoring or change-detection systems check for changes to critical files, and notify when such changes are noted. For file- integrity monitoring purposes, an entity usually monitors files that don’t regularly change, but when changed indicate a possible compromise.

Removed p. 92

Note: Log harvesting, parsing, and alerting tools may be used to meet this Requirement.

Removed p. 92

The log review process does not have to be manual. The use of log harvesting, parsing, and alerting tools can help facilitate the process by identifying log events that need to be reviewed.

Removed p. 93

PCI DSS Requirements Testing Procedures Guidance 10.6.1 Review the following at least daily:

• Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.) Checking logs daily minimizes the amount of time and exposure of a potential breach.

• Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.).

Removed p. 93

Logs for all other system components should also be periodically reviewed to identify indications of potential issues or attempts to gain access to sensitive systems via less-sensitive systems. The frequency of the reviews should be determined by an entity’s annual risk assessment. 10.6.2.b Examine the organization’s risk-assessment documentation and interview personnel to verify that reviews are performed in accordance with organization’s policies and risk management strategy.

If exceptions and anomalies identified during the log-review process are not investigated, the entity may be unaware of unauthorized and potentially malicious activities that are occurring within their own network. 10.6.3.b Observe processes and interview personnel to verify that follow-up to exceptions and anomalies is performed.

Modified p. 93 → 225

• All security ~~events~~

• All security events.

Modified p. 93 → 225

• Logs of all system components that store, process, or transmit CHD and/or ~~SAD~~

• Logs of all system components that store, process, or transmit CHD and/or SAD.

Modified p. 93 → 225

• Logs of all critical system ~~components~~

• Logs of all critical system components.

Modified p. 93 → 225

• Logs of all servers and system components that perform security functions (for example, ~~firewalls,~~ intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication ~~servers, e-commerce redirection servers, etc.).~~

• Logs of all servers and system components that perform security functions (for example, network security controls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers).

Modified p. 93 → 225

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. ~~Note that 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 …

Defined Approach Requirements 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 …

Modified p. 93 → 225

~~10.6.2.a~~ Examine security policies and procedures to verify that ~~procedures~~ are defined for reviewing ~~logs of~~ all other system components periodically

•either manually or via log tools

•based on the organization’s policies and risk management strategy.

10.4.1.a Examine security policies and procedures to verify that processes are defined for reviewing all elements specified in this requirement at least once daily.

Modified p. 93 → 226

~~10.6.1.a~~ Examine security policies and procedures to verify that ~~procedures~~ are defined for reviewing ~~the following at least daily, either manually or via log tools:~~

10.4.2.a Examine security policies and procedures to verify that processes are defined for reviewing logs of all other system components periodically.

Modified p. 93 → 228

~~10.6.3.a~~ Examine security policies and procedures to verify that ~~procedures~~ are defined for ~~following up on~~ exceptions and anomalies identified during the review process.

10.4.3.a Examine security policies and procedures to verify that processes are defined for addressing exceptions and anomalies identified during the review process.

Modified p. 93 → 232

• ~~All~~ security ~~events~~

• Network security controls.

Modified p. 93 → 244

~~10.6.1.b Observe processes~~ and interview personnel to verify that ~~the following~~ are ~~reviewed at least daily:~~

11.3.1.2.b Examine scan report results and interview personnel to verify that authenticated scans are performed.

Modified p. 93 → 295

• ~~Logs~~ of all critical system ~~components~~

• Coverage and responses of all critical system components.

Modified p. 93 → 328

• ~~All~~ security ~~events~~

• Network security controls

Removed p. 94

Retaining logs for at least a year allows for the fact that it often takes a while to notice that a compromise has occurred or is occurring, and allows investigators sufficient log history to better determine the length of time of a potential breach and potential system(s) impacted. By having three months of logs immediately available, an entity can quickly identify and minimize impact of a data breach. Storing logs in off-line locations could prevent them from being readily available, resulting in longer time frames to restore log data, perform analysis, and identify impacted systems or data.

Removed p. 94

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 systems and steal sensitive data from the cardholder data environment.

The specific types of failures may vary depending on the function of the device and technology in use. Typical failures include a system ceasing to perform its security function or not functioning in its intended manner; for example, a firewall erasing all its rules or going offline.

Modified p. 94 → 229

~~PCI DSS Requirements Testing~~ Procedures ~~Guidance 10.7 Retain~~ audit ~~trail~~ history for at least ~~one year,~~ with ~~a minimum of~~ three months immediately available ~~for analysis (for example, online, archived, or restorable from backup).~~

• Procedures for retaining audit log history for at least 12 months, with at least the most recent three months immediately available online.

Modified p. 94 → 229

~~10.7.a~~ Examine ~~security policies and procedures~~ to verify that ~~they define~~ the ~~following:~~

10.5.1.a Examine documentation to verify that the following is defined:

Modified p. 94 → 229

• Audit log retention ~~policies~~

• Audit log retention policies.

Modified p. 94 → 229

~~10.7.b Interview~~ personnel and examine audit logs to verify that audit logs ~~are~~ retained for at least ~~one year.~~

10.5.1.b Examine configurations of audit log history, interview personnel and examine audit logs to verify that audit logs history is retained for at least 12 months.

Modified p. 94 → 229

~~10.7.c~~ Interview personnel and observe processes to verify that at least the ~~last~~ three months’ ~~logs are~~ immediately available for analysis.

10.5.1.c Interview personnel and observe processes to verify that at least the most recent three months’ audit log history is 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.

Modified p. 94 → 232

• Physical access ~~controls~~

• Physical access controls.

Modified p. 94 → 232

• Logical access ~~controls~~

• Logical access controls.

Modified p. 94 → 232

• Audit logging ~~mechanisms~~

• Audit logging mechanisms.

Modified p. 94 → 288

~~• Segmentation controls (if used) 10.8.a~~ Examine ~~documented~~ policies and procedures to verify that processes are defined for ~~the timely detection and reporting of failures of critical security control systems,~~ including ~~but not limited~~ to ~~failure of:~~

12.8.3.a Examine policies and procedures to verify that processes are defined for engaging TPSPs, including proper due diligence prior to engagement.

Modified p. 94 → 328

~~10.8.b~~ Examine detection and alerting ~~processes~~ and interview personnel to verify that processes are implemented for all critical security ~~controls,~~ and that failure of a critical security control results in the generation of an alert.

A3.3.1.b Examine detection and alerting processes, and interview personnel to verify that processes are implemented for all critical security controls specified in this requirement and that each failure of a critical security control results in the generation of an alert.

Removed p. 95

If critical security control failures alerts are not quickly and effectively responded to, attackers may use this time to insert malicious software, gain control of a system, or steal data from the entity’s environment.

Documented evidence (e.g., records within a problem management system) should 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.

Removed p. 95

Personnel need to be aware of and following security policies and daily operational procedures for monitoring all access to network resources and cardholder data on a continuous basis.

Modified p. 95 → 329

~~PCI DSS Requirements Testing Procedures Guidance 10.8.1 Additional requirement for service providers only: Respond to failures~~ of any critical security ~~controls in a timely manner.~~ Processes for responding to failures in security ~~controls must~~ include:

A3.3.1.2 Failures of any critical security control systems are responded to promptly. Processes for responding to failures in security control systems include:

Modified p. 95 → 329

• Restoring security ~~functions~~

• Restoring security functions.

Modified p. 95 → 329

• Identifying and documenting the duration (date and time start to end) of the security ~~failure~~

• Identifying and documenting the duration (date and time from start to end) of the security failure.

Modified p. 95 → 329

• Identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to address root ~~cause~~

• Identifying and documenting the cause(s) of failure, including root cause, and documenting remediation required to address the root cause.

Modified p. 95 → 329

• Identifying and addressing any security issues that arose during the ~~failure~~

• Identifying and addressing any security issues that arose during the failure.

Modified p. 95 → 329

• ~~Performing a risk assessment to determine~~ whether further actions are required as a result of the security ~~failure~~

• Determining whether further actions are required as a result of the security failure.

Modified p. 95 → 329

• Implementing controls to prevent cause of failure from ~~reoccurring~~

• Implementing controls to prevent the cause of failure from reoccurring.

Modified p. 95 → 329

• Resuming monitoring of security ~~controls 10.8.1.a~~ Examine documented policies and procedures and interview personnel to verify processes are defined and implemented to respond to a security control ~~failure, and include:~~

• Resuming monitoring of security controls. PCI DSS Reference: Requirements 1-12 A3.3.1.2.a Examine documented policies and procedures and interview personnel to verify processes are defined and implemented to respond promptly to a security control failure in accordance with all elements specified in this requirement.

Modified p. 95 → 329

• ~~Identifying and documenting the duration~~ (date and time start to end) of the security ~~failure~~

• Duration (date and time start and end) of the security failure.

Modified p. 95 → 329

• ~~Identifying and documenting~~ cause(s) of failure, including root ~~cause, and documenting remediation required to address root cause~~

• Identification of cause(s) of the failure, including root cause.

Modified p. 95 → 329

~~10.8.1.b~~ Examine records to verify that security control failures are documented to include:

A3.3.1.2.b Examine records to verify that security control failures are documented to include:

Modified p. 95 → 329

• Details of the remediation required to address the root ~~cause 10.9 Ensure that security policies and operational procedures for monitoring all access to network resources and cardholder data are documented, in use, and known to all affected parties.~~

• Details of the remediation required to address the root cause.

Removed p. 96

Requirement 11: Regularly test security systems and processes.

Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and custom software should be tested frequently to ensure security controls continue to reflect a changing environment.

PCI DSS Requirements Testing Procedures Guidance 11.1 Implement processes to test for the presence of wireless access points (802.11), and detect and identify all authorized and unauthorized wireless access points on a quarterly basis.

Note: Methods that may be used in the process 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.

Whichever methods are used, they must be sufficient to detect and identify both authorized and unauthorized devices.

11.1.a Examine policies and procedures to verify processes are defined for detection and identification of both authorized and unauthorized wireless access points on a quarterly basis.

Implementation and/or exploitation …

Removed p. 97

For example: In the case of a single standalone retail kiosk in a shopping mall, where all communication components are contained within tamper-resistant and tamper-evident casings, performing a detailed physical inspection of the kiosk itself 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 is difficult. In this case, multiple methods may be combined to meet the requirement, such as performing physical system inspections in conjunction with the results of a wireless analyzer.

Removed p. 97

11.1.2.a Examine the organization’s incident response plan (Requirement 12.10) to verify it defines and requires a response in the event that an unauthorized wireless access point is detected.

11.1.2.b Interview responsible personnel and/or inspect recent wireless scans and related responses to verify action is taken when unauthorized wireless access points are found.

PCI DSS Requirements Testing Procedures Guidance 11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).

Note: Multiple scan reports can be combined for the quarterly scan process to show that all systems were scanned and all applicable vulnerabilities have been addressed. Additional documentation may be required to verify non-remediated vulnerabilities are in the process of being addressed.

For initial PCI DSS compliance, it is not required that four quarters of passing scans be completed if the assessor …

Removed p. 98

A vulnerability scan is a combination of automated or manual tools, techniques, and/or methods run against external and internal network devices and servers, designed to expose potential vulnerabilities that could be found and exploited by malicious individuals.

There are three types of vulnerability scanning required for PCI DSS:

• Internal quarterly vulnerability scanning by qualified personnel (use of a PCI SSC Approved Scanning Vendor (ASV) is not required)

• External quarterly vulnerability scanning, which must be performed by an ASV

• Internal and external scanning as needed after significant changes Once these weaknesses are identified, the entity corrects them and repeats the scan until all vulnerabilities have been corrected.

Identifying and addressing vulnerabilities in a timely manner reduces the likelihood of a vulnerability being exploited and potential compromise of a system component or cardholder data.

Removed p. 98

11.2.1.a Review the scan reports and verify that four quarterly internal scans occurred in the most recent 12- month period.

An established process for identifying vulnerabilities on internal systems requires that vulnerability scans be conducted quarterly. Vulnerabilities posing the greatest risk to the environment (for example, ranked “High” per Requirement 6.1) should be resolved with the highest priority.

(Continued on next page) 11.2.1.b Review the scan reports and verify that all “high risk” vulnerabilities are addressed and the scan process includes rescans to verify that the “high risk” vulnerabilities (as defined in PCI DSS Requirement 6.1) are resolved.

PCI DSS Requirements Testing Procedures Guidance 11.2.1.c Interview personnel to verify that the scan was performed by a qualified internal resource(s) or qualified external third party and, if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).

Internal vulnerability scans can be performed by qualified, internal staff that are reasonably …

Removed p. 99

Note: Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV), approved by the Payment Card Industry Security Standards Council (PCI SSC).

11.2.2.a Review output from the four most recent quarters of external vulnerability scans and verify that four quarterly external vulnerability scans occurred in the most recent 12- month period.

As external networks are at greater risk of compromise, quarterly external vulnerability scanning must be performed by a PCI SSC Approved Scanning Vendor (ASV).

A robust scanning program ensures that scans are performed and vulnerabilities addressed in a timely manner. 11.2.2.b Review the results of each quarterly scan and rescan to verify that the ASV Program Guide requirements for a passing scan have been met (for example, no vulnerabilities rated 4.0 or higher by the CVSS, and no automatic failures).

11.2.2.c Review the scan reports to verify that the scans were completed by a PCI SSC Approved Scanning Vendor (ASV).

Removed p. 99

11.2.3.a Inspect and correlate change control documentation and scan reports to verify that system components subject to any significant change were scanned.

The determination of what constitutes a significant change is highly dependent on the configuration of a given environment. If an upgrade or modification could allow access to cardholder data or affect the security of the cardholder data environment, then it could be considered significant.

Scanning an environment after any significant changes are made ensures that changes were completed appropriately such that the security of the environment was not compromised as a result of the change. All system components affected by the change will need to be scanned.

11.2.3.b Review scan reports and verify that the scan process includes rescans until:

• For external scans, no vulnerabilities exist that are scored 4.0 or higher by the CVSS.

• For internal scans, all “high risk” vulnerabilities as defined in PCI DSS Requirement 6.1 are resolved.

PCI …

Removed p. 100

• Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115)

• Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115)

• Includes coverage for the entire CDE perimeter and critical systems

• Includes coverage for the entire CDE perimeter and critical systems

• Includes testing from both inside and outside the network

• Includes testing to validate any segmentation and scope-reduction controls

• Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5

• Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5

• Defines network-layer penetration tests to include components that support network functions as well as operating systems

• Defines network-layer penetration tests to include components that support network functions as well as operating systems

• Includes review and consideration of threats and vulnerabilities experienced in the last 12 months

• Includes review and consideration of threats and vulnerabilities experienced in the last 12 …

Removed p. 100

• Includes testing to validate any segmentation and scope- reduction controls

The intent of a penetration test is to simulate a real-world attack situation with a goal of identifying how far an attacker would be able to penetrate into an environment. This allows an entity to gain a better understanding of their 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 may include exploiting identified vulnerabilities. Conducting a vulnerability scan may be one of the first steps a penetration tester will perform in order to plan the testing strategy, although it is not the only step. 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 generally a highly manual process. While some automated tools may …

Removed p. 101

11.3.2.a Examine the scope of work and results from the most recent internal penetration test to verify that penetration testing is performed as follows.

Removed p. 102

PCI DSS Requirements Testing Procedures Guidance 11.3.4 If segmentation is used to isolate the CDE from other networks, perform penetration tests at least annually and after any changes to segmentation controls/methods to verify that the segmentation methods are operational and effective, and isolate all out-of-scope systems from systems in the CDE.

11.3.4.a Examine segmentation controls and review penetration-testing methodology to verify that penetration- testing procedures are defined to test all segmentation methods to confirm they are operational and effective, and isolate all out-of-scope systems from systems in the CDE.

Penetration testing is an important tool to confirm that any segmentation in place to isolate the CDE from other networks is effective. The penetration testing should focus on the segmentation controls, both from outside the entity’s network and from inside the network but outside of the CDE, to confirm that they are not able to get through the segmentation controls to access the …

Removed p. 102

11.3.4.c Verify that the test was performed by a qualified internal resource or qualified external third party and, if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).

Removed p. 102

11.3.4.1.a Examine the results from the most recent penetration test to verify that:

• Penetration testing is performed to verify segmentation controls at least every six months and after any changes to segmentation controls/methods.

For service providers, validation of PCI DSS scope should be performed as frequently as possible to ensure PCI DSS scope remains up to date and aligned with changing business objectives.

PCI DSS Requirements Testing Procedures Guidance 11.3.4.1.b Verify that the test was performed by a qualified internal resource or qualified external third party and, if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).

Removed p. 103

Keep all intrusion-detection and prevention engines, baselines, and signatures up to date.

11.4.a Examine system configurations and network diagrams to verify that techniques (such as intrusion-detection systems and/or intrusion-prevention systems) are in place to monitor all traffic:

• At the perimeter of the cardholder data environment

• At critical points in the cardholder data environment.

Intrusion detection and/or intrusion prevention techniques (such as IDS/IPS) compare the traffic coming into the network with known “signatures” and/or behaviors of thousands of compromise types (hacker tools, Trojans, and other malware), and send alerts and/or stop the attempt as it happens. Without a proactive approach to unauthorized activity detection, attacks on (or misuse of) computer resources could go unnoticed in real time. Security alerts generated by these techniques should be monitored so that the attempted intrusions can be stopped.

11.4.b Examine system configurations and interview responsible personnel to confirm intrusion-detection and/or intrusion-prevention techniques alert personnel of suspected compromises.

11.4.c Examine …

Removed p. 103

(Continued on next page) 11.5.a Verify the use of a change-detection mechanism by observing system settings and monitored files, as well as reviewing results from monitoring activities.

Examples of files that should be monitored:

• Centrally stored, historical or archived, log and audit files

Change-detection solutions such as file-integrity monitoring (FIM) tools check for changes, additions, and deletions to critical files, and notify when such changes are detected. If not implemented properly and the output of the change-detection solution monitored, a malicious individual could add, remove, or alter configuration file contents, operating system programs, or application executables. Unauthorized changes, if undetected, could render existing security controls ineffective and/or result in cardholder data being stolen with no perceptible impact to normal processing.

PCI DSS Requirements Testing Procedures Guidance

Note: For change-detection purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. …

Removed p. 104

Personnel need to be aware of and following security policies and operational procedures for security monitoring and testing on a continuous basis.

Removed p. 105

Requirement 12: Maintain a policy that addresses information security for all personnel.

A strong security policy sets the security tone for the whole entity and informs personnel what is expected of them. All personnel should be aware of the sensitivity of data and their responsibilities for protecting it. For the purposes of Requirement 12, “personnel” refers to full-time and part-time employees, temporary employees, contractors and consultants who are “resident” on the entity’s site or otherwise have access to the cardholder data environment.

PCI DSS Requirements Testing Procedures Guidance 12.1 Establish, publish, maintain, and disseminate a security policy.

Removed p. 105

A company's information security policy creates the roadmap for implementing security measures to protect its most valuable assets. All personnel should be aware of the sensitivity of data and their responsibilities for protecting it.

Removed p. 105

Security threats and protection methods evolve rapidly. Without updating the security policy to reflect relevant changes, new protection measures to fight against these threats are not addressed.

Removed p. 105

• Is performed at least annually and upon significant changes to the environment (for example, acquisition, merger, relocation, etc.),

• Identifies critical assets, threats, and vulnerabilities, and

• Results in a formal, documented analysis of risk.

Examples of risk-assessment methodologies include but are not limited to OCTAVE, ISO 27005 and NIST SP 800-30.

12.2.a Verify that an annual risk-assessment process is documented that:

• Identifies critical assets, threats, and vulnerabilities

• Results in a formal, documented analysis of risk A risk assessment enables an organization to identify threats and associated vulnerabilities with the potential to negatively impact their business. Examples of different risk considerations include cybercrime, web attacks, and POS malware. Resources can then be effectively allocated to implement controls that reduce the likelihood and/or the potential impact of the threat being realized.

Performing risk assessments at least annually and upon significant changes allows the organization to keep up to date with organizational changes and evolving threats, …

Removed p. 106

Personnel usage policies can either prohibit use of certain devices and other technologies if that is company policy, or provide guidance for personnel as to correct usage and implementation. If usage policies are not in place, personnel may use the technologies in violation of company policy, thereby allowing malicious individuals to gain access to critical systems and cardholder data.

Removed p. 106

Without requiring proper approval for implementation of these technologies, individual personnel may innocently implement a solution to a perceived business need, but also open a huge hole that subjects critical systems and data to malicious individuals.

Removed p. 106

If technology is implemented without proper authentication (user IDs and passwords, tokens, VPNs, etc.), malicious individuals may easily use this unprotected technology to access critical systems and cardholder data.

Removed p. 106

• A list of all critical devices, and

• A list of personnel authorized to use the devices.

Malicious individuals may breach physical security and place their own devices on the network as a “back door.” Personnel may also bypass procedures and install devices. An accurate inventory with proper device labeling allows for quick identification of non-approved installations.

PCI DSS Requirements Testing Procedures Guidance 12.3.4 A method to accurately and readily determine owner, contact information, and purpose (for example, labeling, coding, and/or inventorying of devices) 12.3.4 Verify that the usage policies define a method to accurately and readily determine owner, contact information, and purpose (for example, labeling, coding, and/or inventorying of devices).

Malicious individuals may breach physical security and place their own devices on the network as a “back door.” Personnel may also bypass procedures and install devices. An accurate inventory with proper device labeling allows for quick identification of non-approved installations. Consider establishing …

Removed p. 107

By defining acceptable business use and location of company-approved devices and technology, the company is better able to manage and control gaps in configurations and operational controls, to ensure a “back door” is not opened for a malicious individual to gain access to critical systems and cardholder data.

Removed p. 107

Remote-access technologies are frequent "back doors" to critical resources and cardholder data. By disconnecting remote-access technologies when not in use (for example, those used to support your systems by your POS vendor, other vendors, or business partners), access and risk to networks is minimized.

12.3.8.b Examine configurations for remote access technologies to verify that remote access sessions will be automatically disconnected after a specific period of inactivity.

Removed p. 108

PCI DSS Requirements Testing Procedures Guidance 12.3.10 For personnel accessing cardholder data via remote-access technologies, prohibit the copying, moving, and storage of cardholder data onto local hard drives and removable electronic media, unless explicitly authorized for a defined business need.

Where there is an authorized business need, the usage policies must require the data be protected in accordance with all applicable PCI DSS Requirements.

12.3.10.a Verify that the usage policies prohibit copying, moving, or storing of cardholder data onto local hard drives and removable electronic media when accessing such data via remote-access technologies.

To ensure all personnel are aware of their responsibilities to not store or copy cardholder data onto their local personal computers or other media, your policy should clearly prohibit such activities except for personnel that have been explicitly authorized to do so. Storing or copying cardholder data onto a local hard drive or other media must be in accordance with …

Removed p. 108

12.4.a Verify that information security policies clearly define information security responsibilities for all personnel.

Without clearly defined security roles and responsibilities assigned, there could be inconsistent interaction with the security group, leading to unsecured implementation of technologies or use of outdated or unsecured technologies.

12.4.b Interview a sample of responsible personnel to verify they understand the security policies.

Removed p. 108

• Defining a charter for a PCI DSS compliance program and communication to executive management 12.4.1.a Examine documentation to verify executive management has assigned overall accountability for maintaining the entity’s PCI DSS compliance.

Executive management assignment of PCI DSS compliance responsibilities ensures executive- level visibility into the PCI DSS compliance program and allows for the opportunity to ask appropriate questions to determine the effectiveness of the program and influence strategic priorities. Overall responsibility for the PCI DSS compliance program may be assigned to individual roles and/or to business units within the organization.

Executive management may include C-level positions, board of directors, or equivalent. The specific titles will depend on the particular organizational structure. The level of detail provided to executive management should be appropriate for the particular organization and the intended audience.

12.4.1.b Examine the company’s PCI DSS charter to verify it outlines the conditions under which the PCI DSS compliance program is …

Removed p. 109

• The formal assignment of information security to a Chief Security Officer or other security-knowledgeable member of management.

• The following information security responsibilities are specifically and formally assigned:

Each person or team with responsibilities for information security management should be clearly aware of their responsibilities and related tasks, through specific policy. Without this accountability, gaps in processes may open access into critical resources or cardholder data.

Entities should also consider transition and/or succession plans for key personnel to avoid potential gaps in security assignments, which could result in responsibilities not being assigned and therefore not performed.

Removed p. 109

12.6.a Review the security awareness program to verify it provides awareness to all personnel about the cardholder data security policy and procedures .

If personnel are not educated about their security responsibilities, security safeguards and processes that have been implemented may become ineffective through errors or intentional actions. 12.6.b Examine security awareness program procedures and documentation and perform the following:

PCI DSS Requirements Testing Procedures Guidance 12.6.1 Educate personnel upon hire and at least annually.

Note: Methods can vary depending on the role of the personnel and their level of access to the cardholder data.

12.6.1.a Verify that the security awareness program provides multiple methods of communicating awareness and educating personnel (for example, posters, letters, memos, web-based training, meetings, and promotions).

If the security awareness program does not include periodic refresher sessions, key security processes and procedures may be forgotten or bypassed, resulting in exposed critical resources and cardholder data. 12.6.1.b Verify that personnel attend …

Removed p. 110

Requiring an acknowledgement by personnel in writing or electronically helps ensure that they have read and understood the security policies/procedures, and that they have made and will continue to make a commitment to comply with these policies.

Removed p. 110

Note: For those potential personnel to be hired for certain positions such as store cashiers who only have access to one card number at a time when facilitating a transaction, this requirement is a recommendation only.

Removed p. 110

Performing thorough background investigations prior to hiring potential personnel who are expected to be given access to cardholder data reduces the risk of unauthorized use of PANs and other cardholder data by individuals with questionable or criminal backgrounds.

Removed p. 110

If a merchant or service provider shares cardholder data with a service provider, certain requirements apply to ensure continued protection of this data will be enforced by such service providers.

Some examples of the different types of service providers include backup tape storage facilities, managed service providers such as web-hosting companies or security service providers, entities that receive data for fraud-modeling purposes, etc.

PCI DSS Requirements Testing Procedures Guidance 12.8.1 Maintain a list of service providers including a description of the service provided.

Removed p. 111

Keeping track of all service providers identifies where potential risk extends to outside of the organization.

Removed p. 111

Note: The exact wording of an acknowledgement will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgement does not have to include the exact wording provided in this requirement.

Removed p. 111

The acknowledgement of the service providers evidences their commitment to maintaining proper security of cardholder data that it obtains from its clients. The extent to which the service provider is responsible for the security of cardholder data will depend on the particular service and the agreement between the provider and assessed entity.

In conjunction with Requirement 12.9, this requirement is intended to promote a consistent level of understanding between parties about their applicable PCI DSS responsibilities. For example, the agreement may include the applicable PCI DSS requirements to be maintained as part of the provided service.

Removed p. 111

The process ensures that any engagement of a service provider is thoroughly vetted internally by an organization, which should include a risk analysis prior to establishing a formal relationship with the service provider.

Specific due-diligence processes and goals will vary for each organization. Examples of considerations may include the provider’s reporting practices, breach-notification and incident response procedures, details of how PCI DSS responsibilities are assigned between each party, how the provider validates their PCI DSS compliance and what evidence they will provide, etc.

Note: The exact wording of an acknowledgement will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgement does not have to include the exact wording provided in this requirement.

PCI DSS Requirements Testing Procedures Guidance 12.8.4 Maintain a program to monitor service providers’ PCI DSS compliance status at least annually.

Removed p. 112

Knowing your service providers’ PCI DSS compliance status provides assurance and awareness about whether they comply with the same requirements that your organization is subject to. If the service provider offers a variety of services, this requirement should apply to those services delivered to the client, and those services in scope for the client’s PCI DSS assessment.

The specific information an entity maintains will depend on the particular agreement with their providers, the type of service, etc. The intent is for the assessed entity to understand which PCI DSS requirements their providers have agreed to meet.

Removed p. 112

In conjunction with Requirement 12.8.2, this requirement is intended to promote a consistent level of understanding between service providers and their customers about their applicable PCI DSS responsibilities. The acknowledgement of the service providers evidences their commitment to maintaining proper security of cardholder data that it obtains from its clients.

The service provider’s internal policies and procedures related to their customer engagement process and any templates used for written agreements should include provision of an applicable PCI DSS acknowledgement to their customers. The method by which the service provider provides written acknowledgment should be agreed between the provider and their customers.

PCI DSS Requirements Testing Procedures Guidance 12.10 Implement an incident response plan. Be prepared to respond immediately to a system breach.

Removed p. 113

Without a thorough security incident response plan that is properly disseminated, read, and understood by the parties responsible, confusion and lack of a unified response could create further downtime for the business, unnecessary public media exposure, as well as new legal liabilities.

Removed p. 113

• Roles, responsibilities, and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum

• Specific incident response procedures

• Specific incident response procedures

12.10.1.a Verify that the incident response plan includes:

• Roles, responsibilities, and communication strategies in the event of a compromise including notification of the payment brands, at a minimum

• Analysis of legal requirements for reporting compromises (for example, California Bill 1386, which requires notification of affected consumers in the event of an actual or suspected compromise for any business with California residents in their database)

• Coverage and responses for all critical system components

The incident response plan should be thorough and contain all the key elements to allow your company to respond effectively in the event of a breach that could impact cardholder data.

12.10.1.b Interview personnel and review documentation from a sample of previously reported incidents or alerts to verify that the …

Removed p. 113

Without proper testing, key steps may be missed, which could result in increased exposure during an incident.

PCI DSS Requirements Testing Procedures Guidance 12.10.3 Designate specific personnel to be available on a 24/7 basis to respond to alerts.

Removed p. 114

These monitoring systems are designed to focus on potential risk to data, are critical in taking quick action to prevent a breach, and must be included in the incident-response processes.

Removed p. 114

Incorporating “lessons learned” into the incident response plan after an incident helps keep the plan current and able to react to emerging threats and security trends.

Removed p. 114

• Firewall rule-set reviews

• Firewall rule-set reviews

• Change management processes 12.11.a Examine policies and procedures to verify that processes are defined for reviewing and confirming that personnel are following security policies and operational procedures, and that reviews cover:

• Change management processes

Regularly confirming that security policies and procedures are being followed provides assurance that the expected controls are active and working as intended. The objective of these reviews is not to re-perform other PCI DSS requirements, but to confirm whether procedures are being followed as expected.

12.11.b Interview responsible personnel and examine records of reviews to verify that reviews are performed at least quarterly.

PCI DSS Requirements Testing Procedures Guidance 12.11.1 Additional requirement for service providers only: Maintain documentation of quarterly review process to include:

• Documenting results of the reviews

• Documenting results of the reviews

• Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program 12.11.1 Examine documentation …

Removed p. 116

• Appendix A1: Additional PCI DSS Requirements for Shared Hosting Providers

• Appendix A2: Additional PCI DSS Requirements for Entities using SSL/early TLS for Card-Present POS POI terminal connections

• Appendix A3: Designated Entities Supplemental Validation Guidance and applicability information is provided within each section.

Removed p. 117

A1 Requirements Testing Procedures Guidance A1 Protect each entity’s (that is, merchant, service provider, or other entity) hosted environment and data, per A1.1 through A1.4:

A hosting provider must fulfill these requirements as well as all other relevant sections of the PCI DSS.

Note: Even though a hosting provider may meet these requirements, the compliance of the entity that uses the hosting provider is not guaranteed. Each entity must comply with the PCI DSS and validate compliance as applicable.

A1 Specifically for a PCI DSS assessment of a shared hosting provider, to verify that shared hosting providers protect entities’ (merchants and service providers) hosted environment and data, select a sample of servers (Microsoft Windows and Unix/Linux) across a representative sample of hosted merchants and service providers, and perform A1.1 through A1.4 below:

Appendix A of PCI DSS is intended for shared hosting providers who wish to provide their merchant and/or service provider customers with …

Removed p. 118

A1.2.a Verify the user ID of any application process is not a privileged user (root/admin).

To ensure that access and privileges are restricted such that each merchant or service provider has access only to their own environment, consider the following:

1. Privileges of the merchant’s or service provider’s web server user ID;

2. Permissions granted to read, write, and execute files;

3. Permissions granted to write to system binaries;

4. Permissions granted to merchant’s and service provider’s log files; and

5. Controls to ensure one merchant or service provider cannot monopolize system resources.

A1.2.b Verify each entity (merchant, service provider) has read, write, or execute permissions only for files and directories it owns or for necessary system files (restricted via file system permissions, access control lists, chroot, jailshell, etc.) Important: An entity’s files may not be shared by group.

A1.2.c Verify that an entity’s users do not have write access to shared system binaries.

A1.2.d Verify that viewing of …

Removed p. 119

Requirement 2.2.3 Implement additional security features for any required services, protocols, or daemons that are considered to be insecure.

Requirement 2.3 Encrypt all non-console administrative access using strong cryptography.

Requirement 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.

SSL and early TLS must not be used as a security control to meet these requirements, except in the case of POS POI terminal connections as detailed in this appendix. To support entities working to migrate away from SSL/early TLS on POS POI terminals, the following provisions are included:

This Appendix only applies to entities using SSL/early TLS as a security control to protect POS POI terminals, including service providers who provide connections into POS POI terminals.

Removed p. 120

Note: This requirement is intended to apply to the entity with the POS POI terminal, such as a merchant. This requirement is not intended for service providers who serve as the termination or connection point to those POS POI terminals. Requirements A2.2 and A2.3 apply to POS POI service providers.

A2.1 For POS POI terminals using SSL and/or early TLS, confirm the entity has documentation (for example, vendor documentation, system/network configuration details, etc.) that verifies the devices are not susceptible to any known exploits for SSL/early TLS.

However, SSL is an outdated technology and may be subject to additional security vulnerabilities in the future; it is therefore strongly recommended that POS POI terminals be upgraded to a secure protocol as soon as possible. If SSL/early TLS is not needed in the environment, use of and fallback to these versions should be disabled.

Note: The allowance for POS POI terminals that are not currently …

Removed p. 121

A2.2 Review the documented Risk Mitigation and Migration Plan to verify it includes:

• Description of usage, including what data is being transmitted, types and number of systems that use and/or support SSL/early TLS, type of environment;

• Risk-assessment results and risk-reduction controls in place;

• Description of processes to monitor for new vulnerabilities associated with SSL/early TLS;

• Description of change control processes that are implemented to ensure SSL/early TLS is not implemented into new environments;

POS POI termination points, including but not limited to a service providers such as an acquirer or acquirer processor, can continue using SSL/early TLS when it can be shown that the service provider has controls in place that mitigate the risk of supporting those connections for the service provider environment.

The Risk Mitigation and Migration Plan is a document prepared by the entity that details their plans for migrating to a secure protocol, and also describes controls the entity …

Removed p. 122

• Those storing, processing, and/or transmitting large volumes of cardholder data,

• Those providing aggregation points for cardholder data, or

• Those that have suffered significant or repeated breaches of cardholder data.

These supplemental validation steps are intended to provide greater assurance that PCI DSS controls are maintained effectively and on a continuous basis through validation of business-as-usual (BAU) processes, and increased validation and scoping consideration.

The additional validation steps in this document are organized into the following control areas:

A3.1 Implement a PCI DSS compliance program.

A3.2 Document and validate PCI DSS scope.

A3.3 Validate PCI DSS is incorporated into business-as-usual (BAU) activities.

A3.4 Control and manage logical access to the cardholder data environment.

A3.5 Identify and respond to suspicious events.

Note: Some requirements have defined timeframes (for example, at least quarterly or every six months) within which certain activities are to be performed. For initial assessment to this document, it is not required that an activity has been …

Removed p. 123

• Providing updates to executive management and board of directors on PCI DSS compliance initiatives and issues, including remediation activities, at least annually

A3.1.1.c Examine executive management and board of directors meeting minutes and/or presentations to ensure PCI DSS compliance initiatives and remediation activities are communicated at least annually.

A3.1.2 A formal PCI DSS compliance program must be in place to include:

• Processes for the continuous validation of PCI DSS requirements (for example: daily, weekly, quarterly, etc. as applicable per requirement)

• A process for performing business-impact analysis to determine potential PCI DSS impacts for strategic business decisions PCI DSS Reference: Requirements 1-12 A3.1.2.a Examine information security policies and procedures to verify that processes are specifically defined for the following:

• Maintaining and monitoring overall PCI DSS compliance, including business-as-usual activities

• Annual PCI DSS assessment(s)

• Continuous validation of PCI DSS requirements

• Business-impact analysis to determine potential PCI DSS impacts for strategic business decisions A …

Removed p. 124

• Maintaining and monitoring overall PCI DSS compliance, including business-as-usual activities

• Annual PCI DSS assessment(s)

• Continuous validation of PCI DSS requirements

• Business-impact analysis to determine potential PCI DSS impacts for strategic business decisions Maintaining and monitoring an organization’s overall PCI DSS compliance includes identifying activities to be performed daily, weekly, monthly, quarterly, or annually, and ensuring these activities are being performed accordingly (for example, using a security self-assessment or PDCA methodology).

Examples of strategic business decisions that should be analyzed for potential PCI DSS impacts may include mergers and acquisitions, new technology purchases, or new payment- acceptance channels.

A3.1.3 PCI DSS compliance roles and responsibilities must be specifically defined and formally assigned to one or more personnel, including at least the following:

• Managing continuous validation of PCI DSS requirements (for example: daily, weekly, quarterly, etc. as applicable per requirement)

• Managing continuous validation of PCI DSS requirements (for example: daily, weekly, quarterly, etc. …

Removed p. 125

PCI DSS Reference: Requirement 12 A3.1.4.a Examine information security policies and procedures to verify that PCI DSS and/or information security training is required at least annually for each role with PCI DSS compliance responsibilities.

Personnel responsible for PCI DSS compliance have specific training needs exceeding that which is typically provided by general security awareness training. Individuals with PCI DSS compliance responsibilities should receive specialized training that, in addition to general awareness of information security, focuses on specific security topics, skills, processes, or methodologies that must be followed for those individuals to perform their compliance responsibilities effectively.

Training may be offered by third parties

•for example, SANS or PCI SSC (PCI Awareness, PCIP, and ISA), payment brands, and acquirers

• or training may be internal. Training content should be applicable for the particular job function and be current to include the latest security threats and/or version of PCI DSS.

For additional guidance on developing appropriate security …

Removed p. 126

• Identifying all in-scope networks and system components

• Identifying all out-of-scope networks and justification for networks being out of scope, including descriptions of all segmentation controls implemented

• Identifying all connected entities

•e.g., third-party entities with access to the cardholder data environment (CDE)

PCI DSS Reference: Scope of PCI DSS Requirements A3.2.1.b Examine documented results of quarterly scope reviews to verify the following is performed:

• Identification of all in-scope networks and system components

• Identification of all out-of-scope networks and justification for networks being out of scope, including descriptions of all segmentation controls implemented

• Identification of all connected entities

•e.g., third- party entities with access to the CDE A3.2.2 Determine PCI DSS scope impact for all changes to systems or networks, including additions of new systems and new network connections. Processes must include:

PCI DSS Reference: Scope of PCI DSS Requirements; Requirements 1-12 A3.2.2 Examine change documentation and interview personnel to verify that for each change …

Removed p. 127

• Network diagram is updated to reflect changes.

• Systems are protected with required controls

•e.g., file-integrity monitoring (FIM), anti-virus, patches, audit logging.

• Verify that sensitive authentication data (SAD) is not stored and that all cardholder data (CHD) storage is documented and incorporated into data- retention policy and procedures

PCI DSS Reference: Scope of PCI DSS Requirements; Requirement 1-12 A3.2.2.1 For a sample of systems and network changes, examine change records, interview personnel and observe the affected systems/networks to verify that applicable PCI DSS requirements were implemented and documentation updated as part of the change.

It is important to have processes to analyze all changes made to ensure that all appropriate PCI DSS controls are applied to any systems or networks added to the in-scope environment due to a change.

A change management process should include supporting evidence that PCI DSS requirements are implemented or preserved through the iterative process.

• for example, a company merger …

Removed p. 128

PCI DSS Reference: Requirement 11 A3.2.4 Examine the results from the most recent penetration test to verify that:

If segmentation is used to isolate in-scope networks from out-of-scope networks, those segmentation controls must be verified using penetration testing to confirm they continue to operate as intended and effectively. Penetration- testing techniques should follow the existing penetration methodology as specified in PCI DSS Requirement 11.

For additional information on effective penetration testing, refer to the PCI SSC’s Information Supplement on Penetration Testing Guidance.

A3.2.5 Implement a data-discovery methodology to confirm PCI DSS scope and to locate all sources and locations of clear-text PAN at least quarterly and upon significant changes to the cardholder environment or processes.

Data-discovery methodology must take into consideration the potential for clear-text PAN to reside on systems and networks outside of the currently defined CDE.

PCI DSS Reference: Scope of PCI DSS Requirements A3.2.5.a Examine documented data-discovery methodology to verify the following:

• …

Removed p. 129

The effectiveness of data-discovery methods must be confirmed at least annually.

• The process includes verifying the methods are able to discover clear-text PAN on all types of system components and file formats in use. components in both the in-scope and out-of-scope networks should be included in the data-discovery process. Accuracy can be tested by placing test PANs on a sample of system components and file formats in use and confirming that the data- discovery method detected the test PANs.

A3.2.5.1.b Examine the results of recent effectiveness tests to verify the effectiveness of methods used for data discovery is confirmed at least annually.

A3.2.5.2 Implement response procedures to be initiated upon the detection of clear-text PAN outside of the CDE to include:

• Procedures for determining what to do if clear-text PAN is discovered outside of the CDE, including its retrieval, secure deletion and/or migration into the currently defined CDE, as applicable

• Procedures for …

Removed p. 130

• Generating logs and alerts upon detection of clear- text PAN leaving the CDE via an unauthorized channel, method, or process detect and prevent situations that may lead to data loss.

A3.2.6.1 Implement response procedures to be initiated upon the detection of attempts to remove clear-text PAN from the CDE via an unauthorized channel, method, or process. Response procedures must include:

• Procedures for the timely investigation of alerts by responsible personnel

• Procedures for the timely investigation of alerts by responsible personnel

• Procedures for remediating data leaks or process gaps, as necessary, to prevent any data loss A3.2.6.1.a Examine documented response procedures to verify that procedures for responding to the attempted removal of clear-text PAN from the CDE via an unauthorized channel, method, or process include:

• Procedures for remediating data leaks or process gaps, as necessary, to prevent any data loss Attempts to remove clear-text PAN via an unauthorized channel, method, or …

Removed p. 131

PCI DSS Reference: Requirements 1-12 A3.3.1.b Examine detection and alerting processes and interview personnel to verify that processes are implemented for all critical security controls, and that failure of a critical security control results in the generation of an alert. undetected for extended periods and provide attackers ample time to compromise systems and steal sensitive data from the cardholder data environment.

A3.3.1.1 Respond to failures of any critical security controls in a timely manner. Processes for responding to failures in security controls must include:

• Identifying and documenting the duration (date and time start to end) of the security failure

• Identifying and documenting the duration (date and time start to end) of the security failure

• Identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to address root cause

• Identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to address root cause

PCI DSS Reference: Requirements …

Removed p. 133

•to assist the entity’s preparation for its next PCI DSS assessment.

PCI DSS Reference: Requirements 2, 6 A3.3.2.a Examine documented policies and procedures and interview personnel to verify processes are defined and implemented to review hardware and software technologies to confirm whether they continue to meet the organization’s PCI DSS requirements.

Hardware and software technologies are constantly evolving, and organizations need to be aware of changes to the technologies they use, as well as the evolving threats to those technologies. Organizations also need to be aware of changes made by technology vendors to their products or support processes, to understand how such changes may impact the organization’s use of the technology.

• Confirming that all BAU activities (e.g., A3.2.2, A3.2.6, and A3.3.1) are being performed

• Confirming that personnel are following security policies and operational procedures (for example, daily log reviews, firewall rule-set reviews, configuration standards for new systems, etc.)

• Documenting how the reviews …

Modified p. 133 → 330

A3.3.2.b Review the results of the recent reviews to verify reviews are performed at least ~~annually.~~

A3.3.2.b Review the results of the recent reviews of hardware and software technologies to verify reviews are performed at least once every 12 months.

Modified p. 133 → 330

A3.3.2.c ~~For~~ any technologies that have been determined to no longer meet the organization’s PCI DSS requirements, ~~verify~~ a plan is in place to remediate the technology.

A3.3.2.c Review documentation to verify that, for any technologies that have been determined to no longer meet the organization’s PCI DSS requirements, a plan is in place to remediate the technology.

Modified p. 133 → 331

A3.3.3 ~~Perform reviews~~ at least ~~quarterly~~ to verify BAU activities are being followed. Reviews ~~must be~~ performed by personnel assigned to the PCI DSS compliance program (as identified in A3.1.3), and ~~include the following:~~

A3.3.3 Reviews are performed at least once every three months to verify BAU activities are being followed. Reviews are performed by personnel assigned to the PCI DSS compliance program (as identified in A3.1.3), and include:

Modified p. 133 → 331

• Confirmation that all BAU ~~activities (e.g.,~~ A3.2.2, A3.2.6, and ~~A3.3.1)~~ are being ~~performed~~

• Confirmation that all BAU activities, including A3.2.2, A3.2.6, and A3.3.1, are being performed.

Modified p. 133 → 331

• Confirmation that personnel are following security policies and operational procedures (for example, daily log reviews, ~~firewall rule-set reviews, A3.3.3.a Examine policies and procedures to verify that processes are defined~~ for ~~reviewing and verifying BAU activities. Verify the procedures include:~~

• Confirmation that personnel are following security policies and operational procedures (for example, daily log reviews, ruleset reviews for network security controls, configuration standards for new systems).

Removed p. 134

A3.4 Control and manage logical access to the cardholder data environment A3.4.1 Review user accounts and access privileges to in-scope system components at least every six months to ensure user accounts and access remain appropriate based on job function, and authorized.

Access requirements evolve over time as individuals change roles or leave the company, and as job functions change. Management needs to regularly review, revalidate, and update user access, as necessary, to reflect changes in personnel, including third parties, and users’ job functions.

A3.5 Identify and respond to suspicious events A3.5.1 Implement a methodology for the timely identification of attack patterns and undesirable behavior across systems

•for example, using coordinated manual reviews and/or centrally managed or automated log- correlation tools

•to include at least the following:

Modified p. 134 → 331

• Collection of documented evidence as required for the annual PCI DSS ~~assessment~~

• Collection of documented evidence as required for the annual PCI DSS assessment.

Modified p. 134 → 331

• Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance ~~program (as~~ identified in ~~A3.1.3)~~

• Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program, as identified in A3.1.3.

Modified p. 134 → 331

• Retention of records and documentation for at least 12 months, covering all BAU activities

• Retention of records and documentation for at least 12 months, covering all BAU activities. PCI DSS Reference: Requirements 1-12 A3.3.3.a Examine policies and procedures to verify that processes are defined for reviewing and verifying BAU activities in accordance with all elements specified in this requirement.

Modified p. 134 → 331

~~PCI DSS Reference: Requirements 1-12~~ A3.3.3.b Interview responsible personnel and examine records of reviews to verify that:

A3.3.3.b Interview responsible personnel and examine records of reviews to verify that:

Modified p. 134 → 331

• Reviews are performed at least ~~quarterly.~~

• Reviews are performed at least once every three months.

Modified p. 134 → 332

• Reviews confirm that access is appropriate based on job ~~function,~~ and that all access is authorized.

• Reviews confirm that access is appropriate based on job function and that all access is authorized. Customized Approach Objective This requirement is not eligible for the customized approach.

Modified p. 134 → 333

A3.5.1.a ~~Review~~ documentation and interview personnel to verify a methodology is defined and implemented to identify attack patterns and undesirable behavior across systems in a ~~timely~~ manner, and includes ~~the following:~~

• Response to alerts in accordance with documented response procedures. PCI DSS Reference: Requirements 10, 12 A3.5.1.a Examine documentation and interview personnel to verify a methodology is defined and implemented to identify attack patterns and undesirable behavior across systems in a prompt manner, and includes all elements specified in this requirement.

Modified p. 134 → 333

• Identification of anomalies or suspicious activity as it ~~occurs~~

• Identification of anomalies or suspicious activity as it occurs.

Modified p. 135 → 333

• Issuance of ~~timely~~ alerts upon detection of suspicious activity or anomaly to responsible ~~personnel~~

• Issuance of prompt alerts upon detection of suspicious activity or anomaly to responsible personnel.

Modified p. 135 → 333

• ~~Response to alerts~~ in ~~accordance with documented response procedures~~ difficult, if not impossible, without a process to corroborate information from critical system ~~components,~~ and systems that perform security functions

•such as ~~firewalls,~~ IDS/IPS, and ~~file-~~ integrity monitoring (FIM) systems. Thus, logs for all critical ~~systems~~ components and systems that perform security functions ~~should~~ be collected, correlated, and maintained. This could include ~~the use of~~ software products and service methodologies to provide real-time analysis, alerting, and reporting

•such as security information and …

• is critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something goes wrong. Determining the cause of a compromise is very difficult, if not impossible, without a process to corroborate information from critical system components and systems that perform security functions, such as network security controls, IDS/IPS, and file integrity monitoring (FIM) systems. Thus, logs for all critical system components and systems …

Modified p. 135 → 333

• On-call personnel receive ~~timely~~ alerts.

• On-call personnel receive prompt alerts.

Removed p. 136

Note: The items at a) through c) below are intended as examples only. All compensating controls must be reviewed and validated for sufficiency by the assessor who conducts the PCI DSS review. The effectiveness of a compensating control is dependent on the specifics of the environment in which the control is implemented, the surrounding security controls, and the configuration of the control. Companies should be aware that a particular compensating control will not be effective in all environments.

b) Existing PCI DSS requirements MAY be considered as compensating controls if they are required for another area, but are not required for the item under review.

c) Existing PCI DSS requirements may be combined with new controls to become a compensating control. For example, if a company is unable to render cardholder data unreadable per Requirement 3.4 (for example, by encryption), a compensating control could consist of a device or combination of devices, …

Modified p. 136 → 334

2. Provide a similar level of defense as the original PCI DSS requirement, such that the compensating control sufficiently offsets the risk that the original PCI DSS requirement was designed to defend against. ~~(See Guidance Column for~~ the intent of ~~each~~ PCI DSS ~~requirement.)~~

2. Provide a similar level of defense as the original PCI DSS requirement, such that the compensating control sufficiently offsets the risk that the original PCI DSS requirement was designed to defend against. To understand the intent of a requirement, see the Customized Approach Objective for most PCI DSS requirements. If a requirement is not eligible for the Customized Approach and therefore does not have a Customized Approach Objective, refer to the Purpose in the Guidance column for that requirement.

Modified p. 136 → 334

3. Be “above and beyond” other PCI DSS requirements. (Simply being in compliance with other PCI DSS requirements is not a compensating control.) ~~When evaluating “above and beyond” for compensating controls, consider the following:~~

3. Be “above and beyond” other PCI DSS requirements. (Simply being in compliance with other PCI DSS requirements is not a compensating control.)

Modified p. 136 → 334

a) Existing PCI DSS requirements CANNOT be considered as compensating controls if they are already required for the item under review. For example, passwords for non-console administrative access must be sent encrypted to mitigate the risk of intercepting ~~clear-text~~ administrative passwords. An entity cannot use other PCI DSS password requirements (intruder lockout, complex passwords, etc.) to compensate for lack of encrypted passwords, since those other password requirements do not mitigate the risk of interception of ~~clear-text~~ passwords. Also, the other …

Note: All compensating controls must be reviewed and validated for sufficiency by the assessor who conducts the PCI DSS assessment. The effectiveness of a compensating control is dependent on the specifics of the environment in which the control is implemented, the surrounding security controls, and the configuration of the control. Entities should be aware that a given compensating control will not be effective in all environments. a. Existing PCI DSS requirements CANNOT be considered as compensating controls if they are …

Modified p. 137 → 336

Note: Only ~~companies~~ that have ~~undertaken a risk analysis~~ and ~~have legitimate~~ technological or ~~documented~~ business constraints can consider the use of compensating controls to achieve compliance.

Note: Only entities that have legitimate and documented technological or business constraints can consider the use of compensating controls to achieve compliance.

Modified p. 137 → 336

1. Constraints ~~List~~ constraints precluding compliance with the original requirement.

1. Constraints Document the legitimate technical or business constraints precluding compliance with the original requirement.

Modified p. 137 → 336

2. Objective Define the objective of the original ~~control; identify~~ the ~~objective met by the compensating control.~~

3. Objective Define the objective of the original control (for example, the Customized Approach Objective).

Modified p. 137 → 336

3. Identified Risk Identify any additional risk posed by the lack of the original control.

4. Identified Risk Identify any additional risk posed by the lack of the original control.

Modified p. 137 → 336

4. Definition of Compensating Controls Define the compensating ~~controls and~~ explain how they address the objectives of the original control and the increased risk, if any.

2. Definition of Compensating Controls Define the compensating controls: explain how they address the objectives of the original control and the increased risk, if any.

Modified p. 137 → 336

6. Maintenance Define ~~process~~ and controls in place to maintain compensating controls.

6. Maintenance Define process(es) and controls in place to maintain compensating controls.

Removed p. 138

Requirement Number: 8.1.1

• Are all users identified with a unique user ID before allowing them to access system components or cardholder data? Information Required Explanation

1. Constraints List constraints precluding compliance with the original requirement.

Company XYZ employs stand-alone Unix Servers without LDAP. As such, they each require a “root” login. It is not possible for Company XYZ to manage the “root” login nor is it feasible to log all “root” activity by each user.

2. Objective Define the objective of the original control; identify the objective met by the compensating control.

The objective of requiring unique logins is twofold. First, it is not considered acceptable from a security perspective to share login credentials. Secondly, having shared logins makes it impossible to state definitively that a person is responsible for a particular action.

3. Identified Risk Identify any additional risk posed by the lack of the original control.

Additional risk is introduced to the access control …

Document Comparison

Content Changes