• PCI compliance is the level of data security a business needs to meet Payment Card Industry requirements.
  • Any business that handles cardholder data and related sensitive information must meet PCI compliance requirements.
  • PCI compliance helps ensure your payment systems are secure, thus reducing fraud.
  • The PCI DSS is an evolving set of requirements that adapts to hackers’ changing strategies for gaining unauthorized access to computer systems.

As credit cards continue to be the popular choice for in-person and online transactions, protecting customer information from unauthorized access is an important priority. Businesses would have a hard time keeping up with the growing sophistication hackers are using to steal sensitive data on their own. That is why the role of the Payment Card Industry Security Standards Council (PCI SSC) in keeping businesses safe is important as we move closer to a cashless economy. 

What is PCI compliance? 

PCI compliance is a standard of operation that certifies a business’s readiness to protect credit card and cardholder information during transactions. A business is PCI-compliant when it meets the criteria set by the PCI SSC, known as the Payment Card Industry Data Security Standard (PCI DSS). 

PCI DSS aims to protect account data, which includes:

  • Cardholder data:
    • Primary Account Number (PAN)
    • Cardholder Name 
    • Expiration Date
    • Service Code 
  • Sensitive authentication data
    • Full track data (magnetic-stripe data or equivalent on a chip) 
    • Card verification code 
    • PINs/PIN blocks 

PCI DSS summary

PCI DSS has six main goals that businesses must comply with by meeting 12 requirements. The PCI SSC monitors the evolving threats to business security and updates these requirements accordingly on a regular basis. Any business with access to credit card and cardholder data should be in PCI compliance.

Below outlines version 4.0.1 of the 12 PCI requirements released in June 2024:

Objectives

Requirements

Build and maintain a secure network and systems

  • Install and maintain network security controls
  • Apply secure configuration to all system components

Protect account data

  • Protect stored account data
  • Protect cardholder data with strong cryptography during transmission over open, public networks

Maintain a vulnerability management program

  • Protect all systems and networks from malicious software
  • Develop and maintain secure systems and software

Implement strong access control measures

  • Restrict access to system components and cardholder data by business need-to-know
  • Identify users and authenticate access to system components
  • Restrict physical access to cardholder data

Regularly monitor and test networks

  • Log and monitor all access to system components and cardholder data
  • Test security of systems and networks regularly

Maintain an information security policy

  • Support information security with organizational policies and programs

History behind PCI compliance 

The launch of the World Wide Web in the 1990s allowed e-commerce to grow exponentially and enabled the ability to use credit cards to pay for online purchases. Amazon went online in 1995, followed by Confinity in 1998, now widely known as PayPal. 

However, as customer shopping convenience grew, so did credit card fraud. Card networks reported as much as $750 million in credit card fraud losses by 1999. As a result, MasterCard introduced its Site Data Protection (SDP) program to address the vulnerabilities in business computer systems used to process credit card transactions. 

In 2000, Visa launched its Cardholder Information Security Program (CISP) and Account Information Security (AIS) program. Soon after, other card brands followed. Discover launched the Discover Information Security & Compliance (DISC) program while JCB introduced its own measures, simply named Data Security Program.

In 2004, Visa developed the foundation of the PCI DSS guidelines (six objectives and 12 requirements) from its original data security program, now referred to as version 1.0. American Express, Discover, JCB International, and MasterCard then updated their program to align with version 1.0 and, in 2006, collectively founded the Payment Card Industry Security Standards Council (PCI SSC) and launched PCI DSS version 1.1

Since then, 10 PCI DSS updates have been released, culminating in version 4.0, implemented in March of this year. In June, another update, version 4.0.1, was released to address feedback and questions about version 4.0. 

Read more: How to accept payments online

Requirements for PCI compliance 

Below are the six main objectives and 12-point PCI DSS requirements for meeting PCI compliance. The checklists under every requirement are the guidelines found in the official PCI DSS testing procedures documentation. 

Build and maintain a secure network and systems

Businesses are expected to create and maintain a secure computer network for both hardware and software systems that access cardholder data when processing credit card transactions. A secure network will have a firewall, passwords, and other technology that monitors and regulates information flowing in and out of the computer network.

1. Install and maintain network security controls

  • Processes and mechanisms for installing and maintaining network security controls are defined and understood. 
  • Network security controls (NSCs) are configured and maintained. 
  • Network access to and from the cardholder data environment is restricted.  
  • Network connections between trusted and untrusted networks are controlled. 
  • Risks to the cardholder data environment (CDE) from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.

2. Apply secure configuration to all system components

  • Processes and mechanisms for applying secure configurations to all system components are defined and understood. 
  • System components are configured and managed securely. 
  • Wireless environments are configured and managed securely.

Protect account data

A PCI-compliant network masks data when processing credit card transactions with encryption and/or tokenization tools. It also limits the storage of sensitive information and secures information with layers of validation and tracking protocols.  

In payment processing, the responsibility of PCI compliance passes, in part, to the payment service provider. Businesses must do due diligence to ensure that they work with a level 1 PCI-compliant payment processor. 

Related: Best payment gateways

3. Protect stored account data

  • Processes and mechanisms for protecting stored account data are defined and understood. 
  • Storage of account data is kept to a minimum. 
  • Sensitive authentication data (SAD) is not stored after authorization.  
  • Access to displays of full PAN and ability to copy PAN are restricted. 
  • Primary account number (PAN) is secured wherever it is stored. 
  • Cryptographic keys used to protect stored account data are secured. 
  • Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.

4. Protect cardholder data with strong cryptography during transmission over open, public networks

  • Processes and mechanisms for protecting cardholder data with strong cryptography during transmission over open, public networks are defined and understood. 
  • PAN is protected with strong cryptography during transmission.

Related: Best healthcare payment processors

Maintain a vulnerability management program

Malicious software is the primary external threat to a computer network. PCI-compliant systems should have measures in place to scan, identify, isolate, and remove these programs. The business will regularly scan its network and check for virus protection software updates. These scans should cover every potential channel where malicious software can originate, such as company emails and vendor software integrations. 

5. Protect all systems and networks from malicious software

  • Processes and mechanisms for protecting all systems and networks from malicious software are defined and understood. 
  • Malicious software (malware) is prevented or detected and addressed. 
  • Anti-malware mechanisms and processes are active, maintained, and monitored. 
  • Anti-phishing mechanisms protect users against phishing attacks. 

6. Develop and maintain secure systems and software

  • Processes and mechanisms for developing and maintaining secure systems and software are defined and understood. 
  • Bespoke and custom software are developed securely.  
  • Security vulnerabilities are identified and addressed. 
  • Public-facing web applications are protected against attacks. 
  • Changes to all system components are managed securely. 

Implement strong access control measures

To effectively protect cardholder data, access to payment information should be highly regulated. PCI compliance requires that only employees needing credit card information to perform their everyday responsibilities should be given access. There should also be a combination of secure log-ins that are constantly monitored and a system to immediately identify and lock down unauthorized users. CVV should not be included in the stored data. 

7. Restrict access to system components and cardholder data by business need-to-know

  • Processes and mechanisms for restricting access to system components and cardholder data by business need-to-know are defined and understood. 
  • Access to system components and data is appropriately defined and assigned. 
  • Access to system components and data is managed via an access control system(s). 

8. Identify users and authenticate access to system components

  • Processes and mechanisms for identifying users and authenticating access to system components are defined and understood. 
  • User identification and related accounts for users and administrators are strictly managed throughout an account’s lifecycle. 
  • Strong authentication for users and administrators is established and managed. 
  • Multi-factor authentication (MFA) is implemented to secure access into the CDE.
  • Multi-factor authentication (MFA) systems are configured to prevent misuse. 
  • Use of application and system accounts and associated authentication factors is strictly managed. 

