You have made the decision to deploy a PCI-listed Point-to-Point Encryption (P2PE) solution on campus. No more worrying about PCI compliance, right?
Wrong. Although the list of requirements that you must comply with is much shorter (as in only 33 requirements versus an average of 129 or 329 for the SAQ D), you do still have security controls that need to be maintained.
Using a P2PE solution listed by the PCI DSS ensures that merchants no longer have access to clear-text cardholder data (CHD) on computer systems and can only enter CHD via hardware payment terminals that are part of that solution. So what is left for you to monitor in this new environment?
First, keep in mind that there are rules to follow during the implementation process that, if not adhered to, will impact the PCI-compliance status and, quite possibly, the security of your deployment. You must follow the vendor’s P2PE Instruction Manual, or PIM, in order to be eligible for the scope reduction a listed and validated solution provides.
The PIM is the deployment guide that listed P2PE solution providers deliver to merchants who have purchased their solution. The PIM provides a roadmap to compliance and outlines the merchant obligations as they relate to the shipping and receiving of devices, chain-of-custody, secure storage of devices, commissioning/decommissioning procedures, device inspections, and device inventory requirements.
If your organization were to have a QSA come onsite for an assessment of any merchants or departments that had deployed a P2PE solution, the PIM is one of the first things they will ask for so they can verify the implementation guidelines were explicitly followed, which also means that you should document you implementation so you can “show your work.”
Now let’s get back to what comes after the deployment. There are still a number of controls that must be maintained in order for the merchant to meet all requirements in the SAQ P2PE.
Requirement 3: Protect stored cardholder data
This requirement will only apply to P2PE merchants that store paper records like mail order/telephone order (MOTO) forms, receipts, or printed reports containing cardholder data. If the merchant is using paper to write down or store CHD, then they are required to have data-retention and disposal policies and procedures in place, as well as security policies and operational procedures for protecting stored cardholder data. If you are not storing any CHD on paper, then this requirement would be considered not applicable.
Requirement 9: Restrict physical access to cardholder data
Again, the first two requirements in this section (9.5 and 9.8) only apply if merchants have stored paper records containing cardholder data. These requirements are in place to ensure that all relevant media (e.g. paper and electronic storage options) are physically secured at all times and later destroyed when no longer needed. Ideally such paper-based media is either never generated/received, or securely destroyed immediately after the transactions are completed, thus reducing both risk and the impact of these requirements.
Requirement 9.9 was added to the PCI DSS after the well-known Michael’s data breach in 2011 in which criminals were able to tamper with in-store POS devices in over 7,000 stores. Since that time, card skimming has become a common threat, as criminals can easily attach or insert a small device into a payment terminal and steal cardholder information.
9.9 is all about protecting the devices that capture payment data from tampering and substitution, and checking to ensure a card skimmer has not been installed. It requires that each merchant maintain an inventory of devices, tracking them from the moment they are unpacked and deployed. Inventory lists should include the make and model number of the device, the location of the device, and the serial number or other unique identifier. P2PE merchants should have clearly defined and documented procedures regarding how they inspect the devices for potential tampering and substitution. CampusGuard generally recommends building the inspection into your daily procedures and having staff do a quick tamper check before the first transaction of the day. This can include comparing the serial number of the device to the one listed on the inventory list, comparing the device to pictures of the “known good” state (perhaps incorporated into the inventory document), checking for any unusual gaps or signs of prying, looking for extra cables, checking tamper-evident screws/stickers, etc.
Requirement 12: Maintain a policy that addresses information security for all personnel
Requirement 12 outlines the need for a security policy that is published, maintained, and disseminated to all relevant personnel. The policy should clearly define information security responsibilities for all personnel. Requirement 12 also includes a formal security awareness program for all personnel involved with the handling of payment card information. All merchants must have an incident response plan that can be implemented in the event of a data breach. And as with all SAQs, the P2PE merchants must also ensure policies and procedures are implemented to manage any service providers with whom cardholder data is shared, which obviously includes the P2PE solution provider.
That doesn’t sound too bad, does it? Deploying a PCI-listed P2PE solution certainly helps to reduce the work effort associated with achieving and maintaining PCI compliance, but your best approach is to maintain your focus on effectively securing systems and ensuring the compliance efforts become part of your Business as Usual (BAU).
The PCI DSS is a great framework for general information security as well and can be used to secure systems and data outside of payments (think: HIPAA, FERPA, GLBA, etc.). Many of the requirements that are no longer appearing on your SAQ P2PE, including things like an annual risk assessment, logging, vulnerability scanning, penetration testing, etc., are still valuable security efforts that should be utilized, as appropriate, to keep your institution and both institutional and sensitive customer information safe.
Some additional guidance from our Security Advisor team below:
[Campbell]: The PCI Council’s formal P2PE program has certainly seen impressive growth in the past couple of years, both in terms of the number of listed solutions, and (perhaps more importantly for higher education) in the number of integrations available. Those integrations are what allow us to pursue P2PE solutions in all of the diverse payment environments we have in higher education: ticketing, food/dining services, parking, tuition and fees, etc. The P2PE program and its solutions absolutely represent an outstanding way for institutions to both ease the compliance burden and greatly reduce the risk of data compromise, and I would certainly be leveraging it wherever possible if I still worked in my old role on campus.
As the article notes, however, even that reduced compliance burden never goes away, and P2PE is a great example of an item we stress whenever we provide merchant training: as long as the institution owns the merchant account for a given activity, it can never fully outsource or otherwise avoid the responsibility to protect customer data and comply with PCI DSS requirements. There are still PCI monsters under your bed. They are just smaller, easier to manage, and less likely to disturb your sleep. Pleasant dreams!
