PCI DSS 4.0: How-To Guide for Compliance Teams in 2022

pci v4 guide

PCI DSS 4.0 is the latest release of the PCI Data Security Standards since Version 3.2.1 on May 17, 2018. Version 4.0 was released in Q2 of 2022 and has been updated to continue the effort and focus around securing cardholder data and the current (and future) state of the payment industry, while also promoting security and PCI as a continuous process.

This release of PCI DSS provides organizations with greater flexibility in reporting, clearer guidance, and sets the stage to be the gold standard for the payment card industry’s security baseline.

In this article, we are going to cover what PCI DSS 4.0 is, how it’s going to affect you, and what the timelines are. We are also going to look at the new requirements and offer ideas for how you can update your processes to meet these requirements when Version 3.2.1 is retired.

Background: Why The Change?

Like other technology industries, the payment industry continues to adopt and integrate newer technologies at an accelerated pace. Therefore, we need to ensure that our security standards are keeping up with the pace. The PCI DSS 4.0 update brings a fresh perspective to the security controls we need to have in place to protect cardholder data (CHD).

With the update to 4.0, the PCI Security Standards Council corrected redundant requirements, clarified guidance and testing procedures, modified wording to include more technologies, and added more efficient ways to report PCI Compliance. 

These changes to the PCI DSS are the result of feedback from the payment industry to the PCI Council. The aim of 4.0 is to allow businesses to report their compliance in a way that best suits them, the technologies they use, and the way their business deploys payment methods.

To sum it up, 4.0 is designed to make PCI DSS Compliance simpler and more flexible to your business by eliminating stringent and specific requirements, adopting a mindset around the security objective that the requirement is designed to achieve, and allowing you to demonstrate the specific controls you have in place to be compliant.

Past Requirements Updated in PCI DSS 4.0

The PCI Council has made three types of changes from version 3.2.1 to version 4.0, which are: evolving requirements, clarifications, and structure or format changes.

  • Evolving requirements help to ensure that the standard is up to date with emerging threats, technologies, and changes in the payment industry.
  • Clarifications are updates to wording, explanation, definitions, or further information on a particular topic.
  • Finally, structure or format changes include reorganization of content which can include combining, separating, and renumbering requirements. 

PCI 4.0 has made numerous changes to previous requirements in version 3.2.1., which help to clarify the requirement intent, merge duplicate requirements, and provide better organization of the requirements. Many of the annoyances and ambiguity have now been either removed or specified. No more guessing!

Most of the previous requirements in version 3.2.1 and their security objectives are still present in version 4.0.

Controls you have developed according to version 3.2.1 will still be applicable to most updated requirements. Due to definition and wording changes, these controls will need to be updated to include more technologies than what was previously defined in 3.2.1. 

While this is not an exhaustive list of changes, this article will focus on the high-level changes from 3.2.1 to version 4.0 that require preparation. You may read the full Summary of Changes from PCI DSS Version 3.2.1 to 4.0 document on the PCI Security Standard’s website. In this document, the PCI Council has created a full matrix that maps changes or modified requirements from 3.2.1 to their new 4.0 requirement.

New Requirements Added by PCI DSS 4.0

This section is the most important part of this article, as these are the new requirements in PCI DSS 4.0 that previously did not exist in version 3.2.1.

These new requirements have been added to now better reflect the payment industry’s emerging threats. The primary principles and objectives from version 3.2.1 are still very much present in version 4.0. Some of the new requirements are fairly simple.

However, there are some that you will need to dedicate time, and potentially, additional budget towards.

Changes to All Requirements

With the exception of Requirement 12, you will notice a new requirement to define roles and responsibilities for performing all the requirements within the main requirement. You will want to create a RACI chart (Responsible, Accountable, Consulted, and Informed) for all of the daily activities.

This change helps to ensure that each activity is assigned to someone and they acknowledge their responsibility to perform that activity. Remember, the goal is to have security be an ongoing process instead of an acute assessment. 

