PCI DSS v4.

0 - Prioritized Approach Tool r1

Release Notes & Instructions
February 2023

Contents:  4 spreadsheets (see tabs at bottom of this page)

·   Release Notes & Instructions (this tab)
·   Change Summary
·   Prioritized Approach Milestones
·   Prioritized Approach Summary

Purpose: Tool for tracking progress toward compliance with PCI DSS version 4.0 by using
the Prioritized Approach. Also provides a sorting tool to analyze progress by PCI DSS
requirement, milestone category, or milestone status.

Step 1: Please indicate "Yes", "No", or "N/A" in Column C of the “Prioritized Approach
Milestones” spreadsheet tab. This step will auto-populate the “percentage complete” fields
on the “Prioritized Approach Summary” spreadsheet tab.

Yes All elements of the requirement have been met as stated.

Some or all elements of the requirement have not been met, or are in the process
No of being implemented, or require further testing before the merchant can confirm
they are in place.
The requirement does not apply to the entity’s environment. For example, a
N/A merchant would use N/A for those requirements that apply only if the entity being
assessed is a service provider.
Future Dated Requirements: These new requirements are not required to be included in a
PCI DSS assessment until the future date has passed. Before that future date, any new
requirements with an extended implementation date that the entity has not implemented
may be marked as N/A.
Step 2: Analyze results. Use the “filter” functions on column headers of the “Prioritized
Approach Milestones” spreadsheet tab to select any of the six milestones.

Step 3: Complete the Organization Information on the "Prioritized Approach Summary"

tab. You may share this document with your acquirer or Qualified Security Assessor to
provide an assessment of progress your organization has completed toward PCI DSS
compliance. You may also manually enter an estimated completion date for each milestone
phase. Check with your acquirer for specific submission instructions.

Step 4: When you get to reach 100% for all of the requirement listed in the milestones
category, talk to your acquirer or the payment brands about the next steps. Questions
about using the Prioritized Approach and how use of the Prioritized Approach may impact
an organization’s compliance obligations should be directed to your acquirer or the
payment brands to which your organization reports compliance.

PCI Security Standards Council® Prioritized Approach for PCI DSS v4.0 r1
Disclaimer: This document does not modify or abridge the PCI DSS or any of its requirements and
may be changed without notice. PCI SSC is not responsible for errors or damages of any kind
resulting from the use of the information contained therein. PCI SSC makes no warranty,
guarantee, or representation as to the accuracy or sufficiency of the information provided as part of
the Prioritized Approach, and PCI SSC assumes no responsibility or liability regarding the use or
misuse of such information.

PCI Security Standards Council® Prioritized Approach for PCI DSS v4.0 r1
 PCI DSS v4.0 - Prioritized Approach Tool r1
Change Summary
February 2023

Document Changes

Date Revision Description

August 2022 Prioritized Approach Tool Initial release for PCI DSS v4.0
PCI DSS v4.0

February 2023 PCI DSS v4.0 - Prioritized Updates include:

Approach Tool r1 - Inclusion of a Change Summary tab
- Explanation of "Yes," "No," and "N/A"
response options, and how to respond to new
PCI DSS v4.0 requirements that are not
required until 31 March 2025
- Alignment of title and PCI DSS version
- Spreadsheet formula correction
- Updates to editable cells

PCI Security Standards Council® Prioritized Approach for PCI DSS v4.0 r1
 Prioritized Approach Summary & Acknowledgment
Part 1: Contact Information
Company Name University of Manitoba Company Mailing Address
DBA (Doing Business As) Company Main Website
Company Contact Name
Company Contact Title
Contact Phone Number      
Contact Email Address    

Part 2a: Merchant Business Channels (Select all that apply) Part 2b: Service Provider Business (Select all that apply)

✘ Mail order/telephone order (MOTO) Hosting Provider: Managed Services: Payment Processing:
✘ E-Commerce Applications / software Systems security services POI / card present
✘ Card-present Hardware IT support Internet / e-commerce
Other processing (specify): Infrastructure / Network Physical security MOTO / Call Center
Physical space (co-location) Terminal Management Syst ATM
Part 3: Relationships Storage Other services (specify): Other processing (specify):
Does your organization have a relationship with one or more third-party agents? Web-hosting services
(Ex: gateways, web-hosting companies, airline booking agents, loyalty program agents, etc)? Security services
Ye 3-D Secure Hosting Provider
✘ No
s
Multi-Tenant Service Provider
Does your organization have a relationship with more than one acquirer? Other Hosting (specify):
✘ Yes No
Account Management Fraud and Chargeback Payment Gateway/Switch
Back-Office Services Issuer Processing Prepaid Services
Billing Management Loyalty Programs Records Management
Clearing and Settlement Merchant Services Tax/Government Payments
Network Provider
Others (specify):
Part 4: Transaction Processing
Payment Application in use List facilities and locations included in PCI DSS Assessment:
Payment Application Version

Questions about use of the PCI DSS Prioritized Approach and its impacts on an organzition's PCI DSS compliance obligations should be directed to your acquirer or the payment brand(s). Prioritized Approach for PCI DSS v4.0 r1
 Prioritized Approach Summary & Acknowledgment

Estimated Date for Completion of

Milestone Goals Percent Complete
Milestone
Do not store sensitive authentication data and limit cardholder data retention. This milestone targets a key area of risk for
entities that have been compromised. Remember – if sensitive authentication data and other account data are not stored, the
1 effects of a compromise will be greatly reduced. If you don’t need it, don’t store it. 0.0%

Protect systems and networks and be prepared to respond to a system breach. This milestone targets controls for points of
2 access to most compromises and the response processes. 0.0%
Secure payment applications. This milestone targets controls for applications, application processes, and application servers.
3 Weaknesses in these areas are easy prey for compromising systems and obtaining access to cardholder data. 0.0%

Monitor and control access to your systems. Controls for this milestone allow you to detect the who, what, when, and how
4 concerning access to your network and cardholder data environment. 0.0%
Protect stored cardholder data. For those organizations that have analyzed their business processes and determined that they
5 must store Primary Account Numbers, this milestone targets key protection mechanisms for the stored data. 0.0%
Complete remaining compliance efforts, and ensure all controls are in place. This milestone completes PCI DSS
6 requirements and finishes all remaining related policies, procedures, and processes needed to protect the cardholder data
environment.
0.0%

Overall 0.0%

An organization submitting this form may be required to complete an Action Plan, located in each Attestation of Compliance in Part 4: Action Plan for Non-Compliant
Requirements. Check with your acquirer or the payment brand(s), since not all payment brands require completion of an Action Plan.
The Prioritized Approach tool is provided to assist organizations seeking to achieve compliance, but it does not, and is not intended in any manner to, modify or abridge PCI DSS or any of its requirements.

Part 5: Target Date for Achieving Full PCI DSS Compliance Date (YYYY-MM-DD) 2024-04-01

Part 6: Organization Acknowledgments (and QSA if applicable)

Name of Executive Officer

Signature of Executive Officer Date (YYYY-MM-DD)

Lead QSA Name (if applicable)
Signature of QSA Date (YYYY-MM-DD)

Questions about use of the PCI DSS Prioritized Approach and its impacts on an organzition's PCI DSS compliance obligations should be directed to your acquirer or the payment brand(s). Prioritized Approach for PCI DSS v4.0 r1
 PCI DSS v4.0 - Prioritized Approach Tool r1

If status is "No", please complete the following

Status
Please enter
If status is "N/A", please
"yes" Estimated Date for
PCI DSS Requirements v4.0 Milestone explain why requirement
if fully compliant Stage of Implementation Completion of Comments
is Not Applicable
with the Milestone
requirement

1.2.3 An accurate network diagram(s) is maintained that shows all connections

between the CDE and other networks, including any wireless networks.
Applicability Notes
A current network diagram(s) or other technical or topological solution that 1
identifies network connections and devices can be used to meet this requirement.

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.
Applicability Notes
A data-flow diagram(s) or other technical or topological solution that identifies flows 1
of account data across systems and networks can be used to meet this
requirement.

