DPO Software for eCommerce: The 2026 GDPR Guide

Key Takeaways

Company size is not a GDPR trigger. Article 37(1) requires a DPO in three cases only — public authority, or core activities involving either large-scale regular and systematic monitoring or large-scale special-category data.
Email retargeting, loyalty programmes and behavioural advertising all appear on the Article 29 Working Party's list of activities that may constitute regular and systematic monitoring — but Article 37(1)(b) fires only where that monitoring is both a core activity and large scale.
Appoint a DPO voluntarily and you inherit the whole regime: Articles 37 to 39 then apply "as if the designation had been mandatory".
The guidance names chief executive and head of marketing among the rule-of-thumb conflicts of interest with the role — the two people a small store is most likely to hand it to.
The Article 30(5) exemption for organisations under 250 persons rarely rescues a store: it falls away where processing "is not occasional", and routine order processing never is.

Introduction

It is the Tuesday after a replatforming, and a customer has emailed asking for the contact details of your data protection officer. Nobody holds the title. One suggestion is to give it to the founder, who signed off the privacy policy. Another is to point privacy@ at the support inbox and move on. The second instinct is closer to right than the first — and neither is a decision to make from the reply window.

Searching for DPO software is its own small trial: half the results are digital purchase order tools, and the privacy-side results that survive are written for banks and multinationals with a standing privacy team. This guide answers what an online store needs to know. Does GDPR require a DPO at all? What does the role do between crises? And what must the tooling cover?

This is informational content, not legal advice.

Most likely not — but the analysis is mandatory, and the answer never turns on your size. Article 37(1) requires a DPO in three cases: you are a public authority; your core activities require regular and systematic monitoring of data subjects on a large scale; or your core activities involve large-scale special-category or criminal-offence data.

The trigger that matters to a retailer is (b): "the core activities of the controller or the processor consist of processing operations which... require regular and systematic monitoring of data subjects on a large scale". Two phrases carry the entire test: core activities and large scale. Employee count, turnover and order volume appear nowhere in Article 37(1) — a 12-person business can be caught, a 300-person business can be outside it.

Where online retail gets close to the line

The Article 29 Working Party — whose DPO Guidelines (WP243 rev.01, adopted 13 December 2016 and last revised 5 April 2017) were endorsed by the EDPB and remain the reference text — lists "email retargeting", "data-driven marketing activities", "profiling and scoring for purposes of risk assessment", "loyalty programs" and "behavioural advertising" among activities that may constitute regular and systematic monitoring. None of those are exotic; they are Tuesday.

But the trigger is conjunctive, and this is where the generic guides stop short. Monitoring alone does not require a DPO. It must also be a core activity — the key operations needed to achieve the organisation's goals, including processing that forms an inextricable part of them. A hospital cannot deliver care without processing health records, so that is core; things every organisation does, such as paying employees or running standard IT support, "are usually considered ancillary functions rather than the core activity."

Our read, and it is a position rather than a certainty: where a store's business is selling products and its tracking exists to sell those products, the monitoring is instrumental rather than core. The trade-off is that you are drawing a line the guidance declines to draw — it offers "behavioural advertising by a search engine" as large-scale processing, no equivalent for a mid-size retailer, and concedes "there is a large grey zone in between these extremes." A store whose product is audience data rather than merchandise should conclude the opposite.

The four factors that decide "large scale"

The GDPR does not define large-scale processing. WP243 rev.01 recommends weighing four factors:

"The number of data subjects concerned - either as a specific number or as a proportion of the relevant population"
"The volume of data and/or the range of different data items being processed"
"The duration, or permanence, of the data processing activity"
"The geographical extent of the processing activity"

For calibration, it treats "processing of customer data in the regular course of business by an insurance company or a bank" as large scale, and an individual physician's patient records as not.

Write the decision down — especially when the answer is no

This is the step almost everyone skips, and the cheapest insurance in the exercise. WP243 rev.01 recommends documenting the internal analysis "in order to be able to demonstrate that the relevant factors have been taken into account properly", and treats it as "part of the documentation under the accountability principle". Appoint voluntarily and you take the whole package: the requirements of Articles 37 to 39 then apply "as if the designation had been mandatory".

If you decide against a DPO but still want someone owning privacy — which most stores should — be careful with the job title. Nothing prevents you employing staff or consultants on data-protection tasks, but the guidance says "it should be made clear, in any communications within the company, as well as with data protection authorities, data subjects, and the public at large, that the title of this individual or consultant is not a data protection officer (DPO)." Call the role Privacy Lead. Do not print "DPO" on a business card you did not mean to sign up for.

What Does a Data Protection Officer Actually Do?

Article 39(1) sets five minimum tasks, and Article 39(2) requires the DPO to have "due regard to the risk associated with processing operations". In the Regulation's wording, the tasks include:

"to inform and advise the controller or the processor and the employees who carry out processing…"
"to monitor compliance with this Regulation, with other Union or Member State data protection provisions…"
"to provide advice where requested as regards the data protection impact assessment…"
"to cooperate with the supervisory authority"
"to act as the contact point for the supervisory authority on issues relating to processing…"

