This document outlines the core architecture, technologies, and data handling practices used in our educational tools, to assist with IT due diligence and compliance processes in schools.
Our platform is built using modern web technologies with security and scalability as primary concerns. It follows a stateless, token-based model that simplifies integration with existing school systems and learning platforms.
Component | Details |
|---|---|
Hosting | Deployed via Netlify, with edge protections provided by Cloudflare |
Frontend | Built in React and Vite, offering high performance and fast load times |
Authentication | Session-based access using JWT (JSON Web Tokens) issued by trusted partners, verified client-side |
Backend | Supabase (hosted Postgres database) powers data storage, access, and APIs |
Edge Functions | Used for secure server-side logic and integrations |
Data Security | Protected by Row-Level Security (RLS), SSL/TLS encryption, and strict access controls |
Data Location | All data is stored and processed on EU-based servers (Supabase EU region) |
No passwords stored: Users are authenticated via short-lived, signed tokens
Strict access rules: Each database query is subject to RLS rules scoped by user identity
End-to-end encryption: All traffic is secured via HTTPS
Edge-isolated functions: Sensitive operations are run in secure, server-side environments
No tracking: We do not use cookies or analytics scripts unless explicitly consented to
Tokens are valid for a short period (e.g. 15–30 mins)
After verification, the user session is created based on decoded token data (e.g. student ID, school code)
Sessions do not persist across systems unless explicitly refreshed
All data is processed and stored within the European Union, complying with UK GDPR and EU GDPR standards.
This section explains how students are securely authenticated into our applications without requiring usernames, passwords, or persistent logins.
Single-use JWTs (JSON Web Tokens) are issued by your school’s trusted student portal or LMS.
These tokens are appended to a launch URL, such as:
https://student.enterpriseskills.co.uk?token=eyJhbGciOi...Student clicks launch link (with embedded token)
JWT is decoded client-side
The app extracts non-sensitive internal IDs:
student_id
access_id
school_code
The session is initialised for the current tool using these IDs
The token is discarded immediately after verification (not reused or stored)
Tokens are minimal and secure:
❌ No passwords
❌ No names or email addresses
✅ Only internal, non-PII identifiers
✅ Encrypted and signed using a private JWT_SECRET known only to the trusted issuer and the application
Short-lived: Tokens are valid for a limited time (e.g. 10–30 minutes)
One-way flow: Tokens are passed into the tool; no user credentials are ever returned or stored
RLS enforcement: Supabase checks every DB access against the student_id in the token
The student_id field used in the token is not a student name, email address, or any identifiable information.
It’s a randomised UUID (e.g. fb8a65ed-1557-4c24-82c2-f102bfd4fe9d) generated by the school’s identity system.
This ID allows our system to manage sessions and progress without ever knowing who the student is.
✅ No PII is stored, transmitted, or processed.
✅ No mapping to real-world identity exists in our systems.
LC-007
Here’s a draft DPIA template schools can use. It’s 80% pre-filled, with placeholders for their own organisational details.
Download our pre-filled template here if it helps you.
We use strong technical and organisational measures to safeguard all data:
End-to-end encryption: All data is encrypted in transit (HTTPS/TLS 1.3).
Row-Level Security (RLS): Strict access rules in our database ensure users only see their own records.
Short-lived JWTs: Authentication tokens expire within minutes and are single-use.
No passwords stored: Students are authenticated via trusted systems; we never store or process usernames or passwords.
Environment separation: Development and production systems are completely isolated to prevent cross-contamination or data leaks.
Enterprise Skills Ltd typically acts as:
Data Processor, working on behalf of your school (the Data Controller) under your instruction.
In some cases (e.g. public pilots or standalone platforms), we may act as a Joint Controller, especially where the product is used without direct instruction from a school.
We are happy to provide:
A Data Processing Agreement (DPA) for standard use cases.
A Joint Controller Agreement if your organisation prefers that model.
For questions about roles and responsibilities under UK GDPR, contact us using the details below.
Controller:
Chris Simmance
chris@enterpriseskills.co.uk
[Registered Data Controller for Enterprise Skills Ltd]
Technical & Support Contact:
Email: chris@enterpriseskills.co.uk
Phone: Available upon request for whitelisting and IT setup
Data Protection Officer:
A DPO is not formally appointed under Article 37 but data responsibilities are overseen by the Controller listed above.
Support Documentation / SLA:
You can access our help documentation and service agreements at:
