Statewide Procurement Division

RFP NO. 304T-26-946M1 ADDENDUM NO. 1

CONTRACT SPECIALIST: Christy Ferro, CTCD, CTCM

PURPOSE OF ADDENDUM

CHANGE RESPONSE DUE DATE:

From: December 2, 2025 To: December 16, 2025

INCLUSION OF EXHIBITS

• Exhibit 1: PCI DSS (Payment Card Industry Data Security Standards)

• Exhibit 2: PCI PED (Payment Card Industry PIN Transaction Security Point of Interaction)

QUESTIONS AND ANSWERS: Reference Page two of this Addendum

THIS ADDENDUM SHALL BE ATTACHED TO AND FORM A PART OF THE REFERENCED RFP AND

THE CONTRACT.

RESPONDENT MUST ACKNOWLEDGE RECEIPT OF THIS ADDENDUM, BY SIGNING AND

RETURNING WITH RESPONSE. FAILURE TO SUBMIT THE SIGNED ADDENDUM MAY DISQUALIFY

THE RESPONSE.

RESPONDENT COMPANY NAME AUTHORIZED REPRESENTATIVE SIGNATURE

AUTHORIZED REPRESENTATIVE PRINTED NAME

Questions and Answers RFP No. 304T-26-946M1 Title:

Question No. Question Answer

Will State of TX DOT601 be participating in this RFP? We observed a past history of significant volume in 2018 that did not recur in subsequent years thereafter.

TXDOT 601 is eligible to participate; however, TXDOT Toll Operations (now part of Harris County Toll Road Authority) is no longer participating in this program. There is nothing preventing Harris County Toll Road Authority from participating in the future.

Can Respondent submit a pricing proposal in a tiered format to incentivize Texas SmartBuy Members and the State to increase volume and take advantage of lower tiered price points?

Multiple pricing proposals may be submitted. However, all Customers must be on the same plan with all volume tracked cumulatively for all Customers and the same discount applied to all.

3 What third party solutions are incorporated in your payment management model? Please include any ERP, CRM, or custom solutions. SnapPay Gateway through CardConnect; subsidiary of Fiserv.

4 Do you accept payment through other channels such as a mobile application, unattended kiosks, invoice presentment and management, call center, etc.? Assume all channels, excluding Texas.gov, may be applicable.

5 Are there any payment frictions or fraudulent activities that interrupt your payment management model? No.

6 Does the State have an existing bank-managed surcharge program? No.

7 Who does the State use as your QSA for PCI annual validations? The qualified security assessor for PCI annual validations is not available at this time.

The RFP states that agencies desire to continue using their existing equipment. Please confirm the willingness to replace equipment and if there is flexibility for agencies to replace equipment.

This may be an option for participants but not a requirement.

Please provide the version currently in use for each of the Clover device types listed below:

· Clover Station

· Clover Mini

· Clover Flex

Clover Station Duo 2, Clover Mini 3rd Gen, Clover Flex 3 and Clover Flex 4.

Are the the following terminals stand-alone devices, or are there POS systems these terminals integrate with?

· FD 150

· Ingenico 3000

· Ingenico Shred Key

· Website

· 3rd Party

Stand alone devices.

Regarding your website, can you provide any information related to current gateways or payment platforms being leveraged by the State?

a. Are your checkout experiences hosted or do you have custom checkout procedures?

b. Do you have a requirement for wallet services like Apple Pay, Google Pay, Paze, PayPal, etc.?

c. Are you storing customer information in the form of secure, tokenized profiles?

d. Do you have a requirement for recurring billing and subscription management?

Reference the NOTE in Part A, Section A.2 Description that specifically excludes Texas.gov transactions from this solicitation.

Merchant Card Services

Addendum No. 1

Question No. Question Answer

12 What is the Comptroller’s Office current provider(s) for these services? The current Contractor is First Data Merchant Services, LLC. (Fiserv)

Will the Comptroller’s Office please clarify which departments will be participating in this procurement?

o Do different departments currently have different pricing models / rates?

Reference Mandatory Price Sheet, tab labeled '2 - Historic Transaction Data' for list of current contract users.

