Our December blog post on PCI DSS v4.0: Targeted Risk Analysis

The year is drawing to a close — and so is PCI DSS v3.2.1.

The PCI Security Standards Council (PCI SSC) has just published new documents on the new concept of “Targeted Risk Analysis” — so let’s take this as an opportunity to take a closer look at the topic.

Targeted Risk Analysis – what is it?

PCI DSS v4.0 aims to enable more flexibility. One of the tools for this is the so-called “Targeted Risk Analysis”.

Targeted risk analyses differ from the company-wide risk analyses that were required in PCI DSS v3.2.1. They look at the specific risks for a very specific use case.

In PCI DSS v4.0, targeted risk analyses appear in two places:

Some requirements of the standard call for targeted risk analyses to determine how often a certain regular control should be carried out.
In addition, the targeted risk analysis is part of the so-called “customized approach”, which allows you to implement a requirement in your own way, deviating from the literal implementation.

We will focus on the first case here, as we will dedicate a separate blog entry to the customized approach in February.

Where is it required?

A targeted risk analysis is required for the following PCI DSS requirements:

5.2.3.1: If an organization has evaluated that system components are not commonly affected by malware and therefore do not require an anti-malware solution, then it must be checked at regular intervals to ensure that this is still the case. The frequency of these checks must be determined in a targeted risk analysis.
5.3.2.1: If regular malware scans are used, their frequency must be determined in a targeted risk analysis.
7.2.5.1: Often there are not only user accounts that are used by people, but also technical user accounts that are used by systems or applications. Their access rights must be checked regularly. The frequency of these checks must be determined in a targeted risk analysis.
8.6.3: Passwords for the aforementioned technical user accounts must be protected. The frequency of password changes and password complexity must be determined in a targeted risk analysis.
10.5.1.2.1: Payment devices (payment terminals) at the point of interaction must be inspected regularly to detect tampering or substitution. The frequency and type of inspections must be determined in a targeted risk analysis.
11.4.2.1: Security-critical logs (security events and logs from systems that come into contact with account data, have security functionality or are otherwise critical) must be reviewed at least daily in order to detect conspicuous activities promptly. The frequency of the review for all other logs must be determined in a specific risk analysis.
11.3.1.1: If high-risk or critical vulnerabilities are discovered during internal vulnerability scans, they must be remedied. For lower-rated vulnerabilities, a targeted risk analysis must determine how these are to be addressed.
11.6.1: E‑commerce payment pages must be regularly checked with a mechanism for detecting changes and tampering. This mechanism must be applied at least every seven days – otherwise a lower frequency must be justified with a targeted risk analysis.
12.10.4.1: The staff responsible for responding to security incidents must be trained in this. The frequency of this training must be determined in a targeted risk analysis.

How to perform the targeted risk analysis

How the targeted risk analysis should be carried out is defined in requirement 12.3.1 of PCI DSS v4.0. This stipulates that the analysis must first identify at least the following points:

The assets to be protected. Of course, those always comprise the account data itself, but other assets such as systems or passwords can also be relevant.
The threats against which the corresponding PCI DSS requirement is intended to protect.
To determine the corresponding threats, it is helpful to consult the “Customized Approach Objective” of the corresponding or higher-level PCI DSS requirement, as this objective often already specifies the threats against which the requirement is intended to protect.
Factors that contribute to the probability of occurrence and/or the impact of the realization of the aforementioned threats.

Let’s get specific and take requirement 9.5.1.2.1 as an example.

Here, both the account data and the payment devices are assets to be protected.

The “Customized Approach Objective” of the overarching requirement 9.5.1.2 is that the tampering of devices, unauthorized substitution of devices, or the attachment of skimming devices cannot be carried out without timely detection.

Typical threat scenarios would therefore be, for example

Attackers install skimming devices that read data input.
Attackers pretend to be service technicians or employees of the device provider and replace the payment device with a manipulated payment device, which then reads account data and forwards it to the attackers.
Attackers steal a payment device on which data could be temporarily stored in the case of offline transactions.
Attackers manipulate the payment device in such a way that its security functionality is weakened (e.g. encryption switched off).

Factors that can have an impact on the realization of these threats are, for example:

