PCI Security Standards Council Publishes New Versions of Self-Assessment Questionnaires

On April 29, 2022, the PCI Security Standards Council (PCI SSC) released new versions of the PCI DSS Self-Assessment Questionnaires (SAQs) ahead of the anticipated June 2022 release timeline. After the release of the new version of PCI DSS 4.0 a month prior, the new versions of the SAQs have been updated to reflect changes in the standard, as well as to adjust requirements applicable for different SAQs for evolving understanding of risks.

SAQs may be used for validation of PCI DSS compliance by merchants or service providers that qualify for validation of compliance via self-assessment. Additionally, for assessments resulting in a Report on Compliance, SAQs define subsets of PCI DSS requirements applicable for validation of PCI DSS compliance for transactions meeting specific qualification criteria outlined in each respective SAQ. This made it a much-anticipated update for many organizations that structured their payment transaction data flows and cardholder environments supporting them to qualify for validation of compliance via a reduced set of PCI DSS requirements from one or more SAQs.

The qualification requirements for each of the SAQs have not changed since the previous version of PCI DSS. The new version of PCI DSS introduced a number of new requirements that have been added to the SAQs, with SAQs A-EP, C and D seeing the highest number of new requirements added. Additionally, some of the PCI DSS requirements that are part of PCI DSS 3.2.1 but have not been included on SAQs have found their way into the new versions of the SAQs. At the same time, comparing the number of questions included in each of the questionnaires, we will notice that the numbers have decreased for most of the SAQs. This is explained by consolidation of multiple questions under the same requirement, and not by an actual decrease in the number of requirements. In most cases, the number of tests or verifications that will have to be performed to validate compliance have increased.

In addition to the changes in applicable requirements for SAQs, a new possible response, “In Place with Remediation,” has been introduced. This response should be selected if a control failed during initial testing and was successfully remediated and confirmed to be in place during revalidation. For all controls for which this response has been selected, the new Appendix C must be completed with explanation of the original control failure, evidence of successful remediation and what has been implemented to prevent this control from failing in the future.

According to the PCI SSC’s announced transition timeline from PCI DSS 3.2.1 to 4.0, PCI DSS 3.2.1 will be retired on March 31, 2024, at which point PCI DSS compliance must be validated using PCI DSS 4.0 only. However, new requirements introduced in the new standard must be implemented by March 31, 2025, with the exception of a few requirements that are not part of any of the new SAQs. Until that date, the new requirements are considered best practices. It is important to recognize that requirements that are not new in PCI DSS 4.0 – yet have been newly introduced into some of the SAQs – do not get the benefit of an additional transition year and will have to be implemented by March 31, 2024, when PCI DSS 4.0 becomes the only active version of the standard.

Below is the summary of changes for each respective SAQ.

SAQ A

SAQ A is used by entities with cardholder data environments outsourced to PCI DSS-validated service providers and payment collection forms for online transactions originating from a validated service provider. This SAQ had multiple new requirements introduced.

E-commerce sites qualify for SAQ A by performing redirection to a payment page hosted by a PCI DSS-validated service provider or by invoking an iFrame from a validated service provider. These sites will need to have controls implemented to detect unauthorized modification to the HTTP headers and the contents of payment pages as received by the consumer browser. Additionally, the sites will need to maintain an inventory of scripts loaded and executed in payment pages and implement controls to confirm that scripts are authorized and ensure their integrity.

It is especially important to note that SAQ A 4.0 calls for external vulnerability scans to be performed by an Approved Scanning Vendor (ASV) targeting the web servers redirecting customers to a hosted payment page or invoking an iFrame. Finally, the new SAQ A has several additional policy-related requirements, and several requirements associated with password settings.

SAQ A-EP

SAQ A-EP is used when websites utilize JavaScript or Direct Post to direct payment transactions to a validated service provider or payment processor. This SAQ includes the highest number of new PCI DSS 4.0 requirements. Among the applicable requirements now are:

  • Updated requirements associated with antimalware and phishing protection
  • A new requirement mandating a web application firewall
  • Requirements around the security of payment pages
  • New requirements around management of user, system and application accounts
  • Enhanced requirements for multifactor authentication
  • Requirement for the use of an automated audit log review solution
  • Requirement for awareness training for phishing and social engineering and documented acknowledgment by all personnel of their security responsibilities
  • Requirement for risk analysis to determine frequency of requirements to be performed periodically
  • Updated requirements associated with account and password settings

Among the requirements not new to this version of PCI DSS but new to this SAQ are:

  • A requirement for external vulnerability scans to be performed by an ASV
  • A requirement to have designated personnel available on a 24/7 basis for incident response

SAQ B and SAQ B-IP

