PCI DSS 4.

0
Everything You Need to Know About The Transformational
Changes Required of Your Business

May 3, 2022
mwe.com
SPEAKERS

TODD ALAN
MCCLELLAND GUTIERREZ-
ARANA

McDermott Will & Emery RSM US

Partner Principal
tmcclelland@mwe.com Alan.gutierrezarana@rsmus.com

MARK
SCHREIBER ROBERT DUFFY BRIAN LONG

McDermott Will & Emery McDermott Will & Emery McDermott Will & Emery

Senior Counsel Counsel Associate

mschreiber@mwe.com reduffy@mwe.com brlong@mwe.com

2 mwe.com
 AGENDA
• Introduction / Overview

• Key Changes

• Legal Risks

• Closing Thoughts

• Q&A

3 mwe.com
KEY CHANGES IN
PCI DSS 4.0

4 mwe.com
PCI DSS VERSION 4.0 TIMELINE

5 mwe.com Copyright © 2006 - 2022 PCI Security Standards Council. https://www.pcisecuritystandards.org/

SUGGESTED PREPARATION
• Near Term: Perform a PCI DSS 4.0 Readiness Assessment
• Do a practice run:
– Before March 31, 2023, perform an assessment of new/updated PCI DSS
4.0 controls along with PCI DSS 3.2.1 efforts
– Remediate any deficiencies with PCI DSS 4.0 required practices
– Develop any controls using a Customized Approach
• Before March 31, 2024: Perform first ROC/SAQ using PCI DSS 4.0 and
perform additional gap assessment against Best Practice Controls
• Before March 31, 2025: Perform next ROC/SAQ using PCI DSS 4.0
and include PCI DSS Best Practice Controls
6 mwe.com
PCI APPLICABILITY AND SCOPE CLARIFICATIONS
• Applicability updated to explicitly include organizations who could
impact the security of the CDE (even entities who are not
processing) (p. 4)
• Scope of PCI DSS Requirements clarified (p. 9):
– CDE, which includes:
 System components, people, and processes that store,
process, and transmit cardholder data or SAD; 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; and
– System components, people, and processes that could impact
the security of the CDE
• Assessed entity must annually confirm PCI Scope (p. 12, req
12.5.2)
Graphic sourced from PCI DSS 4.0, page 11
7 mwe.com
PCI APPLICABILITY AND SCOPE CLARIFICATIONS
(CONT.)

Graphic sourced from PCI DSS 4.0, page 11

8 mwe.com
PCI APPLICABILITY AND SCOPE CLARIFICATIONS
(CONT.)

Graphic sourced from PCI DSS 4.0, page 11

9 mwe.com
PCI APPLICABILITY AND SCOPE CLARIFICATIONS
(CONT.)

• Network segmentation clarified: out-of-scope systems cannot

impact the security of any in scope system components (p. 13)
– If this test fails, the entire network is in scope

• Wireless scans required “even when wireless is not used within

the CDE and the entity has a policy that prohibits the use of
wireless technology” (p. 14, req. 11.2.1)

10 mwe.com
PCI APPLICABILITY AND SCOPE CLARIFICATIONS
(CONT.)

• Encrypted data scope clarifications: channels used to capture the

data, encrypt the data and systems that are on the same network
segment as the decryption key are all in scope (pp. 14-15)

• Service providers that can affect the security of the CDE, now
explicitly in scope (p. 16)
– For example, a loyalty provider who connects to a POS is in scope

11 mwe.com
UPDATED “SIGNIFICANT CHANGE” GUIDANCE
• “Significant Change” is not new; it is an important trigger for timing certain PCI DSS requirements, e.g., perform new
scope validation, vulnerability scans, confirm PCI controls. However, the term’s definition is dependent on the
environment
• Significant Changes determine the timing of requirements such as vulnerability scanning, log review, and Targeted
Risk Analyses
• Significant Change must now include all of the following:
– 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
• Significant Change is still “highly dependent” on an environment’s configuration, activities, and impacts on the CDE
(p. 26)

12 mwe.com
IMPLEMENTATION AND VALIDATION APPROACHES
(CUSTOMIZED APPROACH)
• PCI DSS 4.0 introduces a new way to implement and validate its
requirements: the Customized Approach
Defined Approach (Legacy Approach) Customized Approach
• Implement requirements in a prescriptive manner • Implement requirements using a customized
as done in prior PCI DSS versions control that implements the Customized Control
• Many controls (with some exceptions, such as Objective listed with the requirement
SAD) can be met with a compensating control if • No compensating controls allowed
prescriptive control cannot be implemented • Requires a targeted risk analysis for each control
• Control validation uses defined testing steps or • Customized control defined by entity; testing
compensating control evaluation using the procedure defined by assessor (e.g. QSA)
compensating control worksheet and risk • Intended for risk-mature organizations
assessments • Must meet or exceed the security provided by the
• Annual requirement to document and validate any requirement in the Defined Approach
compensating control and include in the ROC • Expected to be greater effort for documentation
and validation

