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

PCI DSS, Swiss data protection law and Switzerland's own critical-infrastructure reporting duty 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. Swiss data protection law applies to every shop that processes customer data, regardless of the payment method. The Swiss critical-infrastructure reporting duty, despite the attention NIS2 gets in the EU, typically doesn't reach 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, which also serves Swiss merchants, 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.

Data protection under Swiss law (FADP)

Switzerland is neither an EU nor an EEA member, so a shop selling in Switzerland works under the Federal Act on Data Protection (FADP, SR 235.1), whose revised version has been in force since 1 September 2023 (Fedlex, FADP, version of 1 September 2023, read 2026-10-01). If you also sell into the EU, GDPR's own rules on territorial scope can apply in parallel; that is a separate question this article doesn't cover.

The FADP is built differently from GDPR. It does not require a listed legal basis for every processing operation; instead, Art. 6 sets principles that every processing must respect: it "must be processed lawfully", "in good faith and be proportionate", and personal data "may only be collected for a specific purpose that the data subject can recognise". Four provisions matter most in a shop's day-to-day work.

Article 19 (duty to provide information when collecting personal data) requires you to tell the customer, at the point of collection, at least the controller's identity and contact details, the purpose of processing and, where applicable, the recipients or categories of recipients of the data. If data is disclosed abroad (for example to a hosting or email provider outside Switzerland), the state it goes to must also be named. In practice, this is what your privacy policy has to cover.

Article 9 (processing by processors) allows you to hand processing to a processor by contract or by law, provided the processor only processes the data the way you yourself would be allowed to, and no duty of confidentiality prohibits it. Paragraph 2 adds that "the controller must satisfy itself in particular that the processor is able to guarantee data security". Hosting, a SaaS shop platform, an email/SMS provider and a fulfilment company are all typical processors.

Article 8 (data security) requires controllers and processors to "guarantee a level of data security appropriate to the risk by taking suitable technical and organisational measures", and the measures "must make it possible to avoid breaches of data security". The Federal Council sets minimum requirements in an ordinance.

The FADP's sanctions also work differently from GDPR's. Instead of administrative fines against the company, Art. 60 and 61 provide for criminal fines of up to CHF 250,000 against the responsible private individuals who act wilfully: for example, failing to give customers the information required under Art. 19, handing data to a processor without meeting the conditions of Art. 9, or failing to comply with the Federal Council's minimum data-security requirements.

Marketing emails follow separate rules, in the Federal Act against Unfair Competition (UWG, SR 241), Art. 3(1)(o): mass advertising by telecommunication without the customer's prior consent is unfair, with one exception. A seller who obtained a customer's contact details in the course of a sale, and told the customer at that point that they can refuse such messages, may send that customer advertising for its "own similar goods, works or services" without separate consent. Every message must show the correct sender and offer a simple, free way to opt out.

A data-security breach: no fixed deadline, conditional notice to customers

Where GDPR gives you a 72-hour clock, the FADP does something different. Article 24 ("Notifications of data security breaches") sets out the core duties in its first four paragraphs:

> "1 The controller shall notify the FDPIC of any breach of data security that is likely to lead to a high risk to the data subject's personality or fundamental rights as quickly as possible.

> 2 In the notification, it shall as a minimum specify the nature of the breach of data security, its consequences and the measures taken or planned.

> 3 The processor shall notify the controller of any breach of data security as quickly as possible.

> 4 The controller shall inform the data subject if this is required for their protection or if the FDPIC so requests."

Paragraph 5 lets the controller limit, delay or dispense with informing the data subject in defined cases, for example where it is impossible or requires disproportionate effort, or where a public announcement reaches the people concerned equally well. Paragraph 6 states that a notification may only be used against the person who made it in criminal proceedings with that person's consent.

Two differences from GDPR stand out. First, Swiss law sets no fixed number of hours: the standard is "as quickly as possible", and the duty to notify the Federal Data Protection and Information Commissioner (FDPIC) only arises where the breach is likely to lead to a high risk. Second, telling the customers themselves is conditional, which is closer to GDPR's own separate, risk-based duty to inform data subjects than the "72 hours vs. no deadline" headline suggests. If you use an external processor (a hosting or SaaS platform, for instance), its duty under paragraph 3 is to tell you "as quickly as possible", not within a fixed number of hours either.

Switzerland's own critical-infrastructure reporting duty

The EU's NIS2 Directive does not apply in Switzerland: directives bind EU member states through national transposition, and Switzerland is not one of them. Switzerland has its own reporting duty for cyberattacks on critical infrastructure, in the Information Security Act (ISA). The amendment introducing it came into force on 1 April 2025: operators covered by it must report cyberattacks to the National Cyber Security Centre (NCSC), a federal office since 1 January 2024 (BACS in German), within 24 hours of discovery, and have 14 days to complete the report (NCSC, information on the reporting obligation, read 2026-10-01).

Who has to report is set out in a closed list in Art. 74b ISA (AS 2024 257, Fedlex): among others, federal, cantonal and communal authorities, energy and drinking-water suppliers, banks and insurers, hospitals, rail and air transport, registered postal service providers, telecoms providers, cloud, search-engine and data-centre operators based in Switzerland, and companies supplying the population with essential everyday goods whose failure would cause serious supply shortages. Under Art. 74c, the Federal Council exempts organisations where disruption caused by an attack would have only a limited effect on the functioning of the economy or the well-being of the population.

An ordinary online shop selling directly to its own customers is not on that list. The one item worth a second look is the last one: a large retailer of everyday essentials could fall under it. Everyone else should still document the conclusion rather than assume it.

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 gives at least what FADP Art. 19 requires: the controller's identity and contact details, the purpose of processing, the recipients or categories of recipients and, where data goes abroad, the countries concerned.
• You have a contract with every processor handling data on your behalf (hosting, SaaS, email/SMS, fulfilment) and have satisfied yourself that each one can guarantee data security (Art. 9).
• Your marketing emails go only to customers who consented, or to existing customers for similar products with an opt-out offered at collection and in every message (UWG Art. 3(1)(o)).
• You have a breach procedure: who assesses whether the risk is high, who notifies the FDPIC "as quickly as possible" (Swiss law sets no fixed hour count, unlike GDPR's 72 hours), and when you also inform the affected customers.
• You've checked Art. 74b ISA and documented that your shop is not on the list of organisations required to report cyberattacks, rather than just assuming it.

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.