Exhibit D- SAQ D.pdf.crdownload

Payment Card Industry Data Security Standard

Self-Assessment Questionnaire D for Merchants and Attestation of Compliance For use with PCI DSS Version 4.0 Revision 1 Publication Date: December 2022

Docusign Envelope ID: 82B05173-EAEA-47BE-94C5-D5FE83830115

PCI DSS v4.0 SAQ D for Merchants r1 December 2022 © 2006-2022 PCI Security Standards Council, LLC. All Rights Reserved. Page i

Document Changes

Date PCI DSS Version

SAQ

Revision Description

October 2008 1.2 To align content with new PCI DSS v1.2 and to implement minor changes noted since original v1.1.

October 2010 2.0 To align content with new PCI DSS v2.0 requirements and testing procedures.

February 2014 3.0 To align content with PCI DSS v3.0 requirements and testing procedures and incorporate additional response options.

April 2015 3.1 Updated to align with PCI DSS v3.1. For details of PCI DSS changes, see PCI DSS – Summary of Changes from PCI DSS Version 3.0 to 3.1.

July 2015 3.1 1.1 Updated to remove references to “best practices” prior to June 30, 2015, and remove the PCI DSS v2 reporting option for Requirement 11.3.

April 2016 3.2 1.0 Updated to align with PCI DSS v3.2. For details of PCI DSS changes, see PCI DSS – Summary of Changes from PCI DSS Version 3.1 to 3.2.

January 2017 3.2 1.1 Updated version numbering to align with other SAQs.

June 2018 3.2.1 1.0 Updated to align with PCI DSS v3.2.1. For details of PCI DSS changes, see PCI DSS – Summary of Changes from PCI DSS Version 3.2 to 3.2.1.

April 2022 4.0

Updated to align with PCI DSS v4.0. For details of PCI DSS changes, see PCI DSS – Summary of Changes from PCI DSS Version 3.2.1 to 4.0.

Rearranged, retitled, and expanded information in the “Completing the Self-Assessment Questionnaire” section (previously titled “Before You Begin”).

Aligned content in Sections 1 and 3 of Attestation of Compliance (AOC) with PCI DSS v4.0 Report on Compliance

AOC.

Added appendices to support new reporting responses.

December 2022 4.0 1

Removed “In Place with Remediation” as a reporting option from Requirement Responses table, Attestation of Compliance (AOC) Part 2g, SAQ Section 2 Response column, and AOC Section 3. Also removed former Appendix C.

Added “In Place with CCW” to AOC Section 3.

Added guidance for responding to future-dated requirements.

Added minor clarifications and addressed typographical errors.

PCI DSS v4.0 SAQ D for Merchants r1 December 2022 © 2006-2022 PCI Security Standards Council, LLC. All Rights Reserved. Page ii

Contents

Document Changes ..................................................................................................................... i Completing the Self-Assessment Questionnaire ................................................................... iii

Merchant Eligibility Criteria for Self-Assessment Questionnaire D .................................................. iii Defining Account Data, Cardholder Data, and Sensitive Authentication Data ................................. iii PCI DSS Self-Assessment Completion Steps ..................................................................................... iv Expected Testing .................................................................................................................................. iv Requirement Responses ........................................................................................................................ v Additional PCI SSC Resources ........................................................................................................... viii

Section 1: Assessment Information Section 2: Self-Assessment Questionnaire D for Merchants

Build and Maintain a Secure Network and Systems Requirement 1: Install and Maintain Network Security Controls Requirement 2: Apply Secure Configurations to All System Components

Protect Account Data Requirement 3: Protect Stored Account Data Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks Maintain a Vulnerability Management Program

Requirement 5: Protect All Systems and Networks from Malicious Software Requirement 6: Develop and Maintain Secure Systems and Software

Implement Strong Access Control Measures Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to

Know Requirement 8: Identify Users and Authenticate Access to System Components Requirement 9: Restrict Physical Access to Cardholder Data

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

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

Appendix A: Additional PCI DSS Requirements Appendix A1: Additional PCI DSS Requirements for Multi-Tenant Service Providers Appendix A2: Additional PCI DSS Requirements for Entities using SSL/Early TLS for Card-Present

POS POI Terminal Connections Appendix A3: Designated Entities Supplemental Validation (DESV)

Appendix B: Compensating Controls Worksheet Appendix C: Explanation of Requirements Noted as Not Applicable Appendix D: Explanation of Requirements Noted as Not Tested

Section 3: Validation and Attestation Details

PCI DSS v4.0 SAQ D for Merchants r1, Completing the SAQ December 2022 © 2006-2022 PCI Security Standards Council, LLC. All Rights Reserved. Page iii

Completing the Self-Assessment Questionnaire

Merchant Eligibility Criteria for Self-Assessment Questionnaire D Self-Assessment Questionnaire (SAQ) D for Merchants applies to merchants that are eligible to complete a self-assessment questionnaire but do not meet the criteria for any other SAQ type. Examples of merchant environments to which SAQ D may apply include but are not limited to:

§ E-commerce merchants that accept account data on their website.

§ Merchants with electronic storage of account data.

§ Merchants that don’t store account data electronically but that do not meet the criteria of another SAQ type.

§ Merchants with environments that might meet the criteria of another SAQ type, but that have additional PCI DSS requirements applicable to their environment.

This SAQ is not applicable to service providers.

Defining Account Data, Cardholder Data, and Sensitive Authentication Data

PCI DSS is intended for all entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD) or could impact the security of the cardholder data environment (CDE).

Cardholder data and sensitive authentication data are considered account data and are defined as follows:

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

Refer to PCI DSS Section 2, PCI DSS Applicability Information, for further details.

© 2006-2022 PCI Security Standards Council, LLC. All Rights Reserved. Page iv

PCI DSS Self-Assessment Completion Steps

1. Confirm by review of the eligibility criteria in this SAQ and the Self-Assessment Questionnaire Instructions and Guidelines document on PCI SSC website that this is the correct SAQ for the merchant’s environment.

2. Confirm that the merchant environment is properly scoped.

3. Assess environment for compliance with PCI DSS requirements.

4. Complete all sections of this document:

• Section 1: Assessment Information (Parts 1 & 2 of the Attestation of Compliance (AOC) – Contact Information and Executive Summary).

• Section 2: Self-Assessment Questionnaire D for Merchants.

• Section 3: Validation and Attestation Details (Parts 3 & 4 of the AOC – PCI DSS Validation and Action Plan for Non-Compliant Requirements (if Part 4 is applicable)).

5. Submit the SAQ and AOC, along with any other requested documentation—such as ASV scan reports—to the requesting organization (those organizations that manage compliance programs such as payment brands and acquirers).

Expected Testing

The instructions provided in the “Expected Testing” column are based on the testing procedures in PCI DSS and provide a high-level description of the types of testing activities that a merchant is expected to perform to verify that a requirement has been met.

The intent behind each testing method is described as follows:

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

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

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

The testing methods are intended to allow the merchant to demonstrate how it has met a requirement.

The specific items to be examined or observed and personnel to be interviewed should be appropriate for both the requirement being assessed and the merchant’s particular implementation.

Full details of testing procedures for each requirement can be found in PCI DSS.

© 2006-2022 PCI Security Standards Council, LLC. All Rights Reserved. Page v

Requirement Responses

For each requirement item, there is a choice of responses to indicate the merchant’s status regarding that requirement. Only one response should be selected for each requirement item.

A description of the meaning for each response is provided in the table below:

Response When to use this response:

In Place The expected testing has been performed, and all elements of the requirement have been met as stated.

In Place with CCW

(Compensating Controls Worksheet)

The expected testing has been performed, and the requirement has been met with the assistance of a compensating control.

All responses in this column require completion of a Compensating Controls Worksheet (CCW) in Appendix B of this SAQ.

Information on the use of compensating controls and guidance on how to complete the worksheet is provided in PCI DSS Appendices B and C.

Not Applicable The requirement does not apply to the merchant’s environment. (See “Guidance for Not Applicable Requirements” below for examples.)

All responses in this column require a supporting explanation in Appendix C of this

SAQ.

Not Tested The requirement was not included for consideration in the assessment and was not tested in any way. (See “Understanding the Difference between Not Applicable and Not Tested” below for examples of when this option should be used.)

All responses in this column require a supporting explanation in Appendix D of this

SAQ.

Not in Place Some or all elements of the requirement have not been met, or are in the process of being implemented, or require further testing before the merchant can confirm they are in place. Responses in this column may require the completion of Part 4, if requested by the entity to which this SAQ will be submitted.

This response is also used if a requirement cannot be met due to a legal restriction.

(See “Legal Exception” below for more guidance).

© 2006-2022 PCI Security Standards Council, LLC. All Rights Reserved. Page vi

Guidance for Not Applicable Requirements While many merchants completing SAQ D will need to validate compliance with every PCI DSS requirement, some entities with very specific business models may find that some requirements do not apply. For example, entities that do not use wireless technology in any capacity are not expected to comply with the PCI DSS requirements that are specific to managing wireless technology. Similarly, entities that do not store any account data electronically at any time are not expected to comply with the PCI DSS requirements related to secure storage of account data (for example, Requirement 3.5.1).