SAQ B and SAQ B-IP are used by merchants utilizing dial-up or IP-based payment terminals. These SAQs have only a few changes introduced, and all of them are requirements for additional policies. Among them is one requirement that is not completely new. While the requirement for information security responsibilities to be assigned to all personnel was included in PCI DSS 3.2.1, the new testing procedure calls for documented evidence of acknowledgment of security responsibilities by all personnel. While the frequency of the acknowledgment is not specified, the interpretation is that it be annual.

SAQ P2PE

SAQ P2PE is used by merchants who have implemented a P2PE-validated solution for accepting card-present transactions. SAQ P2PE is mostly unchanged. A new requirement for the data retention policy to apply to sensitive authentication data (SAD) stored preauthorization has been added, as well as a requirement for documented evidence of acknowledgment of security responsibilities by all personnel, as described above for SAQ B and B-IP.

SAQ C

SAQ C is used by merchants that process cardholder data via a payment system connected to the internet and that do not store cardholder data on any computer system. This is another SAQ that saw a significant number of changes, second only to SAQ A-EP. The new PCI DSS 4.0 requirements in this SAQ include:

  • Updated requirements associated with antimalware and phishing protection
  • New requirements around management of user, system and application accounts
  • Enhanced requirements for multifactor authentication
  • Requirement for use of an automated audit log review solution
  • Requirement for awareness training for phishing and social engineering and documented acknowledgment by all personnel of their security responsibilities

SAQ C saw the highest number of requirements present in the prior version of the PCI DSS standard introduced into this SAQ. Among these are:

  • Some of the policy-related requirements
  • Requirements associated with secure development processes and change control
  • Requirements for controls around user account management processes and authentication protection
  • Requirements for protection of audit logs
  • Time-synchronization controls
  • Requirement to have designated personnel available 24/7 for incident response

SAQ C-VT

SAQ C-VT is used by merchants who process cardholder data using only isolated virtual payment terminals on a personal computer connected to the internet. This SAQ did not undergo a lot of revisions. Among the added requirements are those associated with:

  • Phishing and social engineering protection
  • Antimalware scanning
  • Requirement for proper management of user accounts
  • Updated password-length requirement
  • A few additional requirements for policies and procedures

It is important to note that segmentation penetration testing will not be required to validate PCI DSS compliance under SAQ C-VT 4.0.

SAQ D for Merchants and Service Providers

SAQ D includes all PCI DSS requirements and is used by organizations that do not qualify for any other version of the SAQ. Since SAQ D represents a full version of PCI DSS, please refer to the summary of changes in the standard for the complete list of the new and updated requirement that will need to be validated under PCI DSS 4.0. It is important to note the SAQ D for service providers is now the only SAQ that requires brief narrative responses for each requirement in addition to checking the box for the appropriate response.

Planning for Transition

Now that the new versions of the SAQs have been released, merchants need to analyze the impact of the new standard and changes to the SAQs on their PCI DSS compliance program and efforts. If gaps against the new standard are identified or additional requirements not previously evaluated will apply, it will be important to take an opportunity to reexamine the scope of the cardholder data environment and consider further possible scope reduction. Additionally, plans for implementation of the new requirements now applicable to the cardholder data environment should be developed to ensure compliance can be validated against the new standard when PCI DSS 3.2.1 is retired.

For organizations eligible to validate PCI DSS compliance via self-assessment, it also will be important for personnel responsible for PCI DSS compliance validation to start familiarizing themselves with the new standard and the required testing procedures and start collaborating with internal stakeholders not only on implementing the new required controls but also on ensuring that these controls generate adequate evidence of execution and are auditable.

For a more detailed review of the new requirements, download the pdf.

Download

How Protiviti Can Help

Protiviti has been involved with PCI since inception of the Data Security Standard in 2002, before the PCI Security Standards Council was formed. As one of the largest and most experienced QSA firms, we have completed numerous PCI compliance assessments for clients ranging from upper midsized organizations to Fortune 500 companies across many industries.
Protiviti is a PCI SSC-approved global provider for the following programs:

  • Qualified Security Assessors (QSA)
  • Payment Application QSAs (PA-QSA)
  • Qualified PIN Assessor (QPA)

Our global PCI Planning, Readiness and Compliance professionals will work with your organization to conduct a PCI 4.0 compliance gap assessment to understand what requirements are not currently in place and require remediation. We can then advise you on the most effective and efficient methods for achieving compliance, whether it involves implementing a new solution, changing or outsourcing a process, implementing compensating controls, or planning for a Customized Approach to some of the requirements.

We can also provide:

  • Annual on-site audits
  • Quarterly vulnerability scans
  • Annual penetration testing
  • Program governance & technical remediation
  • Visa PIN Security reviews

Leadership

Chip is a Managing Director in Protiviti’s Technology Consulting practice focusing on Data Security & Privacy. He presently leads Protiviti’s Data Security practice and focuses on Payment Card Industry and Healthcare Information Security as well as supporting ...
Loading...