Gartner Blog Network


Best Practices in PCI DSS 3.1 are now required

by Jonathan Care  |  August 13, 2015  |  1 Comment

PCI DSS 3.1 became effective April 15, 2015, and impacted organizations were given some “Best Practices”, with a clear indicator that on July 1st, 2015 these would become required. So what has changed, and what (or whom) are impacted? This is dependent on which SAQ you are completing, so let’s take a look at these requirements and see which SAQ they impact.

  • 6.5.10 – Requires specific coding practices to protect against broken authentication and session management. This affects the following SAQs:
    • SAQ A-EP
    • SAQ D-Merchant
    • SAQ D-Service Provider
  • 8.5.1 – Requires that service providers with remote access to customer premises use unique authentication credentials for each customer. This affects SAQ D-Service Provider.
  • 9.9.x – Requires that devices capturing payment card data via direct physical interaction with the card be protected from tampering and substitution. This affects the following SAQs:
    • SAQ C
    • SAQ B
    • SAQ B-IP
    • SAQ D-Merchant
    • SAQ D-Service Provider
  • 11.3 – Requires a methodology be implemented for penetration testing, which affects
    • SAQ A-EP
    • SAQ D-Merchant
    • SAQ D-Service Provider
  • 12.9 – Requires that service providers provide the written agreement/acknowledgment to their customers as specified at requirement 12.8. This affects SAQ D-Service Provider

What does this mean for me?

As a card acceptor, make sure that any entities storing, processing, or transmitting data on your behalf are up-to-date on these new requirements. Especially, make sure that they give you a written acknowledgment of their responsibilities for the security of cardholder data that you entrust to them. If you need to perform penetration testing as part of your PCI DSS compliance exercise, ensure that you have a methodology that covers infrastructure testing, application testing and even social engineering testing, both internally and externally. A lot of recent breaches have involved application security flaws, or exploitation of trust or process flaws to obtain access to cardholder data. And of course, once you have that methodology documented, ensure your penetration testers understand and follow it – whether its an internal team, or a professional service organisation. There are several exemplars available, including the Penetration Execution Testing Standard, guidance from SANS, OWASP, ISECOM, NIST and even the PCI Council has something to say on the matter.

As a service provider, the biggest change is that you are required to state in writing that you are responsible for the security of cardholder data you process on behalf of a card acceptor. This can have significant implications if (or when) a card acceptor is breached. If you’re a payment processor providing additional services to a card acceptor (for example, tokenization), then this may affect you, too.

What’s good about it?

These changes give PCI DSS entities a degree of clarity around what is required for compliance with PCI DSS. Like traffic warning signs placed at accident blackspots, PCI DSS changes usually come about from the card associations identifying key patterns in data breaches, and refining the guidance and requirements. So if you are using a service provider, they are now on notice that they have to accept responsibility for cardholder data, and software developers are getting direction around what they need to do to make their payment applications more resilient against attack. Finally of course, it removes some of the variance in penetration testing quality and execution, giving the opportunity for formal adoption of good security practices in this important area.

Remember, you don’t have a choice around whether your payment systems are tested for vulnerabilities – you only have a choice regarding whether it is done under your control, or not.

Category: pci-dss  

Tags: pci-dss  penetration-testing  

Jonathan Care
Research Director
1 years at Gartner
22 years IT Industry

Jonathan Care expertise includes payment systems, cybersecurity, fraud detection and prevention applications, authentication, identity proofing, identity theft, and insider threats. He also covers the PCI compliance program, tokenization and the security aspects of payment systems. Read Full Bio


Thoughts on Best Practices in PCI DSS 3.1 are now required


  1. […] Jonathan Care PCI DSS 3.1 became effective April 15, 2015, and impacted organizations were given some […]



Leave a Reply

Your email address will not be published. Required fields are marked *

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.