Data Processing Agreement

Between the client named in the order (the controller, or the processor where it runs sites for its own customers) and Keith Taynton, trading as TrioLMS (the processor, or the subprocessor). It forms part of the client’s agreement for TrioLMS. A TrioLMS administrator accepts it for the client when buying, or on the client account’s Home, and TrioLMS records which version each client accepted, by which owner, and when.

1. What this covers

• Subject matter: hosting and running the client’s TrioLMS sites: accounts, groups, courses, training records, reports, certificates and the built-in learning record store.
• Duration: while the client has an account, then until its data is deleted as in clause 9.
• Nature and purpose: storing, organising, showing, reporting on and deleting the client’s people’s data so they can be trained and their training recorded, as the client directs through the product’s screens, files, API and settings.
• Data subjects: the client’s staff, contractors and other learners (externals), and its own site admins, managers and course authors.
• Personal data: company ID, email address, name, language, and for externals organisation, notes and valid dates; training records (enrolments, attempts, scores, completions, certificates, waivers); xAPI statements and the answers courses put in them; sign-in data (methods, authenticator and passkey records, never a password); and the audit log, with the network address of each change.
• Special category data: none is required or asked for. The client must not put special category data into names, notes or courses it makes.

2. Instructions

TrioLMS processes the data only on the client’s documented instructions, which are this agreement and what the client does in the product. It tells the client at once if it believes an instruction breaks data protection law, and does not process the data for any purpose of its own. Where the client runs sites for its own customers and processes their data for them, the client confirms that it has their written authority to use TrioLMS as its subprocessor on these terms, passes on their instructions only through the product, and answers to them for what it does.

3. Confidentiality

Everyone at TrioLMS who can reach the data is bound to confidentiality. Our staff sign in through Cloudflare Access and an authenticator, can do only what their role allows, and what they change is in the audit log.

4. Security

TrioLMS keeps the measures in the Annex, and keeps them up to date. They include encryption of personal fields with a key per site, tenant-scoped data access tested on every change, and regular penetration tests.

5. Subprocessors

The client authorises the subprocessors listed below. TrioLMS will give at least 30 days’ notice by email to TrioLMS administrators before adding or replacing one, and the client may object on reasonable data protection grounds; if we can’t resolve it, the client may end the affected service and get a pro-rata refund of prepaid fees. Each subprocessor is bound by terms that protect the data at least as well as this agreement, and TrioLMS stays responsible for it.

6. Where data is kept and transfers

Each site’s data is stored only in the region chosen when it was made: UK/EU (Cloudflare’s EU jurisdiction) or US. Requests are handled at the Cloudflare location nearest the person, so data passes through other countries in transit. Where a subprocessor processes UK or EU data outside the UK and EEA, the transfer is covered by the EU Standard Contractual Clauses, the UK International Data Transfer Addendum, and/or the EU-US Data Privacy Framework, as each subprocessor offers.

7. Helping the client

• People’s requests: site admins can download everything held about a person (JSON and a PDF transcript) and erase a person early, without asking us. If a request comes to TrioLMS directly, we pass it to the client and don’t answer it ourselves.
• Assessments: TrioLMS gives the client what it reasonably needs for its data protection impact assessments and any consultation with a supervisory authority.

8. Personal data breaches

TrioLMS tells TrioLMS administrators without undue delay, and within 48 hours, of becoming aware of a breach affecting their data, with what is known: what happened, the data and people affected, the likely consequences and what we are doing. We follow up as we learn more, and keep a record of every breach.

9. End of the service

When the client’s account ends, its sites are paused for 60 days, in which site admins can export every record (people, groups, courses, training records, reports and statements). They are then archived, and deleted 6 months after the account ended, unless the law requires us to keep something. Deleting a site destroys its encryption key, so its backups (kept 30 days) can no longer be read. On request, TrioLMS confirms the deletion in writing.

10. Audits

TrioLMS makes available the information needed to show it meets this agreement: this document, the Annex, the summary of its latest penetration test, and answers to reasonable security questionnaires. The client may audit, or appoint an independent auditor, once a year with 30 days’ notice, at its own cost, and more often after a breach or at a supervisory authority’s request.

11. General

This agreement follows the liability terms of the client’s main agreement. If the two conflict on data protection, this agreement wins. It is governed by the law of England and Wales.

Subprocessors

TrioLMS uses no analytics, advertising or support tools that receive personal data. Our code is kept on GitHub, which holds no client data.

Annex: security measures

Keeping clients apart

• Every site has its own address, and the client, site and region always come from the server’s own session, token or verified address, never from what a request says.
• Every read and write goes through data access scoped to the client and site. Automated tests check isolation on every change: per client, per site, per manager’s groups and per role, across every route.
• Each site’s data lives in one region’s databases and file storage, and nowhere else.

Encryption

• Names, email addresses, company IDs and an external’s details are encrypted with AES-256-GCM using a key that belongs to the site, itself encrypted by a regional master key held in Cloudflare’s secret store. Keys can be rotated.
• People are looked up by keyed hashes (HMAC-SHA256), so the database alone reveals no email address or ID.
• Deleting a site destroys its key, so its data can’t be read from backups.
• Everything travels over TLS, with HSTS.

Signing in

• There are no passwords. Every account is verified first. A sign-in is a one-time 6-digit code sent to the verified email address (10 minutes, 5 tries, only in the browser that asked), or single sign-on.
• Site admins, managers, course authors, externals and TrioLMS administrators also need a second step: an authenticator app or a passkey.
• Sign-ins are rate-limited per person and per network, and after repeated failures a bot check appears.
• Sessions are random 256-bit tokens, stored only as hashes, in cookies that work only on the exact address that set them and that scripts can’t read.
• External accounts work only between their valid dates, checked on every request.
• Our own staff reach the panel only through Cloudflare Access and then an authenticator code.

The application

• Course files are served only from a separate domain that never sets or receives a cookie and has no database access, so a course’s own code can’t reach anyone’s account.
• Every page has a strict Content Security Policy with no inline scripts. TrioLMS runs no third-party code in browsers or on its servers, except Cloudflare’s own bot check on public forms.
• Every request body is size-limited and validated; database queries are always prepared statements.
• Webhooks we receive must be signed; webhooks we send are signed; outgoing requests refuse internal addresses.
• Personal data is never written to logs, error reports or addresses.

Records and resilience

• An audit log records who changed what, when and from which network, kept for the site’s audit period (1 to 10 years, 3 by default).
• Cloudflare D1’s Time Travel can restore any database to a point in the last 30 days, and every night each database is exported into its own region’s storage, where each copy is kept for 30 days.
• Separate staging and production environments; changes are deployed only from reviewed code through GitHub Actions, with the full test suite run first.

Testing

• Every change runs the full test suite: isolation sweeps by role and tenant, sweeps of every route with wrong bodies, and requirement lists traced to the xAPI, cmi5, SCORM and other specifications.
• In October 2026 we penetration-tested TrioLMS ourselves, against its code and its staging environment, from outside and signed in. No exploitable weakness was found.