As stated in Part A, Section A.2 Description, there are over 2,000 Texas SmartBuy Members who are eligible to purchase services off this Contract.

Pricing models/rates are the same for all users of the contract.

14 What payment channels does the Comptroller’s Office plan to offer (online, in-person, phone, etc.)?

Reference Part A, Section A.2. Description where CPA requests sealed responses for proposals to establish a contract for merchant card, automated clearing house (ACH) and eCheck services, which will enable State Agencies and Texas SmartBuy Members to accept payments using credit and debit cards, ACH and eCheck payments.

15 If the Comptroller’s Office plans to accept payments in-person, how many point-of-sale terminals and/or kiosks will be needed? Reference the Mandatory Price Sheet tab labeled '3 - Current Equipment'.

Does the Comptroller’s Office plan to accept any payment methods aside from credit cards under this procurement (debit cards, eChecks, digital wallets, etc.)?

See answer to question number 14.

17 What is the annual dollar volume anticipated under this contract? Can this be broken out by department and/or payment method?

Reference Mandatory Price Sheet, tab labeled '2 - Historic Transaction Data'

18 What is the annual transaction count anticipated under this contract? Can this be broken out by department and/or payment method? See answer to question number 17.

19 Will the awarded vendor(s) be required to integrate with any Comptroller’s Office software products? If so, what products?

No, the vendor will not be required to integrate with any Comptroller's office software products for point-of-sale transactions. However, Customers have various POS devices that may require integration.

Does the Comptroller’s Office currently pass a convenience fee on to its payers, or does the Comptroller’s Office pay its current vendor for processing fees?

o Does this differ by department/Merchant ID?

o In either scenario, what are the fees charged by the Comptroller’s Office’s current vendor(s)?

o Is the Comptroller’s Office open to changing the fee structure (i.e., from absorbed to convenience fee, or vice versa)?

Comptroller's Office pays the vendor for processing fees. It does not differ by department or MID. The fees are 0% settlement fee and $0.01 transaction fee and $0.04 gateway fee. The Comptroller's office is not open to changing the fee structure at this time.

21 Will the Comptroller’s Office accept electronic signatures such as DocuSign on proposal forms requiring signatures? Electronic Signatures are acceptable.

22 Can a vendor propose exceptions to the sample contract along with our proposal?

Reference Part A, Section A.17.11 Negotiations, Assumptions and Exceptions.

Section A. 7. 2 Operations states “electronic authorization services, including Internet, if other than Texas.gov and phone authorization, 24 hours per day, seven days per week”.

Please clarify from what payment channel you receive phone authorizations.

Do you utilize Interactive Voice Response (IVR) services?

Some Customers may receive phone calls from their customers and input card information via terminal.

Is the contracted merchant services provider required to provide services to all Texas SmartBuy Members, or does it have the right to refuse a member’s request for service?

CPA is unable to give a blanket answer to a general question.

Vendor will not have the right to refuse a request for service based on volume.

26 Is there a gateway/software that the processor is required to integrate with? Customers have various POS devices that may require integration.

27 Are you experiencing any issues with your current processor? If so, what are they?

Vendor Performance Reports can be found here:

https://www.txsmartbuy.gov/vpts?&page=1&vendorName=First%20Data

28 What is the contract start date? Reference Part A, Section A.3 Term of the Contract. Exact award date is unknown at this time.

29 Who is your current processor? See answer to question number 12.

30 In the pricing spreadsheet, tab 1.1 (row 38), please clarify what ‘ELAVON FEES’ are; what they are needed for?

This line on the Mandatory Price Sheet can be disregarded. Any entries on this row will be disregarded for purposes of evaluation.

31 Is the “Appendix listing” stated in B.2.4 the same as the confidential statement on letterhead in A.17.1?

The "Appendix listing" stated in Part B, Section B.2.4 is the same as the confidential statement on letterhead in Part A, Section A.17.1 Confidential/Proprietary Information.

A.15.1 states that the Respondent will be evaluated on a pass/fail basis on their ability to establish evidence of “sufficient financial resources to perform the contract and provide the service”. A.17.8 states “Respondent must provide evidence of financial responsibility and stability”. What financial evidence should Respondents provide?

