The Payment Card Industry Security Standards Council (PCI SSC) established the Payment Card Industry Data Security Standards (PCI DSS), current version 3.2.1, to help protect consumers’ high-risk payment card data. The PCI DSS requires all organizations that process, transmit and store payment card information to comply with a set of data controls, establish IT and physical security measures and meet policy requirements in order to mitigate the risk of a security breach, or the loss, theft or abuse of payment card data. 

All Stanford departments that accept card payments, and any third party service provider accepting payment data on their behalf, must be PCI compliant and complete an annual certification. All staff handling cardholder data are required to complete an annual training. For more information concerning PCI DSS, please visit the Stanford PCI Compliance website.

PCI DSS has 12 broad requirements and more than 300 sub-requirements. The Council created these requirements to meet six primary control objectives:

Goals PCI DSS Requirements
Build and Maintain a Secure Network
  1. Install and maintain a firewall configuration to protect cardholder data
  2. Do not use vendor-supplied defaults for system passwords and other security parameters
Protect Cardholder Data
  1. Protect stored cardholder data
  2. Encrypt transmission of cardholder data across open, public networks
Protect Cardholder Data
  1. Use and regularly update anti-virus software and programs
  2. Develop and maintain secure systems and applications
Maintain a Vulnerability Management Program
  1. Restrict access to cardholder data by business need to know
  2. Assign a unique ID to each person with computer access
  3. Restrict physical access to cardholder data 
Implement Strong Access Control Measures
  1. Track and monitor all access to network resources and cardholder data
  2. Regularly test security systems and processes
Maintain an Information Security Policy
  1. Maintain a policy that addresses information security for all personnel

Source: PCI DSS Quick Reference Guide: Understanding the Payment Card Industry Data Security Standard version 3.2.1

Each merchant must assign a PCI contact person to monitor, document and manage card acceptance processes and security. There are a few key things merchants should do and not do to ensure you are compliant with PCI’s standards. This short list of “Do’s” and “Don'ts” should get you started down the path of PCI compliance. For a comprehensive list of all the policies, please visit the Stanford PCI Compliance website.

PCI Compliance: DO’s

  • Change the default password on your computer to a complex password.
  • Supervise all visitors (including your regular, part-time or temporary personnel) in areas where credit card information is maintained.
  • Ensure all cardholder data is unreadable (converted by strong encryption into a meaningless character string) during transmission.
  • Handwritten credit card information must be cross-cut shredded immediately after use.
  • Store documents or media-containing cardholder information in a locked drawer or filing cabinet accessible only by PCI trained and authorized personnel.
  • Complete your merchant account’s annual PCI DSS certification. 
  • Take the required annual PCI awareness training through STARS.
  • Maintain an up-to-date inventory of all credit/debit card processing devices. 
  • Perform periodic inspections to look for tampering or substitution. 
  • Report immediately to your supervisor and Merchant Services if you suspect card information has been lost, stolen, exposed or otherwise misused; or if your system containing credit card data has been hacked or breached. 
  • Contact Merchant Services if you are making a change to your cardholder data environment or processes.

PCI Compliance: DON’TS

  • Never physically write down any card information unless you are explicitly required to do so as part of your business processes.
  • Never acquire or disclose any cardholder’s card information without the cardholder’s consent, including but not limited to:
    • Full or partial sections of the sixteen (16) digit card number
    • CVV/CVC security code (three or four digit validation code on the back of the card or on the front for American Express)
    • PIN (personal identification number)
  • Never transmit or accept any of the above cardholder information via unsecured email, fax, scan, unencrypted VOIP phone device (i.e., Jabber) or by end-user messaging technologies (i.e., Slack). 
  • Never store any sensitive authentication data on a university computer, server or on paper, including:
    • The card’s storage chip or magnetic stripe
    • The CVV/CVC security code (the three or four digit validation code on the back of the card or on the front for American Express) post authorization
  • Never leave unsettled batches in terminals at the end of a business day. Instead, set up auto-settle programming or ensure that batches are settled manually each night.
  • Never share the password to your computer or any computer you access with anyone.
  • Never leave sensitive information unattended on a desk, screen or in any public area.

University departments that use or would like to use third party vendors to process credit/debit card transactions must ensure that:

Each new vendor is fully approved by Office of the Treasurer (OOT), possibly the Information Security Office (ISO) and the university’s ISA, and includes validation of its PCI compliance prior to engaging in any contractual relationship. Please refer to the requirements in the vendor evaluation checklist.

Note: Any new or existing vendor is contractually obligated to maintain their PCI DSS compliance, and provide Stanford with the service provider’s Attestation of Compliance (AOC) at least annually and upon request. Other documentation also may be required such as, but not limited to, a process flow of how data is transmitted and or a current SOX1 or SOX2 report.

Pursuant to PCI DSS requirement 12.6, Stanford requires all university personnel (faculty, students, staff and contractors) involved in department credit/debit card processing operations and systems infrastructure to complete an annual PCI awareness online training course and an attestation. Please submit a Support Request to Merchant Services (MS) for enrollment. 

As a Level 2 merchant (a merchant that processes between one to six million card transactions per year), Stanford is required to validate its PCI compliance to its acquiring bank: Wells Fargo Merchant Services (WFMS) and American Express by submitting the following documents: 

  • Annual Self Assessment Questionnaire (SAQ) D for Merchants 
  • Quarterly network security scan by an approved scanning vendor (ASV)
  • Annually signed "Confirmation of Report Accuracy" 

To ensure the timely completion of the PCI DSS certification, all Stanford merchants must validate their compliance through an annual SAQ and compliance certification in SecureTrust online portal (formerly known as TrustWave). Merchants who elect not to participate in, and comply timely with the annual compliance requirements, may find the department’s MID being revoked and the ability to accept payment cards suspended indefinitely.

Annual Compliance Timeline

The timeline below outlines the tasks that must be completed by merchants, and the university as a whole, in order to satisfy the annual PCI DSS Certification: 

Date/Deadline Task
1st Week of September MS sends initial announcement email to all merchants.
September to October MS sends reminder emails to merchants for their SAQ completions.
1st Week of November All merchants complete their MID level SAQs in SecureTrust portal. 
November MS sends warning emails to merchants who missed the deadline.
1st Week of December Stanford submits overall Attestation of Compliance (AOC) to acquiring bank and American Express.

Self Assessment Questionnaire (SAQ)  

The SAQ is a validation tool that is primarily used by merchants to demonstrate ongoing compliance with the PCI-DSS to the university’s acquiring bank: WFMS and American Express. The SAQ includes a series of yes-or-no questions for each applicable PCI DSS requirement. There are eight different types of SAQs depending on merchants’ payment processing methods. If you are not sure which SAQ would apply, or have any questions when filling out the SAQ, please consult with Merchant Services or PCI compliance for further assistance. 
 

SAQ Type Type of Payment System
SAQ A 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 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 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 Merchants using only standalone, point-to-sale (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 Merchants with payment application systems connected to the internet, no electronic cardholder data storage. Not applicable to e-commerce channels.
SAQ C-VT 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 P2PE-HW 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.
SAQ D All other SAQ-Eligible Merchants
arrow_upward
Back to Top