What Security Testing Does PCI Require?
The Payment Card Industry Data Security Standard (PCI DSS) isn’t the easiest set of requirements to read and understand. Many of the items specified in it are ambiguous or open to a variety of different interpretations. So naturally, many organizations required to meet this standard just want to know what exactly do they need to do to meet it! Today I’m just going to focus in on the security testing requirements prescribed and try to answer the question, “What security testing does PCI require?” Additionally, I’m going to try and just focus on organization’s that are filling out a Self-Assessment Questionnaire (SAQ) because that’s often where a lot of questions come from.
It Depends…
You knew I couldn’t make it through this whole post without those two magically infuriating words. But before identifying what’s required, one of the big questions that needs to be answered is what is the scope of PCI in your organization. Depending on what type of SAQ you fill out (A, A-EP, B, B-IP, C, C-VT, D, P2PE) for each payment channel will depend on what types of security assessments or penetration testing you are responsible for conducting. If you are filling out an A, B, B-IP, C-VT, or P2PE SAQ, good news, you can stop reading! None of these SAQs require penetration testing, highlighting why scope reduction can be so crucial for PCI compliance.
Now for everyone else using SAQs A-EP, C, and D, there is some testing that is required.
SAQ A-EP
This SAQ is used by any e-commerce merchant with a website that “does not itself receive cardholder data but which does affect the security of the payment transaction and/or the integrity of the page that accepts the consumer’s cardholder data.” That means, for example, if your website has a page that accepts your client’s payment card information, but then sends it to a third-party processor directly (maybe via an API call), this is going to be where you fall. What security testing does PCI require for SAQ A-EP?
- External Vulnerability Scans (11.2) – Quarterly and after any significant architectural changes, conducted by an approved scanning vendor (ASV)
- External Penetration Testing (11.3.1) – Annually and after any significant architectural changes, conducted by an independent and qualified internal resource or a qualified third-party
- Internal Segmentation Validation Testing (11.3.4) – Every 6 months and after any significant architectural changes, conducted by an independent and qualified internal resource or a qualified third-party
SAQ C
This SAQ is used by any merchant who “process cardholder data via a point-of-sale (POS) system or other payment application system connected to the Internet, do not store cardholder data on any computer system, and may be either brick-and-mortar (card-present) or mail/telephone-order (card-not-present) merchants.” If you don’t fit any of the “lower” SAQs and you’ve properly implemented segmentation and avoid electronic cardholder data (CHD) storage, you probably fill out this SAQ. What security testing does PCI require for SAQ C?
- External Vulnerability Scans (11.2) – Quarterly and after any significant architectural changes, conducted by an approved scanning vendor (ASV)
- Internal Vulnerability Scans (11.2) – Quarterly and after any significant architectural changes, conducted by a qualified internal resource of independent third-party
- Internal Segmentation Validation Testing (11.3.4) – Every 6 months and after any significant architectural changes, conducted by an independent and qualified internal resource or a qualified third-party
SAQ D
This SAQ is really the catch-all for any organization that doesn’t meet the criteria of the other SAQs or electronically store CHD. This is the beefiest questionnaire with the most requirements that your organization must meet, so not surprisingly, it also requires the most testing. What security testing does PCI require for SAQ D?
- External Vulnerability Scans (11.2) – Quarterly and after any significant architectural changes, conducted by an approved scanning vendor (ASV)
- Internal Vulnerability Scans (11.2) – Quarterly and after any significant architectural changes, conducted by a qualified internal resource of independent third-party
- External Penetration Testing (11.3.1) – Annually and after any significant architectural changes, conducted by an independent and qualified internal resource or a qualified third-party
- Internal Penetration Testing (11.3.2) – Annually and after any significant architectural changes, conducted by an independent and qualified internal resource or a qualified third-party
- Internal Segmentation Validation Testing (11.3.4) – Every 6 months and after any significant architectural changes, conducted by an independent and qualified internal resource or a qualified third-party
