What is PCI Compliance? 12 Requirements and More Explained


Overview of PCI compliance

PCI compliance is adherence to the set of policies and procedures developed to protect credit, debit and cash card transactions and prevent the misuse of cardholders’ personal information. All card brands require compliance with the Payment Card Industry Data Security Standard (PCI DSS).

The Payment Card Industry Security Standards Council (PCI SSC) develops and manages the PCI standards and associated education and awareness efforts. The PCI SSC is an open global forum. Its five founding credit card companies — American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa — are responsible for carrying out the organization’s work.

Organizations complying with PCI DSS must meet 12 requirements, covering the use of firewalls, encryption, antivirus software, network monitoring and access controls.

PCI compliance is meant to ensure the security of all aspects of the credit card ecosystem, including wireless hotspots, e-commerce applications, point of sale systems, mobile devices, computers and servers. It also protects cardholder data from data breaches as it moves across the network and is transmitted to and from service providers. This includes security around paper records as well.

12 requirements for PCI compliance

Organizations complying with PCI DSS must meet the following 12 requirements:

  1. Install and maintain a firewall configuration to protect cardholder data. PCI DSS requires proper firewall configuration, including strong passwords and access controls. It also mandates a testing program when configurations change. Traffic must be blocked to and from untrusted networks, and personal firewalls are required for all devices that access cardholder data.
  2. Don’t use vendor-supplied defaults for system passwords and other security parameters. All default passwords must be replaced with strong passwords before a new device that can connect to cardholder data online.
  3. Protect stored cardholder data. Cardholder data should be kept only as long as it’s needed. PCI DSS data retention policies call for purging unneeded data at least once a quarter.
  4. Encrypt transmission of cardholder data across open, public networks. PCI compliance requires strong cryptography for cardholder data. Encryption must be used when sensitive data is transmitted over public networks, such as the internet, cellular networks, satellite communications and wireless technologies.
  5. Use and regularly update antivirus software. Antivirus and antimalware software are standard components of most defense in depth strategies. PCI compliance requires organizations to use strong, regularly updated antivirus software to protect all systems that may be in contact with cardholder data.
  6. Develop and maintain secure systems and applications. PCI DSS regulations require enterprises to update and install all relevant patches for critical systems as soon as possible. They also must have a process for finding and identifying security vulnerabilities and ranking them in order of priority. For internally built apps, software programmers should be trained in secure coding techniques and make security part of the entire software development lifecycle.
  7. Restrict access to cardholder data by business need to know. PCI DSS requires that the principle of least privilege be used to determine access. That’s a concept that gives access to data only to those who need it and for only as long as they need it. Access should be based on a person’s responsibilities and need to know.
  8. Assign a unique ID to each person with computer access. Once least privilege access is defined, individuals should be given unique identifications that correspond to their data access rights. This provides access privileges and tracks who accessed what data.
  9. Restrict physical access to cardholder data. Physical access to cardholder data must be as carefully managed as network access, according to PCI DSS. Only approved personnel should have access to devices that hold cardholder data or paper copies of that data. Access to equipment, files and the premises should be controlled with badges, key cards and other types of identification systems, such as biometrics.
  10. Track and monitor all access to network resources and cardholder data. PCI compliant organizations must be able to monitor and track network access. This is critical to understanding how a security breach occurred and defending against cybersecurity attacks in the future. Maintaining systems activity logs gives companies an audit trail that show suspicious activity and how it occurred across linked system components.
  11. Regularly test security systems and processes. IT systems are subject to frequent change, which means that testing of components and applications must keep pace with system changes. Testing includes vulnerability audits or scans done quarterly or more frequently as well as penetration testing with automated pen testing tools.
  12. Maintain a policy that addresses information security. Security policies are essential to achieving PCI compliance. Companies must carefully develop and execute their PCI DSS security policies in a disciplined way. PCI DSS security policies must also evolve to adapt to changing security threats and should be updated at least once a year. Part of this process is an annual risk assessment process that identifies critical assets, including new applications and gear, as well as new threats and vulnerabilities.

What is cardholder data?

Cardholder data is any personally identifiable information associated with a person who has a credit or debit card. Cardholder data is often stored when a cardholder and merchant do a transaction with the cardholder’s card.

Cardholder data also includes the person’s primary account number along with additional data, such as their credit card number; name; card expiration date; and service code, which is a three- or four-digit number on cards that use magnetic stripes.

If the cardholder’s name, expiration date or service code are stored, processed or transmitted with the primary account number, that data must be protected under PCI compliance regulations. PCI compliance requires merchants regularly purge their data of cardholder information that isn’t required for day-to-day functioning.

PCI DSS versions

Since its development in 2006, there have been four full versions of PCI DSS:

  • PCI DSS 1.0. The first version of the PCI DSS guidelines were released in 2004. It included the original 12 PCI DSS requirements, as well as a strong emphasis on maintaining security policies and procedures, such as regular audits and reporting.
  • PCI DSS 2.0. The second full version of PCI DSS was released in 2011. According to the PCI Security Standards Council, version 2.0 included minor language adjustments to clarify the meaning of the 12 requirements. It also reinforced the need for thorough scoping before an assessment and promoted more effective log management. It broadened validation requirements for the assessment of vulnerabilities in a merchant environment.
  • PCI DSS 3.0. The third major iteration of the standard was released in 2013. It included new requirements for the use of methodology-based penetration testing to verify proper segmentation of the merchant cardholder data environment (CDE) from other IT infrastructures. Other new requirements included an inventory of all hardware and software components within the CDE, and documentation detailing requirements that third-party vendors could manage. PCI DSS 3.0 also outlined new malware detection and remediation standards, as well as strong access control measures for on-site personnel and methods to protect payment data-capture technologies.
  • PCI DSS 4.0. The most recent PCI DSS update was in March 2022. PCI DSS 4.0 included updates to multifactor authentication and password requirements, and it added new phishing and e-commerce standards. It also requires organizations to assign roles and responsibilities for each of its requirements. And in response to changes in payment technology, 4.0 added requirements that increased flexibility and customization for organizations that use multiple methods to achieve security. Organizations will have until March 2025 to become compliant with 4.0’s requirements.
