Undertaking the task of bringing an institution of higher education into compliance with the Payment Card Industry's Data Security Standard (PCI DSS) can feel daunting to say the least. As with most large projects, the undertaking becomes more manageable when broken into smaller tasks. In order to begin to determine an organizations compliance to the PCI DSS, one must first understand the scope of the cardholder environment.
The scope of a PCI DSS assessment consists of the "people, processes, and technology that handle cardholder data or sensitive authentication data". This means that the institution's PCI scope will include any department or group on campus that receives, processes, stores, or transmits cardholder data or has cardholder data collected and processed on their behalf by a third-party entity.
With most higher ed institutions, the best place to begin the scoping discussion is with the treasury or accounting department that manages the institution's merchant account(s). As they say in the movies, "follow the money". Begin with a list of all merchant accounts on campus. This list will help to guide the initial discovery phase.
During the initial discovery phase you will want to meet with representatives from each on-campus merchant to understand how cardholder data is used in their environment. The goal of these discovery meetings is to understand how cardholder data flows through each environment. Understanding the flow of cardholder data simply means knowing how cardholder data is received (card-present transactions, e-commerce website, over the phone, etc.), what systems the data traverses (servers, workstations, databases, etc.), if and where it is stored, and where it is sent for processing. Understanding the card flows in each environment is critical for properly defining your PCI scope.
By the end of your discovery phase you should have a list of 'campus merchants' and a basic understanding of their PCI scope. The next task would be determining the appropriate Self-Assessment Questionnaire for each merchant to be assessed against. The PCI Council has produced a document that helps define the different questionnaires that will be helpful as you begin to categorize your merchants. Below is a very brief summary of the different SAQ types:
SAQ A: This is for e-commerce or MOTO merchants who outsource all cardholder data functions to a PCI DSS compliant service provider. If e-commerce sites are redirecting to a service provider to collect and process cardholder data this must be a full redirect or i-frame implementation.
SAQ A-EP: This is for an e-commerce merchant that is redirecting cardholder data to a service provider but the code on their site can still impact the security of the data (like a direct post method).
SAQ B: This is for merchants using analog connected payment terminals (POI devices usually provided by the bank) or manual imprint machines (knuckle busters).
SAQ B-IP: This is for merchants who are using PTS-approved POI devices (usually provided by the bank) that connect to the IP network instead of dial-up connections.
SAQ C: This is for merchants who use a payment application (POS system) that is segmented from the rest of the campus network and is connected to the Internet for processing. The merchant cannot have any electronic storage of cardholder data.
SAQ C-VT: This would be used for merchants who are using a web browser to connect to an Internet-based PCI compliant virtual terminal to type in single transactions using the keyboard. Network segmentation is required and a swipe/dip reader cannot be used. No electronic storage of cardholder data is allowed.
SAQ P2PE-HW: This SAQ is for merchants who are using a validated P2PE (point-to-point encryption) solution to process transactions. No electronic storage of cardholder data is allowed. Solutions must be listed on the PCI Council's list of validated P2PE solutions.
SAQ D: The SAQ D is for all service providers and for any merchant that is electronically storing cardholder data or otherwise does not meet the qualifying criteria for any of the SAQ types listed above.
Most institutions of higher education that I have worked with will usually treat their central IT group as an SAQ D service provider and will then have multiple SAQ A and SAQ B merchants with a handful of SAQ C merchants and very few SAQ D merchants. You will quickly realize that the cost and burden on maintaining PCI compliance will increase rapidly based on the number of SAQ D merchants on campus. If at all possible eliminate or reduce the number of SAQ D merchants by the use of proper network segmentation and eliminating the electronic storage of cardholder data.
Now that we have a better understanding of our overall merchant environment, we are ready to start diving into evaluating the compliance of each merchant individually.
