Third Party Service Providers (TPSPs)

Northwestern Merchant locations or their representatives, including vendors and other TPSPs, may not enter into legally binding agreements with TPSPs processing or handling any type of CHD (Cardholder Data), or interacting in any other way with the CDE (Cardholder Data Environment), without the proper layers of University vetting and approval first; this would include but not be limited to e-Commerce, Treasury Operations, Northwestern IT Security and Compliance, Northwestern Office of General Counsel, and Northwestern Procurement and Payment Services. ALL agreements with TPSPs must have specific PCI DSS and liability shift language included.

In addition, requests to enter into agreements with TPSPs must be initiated within the the Merchant Card Processing Request and supported by a strong business case, diagrammatic overview of the TPSPs application and network architecture which supports and secures all interaction with the CHD and CDE, verifiable evidence of the TPSPs PCI DSS Compliance and Validation, and other items based upon the scope of the proposed implementation. This information is to be supplied by the Merchant in the completed e-Commerce Addendum which is part of the Merchant Card Processing Request.

Please refer back to the e-Commerce homepage for an overview of this process, and please refer to PCI DSS 3.2 Third Party Security Assurance (below) for explicit guidelines and evaluation matrices which will help the Merchant, in conjunction with e-Commerce and other key teams, evaluate the suitability of the desired TPSP BEFORE commitments are made and an agreement is signed.

PCI DSS Third Party Security Assurance Resources:

TPSP (Third Party Service Provider) – As defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms, a service provider is a business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data. There are many types of businesses that could fall into the category of "service provider", dependent on the services provided.
Nested or Chained TPSP – As defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms, a nested or chained TPSP is any entity that is contracted for its services by another third-party service provider for the purposes of providing a service.

System Vulnerability Scans

Merchants with on-campus payment systems connected to the Internet are required to run vulnerability scans against their systems. Our contract with Trustwave includes external vulnerability scans that are scheduled on the TrustKeeper Portal; scan reports are posted on the TrustKeeper Portal as well. It is the responsibility of the Merchant to review the scans and address any vulnerabilities that have been identified. Failure to address identified vulnerabilities can result in the Merchant location, as well as the entire University, falling out of compliance.

System Penetration Testing

Northwestern is now a PCI Level 3 Merchant based upon recent card processing metrics, and Northwestern Merchants with on-campus payment systems connected to the Internet are now required to have internally conducted penetration testing performed at least quarterly. Since this service is not currently part of our Trustwave contract, arrangements need to be made by e-Commerce Operations and Northwestern IT Security and Compliance, coordinated with Merchant onsite Administrators and IT staff. Failure to cooperate with this mandatory requirement may result in your Merchant account being revoked. Please contact e-Commerce Operations at ccard@northwestern.edu or 847.467.4962 for more information for more information.

Periodic Reviews and Audits

e-Commerce Operations will regularly review the completed SAQs and vulnerability scans on the Merchant's TrustKeeper Portal, along with internal Penetration Tests, all personnel, attestations, training, procedures, controls, and documentation within the CDE (Cardholder Data Environment). Periodically, additional information and follow-up interviews may be requested and visits to Northwestern Merchant locations may take place with or without notice.

At the discretion of e-Commerce Operations, audits by an external PCI-Certified QSA (Qualified Security Assessor) may occasionally be requested in order to comprehensively review a Merchant card location's credit card operations. The intention of these activities is to reduce the University's risk by ensuring that merchants comply with PCI DSS. Failure to cooperate with such activities may result in your Merchant account being revoked.

Trustwave-TrustKeeper Annual SAQ (Self-Assessment Questionnaire)

All Northwestern Merchants are required to validate PCI DSS compliance at least once, annually, by completing the appropriate TrustKeeper PCI Attestation of Compliance (AOC) SAQ in a timely manner (prior to expiration). A separate questionnaire must be completed for each Merchant account, and a new questionnaire must be filled out whenever any of the following have occurred:

payment processing system changes
a year has elapsed since your last SAQ
you have been prompted to do so by e-Commerce Operations

Treasury Operations maintains a contract with Trustwave to centrally manage PCI-DSS validation through the TrustKeeper Portal. All SAQs should be completed through the TrustKeeper Portal.

The PCI SSC has issued Instructions and Guidelines, plus 8 types of SAQs for Merchants in the Document Library of its website. e-Commerce Operations will help determine which SAQ applies to your situation. The table below lists all of the current SAQ form types, along with their general definitions.

SAQ Type	Type of Payment System
SAQ A v3.2	Card-not-present merchants (e-commerce or mail/telephone order) that have fully outsourced all cardholder data functions to PCI DSS compliant third-party service providers, with no electronic storage, processing, or transmission of any cardholder data on the merchant's systems or premises. Not applicable to face-to-face channels.
SAQ A-EP v3.2	Card Not Present, E-commerce merchants who outsource all payment processing to PCI DSS validated third parties, and who have a website(s) that doesn't directly receive cardholder data but that can impact the security of the payment transaction. No electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises. Applicable only to e-Commerce channels.
SAQ B v3.2	Merchants using only Imprint machines with no electronic cardholder data storage and/or Standalone, dial-out terminals with no electronic cardholder data storage. Not applicable to e-Commerce channels.
SAQ B-IP v3.2	Merchants using only standalone, PTS-approved payment terminals with an IP connection to the payment processor, with no electronic cardholder data storage. Not applicable to e-commerce channels.
SAQ C v3.2	Merchants with payment application systems connected to the Internet, no electronic cardholder data storage. Not applicable to e-Commerce channels.
SAQ C-VT v3.2	Merchants who manually enter a single transaction at a time via a keyboard into an Internet-based Virtual Terminal solution that is provided and hosted by a PCI DSS validated third-party service provider. No electronic cardholder data storage. Not applicable to e-Commerce channels.
SAQ D v3.2	All other SAQ-Eligible Merchants
SAQ P2PE‑HW v3.2	Merchants using only hardware payment terminals that are included in and managed via a validated, PCI SSC-listed P2PE solution, with no electronic cardholder data storage. Not applicable to e-Commerce channels.