Preparing For a PCI DSS v4.0 Assessment

Gathering Evidence for Your Report on Compliance (RoC)

Before diving into a PCI DSS v4.0 RoC assessment, it’s worth noting and remembering that the types and amount of evidence that will be gathered by a qualified security assessor (QSA) haven’t actually changed and the assessor will still want to see the same types of evidence as before.  So, whatever planning and preparation for evidence collection you would have carried out under v3, will still be valid and relevant.  What has changed, however, is the way in which the assessor must now document the evidence within the report.  As such, the assessor’s approach to the evidence gathering processes will most likely change.  With that in mind, here’s a quick recap of the types of evidence that are needed for a RoC.

Documentation - This generally takes the form of policies, procedures, processes, configuration standards and any other company documents that support the compliance management process and status of your organisation.  The assessor will use these to evidence that your organisational processes meet the various requirements, as well as using them as a starting point for the other evidence types.

Observations - This is where the assessor will need to observe a particular process or configuration in action to determine whether the above-mentioned documentation is both accurate and is being used by your organisation.  It also allows the assessor to ensure that your processes are suitable for meeting particular requirements.

Interviews - Interviews are included to enable the assessor to determine if your responsible people are aware of all their responsibilities within the policies and procedures, as well as to determine if employees are knowledgeable in their areas of responsibility.  The topics of these interviews will usually cover the above documented and observed processes and procedures, thereby allowing the assessor to verify their observations.

Samples - This type of evidence covers a sample of outputs from any processes that generate records.  Examples of such outputs include change control records, vulnerability scans, training records, and any other period processes.  These sample sets are then used to verify that your processes and procedures are actually performing the desired function.

Whilst some requirements may only need one of the above types of evidence, the vast majority of them require several different types to allow the assessor to be confident that your organisation has met the requirement, and this hasn’t changed in v4.0.  As previously stated, what has changed with the latest version of the Standard is the way evidence is documented within the report.

Documentation still needs to be listed in the table

Documentation evidence is unchanged in that the assessor is required to enter each document as a line item in a table and provide a brief description of each, then when a requirement needs a document as evidence, this table is simply referenced.  This allows the assessor to conduct document reviews off-site in contiguous sessions, thus simplifying the evidence collection.  This process should be very familiar to anyone who has undertaken a RoC before, as it’s the current standard way of collecting and using this evidence.

Changes in ways evidence is collected

For all other types of evidence, however, things have changed.  With v3 RoCs, for each requirement the assessor would have to describe how each type of evidence shows that the requirement was met by your organisation, e.g., ‘Describe how the administrator logon to each system verified that a strong encryption method is invoked’ or ‘For the interview, summarise the relevant details discussed to verify that they have knowledge of common security parameter settings’.

This meant that the typical assessment process was to step through each requirement and talk to the relevant people and observe the relevant processes, whilst documenting the evidence as things progressed.  In practice, this often resulted in multiple sessions having to be scheduled with the same people/teams each time evidence was required to verify the next set of requirements.  In some cases, this could lead people to think that they have given all the evidence only to be called back at a later stage to cover off further requirements.

It could also lead to some evidence being missed as it wasn’t covered by any of the interview sessions.  This omission would then get picked up later by the assessor during the review process which identifies they need some extra evidence and another session would need to be arranged.  The need for an extra session has become a little more commonplace with the trend to more remote assessments following the COVID lockdowns.

Requirement for all evidence to be reported in the same way

For v4.0, all evidence is now to be reported in the same way as documentation was in v3 RoCs.  As such, each observed process needs to be entered as a line item, then described and given a reference number that can then be used for any requirement that needs that process.  Each individual’s interview needs to have all topics summarised in the table and then referenced when needed.  Each type of device in scope also needs to be entered into a table, along with details and quantities.  Furthermore, a list of samples with each specific item chosen also needs to be created.

In practice, what this means is that if all the requirements are known that each individual will be providing evidence against, then observations, interviews, and samples can all be collected in one session and documented simultaneously by the assessor.  This can then simply be referenced for each requirement as needed.

Greater time efficiency but greater planning and preparation required

The end result should be greater time efficiency compared with the previous method of documentation.  However, it needs significantly more planning and preparation to pull off.  Effectively, it requires you to sift through the Standard and determine which requirements each given person would be providing evidence for and then ensuring that enough time was allocated to their session to fully address all requirements.  This leaves the assessor just needing to summarise the evidence provided in each session and subsequently working through the various requirements, inputting the references with each one to support their conclusions as to your organisation’s compliance status.