How easily accessible is the payment device to customers and third parties? Is it securely attached?
Is the payment device permanently attended / under supervision?
How well qualified and trained is the staff on site?
Are the payment device and the data in it protected against tampering, and is this proven by PCI PTS validation of the device and/or PCI P2PE validation of the entire solution?
How heavily frequented is the payment terminal? (This can have an influence on whether it is a particularly worthwhile target for the attacker.)
Has the device provider provided recommendations in their documentation on how frequently the devices should be checked?

The factors then result in the analysis that determines how often an activity must be carried out in order to minimize the probability of the threats occurring.

Factors and results of the targeted risk analysis must be documented.

At least every 12 months, each targeted risk analysis must be reviewed to check whether it is still applicable. If there have been changes in the factors or in their evaluation, the risk analysis must be updated accordingly.

Assistance

As with every PCI DSS v4.0 requirement, the first thing worth looking at is the “Guidance” column to the right of the requirement in the standard itself.

In addition, the PCI SSC published three supporting documents on 28 November 2023:

Information Supplement PCI DSS v4.x: Targeted Risk Analysis Guidance,
PCI DSS v4.x Sample Template: Targeted Risk Analysis for Activity, and
PCI DSS v4.x Sample Templates to Support Customized Approach (in which, as mentioned above, targeted risk analyses are also required).

And as always, you are welcome to ask SRC’s PCI DSS experts for support.

Outlook

This is the last post on PCI DSS v4.0 for this year. We will continue our monthly blog series next year — you can look forward to the following topics then

January: Changes in e‑commerce: What’s changing in Self-Assessment Questionnaire A?
February: Customized Approach
March: Changes in e‑commerce: Integrity protection of payment pages

Happy New Year, and take care!

Our November blog post on PCI DSS v4.0: Roles and Responsibilities

New sub-requirement for all requirements

In PCI DSS version 4.0, a new sub-requirement has been incorporated into Requirements 1 through 11, emphasising the necessity to document, assign, and ensure understanding of roles and responsibilities in executing the respective Requirement x (as stated in sub-requirement x.1.2).

This amendment raises questions for many organisations. They wonder how this assignment of roles and responsibilities should take shape. Should a new document be generated? And should it apply universally throughout the entire company or solely to specialized teams?

PCI DSS deliberately leaves the form of the documentation open. The intention of the sub-requirement is that personnel should be aware of their responsibilities so that activities are carried out reliably.

Almost every PCI DSS assessor has encountered vulnerability scans not being carried out on time every quarter because it was simply overlooked — this is where clearly assigned responsibility for maintaining the quarterly rhythm helps.
Almost every PCI DSS assessor has encountered cash desk personnel who were not aware that they had to check payment terminals on suspicion of tampering or replacement. This responsibility should also be clearly stated — as well as that of the role that trains cash desk personnel to do this.

So what can the assignment of responsibilities look like in practice?

Utilising existing documentation

Many companies already include roles and responsibilities within their existing policies and procedures.

For instance, your software development guidelines may already specify who develops the code, who conducts code reviews, who performs tests, and who grants approval for rollout at different stages of the process. It’s crucial that this role allocation is transparent to all participants during interviews.

However, if such documentation is currently absent, it should be developed. The choice of whether to integrate this assignment into existing documents or to create a new document is inconsequential.

Form of Documentation

The format for documenting roles and responsibilities is flexible. While a RACI matrix or its variations are suitable, other methods such as tables, lists, or narrative texts can also serve this purpose effectively.

For sizable teams with similar tasks, a role description like “the staff is responsible for carrying out activity X, while the team leader is accountable for training staff during onboarding, task transitions, and yearly intervals, as well as for results approval” is often sufficient. In the case of diverse tasks within mixed teams, responsibilities may need to be outlined for individual team members.

Connecting to Practical Implementation

Avoid adhering too closely to the detailed requirements of the PCI DSS. Instead, translate how you implement security-related procedures in your specific operational business. Often, multiple roles are involved in executing a requirement: one role may define and document the rules, another role ensures compliance during operational tasks, and yet another role performs a review and/or gives approval for what has been implemented. When you describe the steps of your implementation process, it becomes easier to identify who is responsible for each activity.

Acceptance of Responsibility

The assignment should, of course, not only be documented, but also known to the individuals concerned. Accordingly, a new or adapted document should be presented to the personnel that is involved.

