What these extensions do about data protection, and what is still yours¶
You are the controller. We are not your processor.
Your customers' data is on your server, in your database, under your control. We never see it, never hold it and are not a party to your processing. What these extensions do is make the mechanisms the regulation names possible on your store: showing you everything held about one person, handing that answer over as a file, and removing it.
That is a part of what the law asks of you. It is not the whole of it, and installing an extension is not a compliance process.
Your job, and our part in it¶
| What the law asks of you | What these extensions give you toward it |
|---|---|
| Answer a request within a month. Somebody asks what you hold about them, asks for a copy of it, or asks for it to be removed, and you have a calendar month to answer. | Every extension publishes, field by field, what it puts in your database about a person and what removes each field, so the answer is read off a page rather than reconstructed out of the database on the day it is asked for. One screen answers for every installed extension at once, and a button on it hands that answer over as a JSON file you can send to the person who asked, structured and machine-readable rather than a screenshot. What the file carries is that same field-by-field answer and not the field values: it tells somebody what is held about them and what removes each of it, which is not the same as handing them the data. Supplying the data itself (the right Article 20 calls portability) is not something these extensions do, and the page for each one says so under that article rather than leaving you to find out. |
| Keep your own record of processing. Article 30 asks you for a document saying what you process, why, who sees it and how long you keep it. | Each extension's page is written to be copied into that record: the table, the column, the one sentence saying why the column is there, and the period it is kept for. |
| Decide your lawful basis. Which of the six grounds you are relying on for each thing you do with a customer's data, and being able to say so. | Nothing. |
| Write consent wording that is valid. Where you rely on consent, it has to be freely given, specific, informed and as easy to take back as it was to give. | Where anything an extension does rests on somebody having agreed to it, the declaration names the wording they agreed to, where the proof of it is recorded, and the path by which they withdraw it. A missing withdrawal path fails our build. The wording itself is yours to write. |
| Decide how long you keep things. Storage limitation is a decision about your business, and the regulation asks you to have made it rather than to have defaulted into it. | Every table an extension can put in your store answers what makes a row holding a person go away: one of six verdicts, and a table answering never says why in the same breath. Where the period is yours, it is a setting rather than a number baked into the code. |
| Decide whether an erasure is owed. A request to be forgotten is not always owed, and the exemption you rely on when it is not is one you have to be able to state. | What an erasure deliberately keeps is published with the reason it was kept, and the screen states that reason to you at the moment you act. Whether the request is owed at all is a judgement about your business, and it stays yours. |
| Notify a breach within 72 hours. Working out whether something is a notifiable breach, telling your supervisory authority, and telling the people affected where the risk is high. | Nothing. |
Two rows say nothing in the second column, and they are the two worth reading first. Your lawful basis and a breach notification are decisions and duties that sit on you, and no configuration of any software puts them anywhere else. A supplier claiming a contribution to every line of that table is a supplier whose boundary is worth nothing on the lines where it matters; these two are blank so that the other five mean something.
The sentence we hold ourselves to, which does not bind us¶
There is exactly one sentence in the regulation addressed to somebody in our position rather than yours, and it is in the article about processors:
taking into account the nature of the processing, assists the controller by appropriate technical and organisational measures, insofar as this is possible, for the fulfilment of the controller's obligation to respond to requests for exercising the data subject's rights laid down in Chapter III;
Source: General Data Protection Regulation, Article 28(3)(e)
We are not your processor, so that sentence does not bind us. We never receive your customers' data and never process it on your behalf; there is no Article 28 contract between us because there is nothing for one to govern. We hold ourselves to it anyway, because it is the best description anybody has written of what a supplier ought to make possible (access, export, erasure), and because it names those three as assistance to the controller, which is exactly the size of the claim we are able to make. Telling you we were your processor, when we hold nothing of yours, would be a larger overstatement than any badge.
What a regulator asked for, and of whom¶
The European Data Protection Board's guidelines on data protection by design and by default close with recommendations. One of them is this:
The EDPB recommends controllers to require that producers and processors demonstrate how their hardware, software, services or systems enable the controller to comply with the requirements to accountability in accordance with DPbDD, for example by using key performance indicators to demonstrate the effectiveness of the measures and safeguards at implementing the principles and rights.
Source: EDPB, Guidelines 4/2019 on Article 25 Data Protection by Design and by Default, version 2.0, paragraph 96
That is a large part of why these pages exist at all: what you are reading is the thing a regulator suggested you go and ask us for. It is also, read on its own, easy to misread as an obligation on us, so here is the paragraph two above it, from the same page of the same document:
Although not directly addressed in Article 25, processors and producers are also recognized as key enablers for DPbDD, they should be aware that controllers are required to only process personal data with systems and technologies that have built-in data protection.
Source: the same guidelines, paragraph 94
Not directly addressed. The duty is yours; the recommendation is that you demand this of the people who sell you software. We publish it because it was asked for, not because we are required to. You would have found paragraph 94 in a minute anyway, so it may as well be here beside 96.
Why there is no badge¶
You will not find a compliance badge on this site, and that is deliberate. Displaying a trust or quality mark without the authorisation behind it is prohibited outright in every EU Member State (Unfair Commercial Practices Directive, Annex I, items 2 and 4), and a GDPR certificate can only be issued by an accredited body, to a controller or processor, about specific processing operations, never to a piece of software. Anyone showing you one for an extension is showing you a picture.
What the words mean¶
Each extension's own page states a row per obligation, with how the row was asserted, what the answer is, and, table by table, what makes a row holding a person go away. Those words are defined here, once, so that one page per extension cannot drift into as many readings of them.
The one to read twice is declared. It is not a pass. It says the extension
has written down what the thing is and that the declaration ships beside the
code; it does not say anybody has looked at the thing and found it fine.
How a row is asserted¶
| Mode | What it means |
|---|---|
machine |
A rule decidable from syntax over an enumerable set of sites, with zero false positives across every extension. Not "few": a rule needing a suppression list has already failed. |
declared |
An object the extension declares. Not a pass: it says what the thing is, and licenses scope rather than clearance. |
proven |
A test that ran and passed on a real store. Never rendered from a check run. |
What the answer says¶
| State | What it means |
|---|---|
checked |
A rule ran over an enumerable set — every column the extension's schema can put in a store — and found nothing unaccounted for. Published with its count, because a count of zero says "vacuously true" better than a further state would, and it is how an extension that holds nothing about a person publishes that. |
not met |
The obligation is unmet. Published with what is wrong and where, so that a defect cannot move from one column to another without this page changing. |
declared |
Not a pass. The extension has declared the object the row is about, and that declaration ships beside the code and renders onto this page. It says what the thing is; it does not say the thing is fine. |
not checked |
Nothing qualifies. A row no arm asserts fails the build, so this state exists in the vocabulary in order to be unreachable. |
What makes a row go away¶
| Verdict | What it means |
|---|---|
expires |
The row carries the moment it dies, computed when it was written — a subscription's expiry, whose period is part of the consent wording the shopper read. |
swept |
A pass deletes rows past a window: a cron of its own, or opportunistically off an index on the next write. The vocabulary does not care which, because a merchant asking what makes this go away is not asking about a cron row. |
blanked |
The row survives and the personal columns are emptied. The one nobody would have invented and the catalogue's best answer: a sweep with a defensible remainder, where what survives is a counter proving one order was asked once and holding nothing about a person. Calling it swept would tell a merchant the row is gone when most of its columns are not. |
with_subject |
It goes when the person goes, on an event rather than on a clock. |
overwritten |
No value persists; the next one replaces it. It survives the you-are-not-going-to-need-it test at one column in one extension because the alternative — never plus an explanation that no single value actually survives — is accurate and misleading to anybody scanning a column of verdicts for red flags. |
never |
Nothing removes it, and a reason is required. Often the right answer and sometimes the only one: a suppression list and a consent proof are both kept precisely so that the store can show what it was asked and what it was allowed. |
OpenCart's own feature is underneath all of this¶
A stock OpenCart store already ships a data-request feature of its own: a request form, an email verification step, a queue in the admin and a cron that acts on it. We do not replace it, and nothing on this page is about it.
What it does, what it does not, and the six things about its flow a merchant is better off knowing before they rely on it are written down separately, with the file and line each was read at: What OpenCart's own GDPR feature does, and what it does not. It is a sibling of this page rather than a section of it, because a position about the law and a list of somebody else's defects each read worse in the other's company.
Every extension, and what it holds¶
One row per extension we ship, and there is no row for an extension that has not declared: not declaring fails our build, so a roster with a gap in it is one that could not have been committed. That is the point of it: a roster you cannot trust to be complete is a roster that tells you nothing.