The PCI Security Standards Council (SSC) published PCI DSS v4.0 on the 31st March 2022. The combined efforts by the SSC, payments brands, participating agents, and QSA the community have yielded a significant overhaul that promises to provide a framework for securing payment card information in the future.
There has since been a lot of activity surrounding the release, which gives rise to a problem. With such an overhaul, people are suffering from information overload and are unable to find a starting point for their organisations. Nettitude will break down what the changes mean and what a merchant or service provider needs to migrate, starting with a series of blogs discussing changes to self-assessment questionnaires allowing you to quickly start forming your plan to move to PCI DSS v4.0.
Updates to SAQs in PCI DSS v 4.0
Self-Assessment Questionnaires (SAQs) define criteria that might allow merchants to reduce the complexity of their compliance requirements. With a more significant number of merchants taking advantage of these SAQs, combined with channel-level reporting of compliance, merchants must review and understand the updates made to the SAQs in PCI DSS version 4.0.
This first blog in the series identifies eight changes applicable to all SAQs. These are:
1. The front covers
It is now more important than ever to ensure that qualifying criteria for an SAQ are re-checked and the use of SAQs is confirmed with the acquiring institute.
For quite some time, the SSC has always included a 'functional summary' of the SAQs on the front cover; examples are:
"Card-not-present Merchants, All Cardholder Data Functions Fully Outsourced" and
"Merchants with Payment Application Systems Connected to the Internet – No Electronic Cardholder Data Storage".
These have all been removed by the SSC in v4.0 SAQs. Whilst there is not any material change to the target environments of the SAQs, there can sometimes be nuances and compliance program influence over when an SAQ is used, which may not match the original functional summary. So, now is an opportune time to go back and check that you are compliant with the qualifying criteria for your chosen SAQ.
2. Qualifying criteria
The SSC has made a minor change, but it is worth pointing out as it identifies a subtle change introduced across PCI DSS v.4.0. In many cases, an implicit statement has been changed to be explicit.
Within qualifying criteria, this is most obviously seen through the change from 'company' to 'merchant' throughout the bullet points, along with statements of non-applicability being made more prominent and closer to the beginning.
All SAQs now confirm that "This SAQ is not applicable to service providers".
This has always been the case with the single exception of SAQ D-SP, but the statement will remove any ambiguity that some felt was present and wrongly used. This is the SSC clearly indicating: service providers cannot use any SAQ other than SAQ D-SP.
There have been other wording changes within the bullet points that improve clarity to its audience, and each of those will be reviewed for each SAQ as the blog series is published.
3. The definition of Account Data
It is not unusual for some merchants to only read the parts of the PCI DSS they need to do something about, which can mean they only sometimes read the information from within the SAQ itself. This oversight can mean that some people do not always know the difference between account data, cardholder data, and sensitive authentication data.
This is a crucial piece of knowledge because it determines whether the PCI DSS is even applicable, so it is now included within every SAQ.
4. The Responses
The updated SAQs increase the response options for each requirement from 4 to 5, along with some minor wording changes.
The response options have been updated to match those a QSA selects when completing a level 1 assessment using a Report on Compliance (ROC) template. The upshot of this is that for SAQs, the fifth option of "Not Tested" may only be selected when using SAQ D or SAQ D-SP and is not available for any of the reduced SAQs.
You may notice a new response introduced with PCI DSS v.4.0 called 'In Place with Remediation'. This response accounts for circumstances when the assessment found something was not quite right but was fixed during the assessment period.
It is important to use this option when appropriate; we are not perfect, systems are not perfect, and things can be overlooked. Showing this to your acquiring institute allows them to support you better and ensure that you report your compliance accurately to reflect your operations fully.
5. Section 1, Part 2 - Executive Summary
The SSC has harmonised the executive summary information across all documents to provide richer detail to the acquiring institutions and for consistency. They also help you identify where you may need to work more closely with a third-party service provider as you did not realise, they impact your compliance efforts. A new table has been introduced in the form of Part 2g - Summary of Assessment, which again is a harmonising effort with a report on compliance to show at a glance which overall requirements comply and those that may need further actions to be taken.
6. Future Dated Requirements
PCI DSS v4.0 has introduced several new requirements, some applicable from day one and some that are good practice until 31st March 2025, when they become mandatory.
Any requirements which are in the future must not be forgotten about until March 2025 because you run the risk of non-compliance or In-Place with Remediation. This grace period is a good opportunity to mature your compliance programs and security measures in a controlled manner between now and 2025. A complete list of future dated requirements can be found in the Summary of Changes between v3.2.1 and v.4.0, available on the PCI SSC website.
7. Applicability Notes
These notes are new to the standard and provide further information into either the intention of a particular requirement or clarification of its purpose.
8. SAQ Completion Guidance
The SSC has included more guidance in the PCI DSS v4.0 SAQs to support the merchant community. These are in addition to applicability notes because there is a slight difference in the purpose of the information:
You will not find them for every requirement as the primary requirements description may not need it, but for some of the more technical or often misinterpreted requirements, their inclusion is helpful in determining the applicability of a given requirement, so these will be very welcomed.
The PCI SSC has developed each SAQ to help merchants operating particular payment channels reduce their compliance burden. Organisations must understand which SAQs they can use and check they meet the qualifying criteria.
There are changes throughout all the commonly used SAQs, as a series, we will be releasing one blog per SAQ type that focuses specifically on those changes to help you to begin planning for a successful SAQ migration to PCI DSS v4.0.