Another example is requirements specific to application development and secure coding (for example, Requirements 6.2.1 through 6.2.4), which only apply to an entity with bespoke software (developed for the entity by a third party per the entity’s specifications) or custom software (developed by the entity for its own use).

For each response where Not Applicable is selected in this SAQ, complete Appendix C: Explanation of Requirements Noted as Not Applicable.

Understanding the Difference between Not Applicable and Not Tested Requirements that are deemed to be not applicable to an environment must be verified as such. Using the wireless example above, for a merchant to select “Not Applicable” for Requirements 1.3.3, 2.3.1, 2.3.2, and 4.2.1.2, the merchant first needs to confirm that there are no wireless technologies used in its cardholder data environment (CDE) or that connect to their CDE. Once this has been confirmed, the merchant may select “Not Applicable” for those specific requirements.

If a requirement is completely excluded from review without any consideration as to whether it could apply, the “Not Tested” option should be selected. Examples of situations where this could occur may include:

§ A merchant is asked by their acquirer to validate a subset of requirements—for example, using the PCI DSS Prioritized Approach to validate only certain milestones.

§ A merchant is confirming a new security control that impacts only a subset of requirements—for example, implementation of a new encryption methodology that only requires assessment of PCI DSS Requirements 2, 3, and 4.

In these scenarios, the merchant’s assessment only includes certain PCI DSS requirements even though other requirements might also apply to its environment.

If any requirements are completely excluded from the merchant’s self-assessment, select Not Tested for that specific requirement, and complete Appendix D: Explanation of Requirements Not Tested for each “Not Tested” entry. An assessment with any Not Tested responses is a “Partial” PCI DSS assessment and will be noted as such by the merchant in the Attestation of Compliance in Section 3, Part 3 of this

SAQ.

© 2006-2022 PCI Security Standards Council, LLC. All Rights Reserved. Page vii

Guidance for Responding to Future Dated Requirements In Section 2 below, each new PCI DSS v4.0 requirement or bullet with an extended implementation period includes the following note: “This requirement [or bullet] is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.”

These new requirements are not required to be included in a PCI DSS assessment until the future date has passed. Prior to that future date, any new requirements with an extended implementation date that have not been implemented by the merchant may be marked as Not Applicable and documented in Appendix C: Explanation of Requirements Noted as Not Applicable.

Legal Exception If your organization is subject to a legal restriction that prevents the organization from meeting a PCI DSS requirement, select Not in Place for that requirement and complete the relevant attestation in Section 3, Part 3 of this SAQ.

Note: A legal restriction is one where meeting the PCI DSS requirement would violate a local or regional law or regulation.

Contractual obligations or legal advice are not legal restrictions.

Use of the Customized Approach

SAQs cannot be used to document use of the Customized Approach to meet PCI DSS requirements. For this reason, the Customized Approach Objectives are not included in SAQs. Entities wishing to validate using the Customized Approach may be able to use the PCI DSS Report on Compliance (ROC) Template to document the results of their assessment.

The use of the customized approach may be regulated by organizations that manage compliance programs, such as payment brands and acquirers. Questions about use of a customized approach should always be referred to those organizations. This includes whether an entity that is eligible for an SAQ may instead complete a ROC to use a customized approach, and whether an entity is required to use a QSA, or may use an ISA, to complete an assessment using the customized approach. Information about the use of the Customized Approach can be found in Appendices D and E of PCI DSS.

Use of the Customized Approach is not supported in SAQs.

© 2006-2022 PCI Security Standards Council, LLC. All Rights Reserved. Page viii

Additional PCI SSC Resources Additional resources that provide guidance on PCI DSS requirements and how to complete the self-assessment questionnaire have been provided below to assist with the assessment process.

Resource Includes:

PCI DSS

(PCI Data Security Standard Requirements and Testing Procedures)

§ Guidance on Scoping § Guidance on the intent of all PCI DSS Requirements § Details of testing procedures § Guidance on Compensating Controls § Appendix G: Glossary of Terms, Abbreviations, and

Acronyms

SAQ Instructions and Guidelines § Information about all SAQs and their eligibility criteria § How to determine which SAQ is right for your organization

Frequently Asked Questions (FAQs) § Guidance and information about SAQs.

Online PCI DSS Glossary § PCI DSS Terms, Abbreviations, and Acronyms

Information Supplements and Guidelines § Guidance on a variety of PCI DSS topics including:

- Understanding PCI DSS Scoping and Network

Segmentation

- Third-Party Security Assurance

- Multi-Factor Authentication Guidance

- Best Practices for Maintaining PCI DSS

Compliance

Getting Started with PCI § Resources for smaller merchants including:

- Guide to Safe Payments

- Common Payment Systems