Respondent shall provide financial evidence that they deem meets these requirements.

A.15.1 states CPA will evaluate the Respondent’s past performance on a pass/fail basis. What information does the Respondent need to provide for past performance?

Reference Part A, Section A.15.1 Investigations for examples of sources of information.

In the Mandatory Price Sheet, please provide average ticket price for each department for the FY24 table.

24 This is the information provided. The average ticket size will vary by Customer.

A.17.9 states Section A7 provides insight into what should be included in the 25 page Proposed Solutions response. A.17.9.1 provides the order that Section A7’s subsections should be presented in the respose. A7 subsections A.7.1, A.7.16 and A.7.17 are not specified within A.17.9.1. Where should subsections A.7.1, A.7.16 and A.7.17 be responded to?

As referenced in Part A, Section A.17.9 Proposed Solutions, in Section A.7, CPA has provided some insight into what should be provided.

However, this should not be considered an exhaustive list.

Please organize in a logical manner and reference the section(s) you are responding to.

35 A.17.9.1 references A.7.5 but A.7.5 references A.17.9.3. Should A.7.5 be responded to under A.17.9.1 or under A.17.9.3? See answer to question number 34.

36 Are the roles mentioned in A.7.5 in addition to the account manager and the three customer services representatives detailed in A.7.14?

The account manager and three customer service representatives detailed in A.7.14 are the minimum requirements.

A.7.14 list customer support as a dedicated account manager and three customer service representatives (CSR) and A.7.5 requests a person to specifically handle error resolution in regard to settlement of funds. Then B.4.1.2 adds a contract manager. Finally, Attachment B lists a representative for receipt of invoices. Taken together, this is six roles. Are we to name individuals for these six roles in our proposal?

Names are not required to be listed in the proposal, only identifed positions that will fulfill these functions.

Attachment B does not contain all the roles stated in the RFP. Should we add an additional page to Attachment B so that we can list all the individuals requested?

Attachment B is a general requirement for contact and identifying information about the Respondent.

Information about the personnel that will fulfill the roles required by the RFP should be detailed in your Response.

39 A.17.9.1 references A.7.8 but A.7.8 references A.17.9.5. Should A.7.8 be responded to under A.17.9.1 or under A.17.9.5? See answer to question number 34.

40 Please confirm that only A.17.9 is limited to 25 pages. The entire Response, excluding the Mandatory Price Sheet and required Attachments A-E, is limited to 25 pages.

41 Based on the large number of sections requiring responses under A.17.9, will CPA increase the page limit to 35 pages? CPA will not increase the response page limit.

42 Please confirm Appendices are not part of the 25 pages. See answer to question number 40.

43 What is the total MID count for the contract? Locations? 173 MIDSs; 136 locations

44 Is the Texas SmartBuy Membership Program limited to entities within the State of Texas? Yes.

45 The PCI DSS and PCI PED links provided return a “Page Not Found” error. See attached Exhibit 1 (PCI DSS) and Exhibit 2 (PCI PED)

46 What is the annual volume for ACH and eCheck transactions?

4/1/2023 - 3/31/2024 ACH Volume: 1,777 Transactions, $67,839.23 Total Spend eCheck Volume: 808 Transactions, $30,507.96 Total Spend

47 Who is your current ACH/eCheck provider? Telecheck

48 Can the State please provide a list of gateways and softwares that the vendor will need to integrate at the start of the new contract?

Currently, the Comptroller’s Office payment processing is connected through Fiserv, which serves as the current merchant card services provider for point-of-sale transactions. Depending on the outcome of this procurement, the selected vendor will serve as the new gateway. If a change occurs, the vendor’s solution will function as the primary integration point for all credit and debit card transactions (point-of-sale transactions).

49 Can chagrebacks and adjustments be debited when received or do those fall under the once per month requirement? Chargebacks and adjustments may be debited as they are received.

Does the State require references during the RFP phase or will you be requesting references between Evaluation Phase II and III? If now, please advise how many references you require.

