08 January 2018

PCI compliance

Pragmatic data protection or money for old rope?

As creative software developers, we often find ourselves dealing with sensitive user data. This can range from contact details right through to the handling of credit card transactions.

We take the responsibility for this very seriously. We are a registered ICO (Information Commissioner's Office) organisation, and we undertake regular self-imposed checks on data management practices and infrastructure security.

Our approach in this gives our clients the confidence that we’re looking out for their best interests.

This week, a long-term and strategically important client asked us to complete a PCI attestation of compliance form. PCI, or Payment Card Industry compliance was set up around ten years ago by the leading payment card providers (Visa, MasterCard etc.) as a means to add data management rigour to payment processes to all parties delivering payment card services.

In the spirit of integrity in all matters data protection, we set out researching PCI Compliance, in order to understand where we fit in.

PCI Compliance for software developers
For this particular client, we have developed an app and website, which links to a third party booking system and payment gateway. The client is therefore the merchant and ourselves and the payment gateway organisation are classed as providers. So far so good. What we needed to do, it emerged was complete a form that confirms we use modern software development techniques and keep up to date development software as standard (this is the very least we do).

It was in the form(s) and guidance notes themselves that our troubles began. Firstly, we were asked to compete form SAQ A (Self Assessment Questionnaire A). This short form should be completed by any software developer producing commercial software for retailers. These forms can be obtained from all reputable payment gateway providers, as well as the PCI Council’s website (https://www.pcisecuritystandards.org).

Then we were informed that, because we produced software for the client that links to a payment gateway, we must complete SAQ D. this 82 page document presented an entirely different set of challenges. The form goes into great detail about network security of offices, network segmentation, employee security checks and more. I suggested to the client that this would take us at least three (oh yes!) hours to complete, and set about doing so.

This is where I really got out of my depth. The document is essentially not relevant to the services that we provide. Of the 12 ‘requirements’ within the form to achieve compliance, only one was in any way relevant to us. How do I know this, you might ask? Because I spent many more hours talking to and reading content from organisations like ours on compliance in order to get the form right.

In total (not counting this article) I estimate that I spent around 20 hours researching PCI Compliance. This time cannot be invoiced or recuperated through the client, as it is expected that we do this at our own expense.

Compliance and self-regulation
Now slightly disgruntled, and feeling distinctly in the dark, I suggested a meeting with the client’s resident PCI adviser would be helpful to air initial experiences / opinions (for what it was worth).

The discussion was enlightening - by attesting compliance, we open ourselves to legal action, should we be found to be non-compliant in the event of a data breach or fraud. It is still not clear whether we would be open to legal action, simply by being compliant, and therefore part of the supply chain where blame is shared.

In a nutshell you are agreeing to something that is not bound by law in the UK. The document is confirmation that you conform to the rules set out by the PCI Council - in exclusion of UK law - a kind of contract of accountability, if you like.

Search on the .gov.org website for ‘PCI’ and you will find nothing. Do the same on the ICO website and you will find nothing. The reason for this is that the PCI Council is a self-appointed regulator. And clients like ours are going through PCI accreditation processes because the payment card providers are insisting on it. This has created an industry all of its own - an unregulated one.

As you can imagine, PCI Compliance is now being applied everywhere. And specialist consultants and advisors which, usefully, can be found on the PCI Council’s website are springing up to help organisations like mine be compliant. All for a fee, of course.

So, what’s the problem?
Payment card security is important. Customers are regularly subjected to fraud in payment processes and it is reassuring that the payment card industry recognises the issue (£768.8m last year in the UK alone in payment transaction fraud - hard to ignore) and is addressing systemic weaknesses.

The problem arises in the way the council has prepared its own material:

  • Much of the requirement wording is ambiguous to the point that it is rendered ineffective. In legal terms this is problematic because it is too vague to draw firm conclusions from. In fact our opinions on security, centred around an app (currently withdrawn), were at odds with the PCI adviser’s, for reasons I still don’t fully understand.
  • The SAQ forms themselves are poorly worded. Here is my personal favourite question from within the pages of form SAQ D: Question 6.4.3 ‘Are production data (live PANs) not used for testing or development?’ (emphasis theirs) Are they not used? Any ideas? Answer choices are ‘Yes’, ‘No’ or ‘Not applicable’. I think the addition of ‘Not understandable’ would be useful here!
  • The documents that we must complete to be compliant are quaint, to be polite, by today’s standards. The self assessment forms are in pdf or Word format. Once complete you give them to your client, or hold them on your own records (it is assumed) to prove compliance when asked. There is no central register of complaint organisations, no transparent grading of security for the public to freely review, and no lasting record of the compliance procedures undertake
  • As a result, because we work with many organisations, providing software that may link to payment gateways, I suspect we will be repeating this exercise a lot. SAQ D took us three hours to complete and much more to research.

Question: Why would the world’s leading payment card organisations set up a platform which was so badly recorded and vaguely worded? They are well funded, technically smart and employ some of our brightest talent.

My best guess is in order to be deliberately vague when legally challenged, to spread responsibility right through the supply chain, and to create work for consultants to advise businesses like mine and my clients on how to navigate such a grey landscape.

Pessimistic I know, but I’m going to hang on to the sentiment until court cases start to happen - I’m feeling prophetic. And it’s my firmly held belief that it’s going to get very messy as PCI Compliance is more widely adopted.

The best defence we have to PCI-related litigation is our now beefed up indemnity insurance. But, by signing an SAQ, even this may be rendered inadequate.

In summary
PCI Compliance is a self-certification process. That is to say that you certify that you follow the requirements it sets out. It is assumed that this is intended to stamp out malicious activity in software development - things like the use of data scraping while transactions take place.

‘I feel so much more secure’, I hear you say. Well don’t. Because if organisations intend to develop malicious software to steal your data, they’ll have no problem with lying on a self-assessment document in order to do so. And it’s this that undermines the whole process. Yes those organisations will be liable for legal action by breaking compliance, but they’ll be long gone before that happens.


Recommendations for change
If things are left unchallenged, businesses (possibly mine) are going to fall victim to a poorly conceived platform - one that is more concerned with spreading cost and blame than eliminating risk. The sentiment is good, don’t get me wrong, but more work needs to be done. Here are a few ideas:

Bring compliance documentation in line with UK law. This at least will give transparency to the yet unknown risks in payment card security litigation.

Get government regulatory buy in. PCI Compliance means nothing to the UK government, as far as I can tell.

Design documents which are clear and unequivocal. Ambiguity is professional risk, and badly written forms betray the actual intent of compliance.

Create a public register of compliance, and design compliance logos for those to display who are on it.

Make completed compliance documentation questionnaires available for all to see. All self-respecting businesses want to do the best they can to guarantee security - it’s important that the good are segregated from the bad. This will save energy and cost incurred by all parties in completing self-assessment.

Provide better guidance on the council website. All organisations have to begin the journey of proper data management - especially if they are a startup. There should be videos and guides to completing questionnaires online. What is available right now is woefully inadequate, and creates more questions than it does answers.

Provide a FREE advisory service. If the council want organisations to get on board, they should be available to answer questions and resolve disputes. They should also take accountability for their errors. The only way to do this currently is to search their endless volumes of lengthy pdf guides, or query the badly conceived FAQs on the website.

What next?
We are contacting the ICO, with a copy of this document in order to inserstand their position in PCI Compliance. I’ll report our findings when they respond.