Educoda handles sensitive personal data for thousands of students across England. Security is built into every layer — from how passwords are stored to how student documents are accessed, from audit logs to encrypted connections.
Report a Vulnerability Privacy PolicyEvery control listed here is implemented and active in the production system.
All connections are encrypted using TLS 1.2 or TLS 1.3. Weak protocols and ciphers are explicitly disabled. HTTP traffic is redirected to HTTPS automatically, and HSTS headers prevent downgrade attacks.
Passwords are hashed using Argon2 — the winner of the Password Hashing Competition and the recommended algorithm for password storage. Plain-text passwords are never stored or logged.
TOTP-based two-factor authentication is available for all users and can be made mandatory for staff roles. All superuser and admin accounts are required by policy to have MFA enabled. Recovery codes are provided at enrolment.
A granular, three-tier RBAC system controls every action in the platform. Permissions can be granted or explicitly denied per-user. Roles can be time-limited, and a full audit trail records every change to who has what access.
Each school operates in a fully isolated tenant. Staff can only access data belonging to their own institution — enforced at the middleware layer on every request, not just in application logic. Cross-school access is impossible without superuser rights.
Sensitive student documents (identification, results) are stored in a private bucket with no public URL. Access is granted only via time-limited, cryptographically signed presigned URLs generated on demand. Documents cannot be guessed or enumerated.
Login events, permission changes, GDPR erasure requests, and payment waivers are written to immutable audit logs. Administrators can review who took what action and when across all security-sensitive operations.
All state-changing requests require a CSRF token. Signup forms include Cloudflare Turnstile challenge and honeypot fields to prevent automated bot registrations. CSRF tokens are transmitted only over HTTPS-secured cookies.
Payments are processed by Stripe. No card numbers, CVV codes, or payment credentials ever touch our servers. Stripe webhook events are verified using cryptographic signatures before processing. We store only payment status and Stripe-issued references.
The platform runs on infrastructure designed for reliability, resilience, and security.
All credentials — database passwords, API keys, payment keys — are stored as environment variables and never hardcoded in source code or version control.
All accounts must verify their email address before accessing the platform. Unverified accounts cannot log in or submit data.
Sessions expire after 60 minutes of inactivity. Password changes immediately invalidate all active sessions. Secure, HttpOnly cookies prevent client-side access.
Background tasks run with strict time and resource limits to prevent runaway processes or resource exhaustion. Workers are automatically recycled to prevent memory leaks.
Security is a practice, not a feature. Here is how we work.
All software dependencies are pinned in a lock file and installed from a frozen, verified state on every deployment. This prevents unintended updates and supply-chain substitution. Dependencies are reviewed before updates are applied.
All code changes pass through an automated test suite backed by a full database before deployment. Payment processing, permission logic, and authentication flows are covered by tests. No untested code reaches production.
Automated static analysis and type-checking tools run on every commit before code is reviewed. These tools catch common security anti-patterns — including injection vectors and unsafe input handling — before code reaches the codebase.
Access rights are granted at the minimum level required. Staff receive only the permissions their role requires. Permissions can expire automatically. Every grant and revocation is written to an immutable audit log with the actor, timestamp, and reason.
All database queries use parameterised queries by default, making SQL injection structurally impossible in standard usage. Output is escaped by the template layer, protecting against cross-site scripting. Neither raw queries nor unescaped output are used.
Application errors are captured in real time. Critical errors trigger immediate alerts to the engineering team. Error rates are monitored continuously to detect unusual activity or degraded behaviour.
We are transparent about what we have implemented, what we are working towards, and what we have not yet achieved.
Educoda Ltd is registered with the Information Commissioner's Office (ICO registration ZB949031). We have published a privacy policy, support data erasure requests, and maintain a GDPR erasure log.
The application is designed following OWASP Top 10 principles. Key risks are addressed through framework-level protections and deliberate architectural choices.
We are working towards NCSC Cyber Essentials certification. The five key controls are partially in place across our infrastructure.
We have not pursued ISO 27001 certification yet. Many of the technical controls required by the standard are already in place. Formal ISMS documentation, risk register, and third-party audit are on our roadmap.
SOC 2 is a US-origin framework primarily relevant to American enterprise procurement. It is not currently on our roadmap. UK and EU customers are better served by our ICO registration and Cyber Essentials certification path.
Answers based on the actual implementation, not aspirational claims.
We welcome responsible disclosure. If you have found a vulnerability, please email us directly. We take all reports seriously and respond within 2 business days.
Please include a clear description of the issue, steps to reproduce, and potential impact. We ask that you do not access or modify data belonging to others and give us a reasonable window to address the issue before public disclosure.