This article provides general educational information about PCI DSS requirements. It is not legal or compliance advice. Businesses with specific compliance questions should consult a Qualified Security Assessor (QSA).
What PCI DSS Is and Whether It Applies to You
If your business accepts credit or debit card payments — in person, online, or by phone — you are subject to the Payment Card Industry Data Security Standard (PCI DSS). There is no revenue threshold, no employee count minimum, and no exception for very small businesses. Any organisation that stores, processes, or transmits cardholder data must comply.
The current standard is PCI DSS v4.0.1, which became the only active version on 31 March 2025. The previous version (v3.2.1) retired on 31 December 2024. There is no transition period remaining and no grace period for businesses still on the old version. If your last compliance assessment was under v3.2.1, it needs to be updated.
PCI DSS is not enforced by a government agency — it’s a standard set by the Payment Card Industry Security Standards Council (PCI SSC), a body founded by American Express, Discover, JCB, Mastercard, and Visa. Enforcement happens through your acquiring bank (the bank that processes your card payments). If you experience a breach and are found non-compliant, your bank can impose significant fines, require a forensic investigation at your cost, and potentially terminate your ability to accept card payments.
The average cost of a PCI non-compliance fine following a breach ranges from $5,000 to $100,000 per month depending on the card network, the scope of the breach, and how long the non-compliance lasted. For a small business, this is often the most financially devastating consequence of a breach beyond the breach itself.
Your Merchant Level Determines How You Demonstrate Compliance
PCI DSS scales its compliance validation requirements based on the number of card transactions you process annually. There are four merchant levels:
Level 1: Over 6 million transactions per year. Requires an annual on-site assessment by a Qualified Security Assessor (QSA) — an independent security assessor certified by PCI SSC. This applies to major retailers and large enterprises. Most small businesses are not Level 1.
Level 2: 1 million to 6 million transactions per year. Requires an annual Self-Assessment Questionnaire (SAQ) completed by the merchant and may require quarterly external vulnerability scans by an Approved Scanning Vendor (ASV).
Level 3: 20,000 to 1 million ecommerce transactions per year. Requires an annual SAQ and quarterly ASV scans for ecommerce merchants.
Level 4: Fewer than 20,000 ecommerce transactions per year, or up to 1 million total card transactions from any channel. Requires an annual SAQ. Quarterly ASV scans may be required depending on the SAQ type and acquiring bank requirements.
Most small businesses are Level 4. At this level, compliance is validated through the Self-Assessment Questionnaire — not through an external assessor audit. The SAQ is a structured questionnaire about your payment environment and security controls that you complete and attest to annually.
Your acquiring bank sets the specific compliance requirements within this framework. Some banks require quarterly ASV scans at Level 4; others do not. Contact your bank or payment processor to confirm your exact requirements.
The Most Important Scope Decision: How Cardholder Data Flows Through Your Business
Before any compliance work, understand your cardholder data environment (CDE) — the systems, networks, and processes involved in storing, processing, or transmitting cardholder data. The smaller and more isolated your CDE, the fewer requirements you need to satisfy.
The single most effective way to reduce PCI DSS scope for a small business is to ensure cardholder data never touches your systems at all. Three approaches achieve this:
Hosted payment page: Customers enter card details on a payment page hosted entirely by your payment processor or gateway (Stripe, Square, PayPal, Worldpay). Your systems never see the card number. This is the most scope-reducing approach for online payments.
Critical caveat for ecommerce merchants (Requirement 6.4.3): Even if you use a hosted payment page, your PCI DSS scope may be larger than you expect. Under PCI DSS v4.0.1, if any JavaScript from your own domain loads on the checkout page — analytics tags, retargeting pixels, tracking scripts — your scope expands significantly. A single analytics tag on a page where a payment iframe loads can move you from the simplest SAQ to a more complex one. Audit every script loading on your checkout page and remove all non-essential scripts before your PCI assessment.
Point-to-Point Encryption (P2PE): In-person payments using a PCI-validated P2PE solution encrypt card data at the point of swipe or tap, before it reaches your systems. The card number is never in a readable form in your environment. This substantially reduces scope for card-present transactions.
Tokenisation: Your payment processor stores card data and returns a token — a substitute value that can be used for future transactions but is meaningless if stolen. Tokens are not cardholder data and are not in scope.
Most small businesses using Stripe, Square, Clover, or similar modern payment platforms can achieve a very limited CDE by using these providers’ hosted payment pages or integrated card readers — and should take the time to verify exactly how their payment flow is configured.
Which SAQ Applies to Your Business?
The Self-Assessment Questionnaire exists in multiple versions (SAQ A through SAQ D) depending on how you accept payments and how cardholder data flows through your environment. Completing the wrong SAQ is a common compliance failure — and answering questions that don’t apply to your business creates compliance documentation that doesn’t reflect your actual environment.
SAQ A: For merchants who have outsourced all cardholder data functions to a PCI DSS-compliant third party and have no direct interaction with, storage, processing, or transmission of cardholder data. Applicable to card-not-present (ecommerce and mail/telephone order) merchants where all payment processing is handled by a third party and the merchant’s website redirects to a fully hosted payment page.
Under v4.0.1: SAQ A now includes Requirement 6.4.3 (script management) and Requirement 11.6.1 (change and tamper detection for payment pages). These were previously not in scope for SAQ A merchants. Ecommerce businesses on SAQ A must now document all scripts on their checkout pages and implement monitoring for unauthorised changes.
SAQ A-EP: For ecommerce merchants who redirect to a third-party payment page but whose own website is involved in the payment flow beyond simple redirect (for example, the merchant’s page loads the payment page in an iframe, or scripts from the merchant’s domain load alongside the payment form).
SAQ B: For merchants with standalone, dial-out card terminals that do not store cardholder data electronically and are not connected to the internet. Typical for older physical terminals dialling over phone lines.
SAQ B-IP: For merchants with standalone PTS-approved IP-connected card terminals that do not store cardholder data electronically and are connected to the payment processor over the internet.
SAQ C: For merchants with payment application systems connected to the internet, but who do not store cardholder data electronically. Typically applies to restaurant or retail point-of-sale systems that connect to a payment processor online.
SAQ C-VT: For merchants who manually enter card data through an internet-based virtual terminal provided by a third-party payment processor. No electronic cardholder data storage. No direct processing capabilities on the merchant’s systems.
SAQ D (Merchant): The most comprehensive questionnaire — covering all 12 PCI DSS requirements in full. Applies to merchants who store electronic cardholder data, or who don’t fit the criteria for any of the simpler SAQs.
SAQ D (Service Provider): For service providers storing, processing, or transmitting cardholder data on behalf of merchants.
For most very small businesses: SAQ A (if you use a hosted payment page with no cardholder data touching your systems) or SAQ B-IP or SAQ C (if you use a modern card terminal or POS system) is typically applicable. Confirm with your acquiring bank and payment processor — they can advise which SAQ is correct for your specific setup.
The 12 PCI DSS Requirements: Simplified for Small Businesses
PCI DSS v4.0.1 has 12 core requirements. The full standard document is approximately 360 pages long. The practical interpretation for a small business with a limited CDE is significantly more manageable. Here is each requirement explained in plain terms with what a small business actually needs to do.
Requirement 1: Install and Maintain Network Security Controls
What it means: Protect the network boundary of your CDE with firewalls or equivalent controls. Restrict traffic to only what is necessary.
What small businesses need to do: If cardholder data flows through any system on your network, use a business-grade router/firewall that separates the payment network from the rest of your business network. Disable remote access to payment systems that is not required. Document your network architecture. Review firewall rules annually.
Key v4.0 change: “Firewalls and routers” became “network security controls” — acknowledging that cloud security groups, VPCs, and software-defined network controls fulfil the same function.
Requirement 2: Apply Secure Configurations to All System Components
What it means: Before deploying any system in your CDE, change all default passwords and settings. Remove or disable anything not needed for payment processing.
What small businesses need to do: Change default admin passwords on every payment terminal, POS system, router, and server in scope. Remove default accounts and services that aren’t used. Document what systems are in scope and how they’re configured.
Requirement 3: Protect Stored Account Data
What it means: Don’t store sensitive authentication data (the full card number, CVV, PIN) unless absolutely necessary — and if you do store card numbers, protect them with strong encryption.
What small businesses need to do: In most cases, the answer is: don’t store cardholder data at all. Most modern payment systems handle this through tokenisation. If you have any historical stored card numbers in spreadsheets, databases, or paper records, they must either be secured or deleted. If you have no reason to store card numbers, delete everything you have and ensure your systems are configured not to log or retain them.
Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission
What it means: Any cardholder data transmitted over open, public networks must be encrypted using strong cryptography.
What small businesses need to do: All payment pages and payment gateways must use TLS 1.2 or higher. TLS 1.0 and 1.1 must be disabled. If you have an ecommerce store, verify your payment pages use current TLS by checking your SSL certificate and server configuration. Your payment processor’s hosted payment page typically handles this — but verify. Disable unencrypted protocols (plain HTTP) on any page involved in the payment flow.
Requirement 5: Protect All Systems and Networks from Malicious Software
What it means: All systems that could be affected by malware — particularly those that touch cardholder data — must have active, updated malware protection.
What small businesses need to do: Endpoint protection software on any system in scope, configured for automatic updates and regular scanning. Under v4.0.1, anti-malware must be capable of detecting phishing and evolving ransomware variants — basic signature-only antivirus is no longer adequate. All systems in the CDE, including POS terminals if applicable, must be covered.
Requirement 6: Develop and Maintain Secure Systems and Software
What it means: Keep all systems in your CDE patched and updated. If you develop or customise payment software, follow secure development practices.
What small businesses need to do: Apply security patches to all in-scope systems within 30 days of release for critical vulnerabilities and within a reasonable timeframe for others. For ecommerce merchants, two specific requirements deserve special attention:
Requirement 6.4.3 (script management for payment pages): Every script loading on your ecommerce payment page must be authorised, its integrity must be verified, and an inventory must be maintained. This includes analytics tags, marketing pixels, chat widgets, and any other JavaScript loading alongside your payment form. Under v4.0.1, this requirement is mandatory — it was a future-dated requirement prior to March 2025. This is one of the most common compliance gaps for small ecommerce businesses.
Requirement 11.6.1 (change and tamper detection): Ecommerce merchants must implement a mechanism to detect and alert on unauthorised modifications to payment page scripts and HTTP headers. Several commercial solutions address this specifically. This requirement also became mandatory in March 2025.
Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know
What it means: Only people who need access to cardholder data and payment systems to do their jobs should have it.
What small businesses need to do: Restrict access to payment systems to the minimum number of staff who genuinely require it. Document who has access to what. Implement role-based access controls in your payment and POS systems.
Requirement 8: Identify Users and Authenticate Access to System Components
What it means: Every person who accesses the CDE must have a unique account and must authenticate securely. Under v4.0.1, MFA is now required for all access to the CDE — not just remote access.
What small businesses need to do: Every staff member who accesses payment systems must have their own unique login — no shared accounts. MFA must be enabled for all CDE access, including internal system access where the system supports it. Passwords for CDE systems must meet current complexity requirements (minimum 12 characters under v4.0.1). Accounts for employees who have left must be deactivated within one day of departure.
Key v4.0 change: MFA is now mandatory for all CDE access, not just remote access. This is one of the most impactful requirement changes for small businesses whose payment terminals or POS systems are accessed by multiple employees through shared credentials.
Requirement 9: Restrict Physical Access to Cardholder Data
What it means: Control physical access to systems that store or process cardholder data. Protect card terminals from tampering.
What small businesses need to do: Restrict access to areas where payment systems are located to authorised staff. Implement visitor access logs if cardholder data is in a specific area. Inspect card terminals regularly for tampering (skimming devices). Maintain an inventory of card terminals including serial numbers, and verify them periodically against the inventory. Train staff to recognise signs of terminal tampering.
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data
What it means: Maintain audit logs of all access to systems in the CDE and review them for suspicious activity. Logs must be retained for at least 12 months, with at least 3 months available for immediate analysis.
What small businesses need to do: Enable logging in your payment systems, POS software, and any network devices in scope. Review logs periodically — under v4.0.1, the expectation is more frequent review than the previous annual approach. Protect logs from modification (a compromised system that can also delete its own logs provides no useful evidence trail). Store logs for at least 12 months.
Requirement 11: Test Security of Systems and Networks Regularly
What it means: Actively test whether your security controls are working through vulnerability scanning and penetration testing.
What small businesses need to do:
- External vulnerability scans: Conducted quarterly by an Approved Scanning Vendor (ASV). This is a mandatory requirement for most merchants — your acquiring bank will typically confirm whether you need this based on your SAQ. ASV scans are conducted remotely and test the external-facing components of your CDE.
- Internal vulnerability scans: Required at least every 90 days under v4.0.1.
- Penetration testing: Required annually for all merchants under v4.0. For Level 4 merchants, this has typically been handled through vulnerability scanning — verify with your bank whether a formal penetration test is required at your level.
- File integrity monitoring: Required on critical system files in the CDE.
Requirement 12: Support Information Security with Organisational Policies and Programmes
What it means: Have written security policies, a formal risk management programme, and clear accountability for PCI DSS compliance.
What small businesses need to do:
- Written information security policy covering PCI DSS requirements, reviewed annually.
- Formal risk assessment process — at least annual, assessing threats to your CDE.
- Documented incident response plan for payment card breaches.
- Security awareness training for all staff with access to the CDE — completed on hire and annually, with content reflecting current threats under v4.0.1.
- Documented contracts with all service providers that specify their PCI DSS compliance responsibilities.
- An annual review and attestation process to confirm ongoing compliance.
PCI DSS Compliance Checklist for Small Businesses
Use this as a starting point for your compliance programme. Items marked with ⚠️ were future-dated under v4.0 and became mandatory on 31 March 2025 — if you haven’t addressed these yet, they are overdue.
Scope and Setup:
- ☐ Confirm merchant level with acquiring bank
- ☐ Identify the correct SAQ for your payment model
- ☐ Map all cardholder data flows in your environment
- ☐ Document all systems in scope for PCI DSS
Network Security (Requirement 1):
- ☐ Firewall or equivalent network security control protects CDE
- ☐ CDE network segmented from general business network
- ☐ Firewall rules documented and reviewed annually
- ☐ Inbound and outbound traffic restricted to necessary only
Secure Configuration (Requirement 2):
- ☐ Default passwords changed on all in-scope devices
- ☐ Unnecessary services and accounts removed or disabled
- ☐ System configuration documented
Data Protection (Requirement 3):
- ☐ Cardholder data not stored unless absolutely necessary
- ☐ Any stored cardholder data encrypted or hashed
- ☐ Historical card data in spreadsheets or legacy systems identified and deleted
Transmission Encryption (Requirement 4):
- ☐ TLS 1.2 or higher on all payment pages and connections
- ☐ TLS 1.0 and 1.1 disabled
- ☐ No cardholder data transmitted over unencrypted channels
Malware Protection (Requirement 5):
- ☐ Endpoint protection on all in-scope systems
- ☐ Anti-malware configured for automatic updates and regular scanning
Software Security (Requirement 6):
- ☐ Security patches applied promptly (critical: within 30 days)
- ⚠️ ☐ Script inventory maintained for ecommerce payment pages (Req 6.4.3)
- ⚠️ ☐ Change and tamper detection implemented for payment pages (Req 11.6.1)
Access Restriction (Requirement 7):
- ☐ CDE access limited to staff with genuine business need
- ☐ Access documented by role
Authentication (Requirement 8):
- ☐ Unique accounts for every user — no shared credentials
- ⚠️ ☐ MFA required for ALL CDE access (not just remote access)
- ☐ Minimum 12-character passwords for CDE accounts
- ☐ Departing employees’ access deactivated within 24 hours
Physical Security (Requirement 9):
- ☐ Physical access to CDE restricted to authorised staff
- ☐ Card terminals included in asset inventory with serial numbers
- ☐ Terminals inspected regularly for signs of tampering
- ☐ Staff trained on terminal tampering recognition
Logging and Monitoring (Requirement 10):
- ☐ Audit logs enabled on all CDE systems
- ☐ Logs retained for minimum 12 months
- ☐ Regular log review process in place
Testing (Requirement 11):
- ☐ Quarterly external ASV scans (if required by bank/SAQ)
- ⚠️ ☐ Internal vulnerability scans at least every 90 days
- ☐ Annual penetration testing (verify requirement at your merchant level)
Policies and Governance (Requirement 12):
- ☐ Written information security policy covering PCI DSS requirements
- ☐ Annual risk assessment of CDE threats
- ☐ Incident response plan for card data breaches
- ☐ Annual security awareness training with current threat content
- ☐ Contracts with payment service providers specifying PCI DSS responsibilities
- ☐ Annual SAQ completed and submitted to acquiring bank
The Fastest Way to Reduce PCI DSS Scope
The most efficient path to simpler PCI DSS compliance is reducing the scope of your cardholder data environment. If cardholder data never touches your systems, the requirements that apply to those systems are dramatically reduced.
For in-person payments: Use a PCI-validated P2PE (Point-to-Point Encryption) solution. The card reader encrypts data at the point of tap or swipe, before it reaches any system you manage. Modern terminals from Square, SumUp, Stripe Terminal, and Zettle use P2PE by default. Verify your specific terminal is on the PCI SSC’s list of validated P2PE solutions.
For online payments: Use a hosted payment page where customers enter card details directly on your payment processor’s domain, with no cardholder data flowing through your website. Stripe Checkout, PayPal Standard, Sage Pay’s hosted form, and equivalent products achieve this. Remove all non-essential scripts from any page in the payment flow.
For phone orders: Use a PCI-compliant virtual terminal provided by your payment processor rather than a custom system. Ensure the virtual terminal is accessed through a dedicated device not used for general internet browsing.
Tokenisation: Ensure your payment processor handles recurring billing through tokens rather than stored card numbers. You should never need to store a card number in your own systems for a returning customer.
Businesses that implement all of the above typically qualify for SAQ A (the simplest questionnaire with fewer than 30 questions). Businesses with complex custom integrations, legacy payment systems, or stored cardholder data face the full SAQ D with all 12 requirements in detail.
What to Avoid
Don’t assume your payment processor handles PCI compliance for you. Your payment processor is responsible for their own PCI compliance. You are responsible for yours. The compliance of Stripe, Square, or PayPal doesn’t transfer to you. You must still complete your SAQ, maintain your own security controls, and attest to compliance annually.
Don’t ignore the script management requirement (6.4.3). This is the requirement most ecommerce businesses discovered in 2025 and 2026 that they weren’t meeting. Every piece of JavaScript loading on your checkout pages must be inventoried, authorised, and monitored. This includes Google Analytics, Meta Pixel, chat widgets, affiliate tracking scripts, and anything else marketing has added over time. A single unapproved script on a payment page is a v4.0.1 violation. Audit your checkout pages now.
Don’t submit your SAQ without verifying it’s the right one. Completing SAQ A when your actual payment flow requires SAQ A-EP is not compliance — it’s a false attestation. If your payment page includes any script from your own domain loading alongside a third-party iframe, you are likely not SAQ A eligible. Confirm with a QSA or your bank if you’re uncertain.
Don’t let compliance lapse between annual attestations. Under v4.0.1, PCI DSS has explicitly moved from a point-in-time annual check to a continuous compliance model. Controls must be in place and documented year-round, not just at attestation time. Quarterly scans, regular log reviews, 90-day internal vulnerability scans, and ongoing monitoring are periodic requirements, not annual ones.
Don’t store cardholder data if you don’t need to. The riskiest thing a small business can do for PCI DSS purposes is maintain historical card numbers in any form — spreadsheets, order management systems, email archives, paper records. If you have stored card data you don’t need, delete it securely and document the deletion. Less stored data means less liability and smaller scope.
PCI DSS Penalties: What Non-Compliance Actually Costs
PCI DSS fines are levied by card brands (Visa, Mastercard) through acquiring banks. They’re not public — your bank typically receives the fine and may pass it to you. Published fine structures vary by card brand, but the general framework for Level 4 merchants following a breach and found non-compliant:
- Initial fines: $5,000–$10,000 per month of non-compliance
- Extended non-compliance: up to $100,000 per month
- Forensic investigation cost: $12,000–$100,000+ (required following certain breaches, and you pay for it)
- Card replacement costs: Charged to your bank, which may charge them back to you
- Increased transaction fees or processing rate increases
- Potential termination of card acceptance privileges
For a small business processing a modest volume of transactions, a breach plus non-compliance findings often costs more than the entire preceding year’s card revenue. The cost of maintaining compliance — completing the SAQ, maintaining controls, running quarterly scans if required — is a fraction of these figures.
Final Verdict
PCI DSS compliance for a small business is not as complex as the 360-page standard document suggests — if you design your payment environment correctly from the start. The key is scope reduction: if cardholder data never flows through your systems, you qualify for the simplest questionnaire with the fewest requirements.
The practical priority list for a small business in 2026:
- Use a hosted payment page or P2PE terminal — keep card data out of your environment entirely.
- Audit every script loading on your checkout pages and remove anything non-essential (Requirement 6.4.3).
- Enable MFA on all accounts that access payment systems (the v4.0 requirement that catches most small businesses unprepared).
- Complete the correct SAQ for your payment model — not the shortest one, the correct one.
- Run quarterly ASV scans if required, internal vulnerability scans at least every 90 days.
- Maintain written policies, complete the annual risk assessment, and train staff.
For businesses that are new to PCI compliance or haven’t reviewed their status under v4.0.1: start with a conversation with your acquiring bank. They can confirm your merchant level, the specific compliance requirements they need you to meet, and whether any quarterly scanning requirement applies. From there, work through the checklist above.
Frequently Asked Questions
Does PCI DSS apply to my small business?
Yes, if your business accepts credit or debit card payments in any form — in person, online, by phone, or through a mobile reader. There is no size exemption and no revenue threshold. Any organisation that stores, processes, or transmits cardholder data must comply with PCI DSS. The compliance requirements scale with transaction volume (your merchant level), but the obligation to comply exists at all levels.
What is the simplest path to PCI DSS compliance for a small ecommerce business?
Use a fully hosted payment page where customers enter card details directly on your payment processor’s domain (such as Stripe Checkout, PayPal Standard, or an equivalent). This keeps all cardholder data entirely outside your systems, allowing you to qualify for SAQ A — the simplest questionnaire. Important caveat: under v4.0.1, even SAQ A merchants must now inventory and manage all scripts loading on checkout pages (Requirement 6.4.3) and implement tamper detection for payment pages (Requirement 11.6.1). Remove all non-essential JavaScript from checkout pages before your compliance assessment.
What is an SAQ and do I need to complete one?
A Self-Assessment Questionnaire (SAQ) is the compliance validation document that most small businesses complete annually. It is a structured questionnaire about your payment environment and security controls that you complete and attest to, then submit to your acquiring bank. There are multiple SAQ versions (A through D) depending on how you accept payments — completing the correct version for your payment model is essential. Most very small businesses processing less than 1 million annual card transactions are Level 4 merchants and validate compliance through the SAQ rather than through an external QSA assessment. Your acquiring bank sets your specific requirements, so contact them to confirm.
What changed in PCI DSS v4.0 that affects small businesses?
The two changes with the most practical impact on small businesses are: MFA is now required for all access to the cardholder data environment — not just remote access. This applies to in-person POS system access and any internal system that touches cardholder data. Previously, MFA was only required for remote access. Additionally, Requirement 6.4.3 requires ecommerce merchants to maintain an inventory of all scripts loading on checkout pages, authorise each one, and verify their integrity. And Requirement 11.6.1 requires change and tamper detection mechanisms for payment pages. Both 6.4.3 and 11.6.1 were future-dated requirements that became mandatory on 31 March 2025. Both frequently catch small ecommerce businesses unprepared.
What happens if I’m not PCI DSS compliant and there’s a breach?
Card brand fines administered through your acquiring bank: typically $5,000–$10,000 per month of non-compliance initially, escalating to up to $100,000 per month for extended non-compliance. You will likely be required to fund a forensic investigation by a PCI Forensic Investigator (PFI) — this costs $12,000–$100,000 or more depending on the scope of the investigation. You may be liable for the cost of replacing compromised cards. Your bank may increase your transaction fees or processing rates. In severe cases, your ability to accept card payments may be terminated. Cyber insurance policies typically require PCI DSS compliance as a coverage condition — a breach occurring while non-compliant may result in a denied claim.
PCI DSS v4.0.1 is published by the PCI Security Standards Council (PCI SSC). For the official standard document, SAQ forms, and list of Approved Scanning Vendors, see pcisecuritystandards.org. For US government guidance on payment security, see CISA’s guidance for small businesses.
Related reading on SmallBiz Defense: