PCI DSS Compliance Policy Template: Complete Implementation Guide
Every business that accepts credit cards must comply with PCI DSS — and the penalties for non-compliance start at $5,000 per month and escalate to $100,000 for repeated violations (PCI Security Standards Council, 2025). PCI DSS v4.0.1 is now the active standard, with all v3.2.1 requirements sunset as of March 31, 2025.
Yet most small and mid-market businesses treat PCI compliance as a checkbox exercise rather than a security program. This guide gives you the policies you need, explains which SAQ (Self-Assessment Questionnaire) applies to your business, and provides a practical implementation timeline.
Key Takeaways
- PCI DSS has 12 core requirements across 6 categories: network security, data protection, vulnerability management, access control, monitoring, and policy
- Most e-commerce businesses qualify for SAQ A (simplest) if they use hosted payment pages — never touching cardholder data themselves
- Implementation takes 3-6 months for most mid-market businesses; plan 6-12 months if starting from scratch
- Use our security compliance templates and compliance management toolkit alongside this guide
What Is PCI DSS and Who Needs It?
PCI DSS (Payment Card Industry Data Security Standard) is a set of security requirements created by Visa, Mastercard, American Express, Discover, and JCB to protect cardholder data. If your business stores, processes, or transmits credit card information — or could impact the security of cardholder data — PCI DSS applies to you.
Who must comply:
- Any business that accepts credit/debit card payments (merchants)
- Payment processors and gateways
- Hosting providers that store cardholder data
- Any third party that handles card data on behalf of merchants
Common misconception: "We use Stripe/Square, so we don't need PCI compliance." Wrong. Using a hosted payment solution dramatically reduces your scope (you'll likely qualify for SAQ A), but you still need to complete a self-assessment questionnaire and maintain basic security policies.
The 12 PCI DSS Requirements
PCI DSS v4.0.1 organizes requirements into 6 categories with 12 core requirements:
Build and Maintain a Secure Network
Requirement 1: Install and maintain network security controls Firewalls, network segmentation, and access rules that restrict traffic to only what's needed for business purposes.
Policy must define: Approved network architecture, firewall rule review frequency (at least every 6 months), change management for network configurations.
Requirement 2: Apply secure configurations to all system components Don't use vendor-supplied defaults for passwords, security parameters, or unnecessary services.
Policy must define: Hardening standards for each system type, default password change procedures, service minimization requirements.
Protect Account Data
Requirement 3: Protect stored account data Minimize cardholder data storage. What you don't store can't be stolen.
Policy must define: Data retention and disposal procedures, encryption requirements for stored data, where cardholder data is and isn't allowed to reside.
Requirement 4: Protect cardholder data with strong cryptography during transmission Encrypt cardholder data when sent across open, public networks.
Policy must define: Approved encryption protocols (TLS 1.2+ minimum), prohibited transmission methods (never email card numbers), certificate management procedures.
Maintain a Vulnerability Management Program
Requirement 5: Protect all systems and networks from malicious software Deploy and maintain antivirus/anti-malware on all systems commonly affected by malware.
Policy must define: Approved antivirus solutions, update frequency, scan schedules, procedures when malware is detected.
Requirement 6: Develop and maintain secure systems and software Keep systems patched. If you develop custom applications, follow secure coding practices.
Policy must define: Patch management timeline (critical patches within 30 days), secure development lifecycle, code review requirements.
Implement Strong Access Control
Requirement 7: Restrict access to system components and cardholder data by business need to know Only people who need cardholder data for their job should have access to it.
Policy must define: Role-based access control matrix, access request and approval process, periodic access reviews.
Requirement 8: Identify users and authenticate access to system components Unique IDs for every user. No shared accounts. MFA for administrative access.
Policy must define: Password requirements, MFA requirements, account lockout settings, session timeout parameters.
Requirement 9: Restrict physical access to cardholder data Physical security for any location that stores cardholder data or payment terminals.
Policy must define: Facility access controls, visitor management procedures, media handling and destruction procedures.
Regularly Monitor and Test Networks
Requirement 10: Log and monitor all access to system components and cardholder data Maintain audit trails. Know who accessed what, when.
Policy must define: Log retention (at least 12 months, 3 months immediately available), log review frequency, alerting thresholds.
Requirement 11: Test security of systems and networks regularly Vulnerability scans and penetration testing on a defined schedule.
Policy must define: Quarterly ASV (Approved Scanning Vendor) scans, annual penetration test, wireless access point detection.
Maintain an Information Security Policy
Requirement 12: Support information security with organizational policies and programs A formal information security policy that addresses all PCI DSS requirements.
Policy must define: Security awareness training program, incident response plan, risk assessment methodology, third-party service provider management.
For a complete information security policy covering all 12 requirements, use our information security policy template and IT security policy guide.
Which SAQ Do You Need?
The SAQ determines how much work compliance requires. Most businesses qualify for a simpler questionnaire than they think:
| SAQ Type | Who It's For | # of Questions | Common Example |
|---|---|---|---|
| SAQ A | E-commerce with fully hosted payment page (Stripe, PayPal) | ~30 | Online store using Stripe Checkout |
| SAQ A-EP | E-commerce where your website controls payment flow but doesn't process data | ~140 | Custom checkout page calling Stripe.js |
| SAQ B | Imprint-only or standalone terminal merchants | ~40 | Retail store with card terminal |
| SAQ C | Merchants with payment application systems connected to internet | ~160 | POS system connected to processor |
| SAQ D | Everyone else — full assessment | ~330 | Companies that store cardholder data |
How to reduce your SAQ scope: Use hosted payment pages (Stripe Checkout, PayPal Hosted) instead of handling card data yourself. This typically moves you from SAQ D (330 questions) to SAQ A (30 questions). That's not a shortcut — it's genuine risk reduction because your servers never touch cardholder data.
Implementation Timeline
For a mid-market business starting with basic security controls already in place:
| Phase | Duration | Key Activities |
|---|---|---|
| Assessment | Weeks 1-4 | Determine SAQ type, scope cardholder data environment, gap analysis |
| Remediation | Weeks 5-16 | Address gaps, implement missing controls, deploy monitoring |
| Documentation | Weeks 13-20 | Write required policies, document procedures, create evidence |
| Testing | Weeks 17-22 | Internal vulnerability scans, penetration test, policy review |
| Validation | Weeks 21-24 | Complete SAQ, submit to acquiring bank, ASV scan |
Total: 5-6 months. Add 3-6 months if you're implementing network segmentation or migrating payment systems.
Track your progress with our compliance management template and security compliance dashboard.
Common PCI Compliance Mistakes
-
Assuming hosted payments = no compliance — You still need SAQ A, security policies, and vendor management. You've reduced scope, not eliminated the requirement.
-
Storing cardholder data unnecessarily — If you don't need the full card number after authorization, don't store it. Tokenization (Stripe tokens, Braintree vault) eliminates most storage requirements.
-
Forgetting third-party providers — Every vendor that touches cardholder data must be PCI compliant. Maintain a list and collect their AOC (Attestation of Compliance) annually.
-
Treating compliance as annual — PCI DSS requires ongoing compliance, not a once-a-year assessment. Quarterly ASV scans, regular log reviews, and continuous monitoring are required year-round.
-
No incident response plan — Requirement 12.10 mandates a documented incident response plan tested at least annually. Many companies skip this until their first breach.
Frequently Asked Questions
How much does PCI DSS compliance cost?
Costs vary dramatically by SAQ type. SAQ A compliance for a small e-commerce business: $1,000-$5,000 (mostly ASV scan fees and staff time). SAQ D for a company that stores cardholder data: $50,000-$200,000+ (penetration testing, security tools, consulting, QSA assessment). The biggest cost driver is remediation — fixing security gaps identified in the assessment. Using hosted payment solutions to qualify for SAQ A is the most cost-effective approach for most businesses.
What happens if we fail a PCI assessment?
Failing a PCI assessment doesn't immediately result in fines. You'll receive a list of findings to remediate, typically with 90 days to fix critical issues. If you don't remediate and a breach occurs, fines escalate rapidly: $5,000-$100,000 per month from card brands, plus forensic investigation costs ($20,000-$50,000), plus liability for fraudulent transactions. The real risk isn't the fine — it's losing the ability to accept credit cards, which effectively shuts down most businesses.
Is PCI DSS compliance legally required?
PCI DSS isn't a government regulation — it's a contractual requirement enforced by the card brands (Visa, Mastercard, etc.) through your acquiring bank. However, many states reference PCI DSS in their data breach notification laws, and several (Nevada, Minnesota, Washington) have incorporated PCI requirements into state law. Practically speaking, non-compliance means your acquiring bank can increase your processing fees, assess penalties, or terminate your merchant account.
How often do we need to complete the SAQ?
The SAQ must be completed annually and submitted to your acquiring bank. Additionally, quarterly ASV vulnerability scans are required for any internet-facing systems, and penetration testing must be performed at least annually (or after significant infrastructure changes). Think of PCI as a continuous program with annual formal validation, not a one-time project.
Can we outsource PCI compliance?
You can outsource the implementation (hiring a QSA or consultant to help build your program) and you can reduce scope by using PCI-compliant service providers (Stripe, AWS, etc.), but you cannot outsource the responsibility. Your organization is still responsible for completing the SAQ, maintaining policies, and ensuring ongoing compliance. The merchant agreement is between you and the acquiring bank — no third party can sign it for you.
What's the difference between PCI DSS v3.2.1 and v4.0?
PCI DSS v4.0 (updated to v4.0.1) replaces v3.2.1 with several significant changes: customized approach for validation (flexibility in how you meet requirements), expanded MFA requirements, enhanced password requirements (minimum 12 characters), targeted risk analysis replacing some prescriptive requirements, and new e-commerce and phishing protections. All organizations must validate against v4.0.1 — the v3.2.1 deadline passed March 31, 2025.