What makes the role tractable for a small team is Article 39(2). WP243 rev.01 reads it as a mandate to prioritise: focus primarily on higher-risk areas without neglecting the rest. That judgement drives which processing gets a data protection impact assessment, what an audit covers, and which training gets written.

The record of processing is the DPO's instrument, not the DPO's duty

This is the most common inversion in the field, and it changes what you should buy. Under Article 30(1) and (2) it is "the controller or the processor, not the DPO, who is required to maintain a record of processing operations…" — though "nothing prevents" assigning the DPO that task. WP243 rev.01 frames the record as "one of the tools enabling the DPO to perform its tasks of monitoring compliance, informing and advising the controller or the processor."

So the record of processing activities is the instrument the whole role reads from, not a filing obligation discharged once a year. If it is stale, every downstream task — DSAR searches, retention reviews, breach scoping, vendor assessments — runs on stale inputs.

The 250-employee exemption that usually is not one

Article 30(5) disapplies the record-keeping obligations for "an enterprise or an organisation employing fewer than 250 persons" — but only "unless the processing it carries out is likely to result in a risk to the rights and freedoms of data subjects, the processing is not occasional, or the processing includes special categories of data…".

Those carve-outs are joined by "or", not "and", so any single one defeats the exemption — and the middle one is fatal for a functioning shop. Processing customer orders is continuous, systematic and central to the business; it is the opposite of occasional. Treat the 250-person threshold as not applying to you, and maintain the record. The exemption is written for the plumber with a customer list, not for a store processing thousands of transactions a month.

What DPO Software Has to Cover

DPO software is not a category the GDPR defines; it is whatever gives the role its evidence base. Working back from Article 39(1), a store-sized toolset needs nine things:

Capability	What the role uses it for	GDPR anchor
Record of processing activities	The inventory every other task reads from	Art 30(1)
DSAR intake and response clock	Proof of what was searched, what was sent, when	Art 12(3)
Consent and proof-of-consent records	A lawful basis existed at the moment of collection	Art 7(1)
DPIA workflow	The Article 39(1)(c) advice task, with a written trail	Art 35
Breach register and notification timer	The 72-hour duty, and decisions not to notify	Art 33
Retention schedule	The "envisaged time limits for erasure" field	Art 5(1)(e)
Processor and sub-processor register	Who you share data with, under which contract	Art 28
AI and automated-decision inventory	Oversight of recommendation, pricing and fraud models	Art 22
Published DPO contact details	The publish-and-notify duty, which is two obligations	Art 37(7)

Two of those rows are routinely built wrong.

The DSAR clock is evidentiary, not just a timer. Article 12(3) gives you "one month of receipt of the request", extendable "by two further months where necessary, taking into account the complexity and number of the requests" — a decision someone has to record. Tooling that only counts down, without capturing what was searched and why an extension was taken, leaves the DPO unable to demonstrate anything later; see automating subject access requests.

The breach register is a standing obligation, not a crisis artefact. Article 33(1) requires notification "without undue delay and, where feasible, not later than 72 hours after having become aware of it", unless the breach "is unlikely to result in a risk to the rights and freedoms of natural persons". Article 33(5) then requires documentation of any breach — including those you correctly decided not to report, which is exactly the decision you will be asked to justify. Our breach notification guide covers the mechanics.

The AI row is the newest: recommendation engines, dynamic pricing and fraud scoring are all processing the DPO has to describe, so that inventory belongs alongside the record — see our guide to AI governance. And if budget forces a single choice, buy for the Article 30 record: every other capability degrades gracefully when it is manual, but the record does not, because everything else reads from it.

How to Choose DPO Software for an Online Store

Start from your Article 37 analysis, not from a feature list. If you concluded no DPO is required, you are buying a privacy operations system for a Privacy Lead — same tooling, different title, different governance story.
Check the record against Article 30(1) field by field — purposes, categories of data subjects and personal data, recipients, third-country transfers, "the envisaged time limits for erasure of the different categories of data", and a description of the Article 32(1) security measures. A tool that cannot express erasure timelines is not an Article 30 record.
Make it connect to where your data actually lives — storefront, email service provider, helpdesk, fulfilment partner. A register maintained by hand drifts from reality within a quarter.
Insist on an immutable audit trail. Article 38(3) says the DPO "does not receive any instructions regarding the exercise of those tasks" and "shall directly report to the highest management level". Independence is hard to demonstrate where the marketing team can quietly edit a record.
Size the tool to your actual volume. The strongest competing content in this category is written for organisations handling 51 to 100 DSARs a month. If you handle four, enterprise workflow tooling costs more to configure than it saves.
Compare against the cost of the human, honestly. Engage Compliance, a fractional-DPO provider, published a 2026 benchmark (reviewed 20 June 2026) putting outsourced DPO services at €1,150–€2,900 per month and an in-house DPO at €80,000–€150,000 per year before benefits and recruitment. Treat those as directional — it is a vendor's own marketing material, drawn from "more than 20 anonymised privacy engagements across 2024 to 2026". The point survives the caveat: software and a person solve different problems.