PCI Security Standards Council® 6 PCI DSS v4.0 - Prioritized Approach Tool r1
 PCI DSS v4.0 - Prioritized Approach Tool r1

3.2.1 Account data storage is kept to a minimum through implementation of data

retention and disposal policies, procedures, and processes that include at least the
following:
• Coverage for all locations of stored account data.
• Coverage for any sensitive authentication data (SAD) stored prior to
completion of authorization. This bullet is a best practice until its effective date;
refer to Applicability Notes below for details.
• Limiting data storage amount and retention time to that which is required for
legal or regulatory, and/or business requirements.
• Specific retention requirements for stored account data that defines length of
retention period and includes a documented business justification.
• Processes for secure deletion or rendering account data unrecoverable when
no longer needed per the retention policy.
• A process for verifying, at least once every three months, that stored account
data exceeding the defined retention period has been securely deleted or rendered
unrecoverable. 1
Applicability Notes
Where account data is stored by a TPSP (for example, in a cloud environment),
entities are responsible for working with their service providers to understand how
the TPSP meets this requirement for the entity. Considerations include ensuring
that all geographic instances of a data element are securely deleted.
The bullet above (for coverage of SAD stored prior to completion of authorization)
is a best practice until 31 March 2025, after which it will be required as part of
Requirement 3.2.1 and must be fully considered during a PCI DSS assessment.

3.3.1 SAD is not retained after authorization, even if encrypted. All sensitive
authentication data received is rendered unrecoverable upon completion of the
authorization process
Applicability Notes
This requirement does not apply to issuers and companies that support issuing 1
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.
3.3.1.1 The full contents of any track are not retained upon completion of the
authorization process.
Applicability Notes
In the normal course of business, the following data elements from the track may
need to be retained:
• Cardholder name. 1
• Primary account number (PAN).
• Expiration date.
• Service code.
To minimize risk, store securely only these data elements as needed for business.

3.3.1.2 The card verification code is not retained upon completion of the
authorization process.
Applicability Notes
The card verification code is the three- or four-digit number printed on the front or 1
back of a payment card used to verify card-not-present transactions.

3.3.1.3 The personal identification number (PIN) and the PIN block are not
retained upon completion of the authorization process.
Applicability Notes
PIN blocks are encrypted during the natural course of transaction processes, but 1
even if an entity encrypts the PIN block again, it is still not allowed to be stored
after the completion of the authorization process.

PCI Security Standards Council® 7 PCI DSS v4.0 - Prioritized Approach Tool r1
 PCI DSS v4.0 - Prioritized Approach Tool r1

3.3.2 SAD that is stored electronically prior to completion of authorization is

encrypted using strong cryptography.
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). 1
Refer to Requirement 3.3.3 for requirements specifically for issuers.
This requirement does not replace how PIN blocks are required to be managed,
nor does it mean that a properly encrypted PIN block needs to be encrypted again.
This requirement is a best practice until 31 March 2025, after which it will be
required and must be fully considered during a PCI DSS assessment.

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

9.4.6 Hard-copy materials with cardholder data are destroyed when no longer
needed for business or legal reasons, as follows:
• Materials are cross-cut shredded, incinerated, or pulped so that cardholder
data cannot be reconstructed.
• Materials are stored in secure storage containers prior to destruction.
Applicability Notes 1
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.

PCI Security Standards Council® 8 PCI DSS v4.0 - Prioritized Approach Tool r1
 PCI DSS v4.0 - Prioritized Approach Tool r1

9.4.7 Electronic media with cardholder data is destroyed when no longer needed
for business or legal reasons via one of the following:
• The electronic media is destroyed.
• The cardholder data is rendered unrecoverable so that it cannot be
reconstructed.
Applicability Notes 1
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.

PCI Security Standards Council® 9 PCI DSS v4.0 - Prioritized Approach Tool r1