- Questions to Ask Your Vendors

- Glossary of Payment and Information Security

Terms

- PCI Firewall Basics

These and other resources can be found on the PCI SSC website (www.pcisecuritystandards.org).

Organizations are encouraged to review PCI DSS and other supporting documents before beginning an assessment.

PCI DSS v4.0 SAQ D for Merchants r1, Section 1: AOC Assessment Information December 2022 © 2006-2022 PCI Security Standards Council, LLC. All Rights Reserved. Page 1

Section 1: Assessment Information Instructions for Submission This document must be completed as a declaration of the results of the merchant’s self-assessment against the Payment Card Industry Data Security Standard (PCI DSS) Requirements and Testing Procedures. Complete all sections. The merchant is responsible for ensuring that each section is completed by the relevant parties, as applicable. Contact the entity(ies) to which the Attestation of Compliance (AOC) will be submitted for reporting and submission procedures.

Part 1. Contact Information Part 1a. Assessed Merchant Company name: Washington State University

DBA (doing business as):

Company mailing address: 220J French Administration Building, PO Box 641025, Pullman, WA 99164

Company main website: www.wsu.edu

Company contact name: Arthur Whitten

Company contact title: Director of Treasury Services

Contact phone number: (509) 335-8154

Contact e-mail address: arthur.whittten@wsu.edu

Part 1b. Assessor

Provide the following information for all assessors involved in the assessment. If there was no assessor for a given assessor type, enter Not Applicable.

PCI SSC Internal Security Assessor(s)

ISA name(s): Not Applicable

Qualified Security Assessor

Company name: SecurityMetrics, Inc.

Company mailing address: 1275 W 1600 N, Orem, UT 84057

Company website: www.securitymetrics.com

Lead Assessor Name: Michael Simpson

Assessor phone number: (801) 705-5647

Assessor e-mail address: michael@securitymetrics.com

Assessor certificate number: 202-108

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

Part 2. Executive Summary Part 2a. Merchant Business Payment Channels (select all that apply):

Indicate all payment channels used by the business that are included in this assessment.

Mail order/telephone order (MOTO)

E-Commerce

Card-present Are any payment channels not included in this assessment?

If yes, indicate which channel(s) is not included in the assessment and provide a brief explanation about why the channel was excluded.

Yes No

Not Applicable

Note: If the organization has a payment channel that is not covered by this SAQ, consult with the entity(ies) to which this AOC will be submitted about validation for the other channels.

Part 2b. Description of Role with Payment Cards

For each payment channel included in this assessment as selected in Part 2a above, describe how the business stores, processes, and/or transmits account data.

Channel How Business Stores, Processes, and/or Transmits Account Data

MOTO Cardholder data received via MOTO payment channels is processed on a mix of cellular-connected PTS-approved POI terminals, analog-connected POI terminals, and POI terminals that are included in either an end-to-end encrypted payment solution or a P2PE-validated payment solution.

E-Commerce Payment capture and transmission for e-commerce payment processes have been outsourced to PCI DSS-compliant TPSPs. In some instances, WSU hosts e-commerce shopping cart web servers that fully redirect customers to a TPSP-managed checkout page for payment capture and processing. Other e-commerce solutions in place at WSU have been fully outsourced to a PCI DSS-compliant TPSP (both the shopping cart and checkout page are hosted by PCI-compliant TPSPs).

Card-Present Card-present payments are processed on a mix of cellular-connected PTS-approved POI terminals, analog-connected POI terminals, and POI terminals that are included in an E2EE or P2PE-validated payment solution.

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

Part 2c. Description of Payment Card Environment Provide a high-level description of the environment covered by this assessment.

For example:

• Connections into and out of the cardholder data environment (CDE).

• Critical system components within the CDE, such as POI devices, databases, web servers, etc., and any other necessary payment components, as applicable.

• System components that could impact the security of account data.

Washington State University (WSU) supports multiple independent payment processing environments. Campus merchant environments include e-commerce and card-present POS as well as analog, cellular, and P2PE-validated POI terminals. All e-commerce payment channels have been outsourced to PCI DSS-compliant third-party providers (e.g., Touchnet, CyberSource, The CBORD Group, etc.). A majority of card-present and MOTO payments are processed using P2PE-validated payment solutions (Clover, Bluefin P2PE, Commerce Platform P2PE, etc.) or IP-connected bank-provided payment terminals.

The WSU merchant environment includes SAQ A, SAQ B, SAQ B-IP, and SAQ P2PE merchant types. No storage of cardholder data is performed by any WSU merchant.

WSU completed a self-assessment to cover each payment flow. SecurityMetrics QSAs reviewed each merchant environment to validate the accuracy of the assessment.