9. Restrict physical access to cardholder data

  • Processes and mechanisms for restricting physical access to cardholder data are defined and understood. 
  • Physical access controls manage entry into facilities and systems containing cardholder data. 
  • Physical access for personnel and visitors is authorized and managed. 
  • Media with cardholder data is securely stored, accessed, distributed, and destroyed. 
  • Point of interaction (POI) devices are protected from tampering and unauthorized substitution. 

Related: Best virtual terminals

Regularly monitor and test networks

The entire business computer system should be equipped with logging mechanisms. Every individual — employee or otherwise — with access to the system should be required to identify themselves with login credentials. Multiple authentication protocols should be in place. Profiles should be created for users, and login and logouts should be recorded. Regularly test log-in and access security using a variety of known hacker strategies to identify any weakness in the network. 

10. Log and monitor all access to system components and cardholder data

  • Processes and mechanisms for logging and monitoring all access to system components and cardholder data are defined and understood.  
  • Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events. 
  • Audit logs are protected from destruction and unauthorized modifications. 
  • Audit logs are reviewed to identify anomalies or suspicious activity. 
  • Audit log history is retained and available for analysis. 
  • Time-synchronization mechanisms support consistent time settings across all systems. 
  • Failures of critical security control systems are detected, reported, and responded to promptly. 

11. Test security of systems and networks regularly

  • Processes and mechanisms for regularly testing security of systems and networks are defined and understood. 
  • Wireless access points are identified and monitored, and unauthorized wireless access points are addressed. 
  • External and internal vulnerabilities are regularly identified, prioritized, and addressed. 
  • External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected. 
  • Network intrusions and unexpected file changes are detected and responded to. 
  • Unauthorized changes on payment pages are detected and responded to. 

Maintain an information security policy

Finally, all security procedures should be fully documented and incorporated into organization policies. This includes establishing protocols to initiate regular PCI DSS certification, adding system security rules into the employee handbook, and conducting training for both old and new members. The business should also keep a record of its PCI DSS certification activities, logging identified vulnerabilities and actions implemented to resolve the issues. 

12. Support information security with organizational policies and programs

  • A comprehensive information security policy that governs and provides direction for the protection of the entity’s information assets is known and current.  
  • Acceptable use policies for end-user technologies are defined and implemented.  
  • Risks to the cardholder data environment are formally identified, evaluated, and managed. 
  • PCI DSS compliance is managed. 
  • PCI DSS scope is documented and validated. 
  • Security awareness education is an ongoing activity. 
  • Personnel are screened to reduce risks from insider threats. 
  • Risk to information assets associated with third-party service provider (TPSP) relationships is managed. Third-party service providers (TPSPs) support their customers’ PCI DSS compliance. Suspected and confirmed security incidents that could impact the CDE are responded to immediately. 

Related: Recurring payments 

How to become PCI compliant 

Below are the general steps for PCI DSS certification and compliance:

Step 1: Identify your PCI level

The PCI levels refer to the standard of security expected based on the business’ annual processing volume. 

  • PCI Level 1: For businesses processing over 6 million transactions per year
  • PCI Level 2: For businesses processing 1 to 6 million transactions per year
  • PCI Level 3: For businesses processing 20,000 to 1 million transactions per year
  • PCI Level 4: For businesses processing below 20,000 transactions per year

Note that there are situations where the requirement level is increased regardless of the transaction volume, such as for businesses that are classified as high-risk.

Step 2: Confirm the scope of the PCI DSS assessment

In preparation for the assessment, businesses should review their computer network and then identify and document all the systems, hardware, and software involved in the flow of cardholder and other sensitive data. This includes:

  • All payment stages 
  • Software and physical storage
  • Transaction processing flow
  • File backups
  • Segmentation controls
  • Third-party connections 

The documentation should include the security measures already in place in all the identified areas. Scope analysis should be performed annually and documented for reference for the next round of assessment.

Step 3: Complete your vulnerability scans

