P2PE in Higher Education--Reducing Applicable Controls

Tyler Baker, Regional Sales Manager

Point to Point Encryption (P2PE) is the hottest topic in the PCI world right now and many of our Higher Education clients are anxious to take advantage of the solutions available to them.  However, with 2.0 not yet released, and then the subsequent release of the audit guidelines, there are many questions on how to benefit from a reduction in applicable controls.  This blog post is the result of an interview with Tyler Baker (Regional Sales Manager focused on Higher Education), Mark Lucas (VP over Higher Education Delivery) and Tim Winston (Director over our P2PE practice).


Tyler:  One of the first issues many organizations have been running into is that there are very few PCI P2PE listed solutions. Why is that?

Tim:  The PCI Security Standards Council has been planning to release a new version, version 2.0, of the P2PE standards.  Most prospective P2PE solution providers are waiting until the updated standards are published to complete their validation.  Once 2.0 is released, and it is expected very soon, there will be a further delay as the assessment guidelines by the Council are published.  So, there are few validated solutions and that will likely remain so for a while.


Tyler:  Will version 2.0 have new requirements that the solution providers will need to meet?

Tim:  There will be some changes, but the biggest change will be in how the process is handled.  Version 2.0 will address the challenges of validating a solution with outsourced components.


Tyler:  How do our clients take advantage of the solutions that are out there, but are not yet validated?

Mark:  We call those “Unlisted” solutions.  Quite a few of our Higher Education clients have taken advantage of these as P2PE solutions, even though they can’t be formally “listed”.
Tim:  Coalfire has a very effective process that allows clients to negotiate reduced controls with their Acquirer.  Essentially, my team works with Mark’s team and the University to understand the solution components and deployment.  We go onsite to ensure it is properly deployed and then write an opinion letter stating that the University has properly implemented a solution that eliminates its access to sensitive credit card data and therefore justifies substantial reduction in applicable PCI DSS controls.  The University, with Mark’s help, then shares that with the University’s Acquirer.  


Tyler:  You mentioned “reduced applicable controls” in your last answer, how is that different from “reduced scope” an organization gets from a listed P2PE solution?

Tim:  The phrase “reduced scope” has a very specific meaning for P2PE in the industry that is limited to listed solutions only.  The phrase “reduced applicable controls” is used for unlisted solutions.

Mark:  For unlisted solutions, the University can receive a reduction in the applicable controls directly from their acquirer.  Coalfire’s official Validation Letter is almost always enough to get “reduced controls” approved by the Acquirer.


Tyler:  Can the University just go straight to their Acquirer and ask for reduced controls?

Mark:  Technically, they can.  We’ve not seen that work, though.  Understand that this is a two-edged sword for Acquirers.  On one side, they like P2PE because it inherently reduces risk.  On the other side, they need to make sure the University has deployed it properly.  They are reluctant to take the University’s word on the subject and want to see some sort of expert, independent analysis of the implementation.  Yet, on the other side they want this technology deployed sooner, rather than later.  The answer is to have Coalfire independently validate that the University has deployed the solution properly.  Coalfire provides the Validation Letter confirming that the University’s environment is truly encrypted end to end.   This gives the Acquirer comfort to allow reduced controls.


Tyler:  Is it true that with a listed/unlisted P2PE solution in place, that the controls or scope will be reduced enough to the point that an organization does not have to do quarterly ASV scans and yearly penetration tests?

Tim:  Yes, that is very likely.  However, it does need to be implemented properly and we need to validate it.

Mark:  A University can only bypass these requirements on those Merchant ID’s that are in the P2PE environment. If there are Merchant ID’s at the University that do not use P2PE, then they still require performing ASV scans and penetration tests.  In fact, we recommend our Higher Ed clients scan and penetration test all IP’s just for good security practices.


Tyler:  What are some issues that Universities run into when trying to validate an unlisted P2PE solution?

Tim:  It generally falls into the category of deployment errors.  We have seen organizations deploy an unlisted P2PE solution but make a simple error that throws a bunch of controls back into scope.  For example, we’ve seen many clients manually enter card numbers into a connected technology (like a mobile device) that is outside the P2PE hardware.  This throws all the controls back into scope.  

Mark:  We would identify that as a gap and provide the University with alternative approaches to such a need.   Generally, credit card transactions have to happen on the pinpad terminal.


Tyler:  This is great!  Tim, do we have other clients outside Higher Education that are pursuing this avenue?

Tim:  We do, but it does seem to be a more common approach in Higher Ed than some other industries we serve.

Mark:  I might take a bit of credit for that.  I’ve been encouraging a lot of our Higher Ed clients to pursue this.  It works and reduces risk for everyone.  


Please watch your email for a future webinar on P2PE in Higher Education.  Be ready to ask Mark and Tim more specific questions!

Tyler Baker


Tyler Baker — Regional Sales Manager

Recent Posts

Post Topics



Accounting Agency AICPA Assessment assessments ASV audit AWS AWS Certified Cloud Practitioner AWS Certs AWS Summit bitcoin Black Hat Black Hat 2017 blockchain Blueborne Breach BSides BSidesLV Burp BYOD California Consumer Privacy Act careers CCPA Chertoff CISO cloud CMMC CoalfireOne Compliance Covid-19 credit cards C-Store Culture Cyber cyber attacks Cyber Engineering cyber incident Cyber Risk cyber threats cyberchrime cyberinsurance cybersecurity danger Dangers Data DDoS DevOps DevSecOps DFARS DFARS 7012 diacap diarmf Digital Forensics DoD DRG DSS e-banking Education encryption engineering ePHI Equifax Europe EU-US Privacy Shield federal FedRAMP financial services FISMA Foglight forensics Gartner Report GDPR Google Cloud NEXT '18 government GRC hack hacker hacking Halloween Health Healthcare heartbleed Higher Education HIMSS HIPAA HITECH HITRUST HITRUST CSF Horror Incident Response interview IoT ISO IT JAB JSON keylogging Kubernetes Vulnerability labs LAN law firms leadership legal legislation merchant mobile NESA News NH-ISAC NIST NIST 800-171 NIST SP 800-171 NotPetya NRF NYCCR O365 OCR of P2PE PA DSS PA-DSS password passwords Payments PCI PCI DSS penetration Penetration Testing pentesting Petya/NotPetya PHI Phishing Phising policy POODLE PowerShell Presidential Executive Order Privacy program Ransomware Retail Risk RSA RSA 2019 Safe Harbor Scanning Scans scary security security. SOC SOC 2 social social engineering Spectre Splunk Spooky Spraying Attack SSAE State Stories Story test Testing theft Virtualization Visa vulnerability Vulnerability management web Wifi women XSS