As for sampling system components and their configurations, planning again is of paramount importance.  You are advised to work with your QSA to select the appropriate sample sets for each requirement in advance of each session.  In this way, your people can be prepared to access each component and show what is needed to cover any requirements that are relevant to that device.

It is also worth noting that the first year you transition from a v3 to a V4 assessment, you will probably need to allocate a significant amount of time for you and your assessor to discuss the new assessment requirements, in order to facilitate the new style of evidence gathering and extra planning required.  However, URM’s initial experiences point to the fact that the assessment should end up being much more time and resource efficient, providing you have done all the necessary planning and preparation.

The Updated SAQs

For those of you who are able to self-assess to the PCI DSS, you’ll be very familiar with the self-assessment questionnaires (SAQs).  If you’re not, then essentially they are tools provided by the Payment Card Industry Security Standards Council (PCI SSC) to help you work out which requirements are not applicable to your payment environment, based on the methods you employ to accept and process card payments.

No changes to eligibility criteria

However, it is worth taking time to examine what has and has not changed with the v4.0 SAQs. The first thing to note is that each of the 9 different SAQs include eligibility requirements that are used to determine if that particular SAQ is suitable for your organisation’s processing of card payments, and none of these have changed with v4.0.  This means that whichever SAQ(s) you were using with v3.0,  will be the same for the new Standard,  as long as your PCI DSS environment hasn’t changed.

Many additions and deletions

Where there has been considerable change is in the requirements which make up each SAQ.  All of the SAQs have had some brand new v4.0 requirements added, as well as some of the existing v3 requirements removed to better fit the different payment channels that each SAQ applies to. As such, you will need to review the new version carefully to ensure you are aware and familiar with what extra requirements have been added… and those that have been removed

The following table presents a general overview of how many requirements have been added to each SAQ.  We say ‘general overview’ as it is open to interpretation how you define and count a requirement, and numbers may vary slightly  depending on your interpretation.  However, the table provides an indication of the scale of the changes and the amount of work that is needed to complete each SAQ.

‍
¹The two SAQ D variants (for merchants and service providers) have been left off as they simply include all the requirements being the default SAQ if none of the others fit your organisation’s setup.

‍

As you can observe, SAQ A-EP and C, in particular, have both undergone some significant revamping and so if you are using either of those SAQs, you will want to spend some time looking at the fine detail to make sure you do not miss anything.

Most significant changes relate to SAQ A

Having said that, the SAQ which has probably undergone the greatest change is actually  SAQ A, as this has had the largest number of added requirements when calculated as a percentage of the original number.  It is also important to remember that SAQ A is the most common type of questionnaire and is the one most merchants strive towards as it was always regarded as being the simplest.  The most significant changes to SAQ A are the addition of two new technical requirements for payment pages, namely 6.4.3 – The authorisation of payment page scripts and 11.6.1 – Change detection on payment page headers.  URM has another blog that covers these challenging requirements in more detail, but they do represent a significant change for SAQ A due to their very technical nature.

Another significant change worth noting is that a caveat has been added to both SAQ A and A-EP: “For the purposes of this SAQ, PCI DSS requirements that refer to the "cardholder data environment" are applicable to the merchant website(s). This is because the merchant directly impacts how account data is transmitted, even though the website itself does not receive account data.”  This caveat has been added because some of the requirements refer to a cardholder data environment (CDE), but any payment method that is eligible for these SAQs shouldn’t have any cardholder data present in the environment and so technically wouldn’t have a CDE.

More information needed in scoping sections of SAQ D

Finally, with SAQ D for service providers, there has been a massive expansion to the amount of detail required in the scoping sections.  This change simply reflects the greater diversity in the types of services being provided over recent decades and the difficultly in identifying exactly what is, and is not, in scope for any given service provider.

Overall, whilst there have been significant changes to SAQs, the scale is not considered unusual for a major revision and much of the development has been led by feedback directly from the industry and exists for the good of the industry.

Further Information on Key Changes to PCI DSS v4.0

On 7 April 2022, URM held a webinar that outlined some of the key changes within v4 of the Standard and the implications of those changes.  If you would like to access a recording of this webinar, please complete the form below and we will email you a link at the earliest opportunity, i.e., during normal office hours – Monday to Friday, 9 to 5:30.

‍