PCI Implementation Guide for Merchants
Navigating PCI DSS requirements can be both complex and daunting. If your business handles card data, you may need to comply with over 300 security controls outlined in PCI DSS. The PCI Council has published more than 1,800 pages of official documentation, including over 300 pages dedicated solely to determining the correct compliance validation forms—reading through all of this would take more than 72 hours.
To simplify the process, here is a step-by-step guide to help you validate and maintain PCI compliance.
Overview of PCI Data Security Standard (PCI DSS)
PCI DSS is the global security standard for organizations that store, process, or transmit cardholder data and sensitive authentication data. It establishes a baseline level of protection for consumers, helping to reduce fraud and data breaches across the payment ecosystem. This standard applies to any entity that accepts or processes payment cards.
Achieving PCI DSS compliance involves three key components:
Securely Collecting and Transmitting Card Data: Ensuring that sensitive card details are handled securely during customer transactions.
Storing Data Safely: Adhering to the 12 security domains outlined in the PCI standard, which include encryption, continuous monitoring, and security testing.
Annual Validation: Confirming the implementation of required security controls through forms, questionnaires, external vulnerability scans, or third-party audits. (Refer to the step-by-step guide below for a detailed table of the four compliance levels.)
Handling Card Data
Some business models require the direct handling of sensitive credit card data during payments, while others do not. Companies that handle card data, such as accepting untokenized PANs on a payment page, may need to comply with all 300+ PCI DSS security controls. Even if card data briefly traverses a company’s servers, they must invest in and maintain robust security software and hardware.
For businesses that don’t need to handle sensitive card data, it’s best to avoid doing so. Third-party solutions, like Cutflow Elements, securely accept and store card data, eliminating much of the complexity, cost, and risk. Since card data never touches the company’s servers, compliance involves only a few straightforward security controls, such as implementing strong passwords.
Storing Data Securely
Organizations that handle or store cardholder data must define the scope of their Cardholder Data Environment (CDE). PCI DSS defines the CDE as the people, processes, and technologies involved in storing, processing, or transmitting cardholder data—or any system connected to it. Since all 300+ security requirements apply to the CDE, it’s critical to segment the payment environment from the broader business systems. Proper segmentation helps reduce the scope of PCI compliance validation. Without segmentation, the entire corporate network, including all systems and devices, would fall under PCI requirements—an overwhelming task.
Annual Validation
Regardless of how card data is handled, organizations must complete a PCI validation form annually. The method of validation depends on various factors, including:
Payment Processors: May require compliance as part of their reporting to payment card brands.
Business Partners: May request it as a condition for entering business agreements.
Platform Businesses: May need to demonstrate compliance to assure customers that data is handled securely.
The PCI DSS standard encompasses 12 primary requirements and more than 300 sub-requirements, reflecting leading security practices.
PCI DSS
BUILD AND MAINTAIN A SECURE NETWORK AND SYSTEMS
1. Install and maintain network security controls.
2. Apply secure configurations to all system components.
PROTECT ACCOUNT DATA
3. Protect stored cardholder data.
4. Protect cardholder data with strong cryptography during transmission over open, public networks.
MAINTAIN A VULNERABILITY MANAGEMENT PROGRAM
5. Protect all systems and networks from malicious software.
6. Develop and maintain secure systems and software.
IMPLEMENT STRONG ACCESS CONTROL MEASURES
7. Restrict access to system components and cardholder data by business need to know.
8. Identify users and authenticate access to system components.
9. Restrict physical access to cardholder data.
REGULARLY MONITOR AND TEST NETWORKS
10. Log and monitor all access to system components and cardholder data.
11. Test security of systems and networks regularly.
MAINTAIN AN INFORMATION SECURITY POLICY
12. Support information security with organizational policies and procedures.
To simplify the PCI compliance process for new businesses, the PCI Council introduced nine different Self-Assessment Questionnaires (SAQs), each representing a subset of the overall PCI DSS requirements. The challenge lies in determining which SAQ applies to your business or whether it’s necessary to engage a PCI Council–approved auditor to verify compliance with all security requirements. Adding to the complexity, the PCI Council updates the rules every three years and releases incremental updates throughout the year, making compliance a constantly evolving process.
Step-by-step guide to PCI DSS compliance
The first step in achieving PCI compliance is knowing which requirements apply to your organization. There are four different PCI compliance levels, typically based on the volume of credit card transactions your business processes during a 12-month period.
Compliance Level
Applies to:
Requirements:
Level 1
Organizations that annually process more than 6 million transactions of Visa or Mastercard, or more than 2.5 million for American Express; or
Have experienced a data breach; or
Are deemed “Level 1” by any card association (Visa, Mastercard, etc.)
Annual PCI DSS Self-Assessment Questionnaire (SAQ)—there are 9 SAQ types shown briefly in the table below
Quarterly network scan by Approved Scan Vendor (ASV)
Attestation of Compliance (AOC)—each of the 9 SAQs has a respective AOC form
Level 2
Organizations that process between 1–6 million transactions annually
Annual Report on Compliance (ROC) by a Qualified Security Assessor (QSA)—also commonly known as a Level 1 onsite assessment—or internal auditor if signed by an officer of the company
Quarterly network scan by Approved Scan Vendor (ASV)
Attestation of Compliance (AOC) for Onsite Assessments–there are specific forms for merchants and service providers
Level 3
Organizations that process between 20,000–1 million online transactions annually
Organizations that process fewer than 1 million total transactions annually
Same as above.
Level 4
Organizations that process fewer than 20,000 online transactions annually; or
Organizations that process up to 1 million total transactions annually
Same as above.
For Level 2–4, there are different SAQ types depending on your payment integration method. Here’s a brief table:
SAQ - Self Assessment Questionnaire
Description
A
Card-not-present merchants (ecommerce 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
Ecommerce 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 ecommerce 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 ecommerce channels. Not applicable to service providers.
B-IP
Merchants using only standalone, PTS-approved payment terminals with an IP connection to the payment processor with no electronic cardholder data storage.
Not applicable to ecommerce channels.
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 ecommerce channels. Not applicable to service providers.
C
Merchants with payment application systems connected to the internet, no electronic account data storage. Not applicable to ecommerce 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 ecommerce channels. Not applicable to service providers.
SPoC
(New for PCI DSS v 4.0)
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
SAQ D FOR MERCHANTS: All merchants not included in descriptions for the above SAQ types.
SAQ D FOR SERVICE PROVIDERS: All service providers defined by a payment brand as eligible to complete an SAQ.
Verify Security Controls and Protocols
After mapping all touchpoints for credit card data within your organization, collaborate with your IT and security teams to confirm that appropriate security configurations and protocols are in place. This includes measures like Transport Layer Security (TLS) to safeguard data transmission.
The 12 PCI DSS security requirements are built on leading practices for protecting sensitive data and often overlap with standards required for compliance with other privacy regulations such as GDPR and HIPAA. As a result, your organization may already have some of these controls in place.
Monitor and Maintain
PCI compliance is not a one-time task but an ongoing process to ensure your business stays compliant as data flows and customer touchpoints evolve. Some credit card brands may require quarterly or annual reports, or an annual on-site assessment, especially for businesses processing over 6 million transactions per year.
Maintaining PCI compliance year-round often requires collaboration across multiple departments. If such coordination isn’t already in place, consider forming a dedicated internal team to oversee compliance. A well-rounded “PCI team” should include representatives from key areas of the business, ensuring comprehensive coverage of compliance needs.
Security: The Chief Security Officer (CSO), Chief Information Security Officer (CISO), and their teams ensure the organization is always properly investing in the necessary data security and privacy resources and policies.
Technology/Payments: The Chief Technology Officer (CTO), VP of Payments, and their teams make sure that core tools, integrations, and infrastructure remain compliant as the organization’s systems evolve.
Finance: The Chief Financial Officer (CFO) and their team ensure that all payment data flows are accounted for when it comes to payment systems and partners.
Legal: This team can help navigate the many legal nuances of PCI DSS compliance.
For more information about the complex world of PCI compliance, head to the PCI Security Standards Council website. If you only read this guide and a few other PCI docs, we recommend starting with these: prioritized approach for PCI DSS, SAQ instructions and guidelines, FAQ about using SAQ eligibility criteria to determine onsite assessment requirements, and FAQ about obligations for merchants that develop apps for consumer devices that accept payment card data.
How Cutflow helps organizations achieve and maintain PCI compliance
Cutflow significantly simplifies the PCI burden for companies that use Cutflow In App payments and Secure payment Forms. Cutflow uses a hosted payment field for handling all payment card data, so the cardholder enters all sensitive payment information in a payment field that originates directly from our PCI DSS–validated servers.
For all our users, regardless of integration type, Cutflow acts as a PCI advocate and can help in a few different ways.
We’ll analyze your integration method and advise you on how to reduce your compliance burden.
We’ll notify you ahead of time if a growing transaction volume will require a change in how you validate compliance.
For large merchants (Level 1), if you need to work with a PCI QSA (because you store credit card data or have a more complex payment flow), there are more than 350 such QSA companies around the world, and we can connect you with several auditors that deeply understand the different Cutflow integration methods.
Conclusion
While assessing and validating PCI compliance typically occurs annually, it’s not a one-time effort—it requires continuous assessment and remediation. As your company grows, its business logic and processes will evolve, potentially impacting compliance requirements. For instance, an online business opening physical stores, entering new markets, or launching a customer support center should proactively assess whether these changes affect its PCI validation method and revalidate compliance as needed.
PCI Compliance Helps, But It’s Not Enough
Adhering to PCI DSS guidelines is essential for safeguarding cardholder data, but it alone doesn’t provide complete protection for all payment environments. A more effective approach involves adopting secure card acceptance methods, such as Cutflow In App payments and Secure Payment Forms. These solutions offer a proactive way to mitigate data breaches and bypass the traditional, labor-intensive PCI validation process. Beyond compliance, they provide consistent, reliable security every day of the year, empowering businesses to operate with confidence and agility.