Introduction

Course Agenda

History

2021 Verizon Business Professional Services PSR PCI DSS 4.0 insights

Introduction & PCI Data Security Standard Overview

What is your PCI DSS Compliance Level?

PCI Validation Requirements

Why is it important to become compliant?

Penalties for non-compliance

The General Data Protection Regulation

Defining Account Data, Cardholder Data, and Sensitive Authentication Data

Even if an entity does not store, process, or transmit PAN, some PCI DSS requirements may still apply

Use of Account Data, Sensitive Authentication Data, Cardholder Data, and Primary Account Number in PCI DSS.

Relationship between PCI DSS and PCI SSC Software Standards

Applicability of PCI DSS to Payment Software Vendors

Bespoke and Custom Software

PCI DSS requirements apply to

Understanding PCI DSS Scoping

Out-of-Scope Systems

Annual PCI DSS Scope Confirmation

Segmentation

Segmentation and Impact to PCI DSS Scope

Wireless

Encrypted Cardholder Data and Impact on PCI DSS Scope

Encrypted Cardholder Data and Impact to PCI DSS Scope for Third-Party Service Providers

Use of Third-Party Service Providers

Using TPSPs and the Impact on Customers Meeting PCI DSS Requirement 12.8

Impact of Using TPSPs for Services that Meet Customers’ PCI DSS Requirements

Importance of Understanding Responsibilities Between TPSP Customers and TPSPs

Options for TPSPs to Validate PCI DSS Compliance for TPSP Services that Meet Customers’ PCI DSS Requirements

TPSPs Presence on a Payment Brand List(s) of PCI DSS Compliant Service Providers

1.1 Examples of how PCI DSS should be incorporated into BAU activities

1.2 Examples of how PCI DSS should be incorporated into BAU activities

1.3 Examples of how PCI DSS should be incorporated into BAU activities

For Assessors: Sampling for PCI DSS Assessments

1.1 When independently selecting samples, assessors should consider

1.2 When independently selecting samples, assessors should consider

PCI DSS Sampling Considerations

Description of Timeframes Used in PCI DSS Requirements

PCI DSS Requirement Timeframes Table 1.1

PCI DSS Requirement Timeframes Table 1.2

Defined Approach

Customized Approach

Processes related to becoming and maintaining a PCI DSS compliant environment

Protection of Confidential and Sensitive Information by Qualified Security Assessor Companies

The intent behind each testing method is described

Instructions and Content for Report on Compliance (ROC)

PCI DSS assessment process includes

"External Organizations Referenced in PCI DSS Requirements and PCI DSS Versions"

Understanding the Parts of the Requirements

Additional Requirements for Service Providers Only

Overview

Requirement 1: Install and Maintain Network Security Controls

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

1.2.1 Configuration standards for NSC rulesets

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

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

1.2.4 An accurate data-flow diagram(s) is maintained

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

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

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

1.2.8 Configuration files for NSCs

1.3.1 Inbound traffic to the CDE is restricted

1.3.2 Outbound traffic from the CDE is restricted

1.3.3 NSCs are installed between all wireless networks and the CDE, regardless of whether the wireless network is a CDE

1.4.1 NSCs are implemented between trusted and untrusted networks.

1.4.2 Inbound traffic from untrusted networks to trusted networks is restricted

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

1.4.4 System components that store cardholder data are not directly accessible from untrusted networks.

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

1.5 Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.

1.5.1 Security controls are implemented on any computing devices

2.1 Processes and mechanisms for applying secure configurations to all system components are defined and understood.

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

2.2 System components are configured and managed securely.

2.2.2 Vendor default accounts are managed

2.2.3.1 Primary functions requiring different security levels are managed

2.2.3.2 Primary functions requiring different security levels are managed

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

2.2.5 If any insecure services, protocols, or daemons are present

2.2.6 System security parameters are configured to prevent misuse.

2.2.7 All non-console administrative access is encrypted using strong cryptography.

2.3 Wireless environments are configured and managed securely.

2.3.2 For wireless environments connected to the CDE or transmitting account data, wireless encryption keys are changed

Requirement 3 : Overview

3.1.1 All security policies and operational procedures that are identified

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

3.2 Storage of account data is kept to a minimum.

3.2.1 Account data storage is kept to a minimum through implementation of data retention and disposal policies, procedures, and processes

3.3 Sensitive authentication data (SAD) is not stored after authorization.

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

