Summary
This guide is designed for departments considering or using external vendors for services involving payment card information. It highlights the need for assessing the Payment Card Industry Data Security Standard (PCI DSS). The guide covers key terms such as HECVAT, PCI DSS, SAQ, AOC, and SOC 2 Type II Report, providing simple explanations for each. It also includes a draft email template to help collect the necessary documentation from vendors.
Body
Introduction
This guide is for those in departments considering or using external vendors for services that involve payment card (credit or debit card) information. This article will help you understand the process for assessing vendors to ensure they meet the necessary security standards, primarily the Payment Card Industry Data Security Standard (PCI DSS). This process is vital for protecting our students, customers, and the University from the risks associated with payment card data breaches. Whenever an external vendor handles payment card information – whether it's for online event registrations, merchandise sales, or any other service – that vendor becomes a partner in protecting sensitive data.
Minnesota State Board Policy '7.3.17.1: Payment Card Acceptance, Processing and Security' mandates that we ensure a safe and secure environment for all payment data and limit processing to PCI DSS compliant third-party providers.
Key Terms to Know
When working through the IT Procurement Risk Review process you might hear these terms. Here’s what they mean in simple language:
- HECVAT (Higher Education Community Vendor Assessment Toolkit):
- What it is: The HECVAT is a standardized questionnaire created by and for the higher education community (universities and colleges). It's designed to help institutions like ours assess how well potential vendors (especially technology service providers) meet our requirements for cybersecurity, data privacy, and compliance with laws like FERPA. Think of it as a detailed checklist that vendors fill out to give us a picture of their security practices.
- Why it matters to you: This is the first major piece of documentation we ask a potential vendor to complete. It provides a broad understanding of a vendor's security posture before diving into PCI DSS specifics.
- PCI DSS (Payment Card Industry Data Security Standard):
- What it is: Think of PCI DSS as a set of security rules created by major credit card companies (Visa, Mastercard, American Express, etc.). Any organization, including vendors, that stores, processes, or transmits credit card information must follow these rules to protect that data.
- Why it matters to you: If your department wants to use a vendor that will handle credit card payments, that vendor must be PCI DSS compliant.
- SAQ (Self-Assessment Questionnaire):
- What it is: This is a form that vendors use to check their own compliance with PCI DSS. There are different types of SAQs depending on how the vendor handles card data (e.g., if they fully outsource payment processing, or if they handle data more directly). For example, a vendor using a secure third-party like Stripe for all payment functions might use a simpler SAQ (like SAQ A). A vendor with more direct involvement in handling card data would use a more detailed one (like SAQ D).
- Why it matters to you: Your department will likely need to ask the vendor for their completed SAQ. This is a standard document used to assess risk in the procurement process.
- AOC (Attestation of Compliance):
- What it is: This is a formal declaration signed by the vendor, confirming that they have completed the correct SAQ and are compliant with the relevant PCI DSS requirements. Think of it as their official statement saying, "Yes, we've done our PCI DSS homework and we meet the standards."
- Why it matters to you: Along with the SAQ, the AOC is a key piece of evidence that the vendor is taking PCI DSS seriously. This is a standard document used to assess risk in the procurement process.
- SOC 2 Type II Report (System and Organization Controls):
- What it is: This is a report from an independent auditor that looks at a vendor's systems and processes related to security, availability, processing integrity, confidentiality, or privacy over a period of time (usually 6-12 months). It’s not specifically a PCI DSS report, but it gives a broader view of the vendor's overall security practices.
- Why it matters to you: For vendors handling sensitive data or providing critical services, this report is used to get a more in-depth understanding of their security controls. It’s a good indicator of a vendor's security maturity.
Draft Email to Vendors 📧
Below is a draft email that can be useful for collecting documentation needed to validate PCI compliance as a part of the IT Procurement Risk Review process.
Subject: St. Cloud State University - PCI Documentation Request
St. Cloud State University is committed to protecting its information assets and ensuring compliance with applicable data security standards, including the Payment Card Industry Data Security Standard (PCI DSS).
As part of our IT Procurement Risk Review process, we require a security assessment for all third-party solutions that handle University data—particularly those involved in payment card processing.
To proceed with the evaluation of your solution, please provide the following documentation:
- Higher Education Community Vendor Assessment Toolkit (HECVAT)
- PCI DSS Attestation of Compliance (AOC) and Self-Assessment Questionnaire (SAQ)
- If your service uses a third-party payment processor (e.g., Stripe, PayPal) for all cardholder data functions, please also include their current AOC.
- SOC 2 Type II Report
- Any additional security-related documentation
- This may include penetration test results, security whitepapers, security program links, or certifications that support a timely and thorough risk review.
Thank you for your cooperation and support.