Highlights of PCI DSS v4.0

Earlier this year, version 4.0 of the PCI DSS (Payment Card Industry Data Security Standard) was introduced, bringing with it several new requirements that are designed to make compliance more flexible yet resilient.

Chief among the changes is the introduction of the “customized approach” to compliance. Previous versions of the Standard were highly prescriptive, with little leeway on how organizations should proceed, but that is no longer the case.

Organizations are now permitted to substitute any defined requirement with one of its own controls, provided it meets the relevant objective.

For every customized approach that an organization adopts, it must:

  • Define the control
  • Explain how it operates and is maintained and
  • Describe how it meets the objective of the original PCI DSS requirement.

Organizations must also describe how it has tested that the control meets the objective and the results of the testing. The organisation must also complete a risk assessment for every requirement treated this way.

Fortunately, organizations have plenty of time to prepare. The current version of PCI DSS (3.2.1) remains valid until March 2024, enabling covered entities to transition over to the new requirements.

What else has changed?

Another significant change in PCI DSS v4.0 is the way compliance is assessed. Under the new rules, a QSA (Qualified Security Assessor) will review the information related to the customized approach and design their own test procedure for the requirement.

There is clearly potential for a lot of work and this could lead to contention between the assessed entity and the QSA as to whether controls implemented do meet the PCI DSS objectives.

Meanwhile, another change concerns the PCI DSS’s scoping requirements. It has always been the assessed entity’s responsibility to define and document the scope of the CDE (cardholder data environment) and the QSA’s responsibility to validate this.

However, this requirement was tucked away in the narrative section at the beginning of the PCI DSS, and in practice, many organizations relied on their QSA to both define and validate the scope when conducting the assessment.

This is no longer possible. It’s now a specific requirement (12.5.2) that the entity defines and documents the scope of the CDE, including identifying data flows and any segmentation controls.

This process must be performed annually and after any significant change to the environment. In future, the first question a QSA asks will likely be “Have you defined and documented the scope of your CDE?”

PCI DSS v4.0 also introduces changes to the risk assessment process. Covered entities are no longer required to conduct an organisation-wide risk assessment, but there are several new rules related to targeted assessments.

These include risk assessments in relation to any vulnerability identified and to determine how often the organisation conducts:

  • Assessments of components not at risk of malware;
  • Malware scans
  • POI device inspections;
  • Log reviews for ‘other’ system components
  • Incident response training; and
  • Mandatory changes of passwords used for application and system access accounts.

These changes have been widely welcomed, because it is unlikely that an organization’s overall risk assessment process would pick up matters at this level of granularity.

Other changes to the PCI DSS reflect more up-to-date information processing environments. For example, v4.0 recognises that network controls, especially in Cloud environments, do not always use firewalls and routers.

Likewise, the new rules further emphasise the importance of strong passwords, mandating that employees’ login credentials be at least 12 characters (or 8 if the organization’s systems do not permit such long passwords).

PCI DSS v4.0 also gives organisations the option to determine access to resources automatically by dynamically analysing the security posture of accounts, rather than changing passwords every 90 days.

New requirements

As well as amending existing requirements, PCI DSS v4.0 introduces several new rules. These include the mandatory use of:

  • Automated mechanisms to protect against phishing;
  • Web application firewalls; and
  • Automated mechanisms to conduct log reviews.

There are also additional requirements related specifically to application- and system-level accounts.

Finally, there are numerous changes to the wording and numbering of requirements even where the actual requirements have remained largely as they were in v3.2.1.

Where organizations have prepared policies and procedures that cross-reference specific requirements, this alone will require an extensive review and update of such policies and procedures.

You shouldn’t overlook the time it will take to implement these new requirements and to update your documentation. A two-year lead time may seem like a lot, but it’s wise to begin early to scope out the extent and impact of the changes.

For those looking to get started, IT Governance USA’s PCI DSS Gap Analysis is the ideal tool.

One of our expert PCI consultants will review your in-scope systems and networks, providing you with a detailed report about the areas that need attention.

You’ll also receive a plan to bridge the gap between your current security posture and full compliance with the PCI DSS, demonstrating the necessary corrective actions and enabling you to reduce the risk of a data breach.

One Response

  1. Charles Denyer November 17, 2014