3.3.1.2 The card verification code is not retained upon completion of the authorization process.

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

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

3.3.3 Additional requirement for issuers and companies that support issuing services and store sensitive authentication data

3.4 Access to displays of full PAN and ability to copy PAN is restricted.

3.4.2 When using remote-access technologies, technical controls prevent copy and/or relocation of PAN for all personnel

3.5 Primary account number (PAN) is secured wherever it is stored.

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

3.5.1.2 If disk-level or partition-level encryption (rather than file-, column-, or field-level database encryption) is used to render PAN unreadable

3.5.1.3 If disk-level or partition-level encryption is used (rather than file-, column-, or field--level database encryption) to render PAN unreadable

3.6 Cryptographic keys used to protect stored account data are secured.

3.6.1.1 Additional requirement for service providers only

3.6.1.2 Secret and private keys used to encrypt/decrypt stored account data

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

3.6.1.4 Cryptographic keys are stored in the fewest possible locations.

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.

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

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

3.7.4 Key management policies and procedures are implemented for cryptographic key changes for keys that have reached the end of their cryptoperiod

3.7.5 Key management policies procedures are implemented to include the retirement, replacement, or destruction of keys used to protect stored account data

3.7.6 Where manual cleartext cryptographic key- management operations are performed by personnel, key-management policies and procedures are implemented

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

3.7.8 Key management policies and procedures are implemented to include that cryptographic key custodians formally acknowledge

3.7.9 Additional requirement for service providers only

Requirement 4: Overview

4.1 Processes and mechanisms for protecting cardholder data with strong cryptography during transmission over open, public networks are defined and documented.

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

4.2 PAN is protected with strong cryptography during transmission.

4.2.1 Strong cryptography and security protocols are implemented as follows to safeguard PAN during transmission over open

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

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

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

Requirement 5: Overview

5.1 Processes and mechanisms for protecting all systems and networks from malicious software are defined and understood.

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

5.2 Malicious software (malware) is prevented, or detected and addressed.

5.2.2 The deployed anti-malware solution(s)

5.2.3 Any system components that are not at risk for malware are evaluated periodically

5.2.3.1 The frequency of periodic evaluations of system components identified as not at risk for malware

5.3 Anti-malware mechanisms and processes are active, maintained, and monitored.

5.3.2 The anti-malware solution(s)

5.3.2.1 If periodic malware scans are performed to meet Requirement 5.3.2, the frequency of scans is defined in the entity’s targeted risk analysis

5.3.3 For removable electronic media, the anti- malware solution(s)

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

5.3.5 Anti-malware mechanisms cannot be disabled or altered by users, unless specifically documented, and authorized by management

5.4 Anti-phishing mechanisms protect users against phishing attacks.

Requirement 6: Overview

6.1 Processes and mechanisms for developing and maintaining secure systems and software are defined and understood

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

6.2 Bespoke and custom software are developed securely.

6.2.2 Software development personnel working on bespoke and custom software are trained at least once every 12 months

6.2.3 Bespoke and custom software is reviewed prior to being released into production or to customers, to identify and correct potential coding vulnerabilities

6.2.3.1 If manual code reviews are performed for bespoke and custom software prior to release to production

6.2.4 Software engineering techniques or other methods are defined and in use by software development personnel

6.2.4 Software engineering techniques or other methods are defined and in use by software development personnel | Good Practice

6.3 Security vulnerabilities are identified and addressed.

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

6.3.3 All system components are protected from known vulnerabilities by installing applicable security patches/updates

6.4 Public-facing web applications are protected against attacks.

6.4.1 For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected

6.4.2 For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks

6.4.3 All payment page scripts that are loaded and executed in the consumer’s browser are managed

6.5 Changes to all system components are managed securely.

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

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

6.5.4 Roles and functions are separated between production and pre-production environments to provide accountability.

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

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

Requirement 7: Overview

7.1 Processes and mechanisms for restricting access to system components and cardholder data by business need to know are defined and understood.

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

7.2 Access to system components and data is appropriately defined and assigned.

7.2.2 Access is assigned to users, including privileged users

7.2.3 Required privileges are approved by authorized personnel.

7.2.4 All user accounts and related access privileges, including third-party/vendor accounts

7.2.5 All application and system accounts and related access privileges are assigned and managed

7.2.5.1 All access by application and system accounts and related access privileges are reviewed