Reference Part A, Section A.15.1 Investigations regarding references.

51 What is the annual volume for surcharges and convenience fees based transactions? What departments use these fees? This information is unavailable.

52 Are we permitted to use the State’s logo or photos from the State website on our response cover? No.

53 Do you accept business/commercial cards that require L2/L3 card data? Yes.

54 Do you accept virtual product cards? Yes.

55 Per historical data, the processing volume has fallen more than 75% since 2018. Will the contracted volume be for the State be $150 million per year?

See answer to question number 1.

Reference Part A, Section A. 2 Description, "no specific Customers or volumes are guaranteed under this RFP."

56 Per historical data, only 15 departments are listed. Will any other departments / locations be a part of this RFP?

Reference Part A, Section A.2 Description for potential use of this Contract.

57 Is TXDOT a part of this RFP (not on historical data after FY18)? See answer to question number 1.

Clover devices and FD devices are proprietary to First Data. Does the State possess devices from prior years that can be reprogrammed to work with the new vendor? Or will the State want all new devices?

A list of known equipment is referenced on the Mandatory Price Sheet, tab 3 - Current Equipment. Instances of incompatibility will be dealt with on a case by case basis.

Mandatory Price Sheet, Tab “2 – Historic Transaction Data”: Can the State confirm/explain the change in dollar volume and transactions across the fiscal years? Is the reduction attributable to Customers transitioning to Texas.gov or Texas SmartBuy Members selecting alternative contracts to process their transactions?

See answer to question number 1.

Mandatory Price Sheet, Tab “1.1 – Processing Fees”: Regarding the Transaction-Based Fees listed in Cells B17–B30, is the contractor expected to provide and price all of the items listed, or does this represent the current contractor’s price sheet?

Respondent should list all fees that they intend to charge. Any fee not listed will be assumed included at no additional charge.

RFP Section 1.7.4 Payment Gateway, page 15: Please provide what gateways are in use by Customers today. Additionally, is it the expectation that the incoming contractor provide these existing gateways or just provide the gateways that are used for their solution?

SnapPay Gateway through CardConnect; subsidiary of Fiserv.

Also, see answer to question number 48.

62 Please provide a breakdown of departments that will use payer funded services fees, and those that will absorb the cost of the payments This information is unavailable.

63 Does the vendor need to provide IVR (Interactive Voice Response) lines for any of the participating departments? No.

64 If known, please supply the number of debit/credit card chargebacks in the last 12 months. 710 chargebacks from Oct 1, 2024 to Oct 31, 2025.

65 If known, please supply the number of e-check returns in the last 12 months. None.

It looks like a number of departments have transitioned their payments over to Texas.gov. Are any more departments still using the contract going to move payments over to Texas.gov?

See answer to question number 56.

67 If the volume has decreased for reasons other than a move to Texas.gov, please explain. See answer to question number 1.

Looking at Attachment F and comparing it to “2 - Historic Transaction Data”, it looks like of the $132.8M 2024 volume, $22.9M is card, and about $112.9M is e-check. Is this correct? If incorrect, please provide the split between card and e-check/ACH.

This report is an example of an acceptable format. The data is sample only.

In the “2 - Historic Transaction Data” tab in “ESBD_458413_1759519814771_5_Mandatory Price Sheet 946M1 Merchant Card” you provide data for 2016, 2017, 2018, 2022, 2023, 2024.

Why are the years 2019, 2020, and 2021 missing?

2019-2021 were transition years for the then new contract, and period when spend dramatically affected by COVID. We do not feel like this data is representative of "normal".

70 Does “ESBD_458413_1759519816601_4_Attachment F 946M1 Merchant Card” contain a full list of the 137 MIDs currently in use under this contract? See answer to question number 68.

Payment Card Industry Data Security Standard

Requirements and Testing Procedures Version 4.0.1 June 2024

Exhibit 1

Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0.1 June 2024 ©2006 - 2024 PCI Security Standards Council, LLC. All Rights Reserved. Page i

Document Changes

Date Version Description

