What we do to protect your account
Written plainly, with the gaps included. If your review needs something that is not here, ask us rather than assume.
No passwords to steal
Sign-in is passwordless — a verified email link or your organisation’s single sign-on. We do not store a password for you, so there is no password database to breach or reset.
Encrypted in transit
Every request is HTTPS over TLS 1.2 or 1.3. HTTP Strict Transport Security is enforced for a year across skill.re and its subdomains, so browsers refuse to downgrade.
Administrative actions are logged
Actions taken in the admin surfaces are recorded, so an organisation can answer who enrolled whom, who changed a cohort and who issued a certificate.
Controls in place today
| Area | What is in place |
|---|---|
| Authentication | Passwordless sign-in by verified email link, and single sign-on for organisations that need it. No password storage. |
| Authorisation | Four separated roles — learner, instructor, admin, superadmin — scoped per organisation. Application surfaces refuse anonymous access and redirect to sign-in. |
| Transport | TLS 1.2 / 1.3 only. HSTS with max-age=31536000; includeSubDomains. HTTP is redirected to HTTPS. |
| Browser hardening | X-Frame-Options: SAMEORIGIN against clickjacking, X-Content-Type-Options: nosniff, and Referrer-Policy: strict-origin-when-cross-origin so your navigation is not leaked to third parties. |
| Input handling | Output is escaped centrally, database access is parameterised, and a human-presence check guards the public application form. |
| Uploads | Learner-submitted files are held outside the executable path and the server refuses to execute code from the upload directory. |
| Infrastructure | Served behind Cloudflare on a maintained Linux and PHP 8.4 stack. |
| Audit | An administrative activity log, available to organisation admins. |
What we do not claim
Security pages usually imply more than they hold. These are ours, stated rather than skipped.
- We are not SOC 2 certified and hold no ISO 27001 certificate.
- We have not completed a third-party penetration test.
- We do not offer a contractual uptime SLA, because we do not yet publish the monitoring that would back one.
- Hardening is ongoing. Response-header policy and platform hygiene are under active work.
- Multi-factor authentication is not yet offered beyond what your SSO provider enforces.
- A status page is on the list and not yet live.
If any of these is a blocker for your organisation, tell us which one — it helps us prioritise. Contact us →
Reporting a vulnerability
If you have found a security issue, please tell us before you tell anyone else. We will not pursue legal action against anyone who reports in good faith, tests only against their own account, and gives us a reasonable chance to fix the problem.
Where to send it
[email protected] — put SECURITY in the subject line so it is routed immediately.
What we ask
- Give us enough detail to reproduce it — a URL, the steps, and what you saw.
- Test against your own account and data only.
- Do not run denial-of-service tests, send spam, or access other people’s personal data.
- Give us 90 days before publishing, or sooner if we have fixed it and agreed.
What you get
- An acknowledgement within 3 working days.
- An assessment and an intended fix timeline within 10 working days.
- Credit in our release notes if you would like it.
We do not currently run a paid bug bounty. We are grateful anyway, and we say so publicly.
Data and privacy
What we collect, why, how long we keep it and how to get it back is set out in the Privacy Policy. The third-party services that process data on our behalf are listed at /subprocessors.
For a security review
If you are running a vendor assessment and need a questionnaire completed, a DPA signed, or answers in a specific framework’s format, contact us and say which framework. We would rather work through a real questionnaire than publish a generic claim.