13 mwe.com
VALIDATION TO THE CUSTOMIZED APPROACH

The Entity The Assessor

Implements control(s) that meet the Plans and conducts the assessment
intent of the PCI DSS requirement

Provides documentation that

describes the customization Review's Documentation details
implementation information testing procedures and
provided by the results of testing in the
entity Report on Compliance
Derives testing (ROC)
procedures based
The who, what, Evidence of how on information
where, when and controls are provided
how of the controls maintained, and
effectiveness is
Evidence to prove assured
the controls meet
the stated intent

Copyright © 2006 - 2022 PCI Security Standards Council. https://www.pcisecuritystandards.org/

14 mwe.com
TARGETED RISK ANALYSES
• Multiple targeted risk analyses required at various points
– Definition: “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
determined the customized control meets the objective of a PCI DSS
requirement”
• Replaces the organization-wide risk assessment in PCI DSS 3.2.1 (req.
12.2)

15 mwe.com
TARGETED RISK ANALYSES (CONT.)
• Targeted Risk Analyses do not have to have a specific format but must
include all the information defined in the template provided in E2
Sample Targeted Risk Analysis Template, p. 337. These include:
– PCI Requirement, Control Objective, and the “mischief” the requirement
was designed to prevent
– Proposed Solution, including what parts of the requirement change, and
how the proposed solution solves the mischief
– Likelihood analysis
– Impact analysis
– Risk approval and review

16 mwe.com
TARGETED RISK ANALYSES TEMPLATE

17 mwe.com Graphic sourced from PCI DSS 4.0, page 338

TARGETED RISK ANALYSES TEMPLATE (CONT.)

18 mwe.com Graphic sourced from PCI DSS 4.0, page 338

TARGETED RISK ANALYSES TEMPLATE (CONT.)

19 mwe.com Graphic sourced from PCI DSS 4.0, page 338

 THIRD PARTY SERVICE PROVIDERS
Entity’s Management of TPSP TPSP’s Responsibilities to Entity
• 12.8.1 Maintain a list and description of all TPSPs • 12.9.1 TPSPs acknowledge in writing to customers that
they are responsible for the security of account data the
• 12.8.2 Maintain written agreements with TPSPs where
TPSP possesses or otherwise stores, processes, or
account data is shared or security of CDE could be
transmits on behalf of the customer, or to the extent that
affected
they could impact the security of the customer’s CDE
• 12.8.3 Establish a process including due diligence prior to
• 12.9.2 TPSPs support their customers’ requests for
engagement for all TSPS
information to meet Requirements 12.8.4 and 12.8.5 by
• 12.8.4 Implement a program to monitor TPSPs’ PCI DSS providing the following upon customer request:
compliance status at least once every 12 months
– PCI DSS compliance status information for any service
• 12.8.5 Maintain information about which PCI DSS the TPSP performs on behalf of customers
requirements are (Requirement 12.8.4)
– managed by each TPSP, – Information about which PCI DSS requirements are the
– managed by the entity, and responsibility of the TPSP and which are the
responsibility of the customer, including any shared
– that are shared between the TPSP and the entity
responsibilities (Requirement 12.8.5)
20 mwe.com
PCI DSS VERSION 4.0 CHANGES
• PCI DSS v4.0 includes 53 new requirements for all entities and 11 new
requires for TPSPs. These requirements are either:

• Effective immediately for all PCI DSS v4.0 assessments (13

requirements)

• Best practices until 31 March 2025, after which these requirements will
be required and must be fully considered during a PCI DSS
assessment (51 requirements)

21 mwe.com
NOTABLE REQUIREMENT CHANGES
High Level Requirement PCI DSS 3.2.1 PCI DSS 4.0 Notable Changes and Updates
Build and Maintain a Secure 1. Install and maintain a 1. Install and Maintain • Focus on a broader range of security controls beyond
Network and Systems firewall configuration to Network Security firewalls and routers using new term “Network Security
protect cardholder data Controls. Controls (NSC)”
• Greater clarity on placement of NSCs between trusted and
untrusted networks
• Clarifications regarding devices that connect to the CDE
and other untrusted networks.