October 2008 1.2 To introduce PCI DSS v1.2 as “PCI DSS Requirements and Security Assessment Procedures,” eliminating redundancy between documents, and making both general and specific changes from PCI DSS Security Audit Procedures v1.1. For complete information, see PCI Data Security Standard Summary of Changes from PCI DSS Version 1.1 to 1.2.

July 2009 1.2.1 Add sentence that was incorrectly deleted between PCI DSS v1.1 and v1.2.

Correct “then” to “than” in testing procedures 6.3.7.a and 6.3.7.b.

Remove grayed-out marking for “in place” and “not in place” columns in testing procedure 6.5.b.

For Compensating Controls Worksheet – Completed Example, correct wording at top of page to say, “Use this worksheet to define compensating controls for any requirement noted as “in place” via compensating controls.”

October 2010 2.0 Update and implemented changes from v1.2.1. See PCI DSS – Summary of Changes from PCI DSS Version 1.2.1 to 2.0.

November 2013 3.0 Update from v2.0. See PCI DSS – Summary of Changes from PCI DSS Version 2.0 to 3.0.

April 2015 3.1 Update from PCI DSS v3.0. See PCI DSS – Summary of Changes from PCI DSS Version 3.0 to 3.1 for details of changes.

April 2016 3.2 Update from PCI DSS v3.1. See PCI DSS – Summary of Changes from PCI DSS Version 3.1 to 3.2 for details of changes.

May 2018 3.2.1 Update from PCI DSS v3.2. See PCI DSS – Summary of Changes from PCI DSS Version 3.2 to 3.2.1 for details of changes.

March 2022 4.0 Rename document title to “Payment Card Industry Data Security Standard: Requirements and Testing Procedures.”

Update from PCI DSS v3.2.1. See PCI DSS – Summary of Changes from PCI DSS Version 3.2.1 to 4.0 for details of changes.

June 2024 4.0.1 Update from PCI DSS v4.0. See PCI DSS - Summary of Changes from PCI DSS Version 4.0 to 4.0.1 for details of changes.

©2006 - 2024 PCI Security Standards Council, LLC. All Rights Reserved. Page ii

Contents 1 Introduction and PCI Data Security Standard Overview 2 PCI DSS Applicability Information 3 Relationship between PCI DSS and PCI SSC Software Standards 4 Scope of PCI DSS Requirements 5 Best Practices for Implementing PCI DSS into Business-as-Usual Processes 6 For Assessors: Sampling for PCI DSS Assessments 7 Description of Timeframes Used in PCI DSS Requirements 8 Approaches for Implementing and Validating PCI DSS 9 Protecting Information About an Entity’s Security Posture 10 Testing Methods for PCI DSS Requirements 11 Instructions and Content for Report on Compliance 12 PCI DSS Assessment Process 13 Additional References 14 PCI DSS Versions 15 Detailed PCI DSS Requirements and Testing Procedures

Build and Maintain a Secure Network and Systems

Protect Account Data

Maintain a Vulnerability Management Program

Implement Strong Access Control Measures

©2006 - 2024 PCI Security Standards Council, LLC. All Rights Reserved. Page iii

Regularly Monitor and Test Networks

Maintain an Information Security Policy

Appendix A Additional PCI DSS Requirements

Appendix B Compensating Controls Appendix C Compensating Controls Worksheet Appendix D Customized Approach Appendix E Sample Templates to Support Customized Approach Appendix F Leveraging the PCI Software Security Framework to Support Requirement 6 Appendix G PCI DSS Glossary of Terms, Abbreviations, and Acronyms

©2006 - 2024 PCI Security Standards Council, LLC. All Rights Reserved. Page 1

1 Introduction and PCI Data Security Standard Overview The Payment Card Industry Data Security Standard (PCI DSS) was developed to encourage and enhance payment account data security and facilitate the broad adoption of consistent data security measures globally. PCI DSS provides a baseline of technical and operational requirements designed to protect account data. While specifically designed to focus on environments with payment account data, PCI DSS can also be used to protect against threats and secure other elements in the payment ecosystem.

Table 1 shows the 12 principal PCI DSS requirements.

