Data processing

RODMENA as controller

For this website and our own business correspondence, as set out in our Privacy Policy.

RODMENA as processor

Where we operate or support systems holding your users’ personal data under contract, the work is governed by a signed Data Processing Agreement (Article 28 UK GDPR).

Role

A processor acting for the learning management system customer, which is the controller. Article 28 terms are on the Data Processing Agreement page.

What is processed

The learner identifier the customer’s system supplies, as an xAPI account of home page and name, and the learning records a course sends, including results and scores. Email-style identifiers are refused.

How it is held

Each customer’s data is separated by rules the database enforces. Learner identities, xAPI statements and stored credentials are encrypted by the application before storage. Learner identifiers are stored as keyed tokens together with an encrypted copy the application can recover, and client IP addresses are never stored.

Retention

Per tenant and contractual. The defaults are 1,095 days for registrations and statement bodies, configurable down to one day.

Optional flows

All of it runs inside RODMENA and adds no new sub-processor. When a customer switches it on, saved-state and learner-preference documents are copied one way to the RODMENA LRS and deleted there with the original or at retention. These documents can hold anything a course stores, including free-text answers. On request, statements are cross-checked against the LRS copy for the evidence pack. Statements cmi5 writes itself can carry RODMENA’s xAPI signature, and the signature is removed with the statement at retention or erasure.

Webhooks

Sent only to HTTPS endpoints the customer registers, signed with HMAC-SHA256, carrying ids the customer already holds and timestamps. No learner identifier and no learning record is sent. Events are kept for 30 days.

Erasure

One erasure request reaches both systems. The learner’s records in cmi5 are pseudonymised straight away, their document copies in the LRS are stopped and removed, and the erasure is passed to the RODMENA LRS with a recorded receipt. After a database restore, the restore procedure re-applies all erasures from sealed records kept outside the database. The reason recorded is a ticket reference or a code, never free text about a person.

Return and deletion

Under Article 28(3)(g), a customer’s export runs only after a second person approves it. It is encrypted to the customer’s own key and carries a signed manifest of the tables the customer owns. At contract end, the customer’s data is deleted and the customer receives a signed, timestamped deletion certificate that lists what was removed and what is retained for audit (the tamper-evident audit chain and its anchors). Backups and logs follow their own retention, and LRS data has its own erasure hand-off.

Location

Data stays in the database tier stated above, in the United Kingdom, France and Germany, and is not transferred anywhere else. Course packages and erasure records are encrypted on our host before they are uploaded to object storage.

RODMENA is based in the United Kingdom. Our own systems and their data are hosted in the United Kingdom, France and Germany. Some providers in the register process data elsewhere: Ireland, the United States and other Google locations. Customer deployments run wherever the customer chooses, commonly on the customer’s own infrastructure.

Each provider that processes data outside the United Kingdom, and the safeguard for that transfer, is shown in the register above: OVHcloud, Google Workspace, Anthropic and GitHub. Our Terms are governed by the law of England and Wales.

We help controllers respond to data-subject rights requests (access, rectification, erasure, restriction, portability, objection) within the statutory one-month period. Requests about data we control go to gdpr@rodmena.co.uk.