PCI DSS and GDPR for an online store — what to get right before you accept card payments

PCI DSS, GDPR and NIS2 are three separate obligations that are easy to lump together as one vague "security" problem — and they have very different scopes. PCI DSS only applies to shops that accept card payments, and its actual scope depends on how the card payment is wired in: a redirect to the payment provider's own page gives you the smallest scope, an embedded iframe requires more. GDPR applies to every shop that processes customer data, regardless of the payment method. NIS2, despite the recent attention around it, typically doesn't apply to a single-vendor online shop at all. This article goes through all three, stating clearly what is confirmed at the source and what isn't.

PCI DSS — what it is, who checks compliance

PCI DSS (Payment Card Industry Data Security Standard) is a data security standard for payment card data, developed by the card payment brands and maintained by the PCI Security Standards Council (PCI SSC). The current version of the standard is PCI DSS v4.0.1 — it appears under that title in PCI SSC's own document library, alongside the document "PCI DSS Summary of Changes v4.0 to v4.0.1" (pcisecuritystandards.org/document_library, read 2026-10-01). PCI SSC published v4.0.1 in June 2024 as a limited revision of v4.0 — with editorial fixes and clarifications, but "There are no additional or deleted requirements in this revision" (PCI SSC blog, 11 June 2024, read 2026-10-01).

Who checks compliance? Not PCI SSC itself — the organisation publishes the standard, but verification is carried out by the compliance-accepting entity, usually an acquirer (the merchant's bank for card payments) or a payment brand. PCI SSC's own FAQ is explicit about this: "Merchants should continue to consult with their compliance-accepting entity, the entity to which the SAQ will be submitted (typically, an acquirer (merchant bank) or the payment brands), to determine if the merchant is required to submit an SAQ, and if so, which SAQ is appropriate for the merchant's environment" (pcisecuritystandards.org/faqs/1588, read 2026-10-01). In other words: it's your acquiring bank, or the payment provider you work with, that decides which document you need to fill in — not you, and not this article.

Payment providers publish attestations for their own services — Stripe, for example, says a PCI-certified auditor evaluated it and certified it to "PCI Service Provider Level 1" (docs.stripe.com/security, read 2026-10-01). That certification covers the provider's systems, not your website. Some providers go a step further and tell you which SAQ to file based on how you integrated them (Stripe says it does this in its Dashboard), but your shop's own compliance remains your responsibility.

Which SAQ applies to your shop

SAQ (Self-Assessment Questionnaire) is the self-assessment form a merchant uses to confirm PCI DSS compliance — its scope depends on exactly how the card payment is wired into your site.

If you redirect the customer to the payment provider's own page (e.g. an HTTP 30x redirect, a meta-redirect or a JavaScript redirect) or fully outsource the payment (e.g. an emailed payment link to a TPSP) — that's the smallest scope: you typically qualify for the simplest SAQ A (provided you meet the other eligibility criteria, which your acquirer will confirm), and the specific, additional script-protection criterion does not apply to your shop. PCI SSC's FAQ #1588 states this directly: the SAQ A r1 script criterion "does not apply to e-commerce merchants with a webpage that redirects customers from the merchant's webpage to a TPSP/payment processor […] or e-commerce merchants that fully outsource payment functions to a TPSP/payment processor" (read 2026-10-01). That doesn't mean zero obligation, though — a separate PCI SSC FAQ (#1604) confirms that SAQ A "includes requirements for external vulnerability scanning by a PCI SSC Approved Scanning Vendor (ASV)… even where payment processing is fully outsourced to a third party" — so even with a full redirect, you still need an ASV scan of your own site. A redirect gives you the smallest scope, not a zero one.

If you embed the provider's payment form in an iframe on your own page (the customer pays without leaving your domain, but the card field itself is rendered by the provider's iframe) — the SAQ A r1 script criterion does apply to you. FAQ #1588: "The above SAQ A eligibility criteria only applies to e-commerce merchants with a webpage that includes a TPSP's/payment processor's embedded payment page/form (for example, one or more inline frame(s) (iframes))." In that case you must meet the criterion one of two ways: either apply script-protection techniques against attacks on card data, including those described in PCI DSS requirements 6.4.3 and 11.6.1, or get confirmation from your (PCI-DSS-compliant) iframe provider that their solution already includes such protection — both paths are explicitly listed in the same FAQ.

