Blog

Requirements for Written Policies and Procedures for PCI DSS Compliance

I often come across clients whose documentation is missing a policy or a procedure that PCI DSS requires. “That will never happen here” or “We don’t have any workflow that could cause us to need that procedure,” they say. This may be true today, but when someone new comes along and decides that since there is no policy prohibiting “it”, and no procedure to follow, they can do “it” however they please. For PCI purposes this is exactly wrong. Relying on the notion that everything that is not specifically allowed is implicitly denied is causing this problem. Written policies need to be explicit, just as the firewall and access management standards require “deny all other” rules, the policies and procedures themselves must have an explicit “denied unless allowed herein” statement.

In addition, incident response plans should have contingencies for when that impossible event occurs. I often point to the period a couple of years ago when a major card processor was sending PAN back to the payment gateways in their authorization message in error. This sprayed unencrypted PAN into logs, transaction histories, backups, and other unexpected places. Several clients had only the incident response plan to fall back on.

Our client’s payment processor-generated data validation did not catch it, their DLP didn’t catch it, their log review processes didn’t catch it. The quarterly PAN scan happened to occur at the same time and that caught the problem.

Our view is that if PCI requires the QSA to identify the policy or procedure which addresses any specific issue, even if your company does not do that, your policy must specifically say “No one is permitted to ship data tapes from one data center to another” as an example. The procedure for shipping media from one place to another should then specifically refer to the policy which says “Don’t”.

One last place these purportedly unlikely events should be listed is in the risk analysis. If someone could elevate the risk to the environment by, for instance, de-facto creation of a procedure that is otherwise undocumented, that risk belongs in the analysis so that it can be re-addressed each year to ensure that conditions have not changed in the interim. Perhaps a new technical control is now available to prevent the unlikely event from occurring and therefore it can be removed from the risk analysis once the control has been implemented. Otherwise, a detective control may be in order so you at least know that unlikely just became current practice, and you can address it appropriately.

If you are a new PCI client and you do not yet have a comprehensive set of PCI-required policies and procedures, Truvantis has a set of templates that you can customize to your specific environment. We can also assist with the customization and guide you through your PCI DSS assessment process.

Related Articles By Topic

PCI DSS

Contact Us
Let Truvantis assist with getting your policies and procedures organized.
Schedule a call
Contact Us