Data protection

When a customer asks you to delete their data, can you?

Every extension you install puts something in your database, and most never tell you what. Ours do. Each one publishes what it holds about a person, why each field is there and what removes it. One screen shows you all of it, for one customer, across every Kyvero extension you have installed.

What each extension holds

All 17 extensions on this site have a page of their own listing every table they can create, every column in it that is about a person, what that column is for in one sentence, how long it is kept and what an erasure does to it. The pages are generated from each extension's own declaration rather than written beside it, so one cannot describe a column the code does not have, or miss one it does.

The roster behind them is every extension in the repository, not the ones with something flattering to say. Answering is not opt-in: an extension that ships without an answer fails our build, and nothing is a legal answer published as a count of zero rather than as a silence.

Returns Portal, field by field, as an example of one

What we refuse to hold

A column that was considered and not stored is worth more to you than a column that was stored carefully, and it is the half nobody publishes. So each page carries it: what the extension deliberately does not keep, in its own voice, with the reason it does not.

The sharpest one is search. Product Search stores no visitor address, no customer id and no session id against a search, only a daily count per term. OpenCart's own search statistics keep every one of them, which is why core ships that feature switched off. Refusing them is what makes there is nobody here a fact about the schema rather than a promise about our intentions: there is no identifier on the table and none reachable from it, so there is nobody for an access, export or erasure request to be about. Data you never collected cannot leak, cannot be subpoenaed and cannot be got wrong by a setting.

What Product Search deliberately does not hold, and why

One screen, every extension

Customers → Personal Data. An email address or a username in, and out comes every holding: from each of our extensions you have installed, each answering for itself, and from OpenCart itself. There is a Remove it button on the same screen, which does what each declaration said an erasure would do, keeps what the declaration said would be kept, and prints the reason for keeping it at the moment you act.

It is read off the extensions rather than configured: install another one and it answers on the same screen, with no list anywhere for somebody to forget to add it to. Uninstalling an extension deliberately removes nothing, because an OpenCart upgrade is an uninstall followed by an install, and software that dropped its tables on the way out would destroy your data on every routine update.

What the screen does, in the release it arrived in

What the list is

Each page answers the same published list of obligations, row by row, saying how the row was asserted and what the answer is. Each row is keyed by the sub-paragraph of the GDPR it comes from (Article 15 for access, Article 17 for erasure, Article 30 for the record you have to keep yourself), so you can read the source it was taken from and disagree with us. A row nothing asserts fails our build rather than being published as unchecked, so the list has only ever grown together with the checks behind it.

Some rows are machine rules, which read the source at every place they could apply and pass only where they found nothing. The rest are declared, which is a weaker thing and is meant to be read as one: it says what a thing is, not that anybody has looked at it and found it fine.

"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." — The data-protection boundary

What each of those words means, defined once

What OpenCart's own feature does

OpenCart ships its own data-request feature, and we do not replace it. What our screen adds is a report on it: for the person in front of you, what OpenCart's own flow will do and what it will not. We read it on both releases we support and wrote down what we found, including the parts that surprised us.

That report is a page of its own rather than a section here, with the file and the line each finding was read at, and a release named beside each one. It names, plainly, the releases nobody has read it on too. None of it is filed upstream yet, and the page says so line by line rather than implying somebody is on it. Read it before you promise anybody a deadline that depends on it.

What OpenCart's own GDPR feature does, and what it does not

What is still yours

The obligation is on you, not on the software you install, so no extension can be compliant on your behalf, and we will not tell you one is. What we can do is make the mechanisms possible on your store and say plainly where our part stops:

"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." — The data-protection boundary

Your lawful basis is yours. Your consent wording is yours. Deciding how long you keep things, whether an erasure is owed at all, and notifying a breach inside the deadline are yours. The boundary page sets out what the law asks of you beside what these extensions give you toward it, line by line. The lines where the answer is that we give you nothing say so in as many words, which is what makes the rest of them worth reading.

Your job, and our part in it