Tiffany Bridge Key takeaways
- PCI compliance applies to businesses that handle payment card data.
- A PCI compliance checklist should cover scope, PCI DSS requirements, scans, documentation, and maintenance.
- PCI-compliant hosting can support compliance, but it doesn’t make a business compliant on its own.
- PCI compliance is ongoing because systems, scans, and security requirements change over time.
Payment data is one of the most sensitive types of information a business handles. If it’s exposed, the damage can be immediate: fraud risk, lost customer trust, potential fines, and lasting reputational damage.
That’s why PCI compliance matters for any business that accepts card payments. A clear PCI compliance checklist helps you understand what systems are in scope, what security controls need attention, and what evidence you may need for validation.
What is PCI compliance?
PCI compliance means meeting the Payment Card Industry Data Security Standard, or PCI DSS, which is designed to protect payment account data and reduce the risk of cardholder data exposure.
On September 7, 2006, the Payment Card Industry Data Security Standard (PCI DSS) was launched. The PCI Security Standards Council was created by the five major credit card companies, Visa, American Express, MasterCard, JCB, and Discover, and provides a framework, tools, and other resources for companies to keep customers’ data secure.
PCI DSS now applies to debit cards and other electronic transactions in addition to credit card payments. It provides a baseline of technical and operational requirements designed to protect payment account data. PCI DSS applies to entities that store, process, or transmit cardholder data or sensitive authentication data, plus entities that could affect the security of the cardholder data environment.
Before an audit or assessment, businesses should confirm the latest PCI DSS version and validation requirements with their payment processor, acquiring bank, Qualified Security Assessor, or official PCI SSC documentation.
Who needs to be PCI compliant?
PCI compliance applies to businesses that accept, process, store, or transmit payment card data. This includes:
- Ecommerce stores
- Donation platforms
- Membership websites
- Subscription businesses
- SaaS companies that accept card payments
- Service providers that support payment-related systems
Using a third-party payment processor does not remove every PCI responsibility. A hosted checkout page or compliant payment gateway can reduce scope, but you still need to understand how cardholder data enters, moves through, or touches your website, application, server, network, logs, backups, and vendors.
If you intend to accept payment via any of the member companies’ cards, you must agree to maintain PCI compliance and adhere to PCI standards. This doesn’t just refer to credit card payments. It also applies to gift cards, prepaid cards, or debit cards operated by these companies.
PCI compliance is not something to take lightly. Failure to comply with PCI guidelines can damage businesses in multiple ways, making the PCI compliance cost worth the investment.
PCI compliance checklist at a glance
Use this checklist as a starting point. It doesn’t replace official PCI DSS documentation, guidance from a Qualified Security Assessor, or requirements from your bank or payment processor.
| Step | What to do | Why it matters | Evidence to collect | Owner |
| Define PCI scope | Identify every system, app, network, vendor, and process that touches cardholder data | Scope determines what PCI requirements apply | Payment flow map, network diagram, system list | Business, IT, security |
| Build an asset inventory | Catalog servers, software, payment apps, network devices, and third-party providers | You cannot secure what you don’t track | Asset inventory, vendor list | IT, security |
| Reduce scope | Avoid storing card data where possible and segment payment systems | Smaller scope can reduce risk and complexity | Segmentation records, payment workflow documentation | Business, IT, payment team |
| Review the 12 requirements | Compare current controls against PCI DSS requirements | The 12 requirements form the foundation of PCI compliance | Gap analysis, control checklist | IT, security, compliance |
| Remediate vulnerabilities | Fix missing patches, weak settings, open ports, and access gaps | Open findings can lead to failed scans or data exposure | Remediation records, change tickets | IT, security |
| Run required scans | Complete vulnerability scans where required | Scans help identify exposed risks | ASV scan reports, remediation notes | IT, security |
| Collect evidence | Save proof of policies, reviews, access controls, scans, and training | Evidence supports validation | Logs, policies, reports, approvals | Compliance, IT |
| Complete SAQ or ROC | Validate compliance through the correct path | Validation requirements depend on merchant level and environment | SAQ, ROC, AOC | Business, QSA if required |
| Train staff | Make sure employees understand security policies | People can create or reduce risk | Training records, policy acknowledgments | Business, HR, security |
| Maintain compliance | Repeat scans, reviews, updates, and documentation | PCI compliance changes as systems change | Quarterly scan records, review logs | Business, IT, security |
How to do your own PCI compliance
Some smaller merchants can start with a self-assessment, but the exact process depends on transaction volume, payment flow, cardholder data handling, merchant level, and validation requirements. Some businesses complete a Self-Assessment Questionnaire. Others need a Report on Compliance from a Qualified Security Assessor.
A practical self-assessment process looks like this:
- Define your PCI scope, including every system, application, network, vendor, and process that touches cardholder data
- Reduce scope where possible
- Compare current controls against the 12 PCI DSS requirements
- Fix gaps and document what changed
- Complete the correct SAQ or work with a QSA if a ROC is required
- Maintain scans, logs, reviews, training, and evidence
Use this as general guidance, not a replacement for advice from a Qualified Security Assessor, acquiring bank, payment processor, legal counsel, or official PCI SSC documentation.
To help you obtain the necessary compliance reports, utilize our Compliance Assistance Scanning tool.
1. Define your PCI scope first
PCI scope includes the people, processes, systems, applications, networks, and service providers that store, process, or transmit cardholder data. It can also include systems connected to or able to affect the cardholder data environment.
Start with these questions:
- Do you store payment card data?
- Where does cardholder data enter the environment?
- Which servers, applications, databases, logs, and backups touch card data?
- Which third-party vendors or payment providers are involved?
- Which networks connect to the cardholder data environment?
- Are development, staging, and production environments separated?
- Do backups, logs, and monitoring tools contain cardholder data?
- Who has administrative access to payment-related systems?
Pro tip: Hosting infrastructure can affect PCI scope. Server configuration, firewall rules, network segmentation, logging, backups, patching, access controls, and physical data center controls all matter, so make sure you’re working with a provider that natively supports compliance requirements.
2. Reduce PCI scope where possible
Reducing PCI scope can make compliance easier to manage. The fewer systems that touch cardholder data, the fewer systems you need to assess, monitor, document, and secure under PCI DSS.
Start by working with a compliant payment processor and avoiding card data storage unless the business has a clear reason to keep it. From there, segmentation, tokenization, and access controls can help reduce scope further.
Common scope reduction steps include:
- Use tokenization where appropriate
- Segment the cardholder data environment
- Keep development, staging, and production environments separate
- Restrict access to systems that touch card data
- Review logs and backups to confirm they don’t store card data unnecessarily
Avoiding storing credit cardholder information at all unless it’s necessary for repeat payments is a good way to avoid falling out of compliance.
3. The 12 PCI DSS requirements
The PCI Security Standards Council established a 12-item checklist for PCI compliance. The 12 requirements fit into six broader goals: building and maintaining secure networks, protecting account data, maintaining vulnerability management, controlling access, monitoring and testing networks, and maintaining an information security policy.
| PCI DSS requirement | Checklist action | Hosting-related consideration | Evidence to collect |
| Requirement 1 | Install and maintain network security controls | Firewall rules, segmentation, allowed ports | Network diagrams, firewall reviews |
| Requirement 2 | Apply secure configurations | Server hardening, default password changes | Hardening standards, configuration records |
| Requirement 3 | Protect stored account data | Encryption, tokenization, retention limits | Data inventory, encryption records |
| Requirement 4 | Protect cardholder data during transmission | TLS, certificates, secure APIs | Certificate records, secure transmission policies |
| Requirement 5 | Protect systems from malware | Anti-malware and monitoring where applicable | Protection tool records, alert history |
| Requirement 6 | Maintain secure systems and software | OS, application, CMS, plugin, and server patching | Patch records, remediation tickets |
| Requirement 7 | Restrict access by business need | Least privilege, role-based access | Access reviews, role records |
| Requirement 8 | Identify users and authenticate access | Unique IDs, MFA, password policies | Account records, MFA settings |
| Requirement 9 | Restrict physical access | Data center access controls, device security | Visitor logs, access control records |
| Requirement 10 | Log and monitor access | System logs, admin logs, alerting | Log reviews, monitoring records |
| Requirement 11 | Test security systems and processes | Vulnerability scans, penetration testing where required | ASV scans, test reports |
| Requirement 12 | Maintain an information security policy | Policies, training, incident response | Policies, training records, risk reviews |
Build and maintain a secure network and systems
Requirement 1: Install and maintain network security controls
Firewalls and network security controls help limit unauthorized access to systems that store, process, or transmit cardholder data. They are a system’s first line of defense against hackers, doing so by blocking any outside entities from accessing private data. This helps protect data from unauthorized access.
For a hosting environment, this may include:
- Firewall rules
- Network segmentation
- Restricted admin access
- Allowed port reviews
- Network architecture documentation
- Rules that separate public-facing systems from sensitive systems
Requirement 2: Apply secure configurations to all system components
Default passwords and insecure default settings can create easy entry points for attackers. PCI DSS requires businesses to apply secure configurations to system components.
Update factory passwords on point-of-sale devices, routers, and other equipment, and keep a list of all devices that require passwords.
In hosting environments, this also includes server hardening, disabling unnecessary services, configuring secure access, and documenting configuration standards.
Protect account data
Requirement 3: Protect stored account data
Stored account data needs strong protection. In many cases, the best approach is to avoid storing cardholder data unless the business has a clear reason and the controls to protect it.
Use algorithms to protect card numbers and information with encryption keys. Regularly check and scan primary account numbers to make sure all data is encrypted so even if someone penetrates the firewall, the data will be useless without the encryption key.
Other approaches may include tokenization, truncation, hashing, retention limits, and secure key management.
Requirement 4: Protect cardholder data during transmission
Customer data is regularly transmitted from homes to stores, payment processors, and banks. During those transmissions, the data must be protected.
For online businesses, this usually means using strong encryption for payment pages, APIs, admin access, and any transmission over open or public networks. Keep TLS certificates current and review where payment data moves between systems.
Before sending any data, make sure you’re sending it to the appropriate location, and never send account information to an unknown location.
Maintain a vulnerability management program
Requirement 5: Protect systems from malware
Malware protection helps reduce the risk that systems handling payment data become compromised.
Businesses should use antivirus or anti-malware tools where required, then keep that software patched and updated. POS platforms, servers, workstations, and other systems in scope should also be reviewed for malware protection needs.
Malware protection requirements can vary by system type, but businesses should document how they protect endpoints, servers, applications, and systems in scope.
Requirement 6: Develop and maintain secure systems and software
Businesses need to keep systems and applications secure over time. That includes patching, vulnerability remediation, secure coding practices, and regular software maintenance.
Some software automatically updates, but it’s important to check all business software for the latest updates. Many updates include important security features that will keep data safe from some of the latest threats.
For hosted ecommerce environments, this may include:
- Operating system patches
- Web server updates
- Ecommerce platform updates
- CMS, plugin, module, and theme updates
- Database updates
- Code review and vulnerability remediation
Implement strong access control measures
Requirement 7: Restrict access by business need-to-know
Access to cardholder data should follow the principle of least privilege. People should only access the systems and data they need for their role.
View all credit card data as being on a “need-to-know basis.” Business partners, staff, and employees who don’t need access to data for their job shouldn’t have access. Keep track of those who do need to access the data and regularly update the information as restrictions change.
Requirement 8: Identify users and authenticate access
Every person with access should have a unique ID. Shared accounts or access codes are easier to compromise and make it harder to track who accessed data or changed a system.
Hosting-related controls may include separate admin accounts, SSH key management, control panel access reviews, strong password policies, and MFA where required.
Requirement 9: Restrict physical access to cardholder data
Physical access matters too. Paper records, external drives, backup media, systems, and facilities that store or process cardholder data need physical controls, such as locked storage, restricted rooms, access logs, and surveillance.
For hosted environments, physical controls can include data center access restrictions, surveillance, visitor processes, and hardware access controls.
Regularly monitor and test networks
Requirement 10: Log and monitor access
Logging helps teams understand who accessed systems, when they accessed them, and what activity occurred.
Use software to track how data flows through the organization and physical logs of who enters rooms or buildings with sensitive information. Record when and how often primary account numbers and cardholder data are accessed. Keep log review documentation as part of your ongoing evidence collection.
Requirement 11: Test security systems and processes
Security controls need regular testing. Vulnerability scans, penetration testing where required, change detection, and security reviews help identify weaknesses before they turn into incidents.
Both physical and network security face changing threats, so testing should happen on a regular schedule instead of only before an audit.
PCI scanning and penetration testing are not the same. PCI scans are vulnerability assessments, while penetration tests attempt to exploit found vulnerabilities. Scans may also return false positives, which is why review and remediation matter.
A scan can pass once and fail later. Server updates, SSL changes, and configuration changes can affect scan results, so businesses should treat PCI scans as part of ongoing security maintenance.
Maintain an information security policy
Requirement 12: Maintain an information security policy
PCI DSS also requires businesses to document and maintain security policies.
Keep an inventory of all equipment and software used to process credit cards, all employees with access to data, and all physical locations that hold sensitive information. Document where data flows and exactly how it’s used beyond the point of sale.
A PCI-ready policy set may include:
- Information security policy
- Staff training records
- Incident response plan
- Vendor management records
- Risk assessments
- Access control policy
- Acceptable use policy
- Data retention policy
Annual training helps keep staff aligned with security expectations and reduces mistakes that could expose payment data.
PCI compliance and hosting: What your provider can and cannot do
Finding a PCI-compliant dedicated hosting provider can help create a safer hosting environment for sensitive data. PCI compliance is a shared responsibility across the merchant, hosting provider, payment processor, developers, and internal team.
| Responsibility | Merchant / business | Hosting provider | Payment provider |
| Payment data flow | Owns and documents payment flow | May support secure infrastructure | Processes payment data |
| Server configuration | Sets requirements and reviews scope | May support hardening and configuration | Usually not responsible |
| Firewall and network rules | Defines business needs | May configure or support rules | Usually not responsible |
| Application security | Owns website, store, and application code | May support hosting security | May secure hosted payment page |
| Patching | Owns application and custom code updates | May support OS and server software updates | Owns payment platform updates |
| Backups | Defines retention and recovery needs | May provide backup services | May not cover merchant systems |
| Logs and monitoring | Reviews activity and keeps evidence | May provide infrastructure logs or monitoring | Provides payment platform records |
| Physical security | Reviews provider controls | Owns data center physical controls | Owns its own facilities |
| Vulnerability scanning | Completes required validation | May support scans and remediation | May provide compliance documentation |
| SAQ / ROC completion | Owns validation | May provide supporting evidence | May provide AOC or service documents |
PCI scans, audits, SAQs, ROCs, and AOCs
PCI compliance involves specific validation terms. These terms often show up during audits, scans, payment processor reviews, or security assessments.
- SAQ: A Self-Assessment Questionnaire that some merchants use to validate compliance
- ROC: A Report on Compliance, often required for larger or more complex environments
- AOC: An Attestation of Compliance that confirms assessment results
- QSA: A Qualified Security Assessor. QSAs are independent security organizations qualified and trained by PCI SSC to perform PCI DSS assessments
- ASV: An Approved Scanning Vendor. ASVs are qualified and trained by PCI SSC to conduct external vulnerability scanning services under applicable PCI DSS requirements
To help customers with compliance, Liquid Web offers a Compliance Assistance Scanning tool.
Evidence to collect for PCI compliance
A checklist helps identify controls. Evidence proves those controls exist and continue to operate. Before an assessment, collect documents such as:
- Network diagrams
- Asset inventory
- Payment flow documentation
- Firewall rule reviews
- Secure configuration standards
- Patch records
- Malware protection records
- Access reviews
- MFA and account management records
- Physical access documentation
- Logs and monitoring records
- Vulnerability scan reports
- Penetration test reports, if required
- Security policies
- Staff training records
- Incident response plan
- Vendor compliance documents
- SAQ, ROC, or AOC documents
Common PCI compliance mistakes
PCI compliance can be complicated for businesses not used to dealing heavily with data due to its technical aspects. These common mistakes can create extra risk or slow down validation:
- Treating PCI compliance as a one-time checklist
- Assuming PCI-compliant hosting makes the business compliant
- Not defining PCI scope first
- Storing cardholder data unnecessarily
- Keeping outdated software or plugins in the payment environment.
- Ignoring logs, backups, and scan findings
- Waiting until an audit to collect evidence
- Not reviewing third-party service providers
- Forgetting that server updates or SSL changes can affect scans
- Giving too many users administrative access
- Failing to document security policies and procedures
PCI compliance checklist for ecommerce businesses
Ecommerce sites can choose self-hosted stores that make it easier for businesses to become PCI compliant. For example, Magento PCI compliance and WooCommerce PCI compliance can be accomplished by following the appropriate steps and working with the platform.
For online stores, PCI compliance should focus on reducing payment data exposure and keeping the hosting environment secure.
Use this ecommerce PCI checklist:
- Use a trusted payment gateway or hosted payment page
- Avoid storing card data unless required
- Keep ecommerce software patched
- Keep plugins, themes, modules, and extensions updated
- Keep server software updated
- Use TLS on payment, login, and admin pages
- Restrict admin access
- Use MFA where appropriate
- Review logs for suspicious activity
- Back up important data
- Run required vulnerability scans
- Review third-party payment and hosting providers
- Collect compliance documents from vendors
PCI compliance checklist FAQs
PCI compliance checklist next steps
PCI compliance starts with knowing where cardholder data lives, which systems are in scope, and which PCI DSS requirements apply.
Start by mapping your payment flow. Identify every system, application, vendor, and hosting component that stores, processes, transmits, or could affect cardholder data.
If you need secure hosting support for payment-related workloads, explore Liquid Web’s PCI-supportive hosting, managed dedicated hosting, and Compliance Assistance Scanning options. Click through to learn how Liquid Web can help you build and maintain a safer hosting environment for ecommerce and payment workflows.