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.
SRC Security Research & Consulting GmbH: Generation change at the top
After almost 25 years of successful management of the company by Gerd Cimiotti, the foundations are now being laid for a generational change in the management of SRC — and thus for the next 25 years. With effect from August 1, 2024, Markus Schierack will be appointed to the management board of SRC Security Research & Consulting GmbH, Bonn.
As Managing Director of the payment transaction institute VÖB-ZVD Processing GmbH (“Pagateq”), he has been responsible for business development, payment transactions, finance and regulatory affairs, among other things. Markus Schierack brings many years of experience in strategic development and transformation in the area of payment transactions to his new role. The corporate finance specialist has held various positions within the Deutsche Bank Group in recent years. Among other things, he actively supported various strategic M&A transformation projects of the bank’s private customer business in the Group Development department of Deutsche Postbank AG and at Deutsche Bank and positioned Pagateq as a BaFin ZAG-licensed payment service provider with its own identity within Deutsche Bank Group.
Gerd Cimiotti, who has been Managing Director of SRC since 2001, will actively support the generational change and the handover to Markus Schierack until 2025 and will then retire from management: “One of the biggest challenges for medium-sized companies is the successful generational change. At SRC, Markus Schierack is the next generation to take on overall responsibility for the company. I am very confident that Markus will not only lead SRC Security Research & Consulting GmbH into a good economic future, but will also keep the special values of our company alive,” explains Cimiotti.
The time frame was deliberately set to allow for a gradual transition. The SRC shareholders’ meeting would like to take this opportunity to thank Mr. Cimiotti for his trusting cooperation and his successful and tireless efforts to develop SRC into a leading IT security competence center.
Markus Schierack already knows SRC very well from his role as Chairman of the SRC Shareholders’ Meeting and will now join the Management Board on August 1. Markus Schierack is looking forward to the challenge that he wants to master together with the employees at SRC: “My heart beats for the company and I have already had the opportunity to get to know SRC well through my work as a representative of a shareholder of SRC Security Research & Consulting GmbH.”
The 43-year-old will be supported by Randolf Skerka, who will be responsible for SRC’s auditing business in the future. The current Head of Sales at SRC has been familiar with the company and the auditing business in particular for many years from various roles at SRC. “For me, teams with strong personalities are always important in order to master upcoming challenges. I am therefore grateful to have Randolf Skerka at my side as an extremely experienced sparring partner,” says future Managing Director Markus Schierack.
About SRC Security Research & Consulting GmbH
SRC is the joint competence center of the German banking industry for IT security. SRC was founded in 2000 with the support of the four credit industry publishers (Bank-Verlag GmbH, DG-Nexolution eG, S‑Payment GmbH and VÖB ZVD-Processing GmbH) and the leading associations of the German credit industry represented on the company’s advisory board (Bundesverband deutscher Banken e.V., Bundesverband der Deutschen Volksbanken und Raiffeisenbanken e.V., Bundesverband Öffentlicher Banken Deutschlands e.V., Deutscher Sparkassen- und Giroverband e.V.).
In April 2001, Gerd Cimiotti joined the company’s management and led the expansion of SRC into a leading IT security service provider in Europe. With more than 120 employees, SRC is not only one of the top addresses when it comes to technical innovations in payment, but SRC also offers a comprehensive IT security and audit program to support customers all over the world.
The plan for the future is to further expand both business areas and take advantage of the emerging market opportunities. The new management team led by Markus Schierack is an important prerequisite for this. The smooth transition in management from Gerd Cimiotti to Markus Schierack also ensures the necessary continuity.
SRC and DAkkS accreditation according to ISO/IEC EN 17025: An important step towards EUCC
SRC Security Research & Consulting GmbH kann einen weiteren bedeutenden Erfolg verzeichnen: Die erfolgreiche Akkreditierung durch die Deutsche Akkreditierungsstelle (DAkkS) nach DIN EN ISO/IEC 17025. Dieser Schritt unterstreicht nicht nur die Kompetenz und Zuverlässigkeit unseres Prüflabors für Common Criteria (CC), sondern bereitet uns auch auf die Einführung der EUCC (European Common Criteria) vor, eine wichtige Entwicklung in der europäischen Cybersicherheitslandschaft.
Bedeutung der DAkkS-Akkreditierung
Die Akkreditierung nach DIN EN ISO/IEC 17025 ist ein klares Zeichen für die Professionalität und den Anspruch von SRC, erstklassige Prüfdienstleistungen anzubieten. Sie bestätigt, dass unser CC-Prüflabors den international anerkannten Standards entspricht und vertrauenswürdige, konsistente Ergebnisse liefert.
Vorbereitung auf die EUCC
Die EUCC stellt das auf den Common Criteria basierende europäische Zertifizierungsschema dar, soll die Sicherheitszertifizierung von IKT-Produkten in Europa verbessern. Mit unserer DAkkS-Akkreditierung ist SRC nun bestens gerüstet, um die Herausforderungen der EUCC zu meistern und eine führende Rolle in der IT-Sicherheitszertifizierung in Europa zu übernehmen. Die EUCC erweitert die Anforderungen der bisherigen Common Criteria und wird künftige Zertifizierungen in der EU grundlegend prägen.
Unser Engagement für Qualität und Genauigkeit
Mit dieser Akkreditierung demonstriert SRC sein Engagement für höchste Qualitätsstandards und Unparteilichkeit in unseren Labortätigkeiten. Wir sind stolz darauf, diesen Meilenstein erreicht zu haben und freuen uns darauf, unseren Kunden weiterhin Dienstleistungen auf höchstem Niveau anzubieten.
Bei weiteren Fragen stehen unser Sales-Team Ihnen jederzeit zur Verfügung!
SRC joins the German IT Security Association (TeleTrusT)
SRC joined the German IT Security Association (TeleTrusT).
The Bundesverband IT-Sicherheit e.V. (TeleTrusT) is a competence network comprising domestic and foreign members from industry, administration, consulting and science as well as thematically related partner organisations.
Due to the permanently changing requirements in the field of IT security, it is important for SRC that its experts regularly inform themselves about and exchange information on new necessities, techniques, processes and regulations.
TeleTrusT offers particularly good conditions for this, since in addition to the exchange of experts from the business world, contact is also established with politics and science.
SRC will contribute its wide-ranging expertise to the various working groups of TeleTrusT and thus give further significance to the status of IT security in Germany and Europe.
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:
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:
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:
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.
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
Factors that can have an impact on the realization of these threats are, for example:
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:
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
Happy New Year, and take care!
The BSI Situation Report 2023: Secure Your Business – Discover Our Solutions.”
The latest Situation Report from the Federal Office for Information Security (BSI) for the year 2023 paints a picture of the German cybersecurity landscape that reveals both challenges and calls to action. As digitalization progresses in all areas of life, the complexity and number of cyber threats are increasing.
Specific IT security threats in 2023
Particularly, ransomware attacks aimed at encrypting company data and demanding ransoms are becoming more sophisticated and are affecting not only large corporations but also increasingly smaller and medium-sized businesses as well as public institutions.
Another prominent topic of the report is the potential misuse of Artificial Intelligence (AI). With the rapid development of AI technologies and their applications, new possibilities for attacks emerge. AI-powered attacks, including deep fakes and manipulated chatbots, represent a serious threat that can undermine not only information security but also societal stability.
Geopolitical tensions, especially the conflict in Ukraine, further demonstrate that cyberattacks are increasingly being used as a means of warfare and political influence. These developments are not limited to state actors but also affect the economy and civil society. The BSI emphasizes that security in cyberspace is no longer just a matter of technical defense but requires a collective societal effort.
The BSI’s recommendation to strengthen “cyber resilience” reinforces the necessity of being proactive and preventive. This means that companies and authorities must not only react to attacks but also improve the resilience of their systems in advance.
This is where the expertise of SRC GmbH comes in, a company that specializes in security needs in the digital age.
How SRC can help establish cyber resilience
Use the insights from the BSI Situation Report 2023 as a decisive impulse to specifically review and optimize your cybersecurity measures – SRC GmbH is ready to work with you to strengthen critical security areas and build resilience against current and future cyber threats.
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.
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.
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:
This approach will facilitate compliance with sub-requirements x.1.2.
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:
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
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
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.
SRC GmbH: Pioneer in BSZ certification with expansion of the team of experts
In the following article you will learn more about how the SRC GmbH has been acting as a recognized test center for the BSZ since September 2021 and what important developments and expertise it offers in this area.
Accelerated Security Certification (BSZ): An Introduction
The BSZ is a procedure offered by the BSI in Germany to prove the security of IT products. It was introduced to give manufacturers a faster way to demonstrate the security of their products with a BSI certificate. This assessment aims to ensure that the product meets the security requirements of the BSI and offers end users an appropriate level of protection. Compared to the conventional certification according to Common Criteria (CC), the BSZ offers the advantage of faster certification, easier to plan evaluation times, and a significantly reduced documentation effort for the manufacturer. SRC is a testing center for accelerated security certification (BSZ) recognized by the Federal Office for Information Security (BSI) and was one of the first recognized certification bodies at all.
The road to security: BSZ versus CC
The procedure only allows a single run, i.e. the product to be evaluated may not be changed during the evaluation. This greatly speeds up the process overall, but there is always a risk that products will fail the first attempt and therefore not receive a certificate. In this case, however, a new certification procedure can be requested from the BSI at any time.
Under the direction of Peter Jung: The first steps of the SRC with BSZ
Under the project management of Peter Jung, who has been responsible for the BSZ at SRC from the start, SCR has since evaluated the Lancom 1900EF VPN router, which was also the first BSZ product ever, and then the secunet high-speed connector. As soon as this is evaluated, we will report on it in another article.
New expertise at SRC: Tim Hirschberg and Dr. Matthieu Felsinger
We are happy to announce that since May 2023 the SRC has been formed with Tim Hirschberg (BSZ evaluator) and Dr. Matthias Heuft (BSZ evaluator) and Dirk Feldhusen (BSZ evaluator for cryptography) — strengthen.
The BSZ certification in detail: concentration on promises of security
The BSZ certification focuses on verifying the safety performance promised by the manufacturer. The actual certification is carried out after the product has been evaluated by a test center recognized by the BSI, such as the SRC. The resulting test report serves the BSI as a basis for awarding the certificate.
The path to the certificate: the verification process at SRC
The evaluation takes place within a fixed timeframe (about 2–3 months) that depends on the complexity of the product. The evaluation services include checking the promised security functionality (conformity tests) and the installation instructions as well as penetration tests, in which the effectiveness of the technical security measures of the product is checked under realistic attack scenarios.
Cryptocurrency ECB Digital EuroA Holistic Review: Cryptography and Beyond
The assessment of the implemented cryptographic procedures is also part of the comprehensive testing process that an IT product has to go through in order to receive the BSZ certification.
A look into the future of safety certification
At SRC GmbH, we are proud of our role as a recognized testing body for accelerated security certification (BSZ) and of continuously promoting security standards in the IT industry. With our experienced team and commitment to innovation, we will continue to help ensure the security of IT products.
If you would like to learn more about our BSZ certification services or have any questions, please do not hesitate to contact us. Together we can meet the safety requirements of your products and pave the way for certification. We look forward to working with you and shaping the future of safety certification.
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:
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 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:
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.
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.
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.
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:
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.
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.
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
2. Free webinars summarizing the changes from PCI DSS v3.2.1 to v4.0 again
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.