Any startup that accepts card payments must follow the Payment Card Industry Data Security Standard, even when a payment gateway does most of the heavy lifting. PCI DSS v4.0.1 contains 64 new requirements compared with the old version, and 51 of them became mandatory after 31 March 2025, according to the PCI Security Standards Council. This guide explains which ones matter for a small online business and how to keep scope small.
Where PCI DSS stands in 2026
PCI DSS v4.0 was introduced in March 2022. Version 3.2.1 was retired on 31 March 2024, and v4.0 itself was retired from 1 January 2025, leaving v4.0.1 as the current text. The 4.0.1 update clarified wording and did not add or remove requirements, according to RSI Security.
The big change for startups was the end of the transition. Requirements listed as best practice since 2022 became mandatory after 31 March 2025 and must now be fully assessed. That includes the e-commerce rules on payment page scripts that affect almost every online checkout.
Pick the right integration to keep scope small
Your checkout design sets your compliance workload. If you redirect customers to a PCI-compliant payment provider, or send payment links, card data never touches your pages. If you embed a provider's iframe or hosted fields, your page still delivers the form, so scripts on it matter. If your own server sees card numbers, you are in full scope.
For most startups the cheapest path is to never store, process or transmit card numbers yourself. Use tokenised payments from your gateway and keep card data out of logs, support tickets and analytics tools. Confirm the right self-assessment questionnaire with your acquirer.
| Checkout pattern | Usual questionnaire | Main effort |
|---|---|---|
| Full redirect or payment link | SAQ A | Vendor due diligence and basic policies |
| Embedded iframe or hosted fields | SAQ A if script criterion met, else SAQ A-EP | Protect the parent page from script attacks |
| Your page posts card data to a provider | SAQ A-EP | Over 100 more requirements than SAQ A |
| Your servers handle card numbers | SAQ D or a full assessment | Full PCI DSS control set |
SAQ A after the 2025 changes
In January 2025 the Council released a revised SAQ A that removed requirements 6.4.3, 11.6.1 and 12.3.1 from the questionnaire. In their place it added an eligibility criterion: the merchant must confirm that its site is not susceptible to attacks from scripts that could affect its e-commerce systems. Merchants who cannot confirm this must use SAQ A-EP.
FAQ 1588, published on 28 February 2025, explained that merchants can meet the criterion with techniques like those in 6.4.3 and 11.6.1, or by getting confirmation from a PCI DSS compliant provider that its embedded payment form includes protections when implemented as instructed. The criterion applies to embedded forms such as iframes, not to full redirects or emailed payment links.
Payment page scripts: 6.4.3 and 11.6.1
These two requirements target e-skimming, where malicious JavaScript copies card details as a customer types. Requirement 6.4.3 says every script on a payment page must be authorised, have its integrity assured and be listed in an inventory with a business reason. Requirement 11.6.1 calls for change and tamper detection on payment pages at least weekly, or as set by a targeted risk analysis.
Rules on skipping them have tightened. A revision of FAQ 1331 dated 4 August 2026 removed the option for a merchant and its QSA alone to mark 6.4.3 and 11.6.1 not applicable in a report. Merchants must now get confirmation from their acquirer or payment brand first, according to Reflectiz.
Access controls every startup should have
Requirement 8.4.2 now calls for multi-factor authentication for all access into the cardholder data environment, covering administrators, users, third parties, remote access and console access. Requirement 8.3.6 raises the minimum password length to 12 characters, or eight where a system cannot support 12.
v4.0.1 also brought back 30-day patching guidance for critical vulnerabilities and exempted accounts using phishing-resistant authentication from some MFA rules. Even if you sit in SAQ A, apply these controls to your payment gateway dashboard, cloud console and code repository, because those accounts can change your checkout.
- MFA on gateway, cloud and repository accounts
- 12-character minimum passwords
- Inventory of every script on checkout pages
- Weekly tamper checks on payment pages
A 30-day plan for a startup
Week one: map every place card data could appear and confirm your integration type with your gateway. Week two: ask your acquirer which questionnaire applies and collect your provider's attestation of compliance. Week three: lock down admin access with MFA and inventory checkout scripts. Week four: complete the questionnaire and set reminders to repeat it each year.
Payment security is a common target. Verizon's 2025 DBIR found ransomware in 44% of breaches, so access controls around payment systems deserve the same care as the checkout itself. XDQ Labs builds payment flows and runs authorised security reviews that check checkout pages for these risks.
Frequently asked questions
Does a startup using Stripe or Razorpay need PCI DSS compliance?
Yes. Every merchant that accepts card payments must comply, but using a compliant provider's redirect or hosted form can shrink the work to SAQ A, a short questionnaire. You still need to protect accounts and pages that could change how customers reach the payment form.
What changed in SAQ A in 2025?
The January 2025 revision removed requirements 6.4.3, 11.6.1 and 12.3.1 from SAQ A and added an eligibility criterion: the merchant must confirm its site is not susceptible to script attacks. FAQ 1588 explains how to meet it. Merchants who cannot confirm it use SAQ A-EP.
When did the PCI DSS 4.0 future-dated requirements take effect?
After 31 March 2025. Until then the 51 future-dated requirements were best practice. They are now mandatory and must be fully considered in assessments, including the payment page script rules 6.4.3 and 11.6.1.
What is the PCI DSS 4.0 password requirement?
Requirement 8.3.6 sets a minimum length of 12 characters. Where a system cannot support 12 characters, the minimum is eight. Requirement 8.4.2 also requires multi-factor authentication for all access into the cardholder data environment.
Sources
- Coffee with the Council Podcast: Guidance for PCI DSS E-commerce Requirements Effective After 31 March 2025, PCI Security Standards Council, 2025
- FAQ Clarifies New SAQ A Eligibility Criteria for E-commerce Merchants, PCI Security Standards Council, 2025
- PCI DSS Future-Dated Controls: 7 Critical Changes That Will Shape Your Security Strategy, Cloud Security Alliance, 2025
- PCI Council Released Update of SAQ A: New Eligibility Criteria Replaces Future-dated Requirements, usd AG, 2025
- PCI Council Revises FAQ 1331: The N/A Path for 6.4.3 and 11.6.1 Just Got Narrower, Reflectiz, 2026
- PCI DSS v4.0.1: Key Updates You Need to Know, RSI Security, 2025
- Verizon's 2025 Data Breach Investigations Report: System intrusion breaches double in EMEA, Verizon, 2025