Do employees have to sign that they are aware of their responsibility? A different requirement, 12.1.3, actually requires a written acknowledgement of general information security responsibilities. The documented acknowledgement of the specific responsibilities of the respective role is not mandatorily required in requirement x.1.2, though. You can of course combine these two points if you wish, by having not only generic but also role-specific responsibilities signed off. However, this combination is not mandatory.

Conclusion

In conclusion, the desired outcomes at the end of these considerations should include:

Comprehensive documentation of the roles and responsibilities pertaining to various tasks in the operational aspects of securing payment card data processing.
Ensuring that personnel are fully aware of their respective roles, responsibilities, and tasks, and that they can confirm this awareness during interviews.

This approach will facilitate compliance with sub-requirements x.1.2.

Information security officers for credit institutions

PCI DSS v4.0 blog entry for October

PCI DSS 4.0 Evidence Guidelines

In this episode of our PCI DSS v4.0 blog, we explain assessors’ responsibilities for providing evidence of their assessment findings, and how to prepare the provision of appropriate evidence for PCI DSS v4.0 assessments.

Assessment process

During a PCI DSS assessment, assessors check the extent to which a company has implemented the PCI DSS requirements.

Typically, an assessment process includes the following steps:

Review of documents,
Review of system components/settings,
Review of processes,
Review of physical conditions,
review of protocols/results, and
Interviews with staff.

This does not change with the migration to PCI DSS v4.0.

Evidence requirements

It usually remains hidden for the assessed company how an assessor makes notes and files evidence. We provide insight into the corresponding changes with PCI DSS v4.0.

With the new reporting template for PCI DSS v4.0 as well as with an update of the PCI DSS Program Guide for QSAs, the PCI SSC has now clarified that they require the assessor to file a corresponding evidence for each assessment step. The PCI SSC checks whether the assessor companies meet this by taking samples.

For documents, this is easy: the respective document itself is the required evidence. Regarding protocols/results, it is similar – here you just have to make sure that it is clear which system or process you are talking about.

If you send a screenshot or file to an assessor as evidence, please make sure to include the information which system component and/or process it is about. When reviewing system components/settings, the assessor must take dedicated notes on the system and setting in question.

When reviewing processes or physical conditions, the respective condition must be described in detail and it must be shown what conclusions the assessor draws from the observation. Similarly, in an interview, the assessor is expected to roughly write down the questions and answers.

Please give the assessor enough time to take notes during the assessment. In many cases, it can shorten the paperwork if the assessor is provided with copies or screenshots or is allowed to take photos.

The PCI DSS v4.0 lists about 250 sub-items for the 12 main requirements — the assessor will need a correspondingly large amount of evidence.

Retention requirements

The PCI DSS Program Guide requires that all of the above evidence must be securely retained by the assessor company for at least three years and made available to the PCI SSC and associated companies upon request.

For reasons of privacy or confidentiality, companies sometimes do not allow the assessor to take and file certain evidence. In this case, the PCI SSC stipulates that the evidence may be filed with the assessed company instead. The requirements for retention period and availability are the same in this case.

Since the obligations to provide evidence have become greater with PCI DSS v4.0, this case is expected to occur more frequently in the future.

If you expect that not all evidence may be passed on to the assessor, the best way to prepare yourself as an assessed company is by

preparing an audit-proof storage of the evidence for at least three years,
keeping a list of documents and evidence not handed over during the assessment,
preparing a written confirmation for the assessor, in which you
- name the place of storage,
- name the contact person whom the PCI SSC can contact if it wishes to inspect evidence, and
- confirm audit-proof storage until a specific date at least three years in the future.

Dealing with deviations

How about evidence if the assessment did not immediately demonstrate compliance with all requirements, but deviations were found?

Planned deviations

In the simplest case is when you, as the assessed company, have already recognised in advance that you cannot fulfil a requirement or do not want to fulfil it in the specified way. In this case, you have already prepared documentation of a compensating control or a customised approach for the assessment. A PCI DSS expert can also help you with this — but it must not be the same individual who then assesses the implementation.

We will comment in detail on the Customised Approach in a later episode of our PCI DSS v4.0 blog.

In both cases, the assessor will review the evidence of your company’s Compensating Control or Customised Approach, ask questions if necessary, and then derive and implement appropriate testing methods. The obligations to collect evidence result from the respective assessment method.

Unplanned deviations — “INFI”