No cardholder data is stored by WSU.

Indicate whether the environment includes segmentation to reduce the scope of the assessment.

(Refer to “Segmentation” section of PCI DSS for guidance on segmentation.)

Yes No

Part 2. Executive Summary (continued)

Part 2d. In-Scope Locations/Facilities List all types of physical locations/facilities (for example, retail locations, corporate offices, data centers, call centers, and mail rooms) in scope for the PCI DSS assessment.

Facility Type Total number of locations (How many locations of this type are in scope) Location(s) of facility (city, country)

Example: Data centers 3 Boston, MA, USA

WSU Main Campus 1 Pullman, WA, USA Vancouver Campus 1 Vancouver, WA, USA Spokane Campus 1 Spokane, WA, USA Tri-Cities Campus 1 Richland, WA, USA

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

Part 2e. PCI SSC Validated Products and Solutions

Does the merchant use any item identified on any PCI SSC Lists of Validated Products and Solutions0F

1F?

Yes No

Provide the following information regarding each item the merchant uses from PCI SSC’s Lists of Validated Products and Solutions.

Name of PCI SSC-validated Product or

Solution

Version of Product or Solution

PCI SSC Standard to which product or solution was validated

PCI SSC listing reference number

Expiry date of listing

(YYYY-MM-DD)

Bluefin P2PE N/A P2PE v3.1 2023-00897.035 2026-12-13 Commerce Platform

P2PE

N/A P2PE v3.1 2022-00909.011 2025-10-19

Clover N/A P2PE v3.1 2024-00893.006 2027-05-07 Worldpay NA P2PE (combining WP Direct, WP Express & WP B2B)

N/A P2PE v3.0 2021-01343.001 2024-11-22

V400m Plus 11.x.x PTS v5.x 4-10231 2026-04-30 FD150 3.0.05.001 PTS v5.x 4-40261 2026-04-30 Clover Mini 02.02.0422 PTS v5.x 4-10248 2026-04-30 Clover Station Printer with customer facing contactless payments

01.10.0462 PTS v5.x 4-30302 2026-04-30

Clover Flex/C405 02.x PTS v6.x 4-40338 2031-04-30 MX925 Vault 12A.x.x

AppM 6A.x.x PTS v4.x 4-10262 2026-04-30

LANE/3000 82054701.05 PTS v6.x 4-30414 2031-04-30 SREDKey 1.01 PTS v3.x 4-10156 2026-12-13 iPP350, iPP320 820305 V11 PTS v4.x 4-30176 2024-04-30 LANE/3000 820547v01 PTS v5.x 4-30310 2026-04-30 ICT220 820305 V02 PTS v3.x 4-20196 2021-04-30 PAX A80 25.00 PTS v5.x 4-30301 2026-04-30

¨ For purposes of this document, ”Lists of Validated Products and Solutions” means the lists of validated products, solutions, and/or components appearing on the PCI SSC website (www.pcisecuritystandards.org)¾for example, 3DS Software Development Kits, Approved PTS Devices, Validated Payment Software, Payment Applications (PA- DSS), Point to Point Encryption (P2PE) solutions, Software-Based PIN Entry on COTS (SPoC) solutions, and Contactless Payments on COTS (CPoC) solutions.

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

Part 2. Executive Summary (continued)

Part 2f. Third-Party Service Providers

Does the merchant have relationships with one or more third-party service providers that:

• Store, process, or transmit account data on the merchant’s behalf (for example, payment gateways, payment processors, payment service providers (PSPs), and off-site storage)

Yes No

• Manage system components included in the scope of the merchant’s PCI DSS assessment¾for example, via network security control services, anti-malware services, security incident and event management (SIEM), contact and call centers, web-hosting services, and IaaS, PaaS, SaaS, and FaaS cloud providers.

Yes No

• Could impact the security of the merchant’s CDE (for example, vendors providing support via remote access, and/or bespoke software developers)

Yes No

If Yes:

Name of service provider: Description of service(s) provided:

Allegiance Fundraising, LLC Fundraising Solution

Amazon Web Services, Inc. Cloud Hosting and Services

Anthology, Inc. iModules Shopping Cart

Bluefin Payment Systems LLC P2PE Solution Provider

CardConnect, LLC Payment Gateway

CloudCME, LLC Hosted E-Commerce Solution

Clover Network, Inc. P2PE Solution Provider

CyberSource (including Authorize.Net and K.K) Payment Gateway

Datatech SmartSoft, Inc. Hosted E-Commerce Solution

EDC Corporation Hosted E-Commerce Solution

Fiserv Global Business Solutions Payment Gateway

Flywire Payments Corporation Website Hosting