"PCI 4.0" — what changed, and why 31 March 2025 matters

PCI DSS v4.0 introduced a mechanism for "future-dated requirements" — new requirements announced in advance that could be marked "Not Applicable" in a compliance assessment before their effective date, and had to be fully assessed from that date on (FAQ #1564). For the future-dated requirements introduced in v4.0, that cutoff was 31 March 2025 — the release of v4.0.1 didn't change it (PCI SSC blog, 11 June 2024). PCI SSC also confirms directly that requirements 6.4.3, 11.6.1 and 12.3.1 — covering payment-page security and scripts — have applied since 31 March 2025. In the same announcement it removed them from SAQ A itself, replacing them with the script-eligibility criterion described above, and noted that the change doesn't remove or weaken those requirements in the standard itself (PCI SSC blog, 30 January 2025, read 2026-10-01).

A separate FAQ #1593 (March 2025) covers a narrower point: three requirements that, as of 31 March 2025, replaced their predecessors (which became "Not Applicable"). These are 6.4.2 (automated detection/prevention of web-based attacks on public-facing applications, replacing 6.4.1), 8.3.10.1 (for service providers: a customer password change at least every 90 days or dynamic risk analysis, replacing 8.3.10) and 10.7.2 (detection/alerting/response for failures of critical security control systems, replacing 10.7.1). That's not a full list of what took effect that day — only the items that replaced earlier ones.

The line "PCI 4.0 has been strictly enforced since 2025" is worth reading carefully: PCI SSC states outright that "PCI SSC does not define compliance requirements for any organization or set compliance validation responsibilities" — validation requirements are set by the payment brands and acquirers (PCI SSC blog, 30 January 2025). The requirements are mandatory within the standard; how and when your acquirer checks them is something you settle with them.

GDPR in an online store

GDPR (Regulation (EU) 2016/679) applies to every shop that processes customers' personal data — which covers essentially every online shop, regardless of whether it accepts card payments. Four articles matter most in practice.

Article 6 sets out the legal bases for processing. Fulfilling an order and running a customer account fall under point (b) — processing "necessary for the performance of a contract". Statutory obligations (issuing invoices, keeping tax records) fall under point (c). Direct marketing to existing customers is usually argued under point (f) — processing "necessary for the purposes of the legitimate interests pursued by the controller" — but that is separate from the channel rules for electronic marketing in the ePrivacy Directive (2002/58/EC), Art. 13: marketing by email requires the recipient's prior consent, with one exception — a shop that obtained a customer's email address in the course of a sale may use it to market its own similar products, provided the customer is given a clear, free and easy way to object both at collection and in every message. The directive is transposed into national law, so the details depend on the member state. A shop has to satisfy both sets of rules at once, not one instead of the other.

Article 13 sets an information duty at the point data is collected — paragraph 1 requires disclosing, among other things, the controller's identity, the purpose and legal basis of processing, and, where the basis is point (f), the specific legitimate interest being pursued. Paragraph 2 adds, among other things, the data retention period (or the criteria for setting it), the catalogue of the data subject's rights (access, rectification, erasure, restriction, objection, portability), the right to lodge a complaint with a supervisory authority, and whether providing the data is a statutory or contractual requirement. Paragraph 4 waives this duty where the person already has that information — in practice, that rarely applies to a new customer placing a first order.

Article 28 governs the relationship with processors handling data on your behalf — hosting, a SaaS platform, an email/SMS provider or a fulfilment company. Paragraph 1: "Where processing is to be carried out on behalf of a controller, the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject." Paragraph 3 requires that relationship to be governed by a contract — in practice, a data processing agreement (DPA) you sign with each such processor.

Article 32 requires implementing appropriate technical and organisational measures to ensure "a level of security appropriate to the risk" — "taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons" — including, among other things, pseudonymisation and encryption of data, the ability to ensure the ongoing confidentiality and availability of systems, the ability to restore availability of data promptly after an incident, and regular testing of the effectiveness of these measures. This is the provision that turns technical security practices — access control, backups with a restore test, encryption — into a legal obligation, not just a good idea.

A data breach — 72 hours and two tiers of fines

If a personal data breach occurs (e.g. a leaked customer database after an administrator account is compromised), GDPR Art. 33(1) sets a specific clock: the controller "shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority […] unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons." If the notification reaches the authority after 72 hours, it must include reasons for the delay. If you use an external processor (e.g. a hosting or SaaS platform), their obligation (paragraph 2) is to notify you without undue delay; your own 72-hour clock to your national supervisory authority starts when you, as the controller, become aware of the breach — not when the processor detected it.

The administrative fines under Art. 83 sit on two tiers, and it's worth knowing which provision lands where. The lower tier (paragraph 4) — up to €10 million or up to 2% of total worldwide annual turnover, whichever is higher — covers, among others, breaches of obligations under Articles 25–39, which includes Article 32 (security measures). The higher tier (paragraph 5) — up to €20 million or up to 4% of turnover — covers breaches of "the basic principles for processing, including conditions for consent", which includes, among others, Article 6 (the legal basis for processing). In other words: getting the legal basis for processing wrong in the first place (e.g. processing without any Art. 6 basis at all) is treated by GDPR as more serious than a purely technical slip in security measures — though both tiers are real, and either can apply to an online shop.

NIS2 — does it apply to your shop

The EU law behind this is NIS2, Directive (EU) 2022/2555, which every EU member state had to transpose into its own national law — check your own country's implementing act for its exact name, scope and terminology, since the transposition details differ by member state even though the directive's own thresholds are set EU-wide.

A typical, single-vendor online shop falls outside NIS2's scope for two independent reasons. First: the directive itself (Art. 2(1)) sets a baseline size threshold of medium enterprise or larger (with a narrow list of exceptions that apply regardless of size — e.g. trust service providers, top-level-domain name registries and DNS service providers) — NIS2 applies to entities of a type listed in its Annex I or II "which qualify as medium-sized enterprises under Article 2 of the Annex to Recommendation 2003/361/EC, or exceed the ceilings for medium-sized enterprises provided for in paragraph 1 of that Article". Second, and more fundamental: even a medium-sized shop would still need to fit one of the listed entity types first — and the type closest to e-commerce, "providers of online marketplaces" (Annex II), relies on a definition NIS2 takes from the Unfair Commercial Practices Directive (NIS2 Art. 6(28), pointing to Directive 2005/29/EC, Art. 2(n)): "a service using software, including a website, part of a website or an application, operated by or on behalf of a trader which allows consumers to conclude distance contracts with other traders or consumers". In other words, an intermediary between a buyer and third-party sellers, the way Amazon or eBay operate. An ordinary shop, where the customer contracts directly with you as the shop's own operator, doesn't meet that definition at all, regardless of the company's size.

This reasoning follows from the text of both instruments, not from a regulator's guidance or a court ruling — if you run both your own shop and a platform where other merchants also sell through you (i.e. you operate a marketplace), get that classification checked individually, because it's a materially different legal situation from an ordinary single-vendor shop. The same applies to a company that, alongside the shop, also runs an activity listed in NIS2's own annexes (e.g. certain manufacturing, or food businesses engaged in wholesale distribution and industrial production and processing) and is at least a medium enterprise — there, the classification depends on that other activity, not on the shop itself.

Security checklist

• You've checked with your acquirer or payment provider which SAQ actually applies to you — not guessed from what your checkout looks like.
• If you embed a payment form in an iframe, you have either confirmation from the iframe provider or your own script-protection techniques in place (per the FAQ #1588 criterion) — you haven't just assumed "that's the payment provider's problem."
• Your privacy policy contains everything required under GDPR Art. 13(1)–(2) — the controller's identity, the purpose and legal basis, the retention period, the catalogue of data-subject rights, and the right to lodge a complaint with a supervisory authority.
• You have a data processing agreement (DPA) in place with every processor handling data on your behalf — hosting, SaaS, email/SMS, fulfilment — consistent with Art. 28.
• You have a breach procedure — who notifies the supervisory authority, within what timeframe (72 hours), and what you document as an explanation if that deadline slips.
• You've checked whether your business model even meets the definition of an "online marketplace" — if you're not operating a marketplace, NIS2 most likely doesn't apply, but it's worth having that documented, not just assumed.

If a large part of your sales stack runs on third-party SaaS services (hosting, payments, a cloud ERP), the split of responsibility for data security between you and the provider is a separate, broader topic — we cover it in our article on cloud security.