5 Things You Should Know about PCI DSS Penetration Testing

5 Things You Should Know about PCI DSS Penetration Testing

The Payment Card Industry Data Security Standard, commonly shortened to PCI-DSS, was introduced to provide a minimum degree of security when it comes to handling customer card information. While the standard has been around for over a decade, specific requirements surrounding the penetration testing have only recently been officially incorporated into the process.

In this article, we are looking at 5 things you should know about PCI DSS Penetration Testing. We asked our CEO and PCI-DSS expert, Peter Bassill, to talk us through 5 things every online merchant should know.

A little background

The Payment Card Industry Data Security Standard, commonly shortened to PCI-DSS, provides a minimum degree of security when it comes to handling customer card information. While the standard has been around for more than a decade, specific requirements surrounding the penetration testing have only recently been officially incorporated into the process.


The PCI-DSS distinguishes between a vulnerability scan (requirement 11.2) and a penetration test (11.3). Both Penetration Testing and Vulnerability Scanning are required for PCI DSS compliance.

The difference between the two is simple. A vulnerability scan is an automated process. It provides no human verification of discovered vulnerabilities and only alerts on known knowns. That is, it only alerts on the presence of vulnerabilities it knows about.

A penetration test is a much larger piece of work. A penetration test attempts to exploit known vulnerabilities using manual techniques. It then takes the process further by looking for unknown vulnerabilities.

Penetration Testing removes false positives from the entire process and demonstrates the real-world risk to the business and what a hacker could actually accomplish.

When booking your penetration test, make sure the penetration testing provider includes manual testing and verification rather than just an automated scan. Also check that the testers performing the test are at least OSCP qualified.


The scope of a penetration test is possibly one of the hardest parts of the entire process. As a professional tester I have had no end of scoping calls where potential clients want to reduce the scope to save on cost. This is a false economy. There have been numerous PCI-DSS audits where the merchant has failed for not having performed a satisfactory penetration test.

The penetration test must include the perimeter of the Cardholder Data Environment (CDE). This must include any systems which, if compromised, could impact the security of, or grant access to, the CDE. A system is out-of-scope for a penetration test when segregated from the CDE. This way the security of the CDE is unaffected when it is compromised.

It’s possible to reduce the scope of the test by segregating your network by segmentation. Segmentation is achieved by using very strict firewall rules or using separate networks. If you have implemented segmentation, you must control both inbound and outbound ports. Do not allow ANY. While segmentation is not compulsory, it reduces the duration and therefore the cost of the test. This also has the added bonus of making your network inherently more secure in case of compromise.

Checks must be performed annually to confirm the effectiveness of segmentation controls. If you are a service provider it is six-monthly. This is requirement 11.3.4. These must be conducted by an individual who is completely separate from the implementation or management of the CDE.


The results of a penetration test vary. Critical and high-risk vulnerabilities must be addressed before any system is compliant. The risk ratings are dependent on multiple factors. These include impact, likelihood, ease of exploit, and an industry score (such as CVSS).

Any existing compensating controls will have an effect in reducing the risk level. It is important to discuss these with your penetration tester. If the tester was not aware of these then you could be receiving a higher risk score. It is possible that low risk issues can impact a separate PCI DSS requirement. If this is going to happen the should be clearly documented in the report.

Your penetration test report is evidence of your security controls. Any additional evidence submitted alongside the report may be sufficient to mitigate a discovered vulnerability without the need for making additional infrastructure or code changes. Ultimately that decision rests with the QSA.


Make the penetration testing provider an extension of your own team rather than an outside third-party. The more detail that you give to the tester the better the results.

Providing documentation on systems or cardholder data flow helps. A list of expected services should also be provided. This allows the testing team to contextualise vulnerabilities and focus on areas where significant issues may exist.


PCI DSS is a minimum level of security. It does not encompass all aspects of cyber security.

PCI-DSS focuses on securing cardholder data. It does not look at other attack vectors. For full coverage, speak to your tester about expanding the test and providing a PCI-DSS report as a separate report.

You should, therefore, change your approach from simply attempting to obtain PCI DSS accreditation, to securing systems as much as reasonably possible, and then achieving compliance as a by-product.

  • Recent Articles
Author Details
Founder & CEO at Hedgehog Security

Peter has been in the Information Security world since 1999 and in IT in general since 1996. His work history contains a unique blended balance between the development of exceptional technical capabilities and business knowledge. Peter is a proud father of twins and enjoys GT endurance racing on the weekends.

We would like to keep you informed about our services. Please tick the options below to receive occasional updates via

  • penetration testing steps
    Peter talks to FindMyUkCasino
  • Malware
    SB Tech Breach

    Last week saw SB Tech Breached by the hacking group Maze. It seems that every week the group are announcing more victims.  GameOn asked our CEO Peter Bassill, to give us some insight into the attack. The GameOn article is here.

  • Privacy
    Howto VPn

    In our “How to securely” series we asked our followers what tools they would like a simple guide on to help them stay secure online. There seemed to be a lot of confusion as to what a VPN is and why you should or should not use one. So we asked Peter to help.

  • WhatsApp
    How To Whatsapp Safely

    WhatsApp is among the fastest-growing instant messengers out there, and almost a social network in its own way. But if you are using it, there are some steps you should take to protect your security and privacy.

  • Morrisons Breach Update

    The UK’s highest court ruled that Morrisons can not be liable for a criminal act of a person seeking to harm their business. On April 1st, 2020, a panel of five justices unanimously ruled that Morrisons was not “vicariously liable”.

  • Remote Working Considerations

    With the current pandemic situation, we all need to be taking remote working considerations. While adjusting the work paradym, it is vital to keep a mind’s eye on the security and safety of the businesses information assets

  • Securing Zoom
    How To: Securing Zoom

    In this guide we are looking at how to go about securing zoom. Since the onset of the global pandemic, we have seen surge in “zoom bombing”. This is where people with malicious intent look for in-progress zoom meetings to join and cause trouble.

  • Software Security
    Dell EMC iDRAC memory corruption Vulnerability

    A critical vulnerabiltiy has been identified in Dell EMC iDRAC7, iDRAC8 and iDRAC9. Some unknown processing is affected by this issue. Manipulation with an unknown input can lead to stack based memory corruption.

  • Hiscox Sues for Failing to Disclose Data Breach

    On March 27th, Hiscox Insurance Company Inc. filed a complaint against law firm Warden Grier for concealing a data breach that occurred back in 2016.

  • Software Security
    Privilege escalation on Nginx Controller up to 3.1.x Controller API

    A critical vulnerability has been identified in Nginx Controller up to 3.1.x (web server,) affecting an unknown code block of the component Controller API.

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Scroll to Top