Table 1. Principal PCI DSS Requirements

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.

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 testing procedures, and other information pertinent to each requirement.

The following sections provide detailed guidelines and best practices to assist entities to prepare for, conduct, and report the results of a PCI DSS assessment. The PCI DSS requirements and testing procedures begin on page 43.

©2006 - 2024 PCI Security Standards Council, LLC. All Rights Reserved. Page 2

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

Limitations If any of the requirements contained in this standard conflict with country, state, or local laws, the country, state, or local law will apply.

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:

Document Library, including:

– PCI DSS Summary of Changes

– PCI DSS Quick Reference Guide

– Information Supplements and Guidelines

– Prioritized Approach for PCI DSS

– Report on Compliance (ROC) Reporting Template and Reporting Instructions

– Self-Assessment Questionnaires (SAQs) and SAQ Instructions and Guidelines

– Attestations of Compliance (AOCs)

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)

Lists of PCI approved devices, applications, and solutions https://www.pcisecuritystandards.org/

©2006 - 2024 PCI Security Standards Council, LLC. All Rights Reserved. Page 3

There are over 60 guidance documents and information supplements available on the PCI SSC website that provide specific guidance and considerations for PCI DSS. Examples include:

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.

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.

https://www.pcisecuritystandards.org/

©2006 - 2024 PCI Security Standards Council, LLC. All Rights Reserved. Page 4

2 PCI DSS Applicability Information 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 and/or sensitive authentication data. This includes all entities involved in payment account processing —including merchants, processors, acquirers, issuers, and other service providers.

Whether any entity is required to comply with or validate their compliance to PCI DSS is at the discretion of those organizations that manage compliance programs (such as payment brands and acquirers); contact these organizations for any additional criteria.

Defining Account Data, Cardholder Data, and Sensitive Authentication Data Cardholder data and sensitive authentication data are considered account data and are defined as follows:

Table 2. Account Data

Account Data

Cardholder Data includes: Sensitive Authentication Data includes:

• Primary Account Number (PAN)

• Cardholder Name

• Expiration Date

• Service Code

• Full track data (magnetic-stripe data or equivalent on a chip)

• Card verification code

• PINs/PIN blocks

PCI DSS requirements apply to entities with environments where account data (cardholder data and/or sensitive authentication data) is stored, processed, or transmitted, and entities with environments that can impact the security of cardholder data and/or sensitive authentication data.

Some PCI DSS requirements may also apply to entities with environments that do not store, process, or transmit account datafor example, entities that outsource payment operations or management of their cardholder data environment (CDE) 1. Entities that outsource their payment environments or payment operations to third parties remain responsible for ensuring that the account data is protected by the third party per applicable PCI DSS requirements.

1 In accordance with those organizations that manage compliance programs (such as payment brands and acquirers); entities should contact these organizations for more details.

©2006 - 2024 PCI Security Standards Council, LLC. All Rights Reserved. Page 5

The primary account number (PAN) is the defining factor for cardholder data. The term account data therefore covers the following: the full PAN, any other elements of cardholder data that are present with the PAN, and any elements of sensitive authentication data.

If cardholder name, service code, and/or expiration date are stored, processed, or transmitted with the PAN, or are otherwise present in the CDE, they must be protected in accordance with the PCI DSS requirements applicable to cardholder data.

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 cardholder data and/or sensitive authentication data because the security of an entity’s infrastructure can affect how cardholder data is processed (for example, via a web server that controls the generation of a payment form or page) some requirements will be applicable.

If cardholder data is only present on physical media (for example paper), requirements relating to the security and disposal of physical media in Requirement 9 will be applicable.

Requirements related to an incident response plan are applicable to all entities, to ensure that there are procedures to follow in the event of a suspected or actual breach of the confidentiality of cardholder data.

Use of Account Data, Sensitive Authentication Data, Cardholder Data, and Primary Account Number in PCI DSS PCI DSS includes requirements that specifically refer to account data, cardholder data, and sensitive authentication data. It is important to note that each of these types of data are different and the terms are not interchangeable. Specific references within requirements to account data, cardholder data, or sensitive authentication data are purposeful, and the requirements apply specifically to the type of data that is referenced.