FreedomPay, Inc. P2PE Solution Provider

Gor Corporation (USAePay) Payment Gateway

Heartland Payment Systems LLC, a division of Global Payments Direct Inc. Payment Gateway iDonate LLC E-Commerce Donation Solution

MBS Textbook Exchange LLC Hosted E-Commerce Shopping Cart

MSB Communications, LLC Call Center Services

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

PayPal, Inc.’s Braintree Payment Processing System SDK Payment Capture

Peppler & Associates Hosted E-Commerce Shopping Cart

QCSS, Inc (DBA Aria) Call Center Services

Revel Systems, Inc. P2PE solution provider

Ruffalo Noel Levitz, LLC (RNL) E-Commerce Donation Solution

Salesforce, Inc. (dba Heroku) PaaS Provider

Spreedly, Inc. Tokenization and Payment Processing

Stova Group LLC Hosted E-Commerce Solution

The CBORD Group, Inc.(“CBORD”) Hosted E-Commerce Solution

TouchNet Information Systems, Inc.

(TouchNet) a subsidiary of Global Hosted E-Commerce Solution

Trace First Limited Hosted E-Commerce Shopping Cart

VisionOne, Inc. (Showare) Hosted E-Commerce Solution

WorldPay, LLC P2PE Solution Provider & Payment Gateway

Zap Solutions, Inc Hosted E-Commerce Shopping Cart

Note: Requirement 12.8 applies to all entities in this list.

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

Part 2. Executive Summary (continued)

Part 2g. Summary of Assessment (SAQ Section 2 and related appendices)

Indicate below all responses that were selected for each PCI DSS requirement.

PCI DSS

Requirement

Requirement Responses More than one response may be selected for a given requirement.

Indicate all responses that apply.

In Place In Place with CCW Not Applicable Not Tested Not in Place

Requirement 1:

Requirement 2:

Requirement 3:

Requirement 4:

Requirement 5:

Requirement 6:

Requirement 7:

Requirement 8:

Requirement 9:

Requirement 10:

Requirement 11:

Requirement 12:

Appendix A2:

PCI DSS v4.0 SAQ D for Merchants r1, Section 2: Self-Assessment Questionnaire December 2022 © 2006-2022 PCI Security Standards Council, LLC. All Rights Reserved. Page 8

Section 2: Self-Assessment Questionnaire D for Merchants

Note: The following requirements mirror the requirements in the PCI DSS Requirements and Testing Procedures document.

Self-assessment completion date: 2024-10-17

Build and Maintain a Secure Network and Systems

Requirement 1: Install and Maintain Network Security Controls

PCI DSS Requirement Expected Testing Response2F

3F(Check one response for each requirement)

In Place In Place with CCW

Not Applicable Not Tested Not in

Place

1.1 Processes and mechanisms for installing and maintaining network security controls are defined and understood.

1.1.1 All security policies and operational procedures that are identified in Requirement 1 are:

• Documented.

• Kept up to date.

• In use.

• Known to all affected parties.

• Examine documentation.

• Interview personnel.

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

• Interview responsible personnel.

1.2 Network security controls (NSCs) are configured and maintained.

1.2.1 Configuration standards for NSC rulesets are:

• Defined.

• Implemented.

• Maintained.

• Examine configurations standards.

• Examine configuration settings.

¨ Refer to the “Requirement Responses” section (page v) for information about these response options.

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

PCI DSS Requirement Expected Testing Response2F

3F(Check one response for each requirement)

In Place In Place with CCW

Not Applicable Not Tested Not in

Place

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.

• Examine documented procedures.

• Examine network configurations.

• Examine change control records.

Applicability Notes

Changes to network connections include the addition, removal, or modification of a connection.

Changes to NSC configurations include those related to the component itself as well as those affecting how it performs its security function.

1.2.3 An accurate network diagram(s) is maintained that

shows all connections between the CDE and other networks, including any wireless networks.

• Examine network diagrams.

• Examine network configurations.

A current network diagram(s) or other technical or topological solution that 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.

• Examine data flow diagrams.

• Observe network configurations.

A data-flow diagram(s) or other technical or topological solution that identifies flows of account data across systems and networks can be used to meet this requirement.

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.

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

PCI DSS Requirement Expected Testing Response2F

3F(Check one response for each requirement)

In Place In Place with CCW

Not Applicable Not Tested Not in

Place

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

• Examine documented procedures.

• Examine documentation from reviews performed.

1.2.8 Configuration files for NSCs are:

• Secured from unauthorized access.

• Kept consistent with active network configurations.

• Examine NSC configuration files.

Applicability Notes

Any file or setting used to configure or synchronize NSCs is considered to be a “configuration file.”

