Accepting card payments is easy. Knowing which security responsibilities belong to your business can be harder. A payment provider may handle transactions while your team still manages website access, supplier checks, and compliance paperwork.
PCI DSS establishes the security requirements that guide how organizations protect payment account data. This guide explains the current version, the 12 core requirements, assessment options, and practical steps to take before buying tools or hiring an assessor. You will also learn why outsourcing checkout can reduce your workload without removing your responsibilities.
What Is PCI DSS, and Who Must Follow It?
The Payment Card Industry Data Security Standard (PCI DSS) sets the requirements for securing payment account data through technical controls and operational practices. The PCI Security Standards Council maintains the standard.
It covers organizations that store, process, or transmit cardholder data, alongside organizations that could affect the security of the cardholder data environment, or CDE. That includes merchants, processors, and relevant service providers.
Business size does not provide an automatic exemption. A small online store still needs to understand its obligations, although its assessment may be simpler than a payment processor’s.
Separate two questions: which security requirements apply, and how must you demonstrate compliance? Your merchant bank (acquirer) or another compliance-accepting entity specifies the process you must follow to demonstrate compliance.
What Changed in PCI DSS 4.0.1?
PCI DSS v4.0.1 remains the current standard. Released in June 2024, it clarified v4.0 and corrected errors without adding or deleting requirements. Version 4.0 retired on December 31, 2024. The future-dated requirements became effective on March 31, 2025.
Authentication and Risk Decisions Need Attention
Review multifactor authentication, or MFA, across access into the CDE, including the applicable exceptions. Protecting only an external VPN connection may leave other access paths unaddressed.
For certain controls, a documented targeted risk analysis lets organizations choose how often to perform them. Use that flexibility only where the requirement allows it. Explain the threat, the assets involved, and why the chosen timing is appropriate.
The 12 PCI DSS Requirements in Plain English
The standard organizes payment security into 12 requirement families. This overview helps identify work areas; the detailed requirements determine what must be implemented and tested.
| Requirement | Main responsibility |
|---|---|
| 1 | Allow only approved network traffic using security controls. |
| 2 | Remove unsafe defaults and harden system settings. |
| 3 | Protect account data retained by the business. |
| 4 | Use strong encryption for cardholder data crossing public networks. |
| 5 | Block and detect malware across relevant systems. |
| 6 | Keep applications and supporting systems secure throughout their lifecycle. |
| 7 | Limit permissions to what each role requires. |
| 8 | Verify identities before granting system access. |
| 9 | Prevent unauthorized physical access to payment data. |
| 10 | Keep access records and investigate relevant activity. |
| 11 | Check systems and networks for security weaknesses. |
| 12 | Define security responsibilities, policies, training, and response plans. |
Turn each applicable requirement into an assigned task. For example, “review access” becomes more useful when it names an owner, the accounts covered, a deadline, and the record that demonstrates completion.
How to Build a Practical PCI DSS Compliance Plan
Map Payment Data Before Choosing Tools
Draw the journey from checkout to your payment processor. Include terminals, websites, support channels, reports, and systems that can affect payment security. Look for unexpected copies in logs, recordings, and spreadsheets.
Consider a retailer whose support team accepts card details by email. Its hosted checkout does not address that separate payment channel. Mapping both journeys reveals the actual work required.
Network segmentation can reduce assessment scope when it effectively separates systems. Merely creating another subnet does not establish that separation; it must be verified.
Confirm Whether You Need an SAQ or ROC
A Self-Assessment Questionnaire, or SAQ, supports eligible organizations in assessing and reporting compliance. Each type has eligibility conditions. Choose according to your payment environment and your acquirer’s instructions.
A Report on Compliance, or ROC, documents a detailed assessment. Confirm whether your program requires one and whether a Qualified Security Assessor, or QSA, must perform it.
Complete the appropriate Attestation of Compliance, or AOC, and submit the requested evidence. Where external vulnerability scans are required, use an Approved Scanning Vendor, or ASV, and obtain passing reports.
Fix Gaps and Keep Evidence as You Work
Track each compliance gap in a register with four columns: requirement, identified issue, responsible person, and required evidence. Prioritize exposed systems, unauthorized access, and sensitive data handling.
Keep evidence alongside the task: access approvals, configuration exports, test results, and supplier documentation. Schedule recurring work instead of rebuilding a year’s history before an assessment. Compliance requires controls to keep operating between reviews.
Payment-Page Security and Outsourced Checkout
Using an external payment processor may narrow the requirements that apply directly to your business environment. You still need to verify the provider’s compliance for the services used, maintain agreements, monitor its status at least annually, and understand shared responsibilities.
Understand the Updated SAQ A Rules
The revised SAQ A removed Requirements 6.4.3 and 11.6.1 from its questionnaire, alongside the related targeted risk analysis requirement. Those controls remain in PCI DSS itself.
For merchants using an embedded payment form, such as an iframe, SAQ A eligibility includes confirming protection against relevant script attacks. Merchants can use suitable protective techniques or obtain their provider’s confirmation that its correctly implemented solution protects the merchant’s payment page from script attacks. This particular eligibility criterion does not apply to redirect-only payment flows.
Where applicable, Requirement 6.4.3 addresses script authorization, integrity, and an inventory explaining why each script is needed. Requirement 11.6.1 addresses detecting unauthorized changes to payment pages and security-impacting HTTP headers as received by the customer’s browser. These controls address browser-based theft, often called e-skimming.
For example, before adding a marketing script beside an embedded checkout, ask who evaluates its security impact. Keep the provider’s implementation instructions and supporting confirmation with your assessment records.
When comparing compliance services, request separate pricing for assessment, vulnerability scanning, penetration testing, remediation, and ongoing support. Check which services are included and who handles unresolved findings. Ask whether retesting costs extra, what evidence you receive, and which tasks remain with your staff. Compare proposals against the same scope so a low headline price does not hide missing work. A useful quote starts with your actual payment environment.
Conclusion: Start With Your Payment Environment
Effective PCI DSS compliance begins with understanding how your business accepts payments. Map the data, confirm your assessment route, assign control owners, and keep evidence as work happens. Give outsourced services and embedded checkout pages the attention their shared responsibilities require. Your next step is practical: document one complete payment journey, then review it with your acquirer or a qualified assessor before committing to tools or services.
Frequently Asked Questions About PCI DSS
Do Small Businesses Need PCI DSS Compliance?
Yes. Small merchants are covered regardless of transaction volume. Their payment methods and systems affect the applicable requirements and validation process.
Does an SSL Certificate Make a Website PCI Compliant?
No. HTTPS protects data in transit when configured properly. PCI DSS also addresses access, software, stored data, monitoring, and other security controls.
Can a Merchant Store CVV Codes for Recurring Payments?
No. Merchants must not retain card verification codes after authorization, even in encrypted form. Customer permission does not override that restriction.
Does My Payment Provider’s PCI DSS Compliance Also Cover My Business?
No. The provider covers its assessed services. Your business remains responsible for its own applicable controls and oversight of that provider.
Can I Complete the Assessment Myself?
If your compliance program permits self-assessment and you meet the relevant SAQ eligibility criteria, yes. Confirm the appropriate questionnaire and submission requirements with your acquirer.
