With 20 year’s experience in the card processing space, I’ve seen PCI DSS evolve from its earliest days to its current form. In that time I’ve worked with lots of outside companies as clients and service providers. PCI DSS is sometimes thought of as a very strict standard, one that takes a prescriptive approach on how things should be done. But in my experience, I’m constantly surprised by some of the creative ways people find to address the requirements.
I won’t go deep into details of some of the quirky approaches I’ve seen, but I’ll try to illustrate how that comes about through a concrete example. Because it’s that experience that allowed me to get comfortable with what I think is the best PCI DSS advice I can give.
Contents
The Advice
Let’s cut to the chase. The best PCI DSS compliance advice I can give for designing controls is “Ask your QSA“.
Is that counterintuitive? For most people, probably so.
Companies that are currently, or will soon be, assessed typically try to limit the visibility of the QSA into their business as much as possible. Writing as a current CISA, it’s a common auditor management approach, and one that in principle I don’t take much issue with. Particularly during an assessment, you treat it as any other important interview: give accurate answers that address the question asked. Beyond that, don’t embellish, don’t over-elaborate. Certainly don’t invite discussion of whether you designed a control correctly if it appears to be operating well.
But when you’re not currently going through an assessment, and are designing a security control to meet PCI DSS requirements, recognize that things are different. In many (most?) cases, you’ll find the right course of action to be relatively clear.
Managing Conflicting Interpretations
There’s a reason there’s an old joke, along the lines of “How did you get three different opinions? You put two auditors in a room together to discuss one control objective.” Which is to say the moment there’s any discretion in how to interpret a requirement, and what it means to comply, you’ll find people have differing opinions.
PCI QSAs come from a range of different backgrounds. I’ve worked with QSAs ranging from former banking auditors through to reformed black hat hackers. When they disagree, it’s likely they both have good points, informed by their respective backgrounds. But only one of them is going to sign your ROC and AOC.
Is my Service Provider compliant?
One of the best examples I have deals with PCI Service Providers (SP). When a company subject to PCI DSS is going through an assessment, they have to disclose any Service Providers they depend on, directly or indirectly, for the security of Cardholder Data (CHD). If you’re using an outside provider to store your Requirement 10 audit trails, that service is in scope for your PCI DSS assessment even though you’re not directly sharing CHD with them. There are two ways that company can fit into your assessment.
The preferred way is that the SP undergoes their own PCI compliance assessment and gets their own AOC. Your QSA effectively reviews their AOC, and confirms that all services in scope for you are checked off as being in scope for their annual assessment. If their QSAC and QSA have current registrations, and the AOC is in date, your QSA accepts that you’re using an appropriate provider for that service.
The other, more complex way is for you to extend the scope of your PCI Cardholder Data Environment to encompass the necessary parts of the Service Provider’s business you depend on.
How much review is enough?
If you go down that path, what level of visibility and review is sufficient? In our cloud logging example, is it enough to confirm that you’ve set the appropriate retention window in the management UI? Or does your QSA need to review the provider’s policies and procedures? Their physical security? Their HR records, to ensure their background check policy is enforced?
We’ve taken a requirement that is straightforward: have audit logs easily accessible for a quarter and available for a year. By outsourcing to a provider that isn’t themselves directly PCI compliant, we’ve introduced significant QSA discretion.
How to manage risk?
What’s going on is that risk based decisions need to be made. You need to determine what is a sufficient level of review during your due diligence and due care processes to ensure you’re getting the service you need.
However there are actually two different levels of risk management going on. You, as the company subject to PCI DSS, need to be sure you and your service providers are meeting all requirements. But then, your QSA has to make their own determination. They need to decide whether they believe you have an adequate level of visibility into your service provider, and can have them provide appropriate evidence, to mark the requirement as being met.
If your QSA finds an issue with your SP during your assessment, that’s too late. An latent problem is exposed. Now, if you are to be marked as compliant at all, you likely need a compensating control to overcome the control gap identified by the QSA.
Ask your QSA early
Which brings us back to my original advice. You’ll encounter scenarios where there are choices to be made. Each will have some pros and some cons. Some will be more palatable than others. You probably have a preference, but the fact there’s no clear path forward indicates that the QSA may have similar concerns during the annual on-site assessment.
In those cases, why not take the options to your QSA and ask for advice? Of course, you only present options that you’re prepared to live with, when the QSA recommends you pick a particular one.
By asking the QSA for advice, a couple of things happen.
First, you find out whether any of these are actually viable from the QSAs perspective. Maybe they don’t like any proposal, but through enumerating the options, you make it clear to the QSA you have considered the options and that there wasn’t an obvious path forward. You make it clear that the likely solution is to be found in the set you’ve presented. If the QSA doesn’t like any of the options, you’re also putting the onus on them to at least tell you what they think the deficiencies in those solutions are, so you can improve your designs.
Second, if the QSA picks one of your options and says “OK, go with that one”, you effectively bind them to the control design. When it’s time for the on-site assessment, assuming the PCI DSS itself hasn’t changed and you’re using the same QSAC, it’s extremely difficult for them to turn around and fail you for what you agreed. They can certainly fail you if you didn’t implement the solution as agreed, but they can’t fault the solution itself.
Get it in writing!
If you go down this path, be sure to get the agreement or confirmation in an email! An understanding QSA being the lead on your account today says nothing about tomorrow or next week or next month. In fact, within the last year, the PCI Council has issued new guidance suggesting rotation of the lead QSA on an account as a best practice. It’s going to become more common to see new faces on your QSAC team every year. Get your agreements in writing.