©2006 - 2024 PCI Security Standards Council, LLC. All Rights Reserved. Page 6

Elements of Account Data and Storage Requirements 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

A cc ou nt

D at a

Cardholder Data

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

Data

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 code

PIN/PIN Block

If PAN is stored with other elements of cardholder data, only the PAN must be rendered unreadable according to PCI DSS Requirement 3.5.1.

Sensitive authentication data must not be stored after authorization, even if encrypted. This applies even for environments where there is no PAN present.

2 Where data exists in the same environment as PAN.

3 Except as permitted for issuers and companies that support issuing services. Requirements for issuers and issuing services are separately defined in Requirement 3.3.3.

©2006 - 2024 PCI Security Standards Council, LLC. All Rights Reserved. Page 7

3 Relationship between PCI DSS and PCI SSC Software Standards PCI SSC supports the use of secure payment software within cardholder data environments (CDE) via 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 integrity and confidentiality of payment transactions and account data.

Qualified Software Vendors: The Secure SLC Standard defines security requirements for software vendors to integrate secure software development practices throughout the entire software lifecycle. Software vendors that have been validated as meeting the Secure SLC Standard are listed on the PCI SSC website as a Secure SLC Qualified Vendor.

For more information about the SSF or PA-DSS, refer to the respective Program Guides at www.pcisecuritystandards.org.

All software that stores, processes, or transmits account data, or that could impact the security of cardholder data and/or sensitive authentication data, is in scope for an entity’s PCI DSS assessment. While the use of validated payment software supports the security of an entity’s CDE, the use of such software does not by itself make an entity PCI DSS compliant. The entity’s PCI DSS assessment should include verification that the software is properly configured and securely implemented to support applicable PCI DSS requirements. Additionally, if PCI-listed payment software has been customized, a more in-depth review will be required during the PCI DSS assessment because the software may no longer be representative of the version that was originally validated.

Because security threats are constantly evolving, software that is no longer supported by the vendor (for example, identified by the vendor as “end of life”) may not offer the same level of security as supported versions. Entities are strongly encouraged to keep their software current and updated to the latest software versions available.

Entities that develop their own software are encouraged to refer to PCI SSC’s software security standards and consider the requirements therein as best practices to use in their development environments. Secure payment software implemented in a PCI DSS compliant environment will help minimize the potential for security breaches leading to compromises of account data and fraud. See Bespoke and Custom Software.

Note: PA-DSS and the related program were retired in October 2022. Refer to the PCI SSC List of Validated Payment Applications for expiry dates for PA-DSS validated applications. Since the expiry date, applications are listed as “Acceptable only for Pre-Existing Deployments.” Whether an entity can continue to use a PA-DSS application with an expired listing is at the discretion of organizations that manage compliance programs (such as payment brands and acquirers); entities should contact these organizations for more details.

http://www.pcisecuritystandards.org/

©2006 - 2024 PCI Security Standards Council, LLC. All Rights Reserved. Page 8

Applicability of PCI DSS to Payment Software Vendors 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 cardholder data and/or sensitive authentication data, 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 the Secure SLC standard) will support an entity in meeting PCI DSS Requirement 6.

See Appendix F for more details.

Note: PCI DSS Requirement 6 fully applies to bespoke and custom software that has not been developed and maintained in accordance with one of PCI SSC’s Software Security Framework standards. Entities that use software vendors to develop bespoke or custom software that could impact the security of their cardholder data and/or sensitive authentication data are responsible for ensuring those software vendors develop the software according to PCI DSS Requirement 6.

©2006 - 2024 PCI Security Standards Council, LLC. All Rights Reserved. Page 9

4 Scope of PCI DSS Requirements PCI DSS requirements apply to:

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

– System components, people, and processes that store, process, or 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.

AND

System components, people, and processes that could impact the security of cardholder data and/or sensitive authentication data. 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, badge access or CCTV), multi-factor authentication systems, anti-malware systems).

Systems that facilitate segmentation (for example, internal network security controls).

