Data and privacy

LOOP implements Moodle's Privacy API, so everything below also appears in the site's own registry at Site administration → Users → Privacy and policies → Plugin privacy registry.

What LOOP stores about a person

What	Why it is kept
Their compliance status and its dates, per certification	The live compliance picture
Every certificate issued, with the window it covers	The record of who was certified
Every notice sent, with its delivery outcome	Evidence that a person was warned
Notices queued but not yet sent	Work still to do
Every monthly report sent, and the address it went to	Whether the summary reached the person responsible

The record of monthly reports has no user id: the addressee is whoever an administrator typed into a settings box, who need not have a Moodle account at all. It is matched by email address instead — in a subject access request, and in an erasure, where those rows are deleted rather than anonymised.

Administrative decisions — recomputing a validity window, rewriting a notice, sending a test, activating a licence — are recorded as standard Moodle events in the site's log store, Site administration → Reports → Logs, rather than in a table of LOOP's. Retention, export and erasure of those entries belong to the log store.

What LOOP writes outside its own tables

One thing, and only when you ask for it: a configuration file with a custom_field edition row writes CERT_<certification id>_<position> into that course's Certification Edition custom field — the field LOOP creates when it is installed. The edition then follows from the mark, which is what the row is asking for.

It is course configuration, not personal data: no name, no id, no status. It is recorded here because it is the one write an import makes that is not in a LOOP table, and because it is visible to anybody who can edit the course. A course's ID number is never written, by an import or anything else — that field belongs to whoever administers the catalogue.

Importing a configuration is recorded in the site log as one event, with the counts of what it wrote. See The audit trail.

What leaves the site

Only licence traffic, and it carries no student data.

Call	Sends
Activation	A site hash, a one-way hash of the administrator's email address, and the Moodle, plugin and PHP versions
Periodic validation	The site hash, the Moodle and plugin versions, and a count of active users for seat accounting

No name, no email address, no course, no status.

A site activated offline makes no calls at all — see Activate the licence.

Subject access requests

A data export through Moodle's privacy tool returns, for the person concerned:

• their certification status and its dates;
• their certification history;
• the notices sent to them and those still queued;
• entries in the site log, which the log store exports on the site's behalf, not LOOP's.

Erasure

An erasure request anonymises the certification history rather than deleting it: the reference to the person is removed, while the certificate, its validity window and its dates remain, so the compliance record survives and stops being personal data. Their compliance status, the notices sent to them and any notice still queued are deleted outright.

Anonymised rows stay visible in the interface, labelled Anonymised (GDPR erasure), with a filter to hide them. They are deleted permanently once they pass the retention period set by the Anonymised history retention (years) setting, which defaults to seven years.

A queued or sent notice carries a fingerprint computed from the person's id, which would let anybody with database access recompute it against each user until one matched. Those rows are deleted rather than anonymised, so no fingerprint survives.

Entries in the site log are the log store's to handle, not LOOP's. Moodle removes the entries a person performed; an entry recording something done to them keeps their id, because the log store deletes on the actor rather than on the subject.

The reasoning and the wider picture are in The audit trail.