Under PCI DSS requirement 11, businesses that use internet-facing systems, such as web servers, may be required by the card network or merchant bank to submit quarterly vulnerability scans. These are external tests conducted on the business’ network firewall on a quarterly basis to confirm that the system is secure, which will result in either a “pass” or “fail.” If so, you will need to hire one of the PCI SSC’s approved scan vendors (ASV) listed on their website. 

Businesses that will be required to use the following SAQs (listed in Step 4) will have to submit vulnerability scans:

  • A
  • A-EP
  • B-IP
  • C
  • D for merchants
  • D for Service Providers 

It’s important to choose an ASV that will not only perform the right vulnerability scan for your business type, but will also help you fix any weakness in your network firewall. Note that 4 passing results are not required for businesses conducting their PCI DSS assessment for the first-time. 

Step 4: Complete the PCI self-assessment questionnaire (SAQ)

This is a requirement for businesses with small to midsize volume transactions, which usually fall under PCI levels 2, 3, and 4. 

Please note: Companies that fall under level 1 category will require a third-party auditor or qualified security assessor (QSA) firm to conduct a Report of Compliance (RoC) in lieu of an SAQ. 

Refer to the table below for the appropriate SAQ document based on your business type. Once you have identified this, download the SAQ document to start the questionnaire.  

SAQ

Description

A

Card-not-present merchants (e-commerce or mail/telephone-order) that completely outsource all account data functions to PCI DSS validated and compliant third parties. No electronic storage, processing, or transmission of account data on their systems or premises.  

Not applicable to face-to-face channels. Not applicable to service providers.

A-EP

E-commerce merchants that partially outsource payment processing to PCI DSS validated and compliant third parties, and with a website(s) that does not itself receive account data but which does affect the security of the payment transaction and/or the integrity of the page that accepts the customer’s account data. No electronic storage, processing, or transmission of account data on the merchant’s systems or premises.  

Applicable only to e-commerce channels. Not applicable to service providers

B

Merchants using only:  

  • Imprint machines with no electronic account data storage, and/or  
  • Standalone, dial-out terminals with no electronic account data storage. 

Not applicable to e-commerce channels. Not applicable to service providers.

B-IP

Merchants using only standalone, PCI-listed approved PIN Transaction Security (PTS) point-of-interaction (POI) devices with an IP connection to the payment processor. No electronic account data storage. 

Not applicable to e-commerce channels. Not applicable to service providers.

C-VT

Merchants that manually enter payment account data a single transaction at a time via a keyboard into a PCI DSS validated and compliant third-party virtual payment terminal solution, with an isolated computing device and a securely connected web browser. No electronic account data storage. 

Not applicable to e-commerce channels. Not applicable to service providers.

C

Merchants with payment application systems connected to the Internet, no electronic account data storage.  

Not applicable to e-commerce channels. Not applicable to service providers.

P2PE

Merchants using only a validated, PCI-listed Point-to-Point Encryption (P2PE) solution. No access to clear-text account data and no electronic account data storage. 

Not applicable to e-commerce channels. Not applicable to service providers.

SPoC

Merchants using a commercial off-the-shelf mobile device (for example, a phone or tablet) with a secure card reader included on PCI SSC’s list of validated SPoC Solutions. No access to clear-text account data and no electronic account data storage. 

Not applicable to unattended card-present, mail-order/telephone order (MOTO), or ecommerce channels. Not applicable to service providers.

D (merchants)

All merchants not included in descriptions for the above SAQ types.  

Not applicable to service providers.

D (service providers)

All service providers defined by a payment brand as eligible to complete an SAQ.

There are three sections in the SAQ:

  • Completing the self-assessment questionnaire: Includes eligibility criteria, Self-Assessment Completion Steps, Expected Testing activities, Requirement Responses options, Guidance for Not Applicable Requirements, use of Legal Exception, and Additional PCI SSC Resources.
  • Attestation of Compliance: (Section 1 & 3) Includes Assessment Information and Attestation and Validation Details. 
  • PCI DSS requirements: (Section 2) Includes the applicable PCI DSS requirements for the environment identified in the SAQ eligibility criteria, along with a place for the entity to record responses for each requirement.  