PCI DSS history timeline
The PCI DSS framework began in the 1990s, though it wasn’t officially established until 2004.

Mobile Payment Acceptance Security Guidelines

In 2013, PCI SSC published “PCI Mobile Payment Acceptance Security Guidelines for Merchants as End-Users” to educate merchants on the risks associated with credit card data transferred via mobile devices, such as smartphones and tablets. The guidance outlined the major risks associated with mobile payment transactions, including account data entering the device, residing in the device and leaving the device.

The guidelines also provided recommendations for how merchants should secure mobile devices used for payment acceptance and how to secure payment acceptance system hardware and software. The PCI SSC noted that until mobile hardware and software implementations could meet the guidelines, the best option for merchants was to use PCI-validated point-to-point encryption.

In 2017, the PCI SSC updated the guidelines to reflect the change in mobile technology and digital payments. These guidelines emphasized access controls, malware protection and the proper handling of phones, such as securing them when not in use and proper disposal. In 2022, these standards were updated to include requirements around new channels of payments, such as Zelle and Venmo.

Merchant levels

The payment card industry uses merchant levels to determine risk and ascertain the appropriate level of security for their businesses. Merchant levels determine the amount of assessment and security validation required for the merchant to pass a PCI DSS assessment. There are four categories of merchant PCI compliance levels. They are based on the number of transactions the merchant handles annually. The four levels are the following:

  • Level 1. Merchants process over 6 million transactions a year across all channels and are typically multinational corporations or organizations with substantial volumes of transactions. Level 1 merchants must undergo a PCI assessment performed by a Qualified Security Assessor (QSA) who issues a Report on Compliance that verifies the business’s PCI DSS compliance. The ROC is sent to the business’s acquiring bank, which then sends it to the appropriate credit card company for verification.
  • Level 2. Merchants are typically medium-sized organizations that process between more than 1 million and up to and including 6 million transactions a year across all channels. These merchants are required to complete a Self-Assessment Questionnaire (SAQ) annually and may have to submit quarterly audits by an Approved Scanning Vendor (ASV).
  • Level 3. Merchants are smaller businesses than process more than 20,000 and up to and including 1 million annual transactions. Level 3 merchants are also required to complete an SAQ and might have to undergo quarterly network audits.
  • Level 4. Merchants are the smallest merchants and process 20,000 or fewer annual transactions. This includes businesses such as restaurants, local stores and e-commerce startups. Like Level 3 merchants, Level 4 merchants must complete an annual SAQ and might have to conduct quarterly network audits.
PCI DSS compliance levels image
There are four PCI DSS compliance levels that determine the security standards an organization must meet.

Is PCI compliance legally required?

PCI DSS is not legally mandated by the government. Instead it’s a contractual requirement set forth in agreements between businesses and merchant service providers or payment service providers, such as Square. The payment brands and merchants are responsible for enforcing compliance, not the PCI SSC. To ensure compliance, companies often follow best practices not stipulated by PCI DSS.

PCI DSS requirements are generally the same across providers, though implementation does vary. Noncompliance can result in penalties, including fines and loss of the ability to process debit, cash card and credit card transactions.

Penalties and consequences for noncompliance

Failure to comply with PCI DSS can have significant consequences for businesses. Noncompliant organizations may face fines ranging from tens of thousands to millions of dollars depending on the severity of the violation and the resulting damage. Fines are capped at half a million dollars per incident.

Noncompliance also can lead to data breaches and compromises that harm a business’s reputation, leading to a loss of customer trust. In some cases, noncompliant organizations may even lose their ability to process card payments altogether.

PCI audits and QSAs

A QSA is a data security firm the PCI SSC trained and certified to perform on-site security assessments to verify PCI DSS compliance. A PCI assessment is an audit for validating PCI DSS compliance. During the assessment, the QSA determines whether the merchant has met the PCI DSS’s 12 requirements, either directly or through a control that provides an equivalent level of defense.

Vulnerability scanning is also a common part of a PCI DSS compliance audit. An ASV conducts these scans. ASVs are service providers that the PCI SSC has certified and authorized to scan payment card networks for compliance.

New best practices for PCI DSS compliance

Some best practices for PCI DSS compliance are changing with the release of PCI DSS 4.0, which addresses the advent of new payment methods such as Zelle and Venmo. These best practices include the following:

  • Obtain and review the new PCI DSS 4.0 carefully, paying attention to updates to the 12 requirements.
  • Organize a project team to complete PCI DSS 4.0 compliance.
  • Compete a self-assessment questionnaire to gauge how the organization does against new compliance standards.
  • Consider using vendor tools to ensure compliance and qualified third parties to confirm compliance.

Learn more about the 10 best practices for complying with the new PCI DSS 4.0.



Source link