2. Do not use vendor- 2. Apply Secure • Document roles and responsibilities^

supplied defaults for Configurations to All • Business justification is now required for any insecure
system passwords and System Components. protocol used
other security parameters • Clarifications on wireless security requirements

^Designates new requirement

*Designates best practice until March 31, 2025

22 mwe.com
NOTABLE REQUIREMENT CHANGES (CONT.)
High Level Requirement PCI DSS 3.2.1 PCI DSS 4.0 Notable Changes and Updates
Protect Cardholder Data [3.2.1] 3. Protect stored 3. Protect Stored • Document roles and responsibilities^
cardholder data Account Data. • Protect SAD prior to authorization^*
Protect Account Data [4.0] • Added issuer requirements for storage of SAD
• Clarifications for PAN masking
• Protect PAN from remote access^*
• Keyed cryptographic hashes for PAN^*
• Disk-level or partition-level encryption only used for on
removable media; additional encryption needed for non-
removable media^*
• Service providers must document the use of the same
cryptographic keys in production and test is prevented^*

4. Encrypt transmission of 4. Protect Cardholder • Document roles and responsibilities^

cardholder data across Data with Strong • Confirm certificates used for PAN transmission are valid
open, public networks Cryptography During and not expired or revoked^*
Transmission Over • Maintain an inventory of trusted keys and certificates^*
Open, Public
Networks.

^Designates new requirement

*Designates best practice until March 31, 2025

23 mwe.com
NOTABLE REQUIREMENT CHANGES (CONT.)
High Level Requirement PCI DSS 3.2.1 PCI DSS 4.0 Notable Changes and Updates
Maintain a Vulnerability 5. Protect all systems 5. Protect All Systems • Document roles and responsibilities^
Management Program against malware and and Networks from • Replaced anti-virus with anti-malware
regularly update anti-virus Malicious Software. • Clarifications regarding documentation required for systems
software or programs not at risk for malware and period review based on risk^*
• Frequency of periodic malware scans based on risk^*
• Malware solution required for electronic media^*
• Detect and protect personnel against phishing^*

6. Develop and maintain 6. Develop and • Document roles and responsibilities^

secure systems and Maintain Secure • Clarification that requirement applies to bespoke and
applications Systems and custom software and not third-party software
Software. • Maintain and inventory of bespoke and custom software^*
• Protect public-facing web apps through automated solutions
only (no more manual checks allows) ^*
• New controls for scripts loaded on consumer’s browser^*
• Development and testing renamed “pre-production”
• Clarifications around “segregation of duties” - focus is now
on accountability that only approved changes occur
• Shift from documented processes and procedures to
specific requirements for testing procedures to verify
policies and procedures of each requirement

^Designates new requirement

24 mwe.com *Designates best practice until March 31, 2025
NOTABLE REQUIREMENT CHANGES (CONT.)
High Level Requirement PCI DSS 3.2.1 PCI DSS 4.0 Notable Changes and Updates
Implement Strong Access Control 7. Restrict access to 7. Restrict Access to • Document roles and responsibilities^
Measures cardholder data by System Components • Expanded guidance on least privilege principles
business need to know and Cardholder Data • Review all user accounts and related access privileges^*
by Business Need to • Management of application and system accounts^*
Know. • Review of all application and system accounts^*

8. Identify and authenticate 8. Identify Users and • Document roles and responsibilities^
access to system Authenticate Access • Clarification: this requirement does not apply to consumers
components to System • Increased password length to 12 characters^*
Components. • Service providers provide guidance on password changes^*
• MFA required for all access to the CDE^*
• Requirements for MFA and interactive logins^*
• No hard-coding of passwords into scripts^*
• Password change / complexity requirements for system and
application accounts^*

9. Restrict physical access 9. Restrict Physical • Document roles and responsibilities^

to cardholder data Access to Cardholder • Clarified requirement to lock consoles in sensitive areas
Data. • Restructured requirements for procedures in this
requirement
• POI device inspections based on targeted risk analysis^*
^Designates new requirement
*Designates best practice until March 31, 2025
25 mwe.com
NOTABLE REQUIREMENT CHANGES (CONT.)
High Level Requirement PCI DSS 3.2.1 PCI DSS 4.0 Notable Changes and Updates
Regularly Monitor and Test 10. Track and monitor all 10. Log and Monitor • Document roles and responsibilities^
Networks access to network All Access to System • Automated log reviews^
resources and cardholder Components and • Frequency of log reviews determined by risk analysis^*
data Cardholder Data. • Alerting requirement for all failures of critical security control
systems^*
• Prompt response required for failure of critical security
controls (newly added for non-service providers) ^*