This includes files, automated and system-based controls, scripts, settings, infrastructure as code, or other parameters that are backed up, archived, or stored remotely.

1.3 Network access to and from the cardholder data environment is restricted.

1.3.1 Inbound traffic to the CDE is restricted as follows:

• To only traffic that is necessary,

• All other traffic is specifically denied.

• Examine NSC configuration standards.

• Examine NSC configurations.

1.3.2 Outbound traffic from the CDE is restricted as follows:

• To only traffic that is necessary.

• All other traffic is specifically denied.

• Examine NSC configuration

1.3.3 NSCs are installed between all wireless networks and

the CDE, regardless of whether the wireless network is a CDE, such that:

• All wireless traffic from wireless networks into the

CDE is denied by default.

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

• Examine network diagrams.

1.4 Network connections between trusted and untrusted networks are controlled.

1.4.1 NSCs are implemented between trusted and untrusted

networks.

• Examine NSC configuration standards.

• Examine current network diagrams.

• Examine network configurations.

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

PCI DSS Requirement Expected Testing Response2F

3F(Check one response for each requirement)

In Place In Place with CCW

Not Applicable Not Tested Not in

Place

1.4.2 Inbound traffic from untrusted networks to trusted

networks is restricted to:

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

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

• All other traffic is denied.

• Examine NSC documentation.

The intent of this requirement is to address communication sessions between trusted and untrusted networks, rather than the specifics of protocols.

This requirement does not limit the use of UDP or other connectionless network protocols if state is maintained by the NSC.

1.4.3 Anti-spoofing measures are implemented to detect and

block forged source IP addresses from entering the trusted network.

• Examine NSC documentation.

1.4.4 System components that store cardholder data are not

directly accessible from untrusted networks.

• Examine the data-flow diagram and network diagram.

This requirement is not intended to apply to storage of account data in volatile memory but does apply where memory is being treated as persistent storage (for example, RAM disk). Account data can only be stored in volatile memory during the time necessary to support the associated business process (for example, until completion of the related payment card transaction).

1.4.5 The disclosure of internal IP addresses and routing

information is limited to only authorized parties.

• Examine NSC configurations.

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

PCI DSS Requirement Expected Testing Response2F

3F(Check one response for each requirement)

In Place In Place with CCW

Not Applicable Not Tested Not in

Place

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, including company- and employee-owned devices, that connect to both untrusted networks (including the Internet) and the CDE as follows.

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

• Security controls are actively running.

• Security controls are not alterable by users of the computing devices unless specifically documented and authorized by management on a case-by-case basis for a limited period.

• Examine policies and configuration standards.

• Examine device configuration settings.

These security controls may be temporarily disabled only if there is legitimate technical need, as authorized by management on a case-by-case basis. If these security controls need to be disabled for a specific purpose, it must be formally authorized. Additional security measures may also need to be implemented for the period during which these security controls are not active.

This requirement applies to employee-owned and company-owned computing devices. Systems that cannot be managed by corporate policy introduce weaknesses and provide opportunities that malicious individuals may exploit.

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

Requirement 2: Apply Secure Configurations to All System Components

PCI DSS Requirement Expected Testing

Response4F

5F(Check one response for each requirement)

In Place In Place with CCW

Not Applicable Not Tested Not in

Place

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

2.1.1 All security policies and operational procedures that are identified in Requirement 2 are:

• Documented.

• Kept up to date.

• In use.

• Known to all affected parties.

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.1 Configuration standards are developed, implemented, and maintained to:

• Cover all system components.

• Address all known security vulnerabilities.

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

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

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

• Examine system configuration standards.

• Review industry-accepted hardening standards.

¨ Refer to the “Requirement Responses” section (page v) for information about these response options.

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

PCI DSS Requirement Expected Testing

Response4F

5F(Check one response for each requirement)

In Place In Place with CCW

Not Applicable Not Tested Not in

Place

2.2.2 Vendor default accounts are managed as follows:

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

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

• Examine system configuration standards.

• Examine vendor documentation.

• Observe a system administrator logging on using vendor default accounts.

• Examine configuration files.

This applies to ALL vendor default accounts and passwords, including, but not limited to, those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, payment applications, and Simple Network Management Protocol (SNMP) defaults.

This requirement also applies where a system component is not installed within an entity’s environment, for example, software and applications that are part of the CDE and are accessed via a cloud subscription service.

2.2.3 Primary functions requiring different security levels are managed as follows:

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

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

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

• Examine system configuration

• Examine system configurations.

2.2.4 Only necessary services, protocols, daemons, and

functions are enabled, and all unnecessary functionality is removed or disabled.

• Examine system configuration

© 2006-2022 PCI Security Standards Council, LLC. All Rights Reserved. Page 15