If unplanned deviations from PCI DSS requirements occur during an assessment period, they must be remedied and the remediation verified by the assessor. This was already the case in PCI DSS v3.2.1.

Additionally, PCI DSS v4.0 additionally explicitly requires that the cause for the occurrence of the deviation is identified and that processes are implemented to prevent a recurrence of such a deviation. Only if this is the case, the assessor can still consider the requirement as in place.

All deviations, their causes, corrective and preventive controls must be documented in the new “Items Noted For Improvement” (INFI) document for any PCI DSS v4.0 assessment.

The assessor provides the INFI document to the assessed company at the end of the assessment and both parties sign it. The INFI document proves that the assessed company has successfully managed the deviations. The document can be used internally within the assessed company — e.g. in compliance and risk departments — and can also be shared with third parties if desired. There is no obligation to present the INFI document anywhere, nor is it referenced in the Attestation of Compliance (A.O.C).

Particularly for processes that have to be repeated regularly, it happens from time to time that one instance is delayed, e.g. within the implementation of

security awareness trainings,
inspection of payment devices,
vulnerability scans, or
installation of patches.

It is best to consider in advance how you can design your processes in such a way that you adhere to the prescribed time periods and notice delays immediately.

For further questions feel free to contact Mrs Jana Ehlers.

PCI DSS v4.0 blog entry for September

Timeline for PCI DSS v4.0 migration – What are the next steps?

With March 31, 2024, the end of PCI DSS v3.2.1 is approaching. All merchants accepting payments with cards of the international payment brands Visa, Mastercard, American Express, Discover, JCB, or UnionPay, and all service providers supporting them, should be prepared for PCI DSS v4.0.

But what should be done in particular, and when?

Gap analysis

The first step should be a gap analysis. Anyone who has not yet checked which new requirements come up to them with PCI DSS v4.0 should do so as soon as possible! The reasons are obvious:

Implementing new requirements will require time and resources.
PCI DSS professionals who can advise on implementation are already well booked.

During the gap analysis, the new requirements must be read, understood, and aligned with the existing landscape of controls. To understand the requirements, it is extremely helpful to read not only the requirement itself, but also the extensive guidance that the PCI SSC has provided alongside each requirement within the standard:

The “Guidance” column (to the right of the requirement),
the objective being pursued by the requirement (below the requirement),
and, if available, the applicability note (below the requirement).

The introductory chapters of PCI DSS v4.0 and the glossary in Appendix G can also support in understanding terminology and applicability.

If you work with a PCI DSS expert at present, feel free to draw on their expertise and experience within this step already.

Prioritisation

When all open items have been identified, timeframes and responsibilities should be assigned. When assigning timeframes, the following should be considered:

How long will the implementation take?

The implementation of new technical solutions often takes a long time due to internal dependencies. Often this comes together with low human resources. Issues that are expected to take a long time to implement need to be addressed earlier than those where a quick completion is expected.

Are targeted risk analyses required?

In v4.0, for many regular tasks the frequency of performance is no longer predefined, but is to be determined by a targeted risk analysis. The implementation of such targeted risk analyses must be coordinated internally and hence requires time.

Are there periods that are particularly good or bad for implementation?
g. for policy changes, it can make sense to consider document review cycles. For technical changes, it makes sense to consider any freeze periods or release periods that have already been planned.
Is the PCI DSS v4.0 deadline for this requirement 2024 or 2025?

For many fundamentally new requirements in PCI DSS v4.0, the applicability notes state that the requirement is considered best practice until 31 March 2025, after which it is mandatory.

Requirements without this note must be implemented by 31 March 2024 and might therefore require a higher prioritisation

Decisions

For some new requirements, there are different ways to implement them. Examples are:

Requirement 3.4.2 calls for preventing copying/moving of PAN when accessing remotely (except for personnel with appropriate business need). There can be several ways to implement this, too — e.g. via a setting in RDP when using the remote connection, or by preventing highlighting/copying/mouse-right-clicking on PAN displays on according web pages.
Requirement 8.4.2 requires multi-factor authentication (MFA) when accessing the Cardholder Data Environment (CDE).Depending on how the access towards the CDE takes place, it may make sense to enforce MFA at network level, at system level, or at application level. This decision must be well weighed with the various parties involved. Several parties may even have to work together on the solution.

Weigh up the impact of different solutions at an early stage!

Tracking and Assessing

