PCI DSS v4.0 ROC Changes – Coming Now to an Organization Near You!

The Payment Card Industry Data Security Standard (PCI DSS) version 4.0 is here! It has been released, the documents are available publicly for anyone who would like to read them, and forms for both the 900-pound level 1 Report on Compliance (ROC) and the Self-Assessment Questionnaires (SAQ) are ready for use today! However, there is a LOT to unpack here. Today we will talk about some of the biggest changes regarding the ROC. My next blog will do the same thing for the SAQs. Much of what is below applies to PCI as a whole and can be applied across the board.

Qualified Security Assessors (QSAs, of which Compass IT Compliance has several) are the assessors that perform the ROC engagements and sign off on the Attestations of Compliance (AOC, my apologies for all the acronyms) for merchants and service providers that show they are PCI compliant. Recently, the PCI council put out PCI DSS v4.0 gap training that must be taken by all QSAs before they can assess to the PCI DSS v4.0 standard. Compass IT Compliance staff have gone through the training, and here are some of the general takeaways:

Timelines – PCI DSS v4.0 is live now. If a QSA has completed the training (and passed the training exam) they can assess to this standard. However, the older version of PCI DSS, 3.2.1, is still active as well, and will not be sunset until the first quarter of 2024. At that point, merchants and services providers MUST use the new 4.0 template. My own thoughts are that if you have an assessment coming up through the end of the year, you will probably be using 3.2.1 and then you will start to see the 4.0 assessments in 2023. However, you have the option to use 3.2.1 for another 20 months or so. All new items in the 4.0 standards must be in place by first quarter of 2025. Which brings us to…

Requirements – PCI DSS v4.0 has 63 new requirements! Of those, 13 apply immediately once you decide to use the 4.0 templates to perform the assessments. The other 51 are “future dated” requirements that will become mandatory on March 31st, 2025. PCI has used this method in the past, realizing that organizations will need time to understand and implement new requirements. Until the 2025 mandatory date, these can be considered “best practices”. However, the takeaway from here is that if you have a ROC in place now, there are going to be many additional requirements, and NOW is the time to start looking at them. PCI provides a document to break them all out so they can be reviewed independently, and Compass IT Compliance will be performing some gap reviews of the new requirements to see what organizations will need to concentrate on.

Risk Assessments – There are multiple new and existing controls that require an organization perform a risk assessment in order to meet compliance with the control. The old language said they needed to be carried out “periodically” without designating a specific time frame. This meant that many companies decided that once or twice a year would suffice. In 4.0, any control that requires periodic assessments to be in place must have a risk assessment to determine what that time period will be. The actual language reads, “where the standard does not define a minimum frequency for recurring activities but instead allows for the requirement to be met “periodically,” the entity is expected to define the frequency as appropriate for its business. The frequency defined by the entity must be supported by the entity’s security policy and the risk analysis conducted according to PCI DSS Requirement 12.3.1.”

12.3.1 is one of the new controls. It states that for these items there needs to be, “targeted risk analysis that is documented and includes:

• Identification of the assets being protected.
• Identification of the threat(s) that the requirement is protecting against.
• Identification of factors that contribute to the likelihood and/or impact of a threat being realized.
• Resulting analysis that determines, and includes justification for, how frequently the requirement must be performed to minimize the likelihood of the threat being realized.
• Review of each targeted risk analysis at least once every 12 months to determine whether the results are still valid or if an updated risk analysis is needed.
• Performance of updated risk analyses when needed, as determined by the annual review.”

In other words, if you were not doing risk analysis on your controls before, you have some work ahead of you!

Partial ROCs and “In Place with Remediation” – These are good changes to the structure of the framework, and hopefully will keep the wheels moving on assessments. The first item allows for a ROC to be completed without testing every control and mark it as such. The goal here seems to be to get more MSPs and service providers who may support infrastructure or operations in some way but only have limited involvement in the cardholder data environment to be able to attest to only those controls that are under their control. For example, a data center that has no POS devices would be able to mark much of requirement 9 as “Not Tested” and still have a valid ROC. The key here is careful scoping in advance to ensure that all applicable controls (especially if required by a customer) are included in the scope.

The other item allows for an organization to have a control that might have been an issue when beginning an assessment, however they corrected it during the assessment period. This control could then be marked, “In place with Remediation”. In theory, this can expedite the assessment process but it also will show transparency on the Attestation of Compliance. It would be similar to a SOC 2 Type 2 report where testing showed an issue, but management corrected it and detailed the correction prior to the report issue. It is something you do not want to see on an annual basis.

Vulnerability Scanning – Finally (for this blog post), I wanted to briefly touch on vulnerability scans. Although a future dated requirement, internal scans in PCI 4.0 are required to be authenticated scans. For those people not aware, most vulnerability scanners by default scan a system without having user or admin access to that system. Because of this, some potential and confirmed vulnerabilities might not be able to be detected. An authenticated scan requires that the scanner uses access credentials to log into the system first and scan behind the curtain. You will get more information, but more false positives as well, and depending on the device it can be tricky to get it to work effectively. For endpoints, if your scanner has an agent installed on the machine, that should suffice. Sadly, network equipment does not have this ability currently. In any event, the takeaway here is that it may be time to review your scan setups and start testing to ensure that your organization can adhere to this requirement.

We have only scratched the surface here today. We will put out another blog soon on the SAQs, and then we will tackle the new requirement a few sections at a time. As always, feel free to reach out to us with any questions you might have regarding PCI DSS v4.0 compliance!