Blog

Changes to SAQs for PCI DSS v3.2.1

Last month I wrote about the new PCI DSS standard version 3.2.1 and how nothing of significance had changed.

Though that remains true, the supporting documents have now been released, and they include a change that may impact your compliance and validation programs.

The supporting documents that have now been updated for PCI DSS v3.2.1 are:

  • Self-Assessment Questionnaires (SAQ)
  • SAQ Instructions and Guidelines
  • Report on Compliance (ROC) Template
  • Attestations of Compliance (AOC)
  • Prioritized Approach for PCI DSS
  • Prioritized Approach Tool

The one document that features a significant change is SAQ A.

The Self Assessment Questionnaires (SAQs) are validation documents that must be filled out annually by organizations if their transaction volumes do not cross the threshold at which they are required to bring in an outside Qualified Security Assessor (QSA).

There are different SAQ documents depending on how you handle payment card data. The criteria are detailed and specific, but in a nutshell:

SAQ A
Card-not-present merchants that have fully outsourced all cardholder data functions.

SAQ A-EP
E-commerce merchants that have outsourced all cardholder data functions but still impact security of card data due to the nature of the integration.

SAQ B
Merchants using only Imprint machines and/or standalone, dial-out terminals.

SAQ B-IP
Merchants using only standalone, network based, PTS-approved payment terminals.

SAQ C-VT
Merchants who manually enter a single transaction at a time via a keyboard into an Internet-based virtual terminal solution.

SAQ C
Merchants with payment application systems connected to the Internet.

SAQ P2PE-HW
Merchants using only a certified P2PE solution.

SAQ D
Service providers and all other Merchants.
 

Though the overarching obligation around PCI DSS that all applicable controls apply should still guide your compliance and validation program, you should find that if you meet the criteria for a particular SAQ, then the controls listed in the SAQ are pretty much the only ones you need.

What is interesting here is that with version 3.2.1, SAQ A has a new control added.

SAQ A now includes requirement 6.2 as a necessary control for compliance and validation. This requirement covers the installation of vendor supplied security patches. So even if you have outsourced all card data processing, and users only enter the payment details into an IFRAME on your site, you still need to patch your web server.

This does not seem to be an unreasonable addition. After all, who does not keep their web server patched and up to date? But what you will need to do now is make sure you have policy and procedures around this function and that you keep records of such patching.

Also note that 6.2 distinguishes between critical patches (deploy within one month of release) and non-critical patches (deploy as appropriate - for example within three months). The determination of criticality is on younot the vendor. So unless you commit to deploying all security patches within one month of release, you will also need to implement controls (policy and procedures) for requirement 6.1risk ranking of vulnerabilities; that is how you must separate critical patches from non-critical ones.

If you have more questions ... Ask a QSA

 

Related Articles By Topic

PCI DSS

Contact Us
Chat with our team about your PCI DSS compliance program.
Schedule a call
Contact Us