Payment Card Industry Data Security Standards (PCI DSS)
Find the resources and information you need to comply with PCI requirements.
Payment Card Processing and Compliance is governed by PPM 300-86.
2019 PCI Validation Schedule of Jobs
PCI Training
2019 PCI VigiOne Webinar
FACTA Compliance
FACTA, the Fair & Accurate Credit Transactions Act (15 U.S.C § 1681c(g)) requires that vendors accepting credit or debit cards shall not print more than the last 5 digits of the card number on any receipt provided to the cardholder at the point of sale, nor may they include the expiration date.
Statutory damages for FACTA violations range from actual damages for a negligent violation, to $100-$1,000 per willful violation.
Merchants with in-person transactions
Ensure that printed receipts do not contain more than the last 5 digits of the card number nor the expiration date.
Merchants with e-commerce websites
Confirm that your 3rd party vendor does not send electronic receipts with more than the last 5 digits of the card number nor the expiration date.
PCI DSS Background and Compliance Requirement
The Payment Card Industry Data Security Standards (PCI DSS) are a set of security guidelines established by the PCI Security Standards Council (Visa, MasterCard, American Express, Discover, JCB, and other institutions) to mitigate risk associated with payment account security and the protection of cardholder information. Compliance with PCI Standards applies to all merchants, processors, acquirers, issuers, and service providers regardless of size or volume of transactions.
As a Campus merchant, you will be responsible for all requirements related to PCI DSS ongoing compliance.
Currently, PCI DSS consist of a minimum set of requirements (12) for protecting cardholder data, and may be enhanced by additional controls and practices to further mitigate risk.
Compliance with Payment Card Industry Data Security Standards (PCI DSS) is mandated by the major credit card organizations and enforced by UCOP. UCOP has delegated this responsibility to the Campus Credit Card Coordinator.
Continuous compliance and validation applies to all UCSD merchants regardless of size or volume of transactions. Specific requirements vary depending on the Cardholder Data Environment (CDE) and the Campus’ merchant level. CDE includes all processes and technology including system components, hardware, software, and all other factors being used during the processing of credit or debit card payments.
Merchant levels fall within categories 1-4 and are based on a 12-month period. The Campus (as a whole) is assigned a merchant level and required to meet level specific requirements. UCSD has been classified a level 2 merchant.
Annually merchants must validate and attest compliance with PCI DSS in order for the Campus to meet overall PCI DSS compliance.
In addition to comply with PCI-DSS requirements, depending on the CDE, merchants may also be subject to additional requirements including: Payment Application Data Security Standards (PA-DSS), PIN Transaction Security Standards (PTS) and Point-to-Point Encryption (P2PE). The PCI Council is constantly updating their requirements to keep up with innovative technology and data security.
Refer to the PCI DSS Website for more details.
VigiOne SAQ Web Portal
As the University's PCI compliance partner, VigiTrust will be administering the campus's Self-Assessment Questionnaire (SAQs). The VigiOne portal is the web tool developed by VigiTrust for merchants to complete their SAQs.
University merchants are notified by Merchant Services to begin their annual assessments. If you do not have access to the VigiOne portal, but you are assigned to perform the SAQ, please contact merchantservices@ucsd.edu and we will assist you with the onboarding process to VigiOne.
How to navigate around VigiOne and to complete your designated SAQ:
Use of Email and Messaging Technologies for Transmitting Card Data
The UCOP-Office of the Chief Investment Officer (OCIO) has agreed that BUS-49 (PDF), University’s Policy on Cash Handling, is applicable to messaging technologies as follows:
BUS-49, Appendix B, 7 to 10. Card data cannot be emailed, either in the body of an e-mail or as an attachment. So current messaging technologies would extend to that as well (an extension of technology).
PCI DSS Requirement 9.9 Equipment Inspection
New Physical Security Requirements, PCI DSS 9.9
The PCI DSS Council introduced a new requirement for inspection of payment devices. Requirement 9.9., of PCI DSS version 3.0 is a mandatory requirement on July 1, 2015.
These requirements apply to card-reading devices used in card-present transactions at the point of sale.
The requirement is not intended to apply to manual key-entry components such as computer keyboards and POS keypads; the application of these principles is a recommended best practice for these device types.
The University’s Qualified Security Advisor (QSA), Coalfire Systems, presented a webinar on this requirement.
Use this Excel file template for implementing the “inspection of payment devices” as required by PCI DSS 9.9.
The file has 3 worksheets:
- Premises risk assessment: To determine the risk category applicable to the location.
- Evaluation forms: To verify integrity of equipment and terminal environment.
- Evaluation checklist: To maintain a log of performed inspections.
PCI DSS Requirement 12.8.1 to 12.8.5 Service Providers
PCI-DSS 3.1, Requirement 12
PCI DSS Questions 12.8.1 to 12.8.5 – Are policies and procedures maintained and implemented to manage service providers with whom cardholder data is shared, or that could affect the security of cardholder data, as follows:
Response is “YES” if the merchant is receiving services from the following providers:
- Bank of America Merchant Services (BAMS)
- Authorize.net
- Cybersource
The third parties listed above provide services under University agreements which are governed by Policy BUS49 (PDF). BUS49 is the evidence that supports compliance with this requirement.
Important
For other service providers, merchants are required to maintain written agreements with the service providers that include acknowledgement that the 3rd party service provider is responsible for complying with all applicable PCI DSS requirements. The intent is to confirm the service provider’s commitment to maintaining all controls for all services that are subject to PCI DSS.
When responding to these questions in the VigiOne portal, merchants will have to upload evidence supporting their responses (i.e., upload a copy of valid and current agreements with service providers).
More information on Third Party Vendor Security Assurance (PDF).
SAQ Resources
Templates, policies, and procedures that you can use as reference or evidence when completing your SAQs:
-
- UCSD Campus Credit Card Policies & Procedures and Terminal Security Policy (PDF)
- Payment Card Processing and Compliance Policy-PPM 300-86 (PDF)
- ITS_Firewall_PCI (PDF)
- Privacy and Data Security Incident Response Plan (PDF)
- BFB-IS-3 Electronic Information Security (PDF).
- UCSD Network Security Policy 135-3 (PDF).
- UCSD Implementation Plan for Protection of Electronic Identity Information (PDF).
- Sample Data Flow Diagram (PDF)
- BUS-49 Policy for Cash and Cash Equivalents Received (PDF)
- Inspection of Payment Device Template (Spreadsheet)
- PCI Blog - P2PE-EMV-Tokenization (PDF)
- FD130, FD130DUO, FD35 PTS certification (PDF)
- E-Commerce merchant Best Practice (PDF)
- How it works: E-commerce merchant (PDF)
- Migrating from SSL and Early TLS (PDF)
- First Data, BAMS connectivity platforms, TLS migration due February 28, 2018 (PDF)
Evidence Required by SAQ Type
Merchants are responsible for gathering required evidence based on the associated SAQ type(s). Evidence must be uploaded to the VigiOne portal as part of the annual PCI validation.
SAQ Type |
Video/Photo Evidence Required |
P2PE |
• Paper forms used to write down/collect CHD • Storage of CHD (e.g. filing cabinets, safes) • Destruction of CHD (e.g. cross-cut shredder, Iron Mountain/Shred-it bins) • Payment devices (make/model, serial) • Physical security of payment capture devices (e.g. mounting, cameras) • Device Inspection Procedures / Logs |
D |
• TBD based on card processing environment |
PCI Additional Resources
- PCI Best Practices (PDF)
- PCI DSS - Alert Use of General Workstations (PDF)
- PCI DSS - Checklist for Contracting with Third-Party Service Providers (PDF)
- PCI DSS - Compliance at the Point of Sale (PDF)
- PCI DSS - Handling Cardholder Data_CHD_on Paper (PDF)
- PCI DSS - Insecure Communications (PDF)
- PCI DSS - New Merchant Do_s and Don_ts (PDF)
- PCI DSS - PCI Compliance Gotchas (PDF)
- PCI DSS - Phishing Prevention (PDF)
- PCI DSS - Protecting Credit Card Devices (PDF)
- PCI DSS - Storing Cardholder Data_CHD (PDF)
Accepting EMV Cards - Employee Training Materials
UCSD is moving toward upgrading our card present merchants to EMV capable terminals. Guidance that will help you understand the EMV technology and assist your staff with accepting these EMV chip cards at merchant locations.
Payment Card Industry Terms and Abbreviations
Cardholder: A person who has a credit or debit card.
Cardholder Data: All personally identifiable information associated with the cardholder including: cardholder name, expiration date, account number, address, social security number, etc.
Data-Flow Diagram: A diagram showing how data flows through an application, system, or network.
DSS: Acronym for “Data Security Standard.”
Encryption: Encryption is the conversion of data into a form, called a ciphertext that cannot be easily understood by unauthorized people. Decryption is the process of converting encrypted data back into its original form, so it can be understood.
Firewall: Hardware and/or software technology that protects network resources from unauthorized access. A firewall permits or denies computer traffic between networks with different security levels based upon a set of rules and other criteria.
Merchant: Any entity that accepts credit or debit cards as payment for goods and/or services.
Network: Two or more computers connected together via physical or wireless means.
Network Security Scan: Process by which an entity’s system is remotely checked for vulnerabilities through use of manual or automated tools. Security scans that include probing internal and external systems and reporting on services exposed to the network. Scans may identify vulnerabilities in operating systems, services, and devices that could be used by malicious individuals.
PA-DSS: Acronym for “Payment Application Data Security Standard.”
PAN: Acronym for “primary account number” and also referred to as “account number.”
PCI: Acronym for “Payment Card Industry.”
PCI DSS: Acronym for “Payment Card Industry Data Security Standard.”
Penetration Test: Penetration tests attempt to identify ways to exploit vulnerabilities to circumvent or defeat the security features of system components. Penetration testing includes network and application testing as well as controls and processes around the networks and applications, and occurs from both outside the environment (external testing) and from inside the environment.
PIN: Acronym for “personal identification number.” Secret numeric password known only to the user and a system to authenticate the user.
QSA: Acronym for “Qualified Security Assessor.” QSAs are qualified by PCI SSC to perform PCI DSS assessments.
ROC: Acronym for “Report on Compliance.” Report documenting detailed results from an entity’s PCI DSS assessment.
Find answers, request services, or get help from our team at the UC San Diego Services & Support portal or call the Finance Help Line at (858) 246-4237.