7.2.6 All user access to query repositories of stored cardholder data is restricted

7.3 Access to system components and data is managed via an access control system(s).

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

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

Requirement 8: Overview

8.1 Processes and mechanisms for identifying users and authenticating access to system components are defined and understood.

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

8.2 User identification and related accounts for users and administrators are strictly managed throughout an account’s lifecycle

8.2.2 Group, shared, or generic accounts, or other shared authentication credentials are only used when necessary on an exception basis

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

8.2.4 Addition, deletion, and modification of user IDs, authentication factors, and other identifier objects are managed

8.2.5 Access for terminated users is immediately revoked.

8.2.6 Inactive user accounts are removed or disabled within 90 days of inactivity.

8.2.7 Accounts used by third parties to access, support, or maintain system components via remote access are managed

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

8.3 Strong authentication for users and administrators is established and managed.

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

8.3.3 User identity is verified before modifying any authentication factor.

8.3.4 Invalid authentication attempts

8.3.5 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1

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

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

8.3.8 Authentication policies and procedures are documented and communicated to all users

8.3.9 If passwords/passphrases are used as the only authentication factor for user access

8.3.10 If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data authentication

8.3.10.1 If passwords/passphrases are used as the only authentication factor for customer user access (i.e., in any single-factor authentication implementation)

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

8.4 Multi-factor authentication (MFA) is implemented to secure access into the CDE.

8.4.2 MFA is implemented for all access into the CDE.

8.4.3 MFA is implemented for all remote network access originating from outside the entity’s network that could access or impact the CDE

8.5 Multi-factor authentication (MFA) systems are configured to prevent misuse.

8.5.1 MFA systems are implemented

8.6 Use of application and system accounts and associated authentication factors is strictly managed.

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

8.6.3 Passwords/passphrases for any application and system accounts are protected against misuse

8.6.3 Passwords/passphrases for any application and system accounts are protected against misuse (continuation)

Requirement 9: Three Different Area's

9.1 Processes and mechanisms for restricting physical access to cardholder data are defined and understood.

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

9.2 Physical access controls manage entry into facilities and systems containing cardholder data.

9.2.1.1 Individual physical access to sensitive areas within the CDE is monitored with either video cameras or physical access control mechanisms (or both)

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

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

9.2.4 Access to consoles in sensitive areas is restricted via locking when not in use.

9.3 Physical access for personnel and visitors is authorized and managed.

9.3.1.1 Physical access to sensitive areas within the CDE for personnel is controlled.

9.3.2 Procedures are implemented for authorizing and managing visitor access to the CDE

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

9.3.4 A visitor log is used to maintain a physical record of visitor activity within the facility and within sensitive areas

9.4 Media with cardholder data is securely stored, accessed, distributed, and destroyed.

9.4.1.1 Offline media backups with cardholder data are stored in a secure location.

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

9.4.2 All media with cardholder data is classified in accordance with the sensitivity of the data.

9.4.3 Media with cardholder data sent outside the facility is secured

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

9.4.5 Inventory logs of all electronic media with cardholder data are maintained.

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

9.4.6 Hard-copy materials with cardholder data are destroyed when no longer needed for business or legal reasons

9.4.7 Electronic media with cardholder data is destroyed when no longer needed for business or legal reasons

9.5 Point-of-interaction (POI) devices are protected from tampering and unauthorized substitution.

9.5.1.1 An up-to-date list of POI devices is maintained

9.5.1.2 POI device surfaces are periodically inspected to detect tampering and unauthorized substitution.

9.5.1.2.1 The frequency of periodic POI device inspections and the type of inspections performed is defined in the entity’s targeted risk analysis

9.5.1.3 Training is provided for personnel in POI environments to be aware of attempted tampering or replacement of POI devices

Requirement 10: Overview

10.1 Processes and mechanisms for logging and monitoring all access to system components and cardholder data are defined and documented.

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

10.2 Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.

10.2.1.1 Audit logs capture all individual user access to cardholder data.

10.2.1.2 Audit logs capture all actions taken by any individual with administrative access, including any interactive use of application or system accounts.

10.2.1.3 Audit logs capture all access to audit logs.

10.2.1.4 Audit logs capture all invalid logical access attempts.

10.2.1.5 Audit logs capture all changes to identification and authentication credentials

10.2.1.6 Audit logs capture the following

10.2.1.7 Audit logs capture all creation and deletion of system-level objects.

