In this guide (10)
- 1The data an ecommerce actually processes
- 2Checkout and payments: what's on you, what's on the gateway
- 3Cookies, pixels and remarketing: where almost everyone goes wrong
- 4Post-sale emails and soft spam
- 5If the store is breached: the 72 hours
- 6Record of processing activities and DPIA: when they're actually needed
- 7Risk area, obligation, who handles it
- 8What KeideaCMS currently states (and what it doesn't)
- 9Checklist before launching or renewing your ecommerce
- 10Sources and verification date
An ecommerce doesn't just handle a name and an email: it handles addresses, order history, payment methods and browsing behavior, often cross-referenced with advertising pixels. Knowing who is responsible for what, between you and the providers you use (payment gateway, platform, marketing tools), avoids both legal risk and commercial promises that no one can actually keep.
An ecommerce doesn't just deal with "a name and an email". It deals with billing and shipping addresses, order history, payment data (even just passing it through), browsing behaviour and, almost always, remarketing cookies that talk to Meta or Google Ads. It's a broader scope than that of a showcase website, and it must be treated as such.
This guide is not a law course and does not replace a privacy consultant for your specific case. It's for those who run (or are about to open) an online store and want to understand which obligations are real, who is responsible between you and the providers you use, and where the most common mistakes hide.
The data an ecommerce actually processes
A customer account, in itself, is no different from that of a site with a contact form: name, email, maybe a phone number. What changes in an ecommerce is everything that gets added around the purchase:
Billing and shipping addresses, often different from each other, and sometimes linked to multiple recipients.
Order history: what they bought, when, with what average spend. It's a profile, even if you don't call it that.
Payment data, even when you don't store it yourself: the fact that it "passes through" your site towards a gateway still involves you in the chain of responsibility.
Browsing behaviour: abandoned carts, viewed products, time on pages, often collected by third-party cookies and pixels.
Data for invoicing, particularly for business customers: VAT number, tax code, recipient code.
The point is not to build up fear, but clarity: the more categories of data you process, the more the obligations for providing notice increase (Art. 13 of the GDPR) and the decisions about where that data lives, for how long, and who can see it.
Checkout and payments: what's on you, what's on the gateway
The actual payment data, card number and CVV, is what most online merchants should never see directly. PCI DSS standards (Payment Card Industry Data Security Standard) exist precisely to define who handles that data and with what guarantees.
For merchants who fully outsource card processing, typically by redirecting the customer to a payment page hosted by a compliant provider (Stripe, PayPal, Nexi and similar) or integrating it via iframe, the PCI Security Standards Council provides a simplified self-assessment questionnaire, the SAQ A. With the update to version 4.0.1, in effect since March 31, 2025, the Council added specific criteria for iframe integrations: the merchant must confirm that their site is not exposed to script attacks that could compromise the payment page, obtaining written confirmation from the third-party provider or independently applying the measures set out in requirements 6.4.3 and 11.6.1 of the standard.
In practice, for those selling online the right question to ask your ecommerce provider or your developer is not "are payments secure?", but:
Does the card number ever pass through my server, even for an instant?
Is the integration via redirect, hosted form or iframe?
Which SAQ level (PCI DSS self-assessment) applies to me with this integration?
Who takes responsibility if the gateway itself is breached?
On KeideaCMS, card, PayPal and bank transfer payments are stated to be integrated into the core via Stripe and PayPal: the card number therefore does not pass through as free text stored in the site's database, but the exact SAQ level depends on the type of technical integration used and must be verified with the payment provider for the specific case, not assumed beforehand.
Cookies, pixels and remarketing: where almost everyone goes wrong
The Italian Data Protection Authority, with the "Guidelines on cookies and other tracking tools" (measure no. 231 of 10 June 2021), clarified some points that remain the most frequent mistake on Italian ecommerce sites:
Consent must come from an unambiguous positive action. Simply scrolling the page does not count as consent.
Profiling cookies (including Meta and Google Ads advertising pixels) require prior consent: they cannot be active by default, in line with the privacy by design and by default principle of Art. 25 of the GDPR.
The cookie wall, i.e. forcing the user to accept cookies in order to use the site, is considered unlawful: it violates the requirement of freely given consent.
The typical mistake on an ecommerce site is not the absence of the banner: it's the remarketing pixel that fires anyway, perhaps because it's installed directly in the theme or through a tag manager configured "across the board", even before the user clicks on anything. If you run retargeting on those who abandoned their cart, that list of users is built with data collected by a profiling cookie: it must be blocked until consent is given, not just declared in the privacy policy.
Post-sale emails and soft spam
After a purchase, many ecommerce sites automatically sign the customer up to the newsletter. The GDPR allows, under certain conditions, the sending of commercial communications about similar products or services to those who have already made a purchase, even without explicit consent collected separately: this is the practice known as soft spam. The key conditions are that the customer was clearly informed of this possibility at the time the data was collected, and that they are always offered, easily and free of charge, the option to opt out, both at the time of collection and in every subsequent communication.
Two common mistakes: signing up those who have made a single purchase to the generic newsletter (not just similar products), and failing to include a clear unsubscribe link in every email. If the customer has not given explicit and broad consent to marketing, the scope remains narrow: products similar to the one purchased, not the entire catalog or third-party communications.
If the store is breached: the 72 hours
If an ecommerce site suffers a personal data breach, for example unauthorized access to the order database, the data controller must notify the Data Protection Authority within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to people's rights (Art. 33 GDPR). If the risk to the data subjects is high, it must also be communicated directly to the customers involved, without undue delay (Art. 34 GDPR).
The practical point: the 72 hours start from discovery, not from when you've finished understanding everything that happened. A written procedure, even a brief one, stating who decides, who writes to the Data Protection Authority and who notifies customers, avoids wasting precious hours figuring out who should handle it while the clock is already running. If the site is under attack right now, the procedure for the first hours is covered in the guide on hacked website, what to do; the topic of backups to restore from is covered in website backup.
Record of processing activities and DPIA: when they're actually needed
The record of processing activities (Art. 30 GDPR) is not reserved for large companies: it also applies to anyone who processes data on a non-occasional basis, which is true for any ecommerce site with recurring customers. Keeping it up to date, with the categories of data processed, the purposes and the providers involved (platform, payment gateway, courier, email marketing tools), is often the first document requested in the event of an audit.
The impact assessment (DPIA, Art. 35 GDPR) is a different level: it's needed when the processing is likely to result in a high risk, for example with systematic and extensive profiling used for decisions that produce significant effects on people, or large-scale systematic monitoring. An ecommerce site that does standard remarketing, with consent collected correctly, does not usually automatically fall within this scope: but the assessment must be made on the specific case, not taken for granted either way.
KeideaCMS
Want to know what's happening today to customer data on your current ecommerce site?
Request a security audit →Contact
Risk area, obligation, who handles it
| Area | What the law requires | Who handles it | Common mistake |
| Accounts and orders | Clear privacy notice (Art. 13), adequate technical measures (Art. 32) | Site owner | Generic privacy policy, downloaded from a template |
| Cookies and remarketing pixels | Active consent, no pre-checked boxes (Data Protection Authority, 2021) | Owner + ad platforms | Pixel already active before consent |
| Payment data | PCI DSS scope, SAQ depending on integration type | Payment gateway | Saving card numbers "for convenience" outside the gateway |
| Post-sale emails | Soft spam only for similar products, opt-out always visible | Site owner | Generic newsletter without explicit consent |
| Data breach | Notification to the Data Protection Authority within 72 hours (Art. 33), to customers if risk is high (Art. 34) | Site owner | Waiting to "understand everything" before starting the procedure |
What KeideaCMS currently states (and what it doesn't)
On the security page, as of September 18, 2026, KeideaCMS declares a native WAF in the core, AES-256-CBC encryption of data entered in forms (name, email, phone, message), TOTP two-factor authentication, 6-level file scanning, geo-blocking from non-EU countries, and an audit trail with configurable log retention, with explicit reference to Article 32 of the GDPR and the technical measures required by the NIS2 directive. On the ecommerce development page, card payments, PayPal and bank transfer are declared as integrated into the core via Stripe and PayPal, with a payment register and automatic order reconciliation.
It's worth being precise about what this covers and what it doesn't. The encryption declared concerns form fields: it is not described, on that page, as automatically extending to the entire order database or to payment data, which remains within the scope of the gateways used. A managed CMS can reduce certain technical risks (WAF, file scanning, protected access), but it does not replace the obligations that remain with the data controller: privacy notice, consents, record of processing activities, data breach procedure. We do not present any platform, including our own, as "GDPR compliant" simply because it is used: compliance is a set of technical and organizational measures, not a feature to switch on. The technical comparison with other solutions is on the comparison page; the general overview of GDPR obligations for a website, not specific to ecommerce, is in the GDPR website guide.
Checklist before launching or renewing your ecommerce
A privacy policy written for your store, not a generic template copied from another site.
A cookie banner with active consent: no pre-checked boxes, no cookie wall.
Remarketing pixels (Meta, Google Ads) blocked until the user gives consent.
Written confirmation with your payment provider on the type of integration (redirect, hosted, iframe) and the SAQ level that applies to you.
No card data saved in notes fields, spreadsheets or internal emails.
Post-sale emails limited to similar products unless there is explicit consent, with an always-visible unsubscribe link.
A written data breach procedure: who decides, who notifies the Data Protection Authority, within how many hours, who informs customers.
An up-to-date record of processing activities, even for a small store.
Data retention defined by category (orders, invoicing, marketing), not "forever" by default.
Check, with a consultant if needed, whether your type of profiling requires a DPIA.
None of these points makes an ecommerce invulnerable or automatically "compliant." They are the obligations and questions that, once verified and put in writing, avoid the most costly part of an incident: finding out afterwards that no one knew who was supposed to do what.
Sources and verification date
Checked on September 18, 2026. The regulations describe general obligations: their application to your specific case should be verified with a privacy or legal consultant. The product pages describe what the provider states, not a certification of compliance.
Regulation (EU) 2016/679 (GDPR), Articles 13, 25, 30, 32, 33, 34, 35, 37.
Italian Data Protection Authority (Garante per la protezione dei dati personali), Guidelines on cookies and other tracking tools, order no. 231 of June 10, 2021.
PCI Security Standards Council, FAQ: How does an e-commerce merchant meet the SAQ A eligibility criteria for scripts? (v4.0.1 criteria, in effect since March 31, 2025).
KeideaCMS, security page and ecommerce development page.
