How To Manage Your PCI DSS Security Policy… And Why That Isn’t Enough

Posted on June 28, 2016 by lexi

In this series, we’ve already talked several times about the need to go beyond compliance with the PCI DSS.

This is doubly true for policy.

Once everything has been setup and documented, there’s a tendency to treat policy as a box ticking exercise. After all, assuming you have the necessary systems and processes in place, how important can the actual policy document be?

Sadly, as with all security matters, many organizations don’t find out the answer to this question until after something has gone seriously wrong.


What Is Policy, Anyway?

In essence, your PCI DSS policy is a set of high-level documents that govern how your security processes will be managed. These documents are usually owned at the highest levels of your organization, and they don’t include day-to-day operational details.

With that in mind, in order to be PCI DSS compliant you must:

“Establish, publish, maintain, and disseminate a security policy that addresses all PCI DSS requirements, includes an annual process for identifying vulnerabilities and formally assessing risks, and includes a review at least once a year and when the environment changes.” PCI DSS Quick Reference Guide requirement 12.1

Since we’ve already covered the risk assessment and vulnerability management elements, it’s really just the policy documents themselves to consider here.

We might be biased, but in our opinion, the simplest way to create, distribute and maintain your PCI DSS policy documents is to use an electronic IT GRC system such as TraceCSO. A quality solution will help you create your documents based on compliance requirements and your own risk profile, as well as automating distribution, tracking sign-off and verifying staff understanding via custom testing.


When Policy Isn’t Policy

You might be surprised to know that of the nine information security policy requirements in the PCI DSS, only three actually contain the word policy.

Why? Because most of the requirements actually relate to procedures, responsibilities, and awareness.

So take a deep breath. Here’s what you’ll need to do in order to be compliant with the PCI DSS policy requirements:

  • Document all operational security procedures
  • Create usage policies and procedures for all critical systems (e.g. remote access tools)
  • Implement a formal security awareness program for cardholder security
  • Screen all new personnel prior to hiring, including their employment history, criminal record, etc.
  • If sharing cardholder data with service providers, implement policies to govern shared processes AND check their PCI DSS compliance at least annually
  • Implement a fast-acting incident response plan to respond to breaches

Sounds like a lot, doesn’t it? And if you consider all these activities purely from the perspective of being PCI DSS compliant, it is a lot.

But that’s not the approach we recommend.

The fact is that a sensible HR department would always insist on screening prospective employees before taking them on. After all, stealing or compromising cardholder data isn’t the only thing an incompetent or malevolent employee could do.

And don’t you already have a security awareness program? There are plenty of other security issues your employees need to be reminded of.

The fact is that most (if not all) of these requirements are things you should be doing anyway, whether or not you’re worried about compliance. They’re simply a sensible set of precautions for any security approach to include.


Be Proactive

I have a theory. I believe one of the best ways to ensure you aren’t compliant with the PCI DSS is to come at it purely with the aim of being compliant.

That might sound counterintuitive, but hear me out.

In the aftermath of a breach, the investigation into your policies and procedures will be considerably more thorough than the one you go through annually to ensure you’re compliant. As a result of this, analysis of these post-mortem investigations has found that in the vast majority of cases the affected organizations weren’t compliant.

The important thing to remember here is that all of these breached organizations have processed card payments, so at least most of them must have believed themselves to be compliant. After all, PCI compliance testing is mandatory on an annual basis.

So what we have, essentially, is a long list of breached organizations that thought they were compliant… but actually weren’t. From this, I’d say, we can conclude that focusing purely on compliance is not a good approach.

Instead, I believe you should approach payment card security in precisely the same way you’d approach security as a whole: Proactively.

If you have a holistic and dedicated approach to security, you’ll already be ticking off nearly every policy requirement in the PCI DSS. Irrespective of compliance, this professional approach to security as a whole will massively reduce the chances of your organization being breached.

Of course, you have to be PCI DSS compliant, and sure, you’ll need to write and distribute the policy documents. But if you take our recommended approach to security, an electronic IT GRC system like TraceCSO will help you tick off these requirements in no time at all.

And if the worst does happen, you’ll be far more likely to be deemed PCI DSS compliant in the aftermath if you can demonstrate a deliberate and proactive attempt to ensure the security of cardholder data.


Check out other posts in this series:

Post 1: PCI Compliance: What, Who, and How?

Post 2: How to Conduct a PCI DSS Risk Assessment (Even if You Have No Idea What You're Doing)



Policy Manager

Are you interested in the ability to create, upload, approve, disseminate and track your IT security policies in one platform? Take a test drive of the policy management capabilities within the TraceCSO platform with our free 30-day trial offer.

Start Your Free Trial Now

Posted in IT Compliance and Regulatory Change Management, Policy Management