10.2.2 Audit logs record the following details for each auditable event

10.3 Audit logs are protected from destruction and unauthorized modifications.

10.3.2 Audit log files are protected to prevent modifications by individuals.

10.3.3 Audit log files, including those for external- facing technologies, are promptly backed up to a secure, central, internal log server(s) or other media that is difficult to modify.

10.3.4 File integrity monitoring or change-detection mechanisms is used on audit logs to ensure that existing log data cannot be changed without generating alerts.

10.4 Audit logs are reviewed to identify anomalies or suspicious activity.

10.4.1.1 Automated mechanisms are used to perform audit log reviews.

10.4.2 Logs of all other system components (those not specified in Requirement 10.4.1) are reviewed periodically.

10.4.2.1 The frequency of periodic log reviews for all other system components (not defined in Requirement 10.4.1) is defined in the entity’s targeted risk analysis

10.4.3 Exceptions and anomalies identified during the review process are addressed.

10.5 Audit log history is retained and available for analysis.

10.6 Time-synchronization mechanisms support consistent time settings across all systems.

10.6.2 Systems are configured to the correct and consistent time

10.6.3 Time synchronization settings and data are protected

10.7 Failures of critical security control systems are detected, reported, and responded to promptly.

10.7.2 Failures of critical security control systems are detected, alerted, and addressed promptly

10.7.3 Failures of any critical security controls systems are responded to promptly

Requirement 11: Overview

11.1.2 Roles and responsibilities for performing activities in Requirement 11 are documented, assigned, and understood.

11.2 Wireless access points are identified and monitored, and unauthorized wireless access points are addressed.

11.2.2 An inventory of authorized wireless access points is maintained, including a documented business justification.

11.3 External and internal vulnerabilities are regularly identified, prioritized, and addressed.

11.3.1.1 All other applicable vulnerabilities (those not ranked as high-risk or critical per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are managed

11.3.1.2 Internal vulnerability scans are performed via authenticated scanning

11.3.1.3 Internal vulnerability scans are performed after any significant change

11.3.2 External vulnerability scans are performed

11.3.2.1 External vulnerability scans are performed after any significant change

11.4 External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected.

11.4.2 Internal penetration testing

11.4.3 External penetration testing

11.4.4 Exploitable vulnerabilities and security weaknesses found during penetration testing are corrected

11.4.5 If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls

11.4.6 Additional requirement for service providers only: If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls

11.4.7 Additional requirement for multi-tenant service providers only: Multi-tenant service providers support their customers for external penetration testing per Requirement 11.4.3 and 11.4.4.

11.5 Network intrusions and unexpected file changes are detected and responded to.

11.5.1.1 Intrusion-detection and/or intrusion-prevention techniques detect, alert on/prevent, and address covert malware communication channels.

11.5.2 A change-detection mechanism (for example, file integrity monitoring tools) is deployed

11.6 Unauthorized changes on payment pages are detected and responded to.

Requirement 12: Overview

12.1.2 The information security policy

12.1.3 The security policy clearly defines information security roles and responsibilities for all personnel, and all personnel are aware of and acknowledge their information security responsibilities.

12.1.4 Responsibility for information security is formally assigned to a Chief Information Security Officer or other information security knowledgeable member of executive management.

12.2 Acceptable use policies for end-user technologies are defined and implemented.

12.3.1 Each PCI DSS requirement that provides flexibility for how frequently it is performed

12.3.2 A targeted risk analysis is performed for each PCI DSS requirement that the entity meets with the customized approach

12.3.3 Cryptographic cipher suites and protocols in use are documented and reviewed at least once every 12 months

12.3.4 Hardware and software technologies in use are reviewed at least once every 12 months

12.4 PCI DSS compliance is managed.

12.4.2 Reviews are performed at least once every three months to confirm that personnel are performing their tasks in accordance with all security policies and operational procedures.

12.4.2.1 Additional requirement for service providers only: Reviews conducted in accordance with Requirement 12.4.2 are documented

12.5 PCI DSS scope is documented and validated.

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

12.5.2.1 PCI DSS scope is documented and confirmed by the entity at least once every six months and upon significant change to the in-scope environment.

12.5.3 Significant changes to organizational structure result in a documented (internal) review of the impact to PCI DSS scope and applicability of controls, with results communicated to executive management.

12.6.1 A formal security awareness program is implemented to make all personnel aware of the entity’s information security policy and procedures, and their role in protecting the cardholder data.

12.6.2 The security awareness program

12.6.3 Personnel receive security awareness training

12.6.3.1 Security awareness training includes awareness of threats and vulnerabilities that could impact the security of the CDE

12.6.3.2 Security awareness training includes awareness about the acceptable use of end-user technologies in accordance with Requirement 12.2.1.

12.7 Personnel are screened to reduce risks from insider threats.

12.8 Risk to information assets associated with third-party service provider (TPSP) relationships is managed.

12.8.2 Written agreements with TPSPs are maintained

12.8.3 An established process is implemented for engaging TPSPs, including proper due diligence prior to engagement.

12.8.4 A program is implemented to monitor TPSPs’ PCI DSS compliance status at least once every 12 months.

12.8.5 Information is maintained about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between the TPSP and the entity.

12.9 Third-party service providers (TPSPs) support their customers’ PCI DSS compliance.

12.9.2 Additional requirement for service providers only: TPSPs support their customers’ requests for information to meet Requirements 12.8.4 and 12.8.5

12.10 Suspected and confirmed security incidents that could impact the CDE are responded to immediately.

12.10.2 At least once every 12 months, the security incident response

12.10.3 Specific personnel are designated to be available on a 24/7 basis to respond to suspected or confirmed security incidents.

12.10.4 Personnel responsible for responding to suspected and confirmed security incidents are appropriately and periodically trained on their incident response responsibilities.

12.10.4.1 The frequency of periodic training for incident response personnel is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.

12.10.5 The security incident response plan includes monitoring and responding to alerts from security monitoring systems

12.10.6 The security incident response plan is modified and evolved according to lessons learned and to incorporate industry developments.

12.10.7 Incident response procedures are in place, to be initiated upon the detection of stored PAN anywhere it is not expected

Additional PCI DSS Requirements.

A1.1 Multi-tenant service providers protect and separate all customer environments and data.

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

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

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.2 Multi-tenant service providers facilitate logging and incident response for all customers.

A1.2.2 Processes or mechanisms are implemented to support and/or facilitate prompt forensic investigations in the event of a suspected or confirmed security incident for any customer.

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

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

A2.1 POI terminals using SSL and/or early TLS are confirmed as not susceptible to known SSL/TLS exploits.

A2.1.2 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

A2.1.3 Additional requirement for service providers only: All service providers provide a secure service offering.

Appendix A3: Designated Entities Supplemental Validation (DESV)

A3.1 A PCI DSS compliance program is implemented.

A3.1.2 A formal PCI DSS compliance program is in place

A3.1.3 PCI DSS compliance roles and responsibilities are specifically defined and formally assigned to one or more personnel

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

A3.2 PCI DSS scope is documented and validated.

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.

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.

A3.2.3 Changes to organizational structure result in a formal (internal) review of the impact to PCI DSS scope and applicability of controls.

A3.2.4 If segmentation is used, PCI DSS scope is confirmed

A3.2.5 A data-discovery methodology is implemented

A3.2.5.1 Data discovery methods are confirmed

A3.2.5.2 Response procedures are implemented to be initiated upon the detection of cleartext PAN outside the CDE

A3.2.6 Mechanisms are implemented for detecting and preventing cleartext PAN from leaving the CDE via an unauthorized channel, method, or process

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.

A3.3 PCI DSS is incorporated into business-as-usual (BAU) activities.

A3.3.1.2 Failures of any critical security control systems are responded to promptly.

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.

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)

A3.4 Logical access to the cardholder data environment is controlled and managed.

A3.5 Suspicious events are identified and responded to.

Appendix B Compensating Controls

Appendix B Compensating Controls *continuation

Appendix C Compensating Controls Worksheet

Appendix D Customized Approach

Appendix D Customized Approach *continuation

Appendix E Sample Templates to Support Customized Approach

E1 Sample Controls Matrix Template

E2 Sample Targeted Risk Analysis Template

Sample Targeted Risk Analysis for PCI DSS Requirements met via the Customized Approach To be completed by the entity being assessed #1

Appendix F Leveraging the PCI Software Security Framework to Support Requirement 6

Use of Bespoke and Custom Software Developed and Maintained by a Secure SLC Qualified Vendor

Validating the Use of the Secure SLC Standard

Validating the Use of the Secure Software Standard

Requirements

Additional PCI DSS Requirements