Once you have prioritised your tasks and decided on implementation paths: please do not sit back! The person or team responsible for maintaining PCI DSS compliance should stay in contact with the teams responsible for the implementation.

Are there any enquiries/comprehension issues?
Do any problems with the implementation arise?
Is the agreed target date at risk?

As soon as a new solution has been implemented, it should be checked whether it meets the corresponding PCI DSS requirement. External PCI DSS experts can also support with small interim pre-assessments in order to be on the safe side for the next official annual assessment.

Continuous Process

Once a requirement is met, there is no guarantee that it will remain so. Card data usage, technologies and attack vectors change. Already today, PCI DSS v3.2.1 comprises regular tasks for maintaining PCI DSS compliance. With PCI DSS v4.0, this is becoming even more of an ongoing process.

Therefore, get into the habit of putting your controls to the test repeatedly, and of adhering to the timeframes for recurring activities (now precisely defined in chapter 7 of the PCI DSS). This will also make it easier for you to comply with new corresponding requirements, such as e.g.

2.4 / 7.2.5.1 Review of user accounts and assigned access rights,
3 Review of risk assessments and review of the appropriateness and security of cryptographic algorithms, hardware and software technologies used,
5 Validate the PCI DSS application scope; and
6.2 Review of the security awareness programme.

Above All: Start!

This is the most important step. If you haven’t started yet, today is the best day to do so. Assemble a team and schedule time.

Should you need any assistance do not hesitate to contact Jana Ehlers via email.

PCI DSS v4.0 approaches – we support your preparation

PCI DSS is a mature standard that defines requirements for secure processing of card data of the international payment brands.
Version 3 of PCI DSS, which has been valid since 2014 — with various updates -, will finally expire at the end of March 2024 and will be replaced by the new version 4.0.

We take the final steps to PCI DSS v4.0 migration with you. Please make use of our offers:

1. Monthly blog articles highlighting one PCI DSS v4.0 topic at a time

September 2023: Timeline for the PCI DSS v4.0 migration – What are my next steps?
October 2023: Evidences in PCI DSS assessments
November 2023: Roles and responsabilities
December 2023: Targeted Risk Analysis
January 2024: Changes in e‑commerce: What’s changing in Self-Assessment Questionnaire A?
February 2024: Customized Approach
March 2024: Changes in e‑commerce: Integrity protection of payment pages
You will find further topics updated here.

2. Free webinars summarizing the changes from PCI DSS v3.2.1 to v4.0 again

Webinar on the full PCI DSS scope (January 2023)
Webinar for card-present merchants with SAQ B‑IP or P2PE scope (January 2023)
Webinar for e‑commerce merchants with SAQ A scope (January 2023)

You find an overview about the current webinars here.

3. PCI DSS v4.0 workshops tailored to your needs, in which we specifically present and discuss the requirements that are relevant to you.

4. A gap-analysis of your environments and processes. You will receive a list of all open items for PCI DSS v4.0 compliance in your company.

5. Consultancy packages of your choice. You can call up quotas at any time if you have specific queries — by telephone, e‑mail, web conference, or in meetings on site.

Please feel free to contact Mrs Jana Ehler via e‑mail for further inquiries.

SRC goes GEAR (Global Executive Assessor Roundtable)!

PCI SSC and SRC

The Payment Card Industry Security Standards Council (PCI SSC) is a global forum that develops and promotes the use of information security standards for secure payments. It is responsible for 15 globally recognized and widely used standards for securing electronic payment processes — from payment card production and issuance to payment at the point of interest or in web & app, to the processing of payments in the background.

SRC has been assessing the use of those information security standards since PCI SSC was founded by means of corresponding assessments and product evaluations. The PCI SSC attaches great importance to the exchange between different stakeholders and uses various committees and activities for this purpose. SRC has so far participated in Special Interest Groups and Task Forces as well as in Community Meetings and Request for Comment phases.

Global Executive Assessor Roundtable

The PCI SSC has been giving experienced assessor companies the opportunity to advise its senior management since 2018 through the Global Executive Assessor Roundtable (GEAR). We are excited that our company has been selected this year to be part of the interfaces between leadership of the PCI SSC itself and leadership of the assessment companies by this responsible membership. This will enable us to contribute our years of experience in a direct way. The nomination is valid for the next two years and gives us the opportunity to play an influential role in the further development of specifications for assessment procedures, new training programs and qualification requirements for future assessors. Other GEAR responsibilities include finding ways to promote assessors’ engagement in emerging and new markets, and optimizing assessors’ skills to add value for payments companies