Executive summary section of the SAQ with table that has a row each of the 12 requirements and a column for each possible test result.
Summary of Assessment page in the SAQ (Source: PCI SSC)
Validation and Attestation Details Page with a table to choose a result of the security assessment as "Compliant" "Non-Compliant" or "Compliant but with Legal exception".
PCI DSS Validation and Attestation results page in the SAQ (Source: PCI SSC)

Step 5: Complete the Attestation of Compliance

The attestation is a two-part section of the SAQ that initially requires the business to declare its ability to complete the assessment. After evaluating the business’ system as specified in the scope (Step 2), the second portion of the attestation will show the results of the self-assessment.  

The evaluation or network testing portion of the assessment is where the PCI DSS checklist comes in. The assessor will conduct testing procedures based on the PCI DSS guidelines that compare the expected activities of a PCI-compliant network (refer to our checklist under the 12 PCI DSS requirements) against the actual activities of the business system. 

The testing methods used to determine compliance for each include:

  • Examination of electronic and physical documents, screenshots, documented process flows, file configurations, audit logs, and data files.
  • Observation of personnel performing procedures, computer systems performing a function, and physical controls.
  • Conducting interviews with company staff members to confirm procedures and gauge their level of awareness in data security as related to their role.    

Both the testing method used and the results should be documented and included in the report.

Sample page of the PCI DSS Requirement assessment page for merchants showing tables for requirements 1.1 and columns for Expected Testing and Response.
Self Assessment Questionnaire D for Merchants page (Source: PCI SSC)

Step 6: Submit your documentation to PCI SSC

Once all the tests are completed, submit all relevant documentation to the requesting body, typically the card network or merchant acquiring bank, for merchants or other requestors for service providers. 

  • Summary of Findings: Statement of the overall result of the security assessment along with details.
  • Audit Details: Documents that show testing procedures and implementation questions based on the SAQ and PCI DSS requirements. The ASV is also included here.
  • Business Information: Business profile summary based on details provided in the SAQ.
  • Card Payment Infrastructure: Documents showing the entire business network included in the scope of the assessment (Network firewall, software, hardware systems).
  • Details of External Relationships: Provides a list of third-party service providers (including payment processors) that have access to cardholder data.

For reports with insufficient findings and a request for system improvements, businesses should submit actions taken to address the issues with another report. 

Read more: Best ecommerce payment processing

Risks of PCI non-compliance 

The consequences of PCI non-compliance affect both businesses and consumers.   

  • PCI non-compliance fines: Businesses found to be non-compliant are imposed with non-compliance fees
    • PCI non-compliance fee: From $19.95 per month 
    • PCI non-compliance fine for security breach: From $5,000 per month 
  • Revocation: The merchant acquiring bank closes your merchant account, effectively removing your ability to accept credit card payments
  • Loss of business reputation: Credit card holders are aware of the consequences of data breach and will likely bring their business to a competitor instead

The risk of a consumer’s identity being used and funds being stolen is a serious concern among customers. So, while the fees for non-compliance may seem stiff, it is an effective protection measure from the potential complete loss of a business in case of a data breach. 

Frequently asked questions (FAQs)

PCI stands for Payment Card Industry, composed of merchants, service providers, financial institutions, and card networks involved in processing credit card transactions.

PCI compliance is a set of standards ensuring cardholder data security and related sensitive information in business systems. 

There are no Federal or State laws governing PCI compliance. However, compliance is an industry mandate by card networks, which operate under Federal laws requiring the protection of consumers who pay using credit cards.

Representatives of the founding card network members Visa, MasterCard, American Express, Discover, and JCB International lead the PCI SSC. Other financial institutions and participating organizations make up the board of advisors and roadmap roundtable groups that participate in updating the PCI DSS requirements.