11. Regularly test security 11. Test Security of • Document roles and responsibilities^
systems and processes Systems and • Must scan for wireless even when wireless not used and
Networks Regularly. policy against wireless^*
• Internal vulnerability scans via authenticated scanning^*
• Clarifications regarding penetration testing requirements
• Multi-tenant service providers must support customers for
external penetration testing^*
• Service Providers must use intrusion-detection or intrusion-
prevention techniques to address covert malware
communication channels^*
• Change-and-tamper-detection mechanism deployed to alert
for modifications to HTTP headers and content of payment
pages received by consumer browser^*
^Designates new requirement
*Designates best practice until March 31, 2025
26 mwe.com
NOTABLE REQUIREMENT CHANGES (CONT.)
High Level Requirement PCI DSS 3.2.1 PCI DSS 4.0 Notable Changes and Updates
Maintain an Information 12. Maintain a 12. Support • Clarified that use of a PCI DSS compliant TPSP does not make an entity
Security Policy policy that Information compliant or remove responsibility for compliance from entity.
addresses Security with • Formal organization-wide risk assessment changed to targeted risk analyses^
(which includes many more information Organizational • Personnel must formally acknowledge responsibilities^
requirements about security for all Policies and • Targeted risk analysis required for any requirement that has flexibility in
managing the security personnel Programs. frequency of performance^*
program and third-party • Targeted risk analysis for any customized approach control^
vendors) • Review cryptographic cypher suites and protocols at least every 12 months^*
• Review hardware and software technologies at least every 12 months^*
• Document and confirm PCI Scope at least every 12 months and after
significant change^
• Service Provider document and confirm scope at least every 6 months
and on significant change^*
• Service Providers must review impact to PCI of every significant change^*
• Review and update security awareness program at least every 12 months^*
• Security Awareness training includes threats and vulnerabilities that could
impact CDE^*
• TPSPs must support entity’s requirements for PCI compliance for tasks
they perform or share with entity^
• Targeted risk analysis to determine frequency of training^*

^Designates new requirement

*Designates best practice until March 31, 2025
27 mwe.com
LEGAL RISKS

28 mwe.com
LEGAL RISKS
• What constitutes “reasonable security?” Has the bar (now) been
raised?
– FTC’s unfair and deceptive practices standard
– US state incorporation of or safe harbor for PCI DSS (Nevada,
Washington, Minnesota, Ohio, Utah, Connecticut)
– Implications of 4.0’s “clarifications” on existing 3.2.1 compliance

• Conducting readiness exercises under attorney-client privilege

29 mwe.com
LEGAL RISKS (CONT.)
• Risk Analyses and Management
– Who performs (in-house / third party vendor)?
– Drafts of Targeted Risk Analyses and readiness exercises may be
discoverable outside of attorney-client privilege
– Final Targeted Risk Analyses are likely discoverable

• Decision making / acceptance of risk identified in course of Targeted

Risk Analyses

30 mwe.com
LEGAL RISKS (CONT.)
• Contracting with or as Third-Party Service Providers (TPSPs)
– Need to evaluate which third parties are in scope
– Need requisite terms in place that complies with PCI DSS Req. 12

• Assessing responsibilities as a TPSP (including existing contracts)

• Disputes with TPSPs arising under PCI DSS 4.0

31 mwe.com
LEGAL RISKS (CONT.)
• Risk considerations between the prescriptive and customized
approaches

• Governance issues
– Board reporting
– Roles and responsibilities
– Policies

32 mwe.com
CLOSING
THOUGHTS

33 mwe.com
THANK YOU /
QUESTIONS

This material is for general information purposes only and should not be construed as legal advice or any other advice on any specific facts or circumstances.
No one should act or refrain from acting based upon any information herein without seeking professional legal advice. McDermott Will & Emery* (McDermott)
makes no warranties, representations, or claims of any kind concerning the content herein. McDermott and the contributing presenters or authors expressly
disclaim all liability to any person in respect of the consequences of anything done or not done in reliance upon the use of contents included herein.
*For a complete list of McDermott entities visit mwe.com/legalnotices.

©2021 McDermott Will & Emery. All rights reserved. Any use of these materials including reproduction, modification, distribution or republication, without the
prior written consent of McDermott is strictly prohibited. This may be considered attorney advertising. Prior results do not guarantee a similar outcome.

34 mwe.com