Information security statement

This statement describes how rTraining protects the training records it holds: who can see what, how sign-in works, what is logged, and how to report a weakness. It is written for the person filling in a procurement or security questionnaire, and it describes what the platform does rather than what we intend. Where something is not yet in place, it says so.

The principle

A person's training record belongs to them. An organisation that sponsored their training can see the part of it created while it sponsored them, and nothing wider. Both rules are enforced in the database, not only in the pages that show the data, so a mistake in the application's code cannot by itself expose one person's or one customer's records to another.

Who can see what

• Row-level security is on for every table. Each table decides, row by row, who may read or change it, based on who is signed in. It keys first on the person and second on an organisation's grant.
• An organisation sees whether each of its people passed, the certificate number, course, dates and whether it has been withdrawn, for certificates dated inside that person's membership. It cannot see answers, scores or attempt history: the database refuses them, whatever role the person asking holds.
• Nobody can be added to an organisation without accepting. An organisation can only invite; the membership exists once the person accepts, and until then the organisation cannot read anything about them.
• Assessment integrity. The bank of questions is readable only for questions already drawn into the learner's own attempt. A learner's session cannot write to an attempt at all, and scores and results cannot be written by any application role.
• Course content is readable only by somebody entitled to the course, except one free sample section per course.
• What is public: published course details, the free sample section, the certificate check, and a training profile a learner has chosen to share by link. Nothing else can be reached without signing in.

Signing in

• No passwords. You sign in with a single-use link sent to your email address. There is no password to guess, reuse or leak.
• The sign-in form gives the same answer for every address, so it cannot be used to find out whether somebody has an account.
• Limits. Sign-in requests are limited to 4 every 15 minutes for one address and 12 every 15 minutes from one device.
• Two-factor sign-in is not offered yet, for anybody, including our own staff. Signing in needs access to the email account the link is sent to.

Our own staff

• Two staff roles, staff and admin. Only an admin can change prices, give free access, change a plan, or suspend, archive or delete an account. A person cannot give themselves either role.
• Every change our staff make in the back office is logged, with who made it and when, in an audit log that nobody can edit or delete from, including the platform itself.
• The course-authoring connector signs in with a token issued to one named member of staff. We store only a hash of the token, it can be revoked, and everything done with it is logged against that person.
• Access to learners' records is given only to rTriibe staff who need it for their work, granted by a director, removed when no longer needed, and reviewed at least once a year. Staff have checks appropriate to the role.

Protecting the service

• Encrypted connections. The site is served only over HTTPS, and browsers are told to insist on it for two years.
• Security headers on every page: a content security policy that limits scripts and connections to this site, Supabase, Stripe and PostHog; the site cannot be framed by another site; and pages behind the sign-in are not stored by the browser or any cache. A page drawn for each request runs only the inline scripts we vouch for, each carrying a one-off code or a fixed fingerprint. Public pages served from the cache still allow inline scripts, because a cached page cannot carry a one-off code; they are for visitors who are not signed in and show nothing a visitor typed.
• Rate limits on signing in, checking certificates (30 every five minutes), opening share links, checkout, and Ask. The limits are counted separately on each server, so they slow down abuse rather than guarantee a ceiling; Ask's monthly allowance is counted in the database.
• Payments. Card details are entered into Stripe's own form and never reach our servers. Messages from Stripe are accepted only with a valid signature.
• Share links carry 256 bits of randomness, cannot be chosen or shortened, and a link that has expired or been withdrawn answers exactly as one that never existed.
• Files. Narration, question audio, uploaded certificates and course records are in private storage and reached only through short-lived signed links. Profile photos and course cover images are public, so that they can be shown.
• Keys. The key that can bypass the database's access rules is held only on the server, and the build fails if any code that reaches the browser could import it.
• Errors shown to you carry a short reference, never the underlying database or payment message.

Data at rest, backups and hosting

• Hosting: the application runs in Vercel's London region (lhr1). The database is hosted by Supabase in London, United Kingdom (AWS eu-west-2).
• Encryption at rest: our database and file storage are encrypted at rest by Supabase.
• Backups: daily, kept for up to 7 days by our database provider. We test a restore at least once a year.
• Certification: we do not yet hold a security certification such as ISO 27001 or Cyber Essentials.
• Penetration testing: we have not yet commissioned an independent penetration test.

What leaves the platform

• No assessment data is ever sent to an analytics service, under any setting.
• Analytics runs only with consent, identifies a signed-in person by an opaque id and never by name or email, and records visits only on the public site, sign-in, checkout and sign-up, with everything typed masked.
• Ask is never sent a learner's name, email address, employer or any identifier, or anything from an assessment. See Ask and AI use.
• The full list of who receives what is on the sub-processors page.

If something goes wrong

• Breach notification to organisation customers: without undue delay and in any event within 48 hours of becoming aware of a personal data breach affecting their data, as the data processing agreement sets out.
• Incident response and business continuity plan: reviewed at least once a year.

Reporting a vulnerability

If you find a security weakness, report it privately to training@rtriibe.com, with "security" in the subject line, before telling anybody else, with enough detail for us to reproduce it. Please do not test further than you need to show it, and do not access, change or keep anybody else's data. Anything that touches another person's records, or the honesty of assessments and certificates, is treated as urgent.