It’s not every day that the PCI Security Standards Council issues a new guidance document. But today is one of those days! Per the announcement on their PCI Perspectives blog, the PCI Council has issued new guidance on PCI DSS for Large Organizations.
I’ve already reviewed the document, and unlike some of the other guidance that can get a bit esoteric, I recommend that everyone read this document. There’s a lot in here that reads as common sense – given a scenario, their comments on what to look for and how to handle seem very reasonable. But that’s the beauty of common sense. It’s intutively correct when explained to you, but you wouldn’t necessarily jump to that conclusion quickly if it wasn’t presented as an option. What they’re doing here is offering people good defaults to use in various scenarios.
Part of the value of this stems from how they are defining “Large Organizations”. The focus is less on absolute size of any organization, and more to do with organizational complexity. That complexity can be structural, or the complexity of managing change.
This guidance is immediately applicable to you if your company, among other scenarios detailed in section 3:
- is operating in multiple regions or legal / regulatory jurisdictions
- has multiple acquirers
- is currently / was recently engaged in mergers & acquisition activity
- operates on a central office / multiple franchises model
There is basic guidance covering these scenarios and more. You may not be dealing with any of these things today, but most companies will have to deal with at least one of these at some point. Particularly if you’re a growth company, you should always be thinking about how to effectively manage change when it comes.
Contents
Example: The Accidental Service Provider
A good example is something that I hadn’t previously considered. It’s quite possible during significant business changes to become an accidental service provider. Say you’re a large merchant, and you’re in the process of selling or spinning out a division. Once you are fully decoupled, you will both be standalone merchants. But it’s quite possible that in that transition period, one company will be acting as a service provider for the other, as both entities are not fully standalone yet.
If a previous shared PCI scope spanned the line separating the original divisions, it’s even quite possible for them to be service providers for each other on a temporary basis. Perhaps one company retained control of all physical network infrastructure, whereas the other retained the servers, including Active Directory and the RADIUS servers. Here, they each play a part in maintaining the security of the other.
To most people on the implementation team working to decouple the two companies, it will be very obvious that there are shared services, or service being provided from one to the other. Their day-to-day job is to replicate those services on each site to make them fully self-sufficient. But this understanding needs to propagate up to much higher levels, so that the compliance aspects can be managed appropriately.
RACI
The authors of this document are clearly very big on RACI matrices. These are tables listing out, for various identified functions, who is Responsible, Accountable, Consulted, and Informed. It’s a common tool for mapping out who within an organization fulfils different roles for each function. With that said, over the last decade I’ve spent more time at organizations that did not use (or possibly even know!) about the RACI approach, so it’s far from universal.
The PCI SSC are certainly not requiring that compliant companies now use these, but they are proposing them as one solution to more formally managing the PCI Cardholder Data Environment. More pages of the document are devoted to the RACI section than to any other, which I think gives some insight into where the PCI SSC (or at least the members of the Special Interest Group who drafted this guidance) see big gaps in larger / more complex organizations.
Even if you don’t want to adopt a new methodology, the RACI sections in the appendices are still worth reviewing. They outline the roles, responsibilities, and tasks that need to be assigned as part of a PCI compliance project. As such, they can be thought of a checklists to be factored into your planning. If you’ve got a PCI DSS project underway, and you don’t plan to do something listed in these appendices, you should at least consider why that is. Perhaps there’s a gap?
Get Leadership Buy In
Perhaps the most important, albeit least specific advice is to be found in the executive summary. And it’s advice that’s generally applicable to companies of all sizes, from the smallest to the largest, and it’s not just limited to PCI DSS compliance:
“… continued PCI DSS compliance requires not only a strong culture of collaboration and communication, but also support and commitment from executive leadership.”
It’s a sign of the times that they felt it necessary to put that statement in the Executive Summary. Possibly it was prompted by the finding, publicly reported in the most recent Verizon Payments Security report, that only 36.7% of organizations were fully compliant with PCI DSS.
If executive management don’t buy into an initiative, whether security, new line of business, or something else, that initiative will struggle to succeed even with the best intentions of the project team.