PCI DSS Requirement Expected Testing

Response4F

5F(Check one response for each requirement)

In Place In Place with CCW

Not Applicable Not Tested Not in

Place

2.2.5 If any insecure services, protocols, or daemons are

present:

• Business justification is documented.

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

• Examine configuration standards.

2.2.6 System security parameters are configured to prevent

misuse.

• Examine system configuration standards.

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

• Examine system configuration standards.

• Observe an administrator log on.

• Examine system configurations.

• Examine vendor documentation.

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

© 2006-2022 PCI Security Standards Council, LLC. All Rights Reserved. Page 16

PCI DSS Requirement Expected Testing

Response4F

5F(Check one response for each requirement)

In Place In Place with CCW

Not Applicable Not Tested Not in

Place

2.3 Wireless environments are configured and managed securely.

2.3.1 For wireless environments connected to the CDE or

transmitting account data, all wireless vendor defaults are changed at installation or are confirmed to be secure, including but not limited to:

• Default wireless encryption keys.

• Passwords on wireless access points.

• SNMP defaults.

• Any other security-related wireless vendor defaults.

• Examine policies and procedures.

• Review vendor documentation.

• Examine wireless configuration settings.

This includes, but is not limited to, default wireless encryption keys, passwords on wireless access points, SNMP defaults, and any other security-related wireless vendor defaults.

2.3.2 For wireless environments connected to the CDE or

transmitting account data, wireless encryption keys are changed as follows:

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

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

• Examine key-management documentation.

© 2006-2022 PCI Security Standards Council, LLC. All Rights Reserved. Page 17

Protect Account Data

Requirement 3: Protect Stored Account Data

PCI DSS Requirement Expected Testing Response6F

7F(Check one response for each requirement)

In Place In Place with CCW

Not Applicable Not Tested Not in

Place

3.1 Processes and mechanisms for protecting stored account data are defined and understood.

3.1.1 All security policies and operational procedures that are identified in Requirement 3 are:

• Documented.

• Kept up to date.

• In use.

• Known to all affected parties.

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

¨ Refer to the “Requirement Responses” section (page v) for information about these response options.

© 2006-2022 PCI Security Standards Council, LLC. All Rights Reserved. Page 18

PCI DSS Requirement Expected Testing Response6F

7F(Check one response for each requirement)

In Place In Place with CCW

Not Applicable Not Tested Not in

Place

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

• Examine the data retention and disposal policies, procedures, and processes.

• Interview personnel.

• Examine files and system records on system components where account data is stored.

• Observe the mechanisms used to render account data unrecoverable.

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.

© 2006-2022 PCI Security Standards Council, LLC. All Rights Reserved. Page 19

PCI DSS Requirement Expected Testing Response6F

7F(Check one response for each requirement)

In Place In Place with CCW

Not Applicable Not Tested Not in

Place

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

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.

• Examine documented policies and procedures.

• Examine system configurations.

• Observe the secure data deletion processes.

Part of this Applicability Note was intentionally removed for this SAQ as it does not apply to merchant assessments.

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.

• Examine data sources.

Applicability Notes

In the normal course of business, the following data elements from the track may need to be retained:

• Cardholder name.

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

• Examine data sources.

Applicability Notes

The card verification code is the three- or four-digit number printed on the front or 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.

• Examine data sources.

© 2006-2022 PCI Security Standards Council, LLC. All Rights Reserved. Page 20

PCI DSS Requirement Expected Testing Response6F

7F(Check one response for each requirement)

In Place In Place with CCW

Not Applicable Not Tested Not in

Place

Applicability Notes

PIN blocks are encrypted during the natural course of transaction processes, but even if an entity encrypts the PIN block again, it is still not allowed to be stored after the completion of the authorization process.

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

• Examine data stores and system configurations.

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.

Part of this Applicability Note was intentionally removed for this SAQ as it does not apply to merchant assessments.

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 service providers only

© 2006-2022 PCI Security Standards Council, LLC. All Rights Reserved. Page 21

PCI DSS Requirement Expected Testing Response6F

7F(Check one response for each requirement)

In Place In Place with CCW

Not Applicable Not Tested Not in

Place

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

3.4.1 PAN is masked when displayed (the BIN and last four

digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see more than the BIN and last four digits of the PAN.

• Examine documented policies and procedures.

• Examine system configurations.

• Examine the documented list of roles that need access to more than the BIN and last four digits of the PAN (includes full PAN).

• Examine displays of PAN (for example, on screen, on paper receipts).

This requirement does not supersede stricter requirements in place for displays of cardholder data—for example, legal or payment brand requirements for point-of-sale (POS) receipts.

This…