Skip to main content

Which PCI Requirements Are Hardest to Achieve For Companies?

Think of PCI compliance like it’s the health of your company.

If you read our last blog, you now have a solid grasp of the PCI compliance basics and why your company should be compliant. It’s time to dive deeper into which requirements and sub-requirements are the most time-consuming to achieve.

Keep in mind that maintaining PCI compliance is an ongoing initiative. Think of it like you’re monitoring the health of your company’s payment security, brand, and reputation. Just like you need to keep up with your health through regular checkups with your doctors, eating well, and staying active, you need to have a similar mindset for your business.

So what’s the best way to approach attaining and maintaining PCI-DSS?

Start with looking at the size of your organization and the state of your technology. Depending on these factors, there will be some PCI requirements that are more challenging to implement than others.

This post comes from our guide A Definitive Guide to PCI Compliance that you can view on our site.

Here are 7 requirements, sub-requirements, and procedures that are the most difficult to achieve and some tips on how your company can prioritize each one.

Requirement 2.4: Maintain an inventory of system components that are in scope for PCI-DSS.

This PCI sub-requirement requires every organization to document and maintain a detailed list of all their assets involved in the process of payment card processing to ensure that each asset receives all the protection required for it to meet configuration standards.

Maintaining this inventory is important because the PCI-DSS requirements apply to all systems within the organization’s PCI-DSS scope (which is defined according to the PCI-DSS scoping guidance document as all people, processes, and technologies that interact with or could otherwise impact the security of cardholder data) and there is a risk of having systems which are within the PCI scope that are unaccounted for, and therefore unprotected. 

To ensure that your asset inventory document is complete and accurate, it’s important to maintain asset management policies and procedures and distribute them to the personnel responsible for maintaining the inventory. Also, automated processes such as network discovery scans will help ensure that all assets are discovered, accounted for, and secured using the organization’s configuration standards. Supporting documentation such as network diagrams may also be used to verify the accuracy of the asset inventory. 

Requirement 3: Protect stored cardholder data.

This PCI requirement requires every organization that stores cardholder data to put in place several controls to ensure that this data is stored securely and not disclosed to unauthorized parties. This doesn’t only include methods for protecting stored cardholder data such as hashing, encryption, truncation, masking, and tokenization, but also data retention policies, cardholder data flows (to ensure that all systems that interact with cardholder data are accounted for), and key management policies and procedures to ensure that the keys used to encrypt cardholder data are handled and stored as securely as possible and accessed by a few key custodians as possible.

This requirement also defines which parts of cardholder data can be stored after authorization (such as cardholder name, Primary Account Number (PAN)/Credit card number, card brand, expiration date, etc) and which parts cannot (full track data, PIN data and the 3-digit card verification code/value on the back of the card) be stored unless the organization performs, facilitates or supports card issuing services or has a legitimate business need to store that data. Also, masking must be implemented to ensure that no more than the first six and last four digits of a PAN is visible unless there’s a legitimate business need to view the full PAN.

To achieve compliance with this requirement, an organization must identify all systems that interact with cardholder data, ensure that cardholder data is only stored in authorized and secured storage locations, and that it doesn’t exist in locations such as system logs and end-user messaging tools. This can be verified using a PAN discovery scanner or detected manually. Cardholder data must also be deleted periodically and securely when it’s no longer needed in line with the documented data retention policy. A good rule of thumb is to never store cardholder data unless it is required. Lastly, key management policies and procedures must be documented, maintained, and disseminated to key custodians to ensure that that the cardholder data as well as the encryption keys are protected from disclosure and misuse. All individuals who have access to cardholder data and the encryption keys used to protect them must be documented. 

Requirement 6.2: Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches.

This PCI sub-requirement requires every system within the PCI scope to be protected from known vulnerabilities by installing critical or urgent patches within a month of release. All other security patches may be installed within a reasonable time frame of up to three months from release. This requirement also requires policies and procedures for the patch management process to be created, documented, and approved by management. 

Depending on the size of your organization, it may be difficult to detect the missing patches for the operating systems and installed software on your critical infrastructure. However, patch management solutions can be used to automatically detect and install selected patches. 

A good practice would be to patch applicable systems in phases after they have been verified in a testing or staging environment. It’s also recommended to carry out reboots in phases (if required by your operating system after patching) to ensure as little downtime disruption as possible. 

Requirement 6.5: Address common coding vulnerabilities in software-development processes.

This PCI sub-requirement requires every organization that develops custom software to ensure that all software released is developed securely (i.e. with security incorporated in each phase of the software development lifecycle) and free from the most common coding vulnerabilities. This can be challenging for your organization since it requires every software developer to receive and complete training on up-to-date secure coding techniques at least annually to ensure that application developers have the necessary skills to avoid common coding vulnerabilities. 