We are proud to be included in this circle and see it as a recognition of our past performance and relevance in the payments security market. At the same time, we are aware of our responsibility to act as a representative for a large community of assessment companies and take this as an additional incentive for the future.

Link to GEAR: https://www.pcisecuritystandards.org/about_us/global_executive_assessor_roundtable/

8 digit BINs and PCI DSS

On April 1, 2022, the payment brands Visa and Mastercard will expand the BIN (Bank Identification Number) of their cards worldwide from 6 to 8 digits. In future, the first 8 digits of a 16-digit credit card number (Primary Account Number, PAN) will be used to identify the card issuer. The BIN is used in many occasions where the use of the full PAN is not necessary — e.g. for routing of transactions, or for reporting.

BINs and PCI DSS

Wherever a full PAN is used, the systems, environments, processes and people must meet the requirements of the data security standard PCI DSS (Payment Card Industry Data Security Standard). As useful as the protection of the PAN by the PCI DSS is – it is not necessary for the BIN. The PCI DSS therefore describes the conditions under which parts of the PAN do not require the same protection as the full PAN. If not the full PAN is stored, processed or transmitted, but only parts of it, the PCI DSS refers to “truncation”. If the full PAN is stored in the background, but not all digits are displayed in an application, the PCI DSS refers to the display as “masking”. In everyday life, the term “crossing out” is also used for the two different measures; from PCI DSS point of view, however, they have to be differentiated.

The following rules previously applied to truncation and masking:

Masking: PCI DSS Requirement 3.3 states that a maximum of the first six and last four digits (“first 6, last 4”) of the PAN may be displayed, as long as there is no business need to view the full PAN.
Truncation: PCI DSS Requirement 3.4 lists truncation as an example of rendering PANs unreadable, but does not define it. The permitted formats are rather defined by the international payment card organizations and get summarized by the PCI SSC in FAQ entry #1091. Most of them had agreed on the rule “first 6, any other 4”, which had lasted for many years.

Changed rules for truncation and masking

However, due to the switch to 8‑digit BINs and the need for many companies to process them, the payment brands have now changed their specifications. The current summary in the PCI SSC FAQ entry now defines that “first 8, any other 4” is permitted for truncation for 16-digit PANs. The (test) card number 4012888888881881 is then allowed to be stored and processed in the form 40128888xxxx1881, for example — it is sufficient if any four digits are crossed out after the BIN. Only for shorter PANs, the existing rules “first 6, any other 4” (Discover) or “first 6, last 4” (American Express) remain in place. A corresponding adjustment of the PCI DSS requirement for masking is expected with the change to PCI DSS v4.0.

From a security point of view, removing so few digits is not an improvement — but from a business perspective, the change is probably necessary. It is to be hoped that, overall, this will be offset by other security measures.
In any case, the requirements of the PCI DSS will not prevent the use of 8‑digit BIN in the future.

Caution when combining different formats

Regardless of the length of the BIN, merchants and service providers who work with truncated card data should take care not to weaken the protection by mixing different formats.

It must be considered that the extended truncation formats only apply to 16-digit PANs. The length of the PAN must therefore be taken into account for truncation during storage.
Truncation formats such as “first 6, any other 4” theoretically allow the existence of different truncated versions of the same PAN. The above card number might be stored as 40128888xxxx1881 in one system and 401288888888xxxx in another. This is not prohibited — but it must be ensured that no one without an according business need can merge the two versions and thus reconstruct further digits of the PAN — right down to the complete card number.
This also applies if different formats are used for masking and truncation.
If both truncated PANs and the hash values of PANs are stored in an environment, the two values themselves are initially uncritical. However, if the truncated PANs and their hash values can be related, the original full PAN can be easily reconstructed using rainbow tables. In this case, additional measures must also be taken to prevent the two versions from being merged.

PCI DSS v4.0 is coming — an overview

The PCI DSS (Payment Card Industry Data Security Standard) is well known as a comprehensive data security standard for payment card data of the international payment brands. The Payment Card Industry Security Standards Council (PCI SSC) keeps revising the standard throughout the years to address evolving risks and threats to payment data, to keep pace with the ever changing IT and payment landscape, and to reinforce security.
The PCI SSC has been working on the new, fundamentally revised version 4.0 of the standard for a long time now. After three RFC phases throughout the years, the new version will now be officially published on the PCI SSC website in March 2022.
Several changes have already been announced and are listed hereafter.

New validation options

PCI SSC plans to add more flexibility to the standard. Traditionally, the intended way of fulfilling a PCI DSS requirement is to follow it word by word. Now, the PCI SSC plans to add a choice: For nearly each requirement, an entity can either choose the traditional way of fulfilling it word by word, or they can use a customized validation.
For each requirement in the standard, the objective that is intended to be reached with it will be given. If an entity thinks that they want to use another way of meeting this intention than following the requirement word by word, they can document how they do this. This includes a risk assessment to verify the appropriateness of the customized way. This documentation, including the risk assessment, is then provided to the assessor, and the assessor identifies suitable testing procedures to verify the implementation of the customized controls.

Requirement changes

To make sure PCI DSS compliance is kept up throughout the year, additional requirements are announced by the PCI SSC, e.g. the necessity for

Definition of roles and responsibilities for all PCI DSS relevant topics; and for
Regular verification of PCI DSS scope.

In addition, existing requirements will be adapted to threat and security evolvement. Changes to requirements on the following topics are forecasted:

Authentication requirements,
Detection mechanism and awareness measures for ongoing threats, and
Risk assessments.

Also the use of 8‑digit BINs will need to be addressed (see our blog entry).
Of course, the exact details of changes can only be given after the final publication.

Transition process

The PCI SSC has announced a transition period of two years, plus additional transition time for completely new requirements.

So after publication in March 2022, take your time to read the new PCI DSS version, identify the changes, and understand the impact on your environment. Use this year to plan migration to PCI DSS v4.0 and decide when is the right moment for your entity to switch from version 3.2.1 to 4.0.

Your PCI DSS consultant or assessor can help you understanding the intention of changes, your need for migration, and the validation requirements. Please do not hesitate to contact them. If you do not have direct contact to a PCI DSS expert, please contact SRC’s PCI DSS responsible.

To get a first overview of the changes to the standard, you can also join our free PCI DSS v4.0 webinar on 20th of April: Register here.

PCI DSS v4.0 release delayed

The publication of a new, fundamentally revised version of the payment transaction standard PCI DSS has been announced since 2019. We are eagerly awaiting the changes that the new version will bring.

After PCI DSS v4.0 had already undergone two RFC phases in 2019 and 2020, the PCI Security Standards Council has now decided to also initiate an RFC phase for supporting documents, in particular for

the template for the Report on Compliance (ROC),
the template for the Attestation of Compliance (AOC), and
the self-assessment questionnaires (SAQs)

in June 2021. However, this will also delay the publication of PCI DSS v4.0.

Instead of the announced release period in Q2 2021, the aimed period of finalization is now Q4 2021. The actual release date has not yet been specified.

We must therefore be patient a little longer before we can properly plan the migration. With the shift of the publication date, the planned transition periods from PCI DSS v3.2.1 to v4.0 have also been postponed. We are therefore also postponing our PCI DSS v4.0 webinars to 2022.

SRC-Expertin Ehlers: Standards of the Payment Card Industry (PCI)

SRC-Expert Ehlers: Standards of the Payment Card Industry (PCI)

“PCI compliance requires know-how and resources.” SRC expert Jana Ehlers explains the different PCI security standards in an article which has just been published on the professional platform “All About Security”.

In view of the increasing number of card payments in pandemic times, the protection of payment card data is a very current topic.

All PCI standards aim at protecting payment card data of international payment systems. The most well-known standard alone, PCI DSS, has around 250 individual requirements. If these are already taken into account when setting up networks and structures, there is often no need for complex and expensive retrofits. But also the permanent maintenance of PCI DSS conformity poses challenges for companies.

SRC examines and advises on PCI standards since their emergence in 2006. This experience can be used to correctly understand and consider the intentions of the PCI standards. SRC accompanies through the whole process. Thus, not only PCI-conformity can be achieved in an understandable way, but also a great deal more security for the customers’ payment card data worthy of protection.

Our December blog post on PCI DSS v4.0: Targeted Risk Analysis

Our November blog post on PCI DSS v4.0: Roles and Responsibilities

PCI DSS v4.0 blog entry for October