Systems that could impact the security of account data or the CDE (for example, name resolution, or e-commerce (web) redirection servers).

Virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors.

Cloud infrastructure and components, both external and on premises, and including instantiations of containers or images, virtual private clouds, cloud-based identity and access management, CDEs residing on premises or in the cloud, service meshes with containerized applications, and container orchestration tools.

4 For additional guidance, refer to Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation on the PCI SSC website.

©2006 - 2024 PCI Security Standards Council, LLC. All Rights Reserved. Page 10

Network components, including but not limited to network security controls, switches, routers, VoIP network devices, wireless access points, network appliances, and other security appliances.

Server types, including but not limited to web, application, database, authentication, mail, proxy, Network Time Protocol (NTP), and Domain Name System (DNS).

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

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.

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.

©2006 - 2024 PCI Security Standards Council, LLC. All Rights Reserved. Page 11

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

Figure 1. Understanding PCI DSS Scoping

©2006 - 2024 PCI Security Standards Council, LLC. All Rights Reserved. Page 12

Annual PCI DSS Scope Confirmation The first step in preparing for a PCI DSS assessment is for the entity to accurately determine the scope of the review. The assessed entity must confirm the accuracy of their PCI DSS scope according to PCI DSS Requirement 12.5.2 by identifying all locations and flows of account data, and identifying all systems that are connected to or, if compromised, could impact the CDE (for example, authentication servers, remote access servers, logging servers) to ensure they are included in the PCI DSS scope. All types of systems and locations should be considered during the scoping process, including backup/recovery sites and fail-over systems.

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.

Segmentation Segmentation (or isolation) of the CDE from the remainder of an entity’s network is not a PCI DSS requirement. However, it is strongly recommended as a method that may reduce the:

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 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 configured internal network security controls, 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 for PCI DSS, a system component must be properly segmented (isolated) from the CDE, such that the out-of-scope system component could not impact the security of cardholder data and/or sensitive authentication data, even if that component was compromised.

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.

©2006 - 2024 PCI Security Standards Council, LLC. All Rights Reserved. Page 13

Documenting account data flows via a data-flow diagram helps an entity fully understand how account data comes into an organization, where it resides within the organization, and how it traverses through various systems within the organization. Data-flow diagrams also illustrate all locations where account data is stored, processed, and transmitted. This information supports an entity implementing segmentation and can also support confirming that segmentation is being used to isolate the CDE from out-of-scope networks.

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.

Figure 2. Segmentation and Impact to PCI DSS Scope

©2006 - 2024 PCI Security Standards Council, LLC. All Rights Reserved. Page 14

Wireless If wireless technology is used to store, process, or transmit account data (for example, wireless point-of-sale devices), or if a wireless local area network (WLAN) is part of or connected to the CDE, the PCI DSS requirements and testing procedures for securing wireless environments apply and must be performed.

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.

When Cardholder Data and/or Sensitive Authentication Data is Accidentally Received via an Unintended Channel

There could be occurrences where an entity receives cardholder data and/or sensitive authentication data unsolicited via an insecure communication channel that was not intended for the purpose of receiving 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

Securely delete the data and implement measures to prevent the channel from being used in the future for sending such data.

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 DSS in that environment. The entity’s environment is still in scope for PCI DSS due to the presence of cardholder data. For example, for a merchant card-present environment, there is physical access to the payment cards to complete a transaction and there may also be paper reports or receipts with cardholder data. Similarly, in merchant card-not-present environments, such as mail-order/telephone-order and e-commerce, payment card details are provided via channels that need to be evaluated and protected according to

PCI DSS.

The following are each in scope for PCI DSS:

Systems performing encryption and/or decryption of cardholder data, and systems performing key management functions, Encrypted cardholder data that is not isolated from the encryption and decryption and key management processes, ©2006 - 2024 PCI Security Standards Council, LLC. All Rights Reserved. Page 15

Encrypted cardholder data that is present on a system or media that also contains the decryption key, Encrypted cardholder data that is present in the same environment as the decryption key, Encrypted cardholder data that is accessible to an entity that also has access to the decryption key.

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 party, and the agreement between parties.