The Payment Card Industry Data Security Standard (PCI DSS) is a required set of standards for optimizing the security of payment card transactions. A payment card is any type of credit, debit, or prepaid card used in a financial transaction. The PCI DSS was developed by the PCI Security Standards Council, an organization founded by American Express, Discover Financial Services, JCB International, MasterCard, and Visa Inc. The standard applies to all organizations that process cardholder information.
Compliance with the Payment Card Industry Data Security Standard (PCI DSS) is required of all Stanford University departments and organizations (officially known as Stanford Merchants) that accept payment cards for financial transactions. Also, any organization that provides services that could affect the security of payment card data for another organization and owns a Merchant ID (MID) which includes third-party vendor engaged by Stanford Merchants to process payment card transactions on their behalf, or who is engaged in payment card financial services on our campus, must also comply with the PCI DSS.
Adhering to the PCI DSS requirements provides critical protective measures to make sure payment card data is being kept safe throughout every transaction.
It is your responsibility to read and understand the policies posted on this website.
You must complete the PCI Security and Compliance Awareness training, and you must retake the training on an annual basis to continue to attest to your knowledge and compliance.
For support questions regarding PCI infrastructure services, please refer to the Technical Services FAQ.
Merchant level is determined by the number of credit card transactions a merchant accepts in a year. The amount of the transactions is irrelevant. Merchants who accept less than 20,000 transactions annually are considered a Level 4 merchant. Once a merchant accepts over 6 million transactions in a year they are considered a Level 1 merchant and must have a third-party assessment performed annually. All other merchant levels qualify for an internal or self-assessment. Stanford is a Level 2 merchant.
PCI DSS version 4.0 is out and the PCI Compliance team is working with our consulting firm to identify some gaps and next steps. We are not required to apply the new 4.0 until 2025. PCI Compliance team along with the Merchant Services team will work together to draft a plan to implement 4.0 and will notify our merchants accordingly.
We only do e-commerce. Which SAQ should we use?
We use the same third-party vendor for eCommerce, Mobile app, virtual terminal, and point of sale. Which SAQ should we use?
We have multiple merchant accounts in our department. Which SAQ should we use?
Vulnerability scanning (req. 11.2) seeks to identify known (published software flaws) weaknesses so that they can be corrected (patched) before they are exploited by an adversary. Vulnerabilities above a severity CVSS 4.0 must be remediated in order to be compliant. Penetration testing (req. 11.3) seeks to identify less obvious weaknesses that may be the result of a confluence of other factors (misconfiguration, poor system design) that may be exploited by someone engaged in active probing. Merchants with SAQs that indicate these requirements are in-scope must complete them.
Vulnerability scanning is akin to checking for unlocked doors at a facility so they can be addressed. Penetration testing is using an unlocked door to gain unauthorized access to the facility.
In general, the use of a dedicated PCI workstation protects transactions from the risk of system compromise that is present on computers that are used to receive an email, browse the Internet, and are susceptible to other vectors of malware infection. Additionally, at Stanford, the use of a UIT ET Compliance Services provisioned PCI workstation or the PCI VPN solution serves to route transactions to the dedicated PCI network, and thus removes the larger University network from PCI compliance scope.
Because the use of non-P2PE solutions subjects the associated transaction process to PCI scope inclusion, you may not use them without review and approval from the PCI Compliance team to ensure that other appropriate compensating controls are implemented.
Request their PCI DSS SAQ documents as well as copies of their recent ASV scan and penetration test report (if applicable).
Third-party service provider (TPSP) management begins at contract signing or acceptance of the user agreement with the appropriate language protections in place. Annually collect the required documentation from the TPSP, which is a component included in the contract.
The minimum necessary (first six + last four, etc.) in a physically secure manner to facilitate business payment requirements, i.e., card-not-present repeating orders. May not store SAD after payment authorization, and should leverage third-party payment portals for out-of-scope storage wherever possible.
Notify the Stanford Information Security Office as soon as possible by following the steps on Report an Incident page. Your report will then be assigned to the ISO PCI Compliance team for review and follow-up.
Issues related to lack of accessibility to physical assets previously used to support PCI transaction processing at specific sites - i.e., dedicated PCI workstations, POS devices. Also, issues associated with lack of use, i.e., discharge of POS device internal batteries causing the device to lose internal configuration setting and enter a tampered state. Challenges adapting to new processes designed to facilitate remote work, such as setup and training to utilize specially configured virtual desktop environments to process transactions using dedicated virtual terminals, or ensuring that the physical security of home offices is sufficient.
Our policy states that you are required to use a specific Stanford-issued device to process credit cards. This is because once any device is used to process a credit card, then it puts the device and the entire network into PCI scope. There are several technical controls that must be in place on devices used to process payment cards which will reduce the functionality of the device. You can use a P2PE SRED keypad that's attached to a Stanford-issued laptop, which will allow you to run other programs. Even then, the P2PE implementation manual must be followed to ensure the cardholder data is secured appropriately. Generally, the use of personal devices to process credit cards is not allowed and if you have special circumstances, contact the merchant services operations team by submitting a support request.
Even though Stanford is not directly responsible for these activities, we recommend the following:
There are several options to take:
Contact the Merchant Services Team if you want to discuss different options.