Common Mistakes

1. Making the founder or the head of marketing the DPO. The worst of the four: the most common, and the most clearly addressed. Article 38(6) requires that other duties "do not result in a conflict of interests", and WP243 rev.01 is specific — the DPO "cannot hold a position within the organisation that leads him or her to determine the purposes and the means of the processing of personal data". Its rule of thumb names "senior management positions (such as chief executive, chief operating, chief financial... head of marketing department, head of Human Resources or head of IT departments)". In a 30-person store, those are precisely the candidates who volunteer.

2. Treating the DPO as the person who takes the blame. WP243 rev.01 states it plainly: "DPOs are not personally responsible in case of non-compliance with the GDPR", because Article 24(1) puts the duty to ensure and demonstrate compliance on the controller. Appointing a DPO does not transfer liability; it buys advice and monitoring.

3. Publishing nothing, or publishing without notifying. Article 37(7) contains two obligations: "The controller or the processor shall publish the contact details of the data protection officer and communicate them to the supervisory authority." An address on the privacy page satisfies half of it. The guidance also wants details that let people "reach the DPO in an easy way (a postal address, a dedicated telephone number, and/or a dedicated e-mail address)".

4. Believing the UK swapped the DPO for a "senior responsible individual". It did not, and the misconception is still circulating. That model belonged to the Data Protection and Digital Information Bill, which never became law. Comparing the enacted Data (Use and Access) Act 2025 with its predecessor, Stephenson Harwood wrote that "The DPDI Bill would have replaced DPOs with Senior Responsible Individuals" while "The DUAA keeps the DPO requirement unchanged". Run the Article 37 analysis as before.

How PrivacyForge Helps

PrivacyForge is not a DPO, and no software is. What it does is hold the evidence base the role runs on, in one place instead of six.

The record of processing is built around the Article 30(1) fields, including retention periods and security measures, so it functions as an Article 30 record rather than a diagram. DSARs run through a workflow that timestamps receipt, tracks the one-month clock and records extensions with their reasons. Consent is stored as proof — what was shown, what was agreed, when. The breach register captures every incident, including those assessed as not notifiable.

Still deciding whether you need any of it? Our complete guide to GDPR compliance is the better starting point.

Frequently Asked Questions

Does my eCommerce business need a DPO?

Usually no, but you must run the analysis. Article 37(1) turns on three triggers: public authority status, core activities requiring regular and systematic monitoring on a large scale, or core activities involving large-scale special-category or criminal-offence data. Company size is not a factor. Most stores fall outside all three, because tracking serves the business rather than being the business.

Can the founder or CEO be the data protection officer?

No, in almost every case. Article 38(6) requires that other duties create no conflict of interests, and the Article 29 Working Party's DPO Guidelines name chief executive, chief operating, chief financial officer, head of marketing, head of HR and head of IT as rule-of-thumb conflicting positions. The test is whether the person determines the purposes and means of processing.

Can we outsource the DPO role?

Yes. Article 37(6) states the DPO "may be a staff member of the controller or processor, or fulfil the tasks on the basis of a service contract", so an external or fractional DPO is expressly permitted. The independence requirements in Article 38 apply either way, and you still have to publish their contact details and notify your supervisory authority under Article 37(7).

Is the DPO personally liable if our company is fined?

No. WP243 rev.01 states that "DPOs are not personally responsible in case of non-compliance with the GDPR", because Article 24(1) places the obligation to ensure and demonstrate compliance on the organisation as controller. The DPO advises and monitors. Liability for the organisation's processing stays with the organisation.

Did the UK replace the DPO with a senior responsible individual?

No. That model was in the Data Protection and Digital Information Bill, which never became law. Reviewing the enacted Data (Use and Access) Act 2025, law firm Stephenson Harwood wrote that "The DUAA keeps the DPO requirement unchanged". UK-facing stores should continue to apply the Article 37 analysis as before.

What is the difference between DPO software and a DPO?

A DPO is a person with statutory tasks under Article 39 and statutory protections under Article 38. DPO software is the evidence base that person works from: the record of processing, the DSAR trail, consent proof, the breach register. Software cannot hold the appointment, and a DPO without maintained records cannot do the monitoring the role requires.

Conclusion

The honest answer for most EU and UK online stores is that GDPR does not require a data protection officer — and that this changes less than you would hope. The Article 30 record still has to exist, because the fewer-than-250-persons exemption dies on "not occasional". Subject access requests still run to a one-month clock. Breaches still need documenting even when you correctly decide not to notify. The work does not disappear with the job title; only the statutory protections do.

So run the Article 37 analysis, write down the conclusion, and buy tooling for the workload rather than the title. If you do appoint someone, appoint someone who does not also decide how customer data gets used.

Start with PrivacyForge and build the record everything else reads from.

Sources

#DPO #GDPR #eCommerce #compliance #data mapping