For the remainder of the article, and for each list of requirement changes, we will exclude the roles and responsibilities requirements and any service provider-related requirements. 

Changes to Requirement 1: Firewalls

The first change you will notice in Requirement 1 is the term “network security controls” or NSCs. This wording change better reflects the various types of network security appliances that are on the market now. Previously, the DSS wording focused specifically on defining firewalls, routers, etc.

This will allow you to focus on better security controls that are available to your environment through a broader range of technologies.

Changes to Requirement 2: Vendor-Supplied Defaults

The primary focus has shifted from focusing solely on vendor-supplied defaults to secure configurations overall. You’ll see that most of the wording in Requirement 2 has replaced the term “vendor-supplied defaults” with “secure configurations.”

Changes to Requirement 3: Protect Stored Cardholder Data

Requirement 3 has six new requirements. The primary focus of Requirement 3 has changed to focus on account data instead of “cardholder data” in version 3.2.1.

Requirement 3.2.1 – This requirement replaces 3.1 in version 3.2.1. The update now requires sensitive authentication data (SAD) that is stored prior to completion of authorization to follow data retention and disposal policies, procedures, and processes.

Requirement 3.3.2 – This new standard requires that SAD is encrypted if stored prior to the completion of authorization. This means that if you are using a cloud queuing service like Amazon SQS or within your point-of-sale (POS) devices SAD must be encrypted and follow data retention and disposal processes that are stored for any amount of time.

Requirement 3.3 – This requirement now clearly defines that the primary account number (PAN) is masked when “the bank identification number (BIN) and the last four digits are the maximum number of digits to be displayed.”

Requirement 3.4.2 – When using remote-technologies (VPN, SSH, Remote Desktop, Cloud Virtual Workstations, etc.) technical controls must be in place to prevent the copy and/or relocation of PAN. This is a big update, and one that could prove to be complicated to implement to your environment. 

Requirement 3.5.1.1 – If you are using one-way hashes to encrypt your PAN, the method must now include keyed cryptographic hashes of the entire PAN. This means that you must have a key-management process surrounding the hashing process that follows the key management requirements throughout the remainder of the PCI Data Security Standard.

Requirement 3.5.1.2 – 3.5.1.2 now states that disk or partition-level encryption must be used to render PAN unreadable on non-removable media rather than throwing disk-encryption on a workstation or server. It must also include a secondary mechanism listed in Requirement 3.5.1. This could include hashing, truncation, or tokens. Additionally, disk or partition-level encryption alone can only be used to secure removable media like flash drives, external hard drives, etc. 

Changes to Requirement 4: Encryption for Cardholder Data

Requirement 4 now focuses on the use of “strong cryptography” to protect the transmissions of cardholder data. There are two new requirements you need to be aware of:

Requirement 4.2.1 – There is a new bullet tucked into what was Requirement 4.1 in version 3.2.1. The new bullet requires that certificates that are used to transmit PAN over open or public networks are valid and not expired or revoked.

Requirement 4.2.1.1 – In order to ensure that your certificates are valid and not expired, you now need to keep an inventory of trusted keys and certificates.

While this isn’t included in the requirement wording, I would recommend that your inventory consists of the following points: Certificate/key name, storage location, encryption level, and expiration date. Also make them actionable. If using cloud services like AWS Certificate Manager, setup automatic renewal and rotation. If using manual methods, setup reminders to a group message board or email group.

Changes to Requirement 5: Antivirus Software

Requirement 5 has retired the term “anti-virus” (AV) and now focuses on protecting all systems and networks from malicious software. This change in focus allows you to use various types of new technologies to protect against malicious software. While this can still include anti-virus you can now use host-based technologies like AI/ML threat detection and more. There are four new requirements in Requirement 5. 

Requirements 5.2.3.1 & 5.3.2.1 – These two requirements are the first where we see a new 4.0 assessing tool, the Targeted Risk Analysis. PCI DSS 4.0 allows organizations to define the frequencies of periodic evaluations for most, but not all requirements (ASV and penetration testing). In these two requirements, you can define the frequency in which you perform the following two activities based on your organization’s specific risks.

The first are system components not at risk for malware. If you do not deploy AV or anti-malware solutions to every system component, you can now define the frequency in which you review if their risk to malware has increased or stayed the same, enabling you to decide how often you review these technologies for emerging risks. 

The second is the frequency of malware scans you perform in your environment. In the targeted risk analysis you have to justify your reasoning for the period that you choose. For example, while you may want to say once every six months, do you have a valid business justification for doing so? 

Requirement 5.3.3 – This new requirement compels your anti-malware solution to scan removable electronic media when it is inserted, connected, or logically connected to the machine. 

Additionally, the anti-malware solution can also perform continuous behavioral analysis of the system. This aims to protect against the introduction of malware to the system via removable media. Many new anti-malware solutions are perfectly capable of doing this activity and it only takes a few clicks to enable. Ensure that you test the feature to guarantee that logs or another verification are captured which shows the removable media is being scanned. 

Requirement 5.4.1 –  This requirement addresses the weakest link in security: people. In version 3.2.1 there were a few requirements in Requirement 12 that focused on security awareness and education. While they are still there, version 4.0 is now requiring additional processes and mechanisms to detect and protect personnel against phishing attacks. 

The requirement notes state that this does not bring the mechanisms into scope for things like email servers, as long as they are not currently in scope for your environment.

Anti-phishing mechanisms can include things like DMARC, SPF, and DKIM policies on your email domain. These controls help phishers from spoofing your domain and impersonating personnel.

While this is all that is technically required, I would highly recommend implementing additional commercial software like Proofpoint or other email scanning services as a worthwhile investment.

Changes to Requirement 6: Secure Systems & Applications

Requirement 6 addresses software instead of just applications. In version 3.2.1, entities would focus solely on payment applications instead of any software that may be involved in payment processes. This wording change now applies to all software including bespoke and custom software. While this wording change will most likely involve a larger amount of evidence to gather and review, there are only three new requirements within Requirement 6.

Requirement 6.3.2 – For bespoke and custom software, you are required to keep and maintain an inventory of both.

My recommendation would be to add this inventory to your existing PCI DSS inventory with a new “type” of “Bespoke/Custom Software” as the inventory type. Avoid keeping multiple separate inventories for all PCI inventories to prevent confusion.

Ultimately, the inventory method will depend on your organization and the PCI DSS environment. 

Requirement 6.4.2 – This new requirement now prescribes web application firewalls (WAFs) in front of all public-facing web applications. WAFs were previously recommended in version 3.2.1 but not specifically defined.

Public-facing infrastructure is the most at-risk and primarily targeted by attackers. In recent years, WAFs have become much more affordable and smarter. Ensure that the WAF, or other technical solution in place, does the following: is installed in front of all public-facing web applications and detects/prevents web-based attacks, is actively running and up to date, generates audit logs (and delivers them to your centralized audit solution), and either blocks attacks or generates an alert to personnel.

Despite the potential inconvenience, they are the best line of defense to help secure your applications and environment.

Requirement 6.4.3 – Previously payment scripts could be argued out of PCI DSS scope as they weren’t an “application” on their own, which is antithetical because payment scripts can impact the payment flows.

However, with the new focus on software, that argument cannot be justified in version 4.0. Any scripts that are loaded and executed on the customer browser on all payment pages must be managed. You are obliged to ensure that there is a method in place to confirm that the script is authorized, the script’s integrity is maintained when executed, and maintain an overall inventory of the scripts.

Scripts can be enforced by several mechanisms including: subresource integrity (which allows the browser to validate the script), a content security policy (CSP) that limits the locations where a consumer browser can load a script from and transmit account data to, or a proprietary script system that can prevent malicious script execution. 

I would recommend the payment scripts inventory be kept and maintained in your overall PCI DSS inventory. 

Changes to Requirement 7: Access to Cardholder Data

Within the minimal changes to Requirement 7, there are three new requirements that focus on better and ongoing account management.

Requirement 7.2.4 – Version 4.0 now states that you have an ongoing user account and access review process. Semiannually (once every six months), you must ensure that the user accounts and access continue to be appropriate for their job function. If access needs have changed, they should be removed as needed. Finally, you will need to request and maintain a record of management acknowledgments to attest that the access is appropriate for the users. 

Typically this process is referred to as a periodic access review or PAR. While the PAR for this exercise will only include accounts in scope for PCI DSS, it should be a general practice organization-wide. There are new IAM services, like SailPoint, that have modules you can purchase to complete this access report for you. Access should be per group, job code, etc. Irregularities on a specific user can be automatically flagged and reviewed. The last missing piece is the manager’s approval to confirm the access. 

Requirement 7.2.5 – This is a new requirement that should already be a part of your PCI DSS account and access management processes. This requirement now states that application and system account access should be least-privilege, meaning that access for service accounts are only granted with the least privileges necessary for the operability of the system or application.

In simpler terms: you cannot assign a system or application account administrator or root rights unless it’s absolutely needed. Additionally, the access needs to be restricted specifically to the system, application, or process that requires the use. This restriction can be based on time, restricting to internal network use only, or specific computers. 

Requirement 7.2.5.1 – Similar to Requirement 7.2.4, application and system accounts now must follow a PAR. The difference between 7.2.4 and this requirement is that you are able to define the frequency in which this review is performed in a targeted risk analysis. You must ensure the access is still appropriate, inappropriate access is addressed, and the managers of the accounts acknowledge the access is appropriate. 

Changes to Requirement 8: Unique IDs for Users

The confusing wording of “non-consumer users.” has now been removed and clarified that in-scope accounts do not apply to accounts that are used by consumers (cardholders). Instead, Requirement 8 now standardized the terms “authentication factor” and “authentication credentials.” There are six new requirements within Requirement 8 in version 4.0. 

Requirement 8.3.6 – Password lengths are now required to be 12 characters minimum. Exceptions can still be made to systems that don’t support a minimum length of 12. However, they must be changed to reflect eight characters instead of seven.

There is a caveat to this requirement: User accounts on point-of-sale (POS) terminals, or systems that have access to a single card number/transaction at a time, are excluded, which means that you can continue to use seven-character passwords on POS systems.

Requirement 8.4.2 – In version 3.2.1 MFA access into the Cardholder Data Environment was previously only for administrators. This new requirement now applies to all access into the CDE, which will include both administrators and users. There are two exceptions to this requirement: MFA is not required for application or system accounts that are only performing automated functions, or user accounts on POS terminals that access a single card/transaction at a time. 

Requirement 8.5.1 – This new requirement applies to any system that provides MFA functionality used in Requirement 8. You will need to ensure that the MFA systems are resistant to attacks and strictly control any administrative overrides.

The best approach to this requirement is by utilizing a third-party service like Okta, which enables you to rely on their PCI AOC to cover a large portion of the bullet points in this requirement. However, there are still implementation requirements you need to be aware of and perform on your own. This will most likely be a shared requirement between the service provider and you as the entity. 

Requirement 8.6.1 – Accounts with interactive access must now be managed. There are six bullets you will need to follow. The purpose of this requirement is to limit the permissions and access specifically for accounts with interactive login when used by systems or applications. If you are using cloud services like AWS, this is as simple as generating programmatic access keys in IAM if the application or system does not require interactive login.  

Requirement 8.6.2 – Passwords/passphrases for application and system accounts with interactive login cannot be hard-coded into applications. This is a security best practice, which helps curtail the potential for hackers to find credentials baked into code should it ever be compromised.

While the requirement only specifies accounts with interactive logins, I would recommend you apply this practice to all application or system accounts. 

Requirement 8.6.3 – Passwords/passphrases for application and system accounts must now be changed periodically (as defined in a targeted risk analysis) and the password/passphrase complexity should be appropriate for the frequency of change.