This can be challenging for your organization since it requires every software developer to receive and complete training on up-to-date secure coding techniques at least annually to ensure that application developers have the necessary skills to avoid common coding vulnerabilities. 

This secure coding training can be developed in-house or provided by a third party. It is also important to note that the list of common coding vulnerabilities identified in the PCI requirements is a minimum baseline and it is the responsibility of the organization to remain up to date with vulnerability trends and include measures against the threats in its secure coding training and practices. 

A good practice to ensure compliance with this requirement would be to have static and dynamic application security testing take place early and often during the software development lifecycle to complement the secure coding training and prevent common coding vulnerabilities from being introduced into production builds of your organization’s software. 

Requirement 10: Track and monitor all access to network resources and cardholder data processes.

This PCI requirement requires every organization to ensure that all user activity that leads to cardholder data being accessed is logged and monitored. This includes not only ensuring the completeness and accuracy of the security and/or event logs, but it’s ensuring that they’re protected from tampering and only viewed by authorized users.

To achieve this, all logs must be automatically generated and detailed enough (including details such as username, event, time and date of the event, affected resource, etc) to link all access to individual accounts, including and especially privileged accounts. An activity like invalid login access, changes to privileged accounts (including privilege escalation), changes to logging (including pausing, stopping, deletion, etc), and changes to system-level objects. Logs must also be backed up centrally and reviewed periodically, with documented policies and procedures defining the periodic (at least daily) review of security events and the subsequent follow-ups and investigations as a result of the reviews if exceptions and anomalies are detected.

The procurement of a Security Information and Events Management (SIEM) solution will be extremely beneficial to any organization that seeks to pass this requirement. When configured properly, the SIEM can be used to automatically collect and analyze logs from various systems and then store these logs centrally where they can be accessed and analyzed frequently by the responsible personnel. It can also be used to notify users of events and alerts and play a role in preventing or responding to incidents.

A SIEM is a very useful tool to ensure that critical systems interacting with cardholder data (as long as they send over complete and accurate logs) are properly monitored for threats and aids the investigation and incident response processes greatly. 

Requirement 11: Regularly test security systems and processes.

This PCI requirement requires every organization to test all systems and processes for vulnerabilities, as well as remediate all found vulnerabilities and exploits as soon as possible. It also outlines the need to have solutions in places such as intrusion detection systems (IDS) or intrusion prevention systems (IPS) and a file integrity monitoring (FIM) tools to prevent breaches as well as documented policies and procedures guiding all of the above. Lastly, a process to detect and identify unauthorized wireless access points has to be created to ensure the security of your network and other infrastructure.

Passing this requirement can be a bit challenging depending on the resources available to your organization. It is important to use a rogue access point detection solution at least quarterly to ensure that there are no unauthorized wireless access points in your network which can lead to a breach. Internal and external vulnerability scanning schedules must be implemented and documented (preferably monthly), and an ASV must be used to carry out the external scanning. In both cases, all vulnerabilities must be remediated, with rescans carried out until a passing scan is achieved quarterly.

Internal and external penetration testing must be carried out with an industry-accepted methodology and by qualified personnel (a qualified internal resource can carry out internal testing, or a qualified external third party can carry out both the internal and external penetration testing) at least annually. All exploits found during penetration testing must be resolved as soon as possible, and the penetration test is not considered successful until a rescan is carried out to ensure remediation. Service providers will also have to carry out penetration testing on segmentation controls every six months. Lastly, the IDS/IPS and FIM solutions must be implemented and configured properly and monitored per PCI requirement 10. 

Requirement 12: Maintain a policy that addresses information security for all personnel.

The last of the 12 PCI requirements is the least technical and is centered around the creation, implementation, maintenance, and dissemination of security policies and procedures to employees to ensure that they’re aware of their security responsibilities. This includes third parties such as contractors, vendors, and business partners, if applicable. It outlines the security policies and procedures that every organization seeking PCI compliance must establish and review at least annually. 

To pass this requirement, each organization must create policies and procedures including but not limited to the following:


Maintaining PCI compliance can feel overwhelming, but with proper planning, it doesn’t have to feel that way. PCI compliance looks different for each company depending on the size and technology, so start with identifying the requirements and/or sub-requirements that will require more time and investment. From there, your company can develop an actionable plan broken down into small increments to help reach those requirements. While PCI compliance does fall under the IT team’s responsibilities, everyone at your company plays a part in helping to achieve and maintain compliance.  

Interested in learning more? Check out A Definitive Guide to PCI Compliance.