Essentially, if you have shorter and non-complex passwords they should be changed more frequently. If passwords are long and complex they can be changed at longer frequencies. 

Changes to Requirement 9: Restrict Access to Data

Requirement 9 focuses on physical security requirements. In version 4.0, the DSS now defines three different areas that are covered; sensitive areas, CDE, and facilities. Each requirement will state specifically which area is covered in that requirement. There is only one new requirement in Requirement 9 for version 4.0.

Requirement 9.5.1.2.1 – This new requirement requires that there is a periodic review of the physical point-of-interaction (POI) devices. The frequency of these reviews will be defined by you through a targeted risk analysis. 

Changes to Requirement 10: Track & Monitor Access to Data

Requirement 10’s focus is primarily on audit logs, system components, and cardholder data. Wording that previously contained “audit trails” has now been replaced with “audit logs” for clarity. There are four new requirements in Requirement 10.

Requirement 10.4.1.1 – Automated log reviews are now a requirement. If you are currently using a modern centralized logging application you are already potentially covered for this requirement. Ensure that these automated log reviews are set up to identify suspicious or anomalous activities. As a best practice, a daily report should be delivered to your security operations team. 

Requirement 10.4.2.1 – Log reviews for lower-risk system components can now be reviewed periodically. With every “periodic” requirement, you must define this frequency in a targeted risk analysis. The purpose of this requirement is geared toward larger and more complex environments. Make sure that if you do choose to group lower-risk systems, you have valid and justified reasoning for this grouping in the targeted risk analysis. 

Requirement 10.7.2 – Failures of critical control systems have to be detected and alert security personnel. The requirement wording gives a summary of the device types this can be applied to. In cloud environments including setting up Amazon CloudWatch with SNS notifications to detect if these systems lose network connectivity or go offline, among other failures that you need to define for your environment. 

Requirement 10.7.3 – Following Requirement 10.7.2, failures of critical security control systems must be promptly handled. The detailed guidance is located within the requirement wording.

It’s recommended that you integrate these processes into your Incident Response plan instead of a stand-alone document.

This will make the overall management of these processes better and place them in existing processes. For any failures of critical security control systems, ensure you have valid documentation available for the assessment, which must include the cause of the failure, the duration of the security failure, and details on the remediation that addresses the root cause. 

Changes to Requirement 11: Regularly Test Security Processes

pci compliance logging

Requirement 11 has remained the same with only three new requirements.

Requirement 11.3.1.1 – For any vulnerabilities in your vulnerability scans that aren’t categorized as high or critical risk, they must now be addressed on a periodic basis. The frequency must be defined in a targeted risk analysis. The purpose is to ensure that while lower-risk vulnerabilities aren’t a high priority, they must be addressed eventually. 

Requirement 11.3.1.2 – Authenticated vulnerability scanning is now a requirement. This means that the vulnerability scanner must now be able to log in to the systems it is scanning to perform more detailed checks. While unauthenticated (gray box) tests can still be valuable, you are getting more accurate findings through authenticated scanning as the scanner is now able to perform actual checks on the devices. The credentials used for the vulnerability scanner should be documented, the privileges must be sufficient for the scans, and the accounts must be managed according to Requirement 8.2.2.

Requirement 11.6.1 – In order to combat e-commerce skimming attacks, payment pages must now validate and alert personnel to unauthorized modifications of HTTP header and payment page contents that are received by the consumer browser. A CSP should be used to monitor these pages on a weekly (once every seven days) or a periodic basis, as defined by a targeted risk analysis. 

Changes to Requirement 12: Information Security Policy

Requirement 12’s focus has been targeted just towards policies and programs that support information security. There are 11 new requirements in Requirement 12, by far the most than in any other requirement. Remember, PCI DSS 4.0 has been defined to be more than just a point-in-time assessment but rather a continuous process. This happens through governance. These new requirements have been added to reinforce the continuous processes that we’ve seen in most of the new requirements.

Requirement 12.3.1 – As you’ve seen in many of the new requirements, this requirement compels you to perform targeted risk analysis for any requirement that provides flexibility in how it’s performed. You can find the targeted risk analysis template in Appendix E2 within the DSS.

Requirement 12.3.2 – For any requirement in which you chose a customized approach over the defined approach, you must also perform a targeted risk analysis for these requirements. This is new in PCI DSS 4.0. A custom approach is different from a compensating control. Custom approaches allow you to define how you meet the requirement as long as you can achieve the Customized Approach Objective in the requirement. In the absence of the direct approach method that allows for more flexibility, the Customized Approach will require more work to document. 

Requirement 12.3.3 – An inventory of all cryptographic cipher suites and protocols that are in scope must now be kept. The inventory must include the cipher suites and protocols in use, including the purpose and where they are used. Monitoring should be in place to ensure that any new known vulnerabilities on the cipher suites and protocols can be quickly addressed. 

Requirement 12.3.4 – The PCI DSS inventory has now been defined to include hardware and software technologies. The inventory must be reviewed and validated every 12 months. The inventory must be continually used to identify vulnerabilities that affect the inventory, end-of-life (EOL) identifications, and documented plans on how EOL devices will be addressed. 

Requirement 12.5.2 – The PCI scope must now be validated at least every 12 months or upon significant change to the in-scope environment. There are seven total bullet points in the requirement that this validation must include. This should be familiar, as this is the standard scoping exercise. What the PCI Security Standards Council found is that scoping was only being performed at its initial implementation. This revised requirement now codifies an annual validation.. 

Requirement 12.6.2 – In order to better keep employees knowledgeable about current security trends, the security awareness program must now be reviewed and updated once every 12 months to ensure currency. Content should be updated to include any new threats and vulnerabilities that may impact the security of your CDE. The end goal of the security awareness program is to ensure that personnel are aware of their roles in protecting cardholder data. 

Requirement 12.6.3.1 – Building upon 12.6.2, the training should also include threats and vulnerabilities that can directly affect the security of the CDE. This will include phishing and social engineering attacks as they are the most common. Personnel should be aware of how to detect, react to, and report potential phishing and social engineering attacks. 

Requirement 12.6.3.2 – To again expand on 12.6.2, the security training should also point out the responsibilities users have as defined in your acceptable use policy. 

Requirement 12.10.4.1 – Previously in version 3.2.1, training for incident response (IR) personnel had to occur annually. This new requirement allows you to define a period that works best for your organization. The period must be documented in a targeted risk analysis. 

Requirement 12.10.5 – There is one new bullet within Requirement 12.10.5 that includes change-and tamper-detection mechanisms for payment pages to be included in your IR plan. For all new requirements that focus on payment pages, there needs to be a plan to remediate threats when there is an issue in the payment page security. 

Requirement 12.10.7 – You are now required to have incident response procedures in place to react if PAN is detected anywhere that it is not expected to be. You will also need to have monitoring setup throughout your environment to check for PAN. Step 1 will involve defining where PAN is expected. From there you will need to develop plans on how you will detect it and have documented plans and procedures on how you will respond, according to the requirement. 

How Long Do You Have to Update to PCI DSS 4.0?

Although there are many changes, thankfully not all the new requirements are immediate. There are some requirements that are quick to implement however some will require planning. 

PCI DSS version 3.2.1 will remain active until Q1 2024. This means that for the next few years you can still continue to assess with 3.2.1. At this time, all new requirements will still be best practices until Q1 2025. In Q1 2025 all future dated new requirements will become requirements. 

Do not wait! Begin planning your transition to version 4.0 now. Ensure you are ready for this transition over the next 3 years. Perform a gap analysis on your organization to ensure that you are ready for the Q1 2025 date.

Getting a PCI 4 Gap Analysis

While there are several ways to go about this, the best method is to perform a side-by-side assessment with version 3.2.1 over the next few years. You can ask your PCI QSA to perform this or utilize an internal resource.

Essentially you will have your SAQ or ROC for version 3.2.1 but as you are requesting or gathering evidence, map the evidence to both 3.2.1 and 4.0 requirements. For all new requirements, have meetings with applicable personnel to discuss what processes they might already have in place that could satisfy the new requirements. During your assessment, request the evidence needed in the new 4.0 requirements and analyze it for gaps. 

Additionally, you could perform a standalone gap analysis outside of your assessment period. Depending on the size and complexity of your environment you can expect a gap analysis to take a few weeks and up to a month to complete. The pricing for this assessment will depend on the consulting firm, but will likely cost a few thousand dollars.

How Long Will it Take to Meet the New Standards?

There are a total of 64 new changes or requirements within PCI DSS 4.0 (including service provider requirements).

Including a gap analysis and implementing the new requirements into your environment, you can expect this process to take at least six months.

Naturally, this depends on the size and complexity of your environment, the amount of personnel you have in your organization, and how advanced you currently are in your security posture, namely if you already exceed security best practices. 

As mentioned previously, you will want to perform a gap analysis to identify any weak areas that need fortification. It would be best to engage a PCI QSA or, at a minimum, a PCIP to ensure that you have the gaps filled in for version 4.0. It’s best to involve your current PCI QSA in the process if you utilize a QSA for your assessments. Ultimately the evidence will be up to the QSA or ISA (internal to your organization) to decide if the controls in place satisfy the requirements.

To summarize the process, follow these seven steps.

  1. Engage Your QSA, Internal ISA, or An External PCIP
  2. Perform a Gap Analysis
  3. Remediate Your Gaps
  4. Test Your Controls
  5. Note Customized Approaches
  6. Perform All Targeted Risk Analyses
  7. Perform a PCI DSS 4.0 Assessment

For a more detailed timeline for how long PCI certification can take, see this article.

Tips For Effectively Updating to PCI DSS 4.0

While the transition to PCI 4.0 can seem daunting, here are seven tips to get ready for PCI 4.0.

  1. Don’t Assume, Assess

The worst thing you can do is assume that you are compliant; you need to know. Read through the PCI DSS 4.0 document and identify what you know. You will want to perform a theoretical assessment without actually gathering evidence first. See what you don’t have, what you partially have, and what you have in place already. 

  1. Modify and Update Your PCI Governance (Point-in-Time vs. Continuous)

Targeted risk analyses, RACI charts, and overall information security governance need to be continuous. Ensure that you identify all requirements that now require either a defined timeline or a periodic timeline (that you define). Bake these processes into policies and procedures so they can be enforced. Create your RACI chart, distribute it to the stakeholders, and ensure that they understand and acknowledge their responsibilities. 

  1. Identify Your Organization’s Risks

For either the customized approach or the targeted risk analyses, PCI 4.0 focuses heavily on risk. Risk is not the same across even two organizations. The requirements and the overall PCI DSS reporting are focused on you defining your various risks. Knowing your risks helps you to better protect your organization. 

  1. Consult Externally

Consult with either a QSA or PCIP to perform your PCI 4.0 gap analysis. They can help you to identify what you may already be, partially be, or be out of compliance with. Use their report to guide you with the next tip. 

  1. Consult Internally

Consult your internal teams, stakeholders, and SMEs to identify how you must practically implement the gaps and requirements as noted by the external consultant or QSA. Have a documented project or plan in place and include all the teams that need to be involved.

  1. Involve Stakeholders

Involve all PCI Stakeholders as outlined in your PCI governance policy. This can include information security, IT, legal, executive leaders (C-suite), and others. Make sure they are aware of your organization’s path to compliance with PCI 4.0. Ensure that they are involved in the process, aware of the timeline/progress and that they are willing to remove any potential roadblocks in the future. 

  1. Assign Ownership

Every step in your process should have a name attached to it. Define and provide that ownership to the applicable individuals to ensure that the work is being completed. 


Published by Noah Stahl PCI ISA
Noah Stahl is a PCI Internal Security Assessor and experienced consultant, having conducted PCI assessments for small businesses to Fortune 500 companies....
    
Copyright © 2022 Network Assured