Skip to main content
Security

How we protect your data.

myBursary handles sensitive financial eligibility data on behalf of schools and colleges. We take that responsibility seriously. Here is what that looks like in practice — first in plain English, then in technical detail for anyone who needs it.

What this means in practice

Four things you can rely on.

Encrypted in transit

Every connection to myBursary uses HTTPS. Data moving between your browser and our servers cannot be read in transit.

Staff always use two-factor authentication

All staff and administrator accounts require MFA. No-one can access student data with a password alone.

Evidence files are access-controlled

Uploaded documents have no public URL. Access is granted only through short-lived links generated at the moment of access, by authorised users.

Your data stays yours

Each institution's data is strictly isolated. No school can see another school's applications, evidence or student records.

For IT and data leads

Technical detail.

The following covers the technical controls we have in place. If you are completing a data protection impact assessment or vendor security questionnaire, please also refer to our Privacy Policy and contact us at [email protected] for anything not covered here.

Transport security

TLS 1.2 minimum for all connections. HTTP requests are redirected to HTTPS. HSTS is enforced. Connections to the platform via a custom subdomain (yourschool.mybursary.org) use the same TLS configuration.

Password storage

Passwords are hashed using PBKDF2-SHA256 with a salt. They are never stored in readable form. Our systems cannot recover a password — only reset it.

Multi-factor authentication

MFA is enforced for all staff and administrator accounts. Supported second factors include TOTP authenticator apps (e.g. Google Authenticator, Authy) and passkeys (WebAuthn). Recovery codes are provided at enrolment. Staff cannot access student data until MFA is configured.

Evidence file storage

Uploaded documents (payslips, benefit letters, care leaver letters, etc.) are stored in private object storage with no public URLs. Files are accessed only through short-lived signed URLs generated on request, scoped to the requesting user's institution. Storage is provided by Cloudflare R2.

Tenant data isolation

All application data is scoped to a tenant at the database level. Every query is filtered by tenant. An authenticated user at one institution cannot retrieve records belonging to another, regardless of URL manipulation or permission state.

Infrastructure

The platform is hosted on cloud infrastructure in the UK/EEA. Static assets and media are served via Cloudflare's CDN. Cloudflare is a US-headquartered company; data transfers rely on the UK Addendum to the EU Standard Contractual Clauses. See our Privacy Policy for full detail on international data transfers.

Access control (internal)

Access to production systems and data at the infrastructure level is restricted to a small number of authorised personnel. We maintain the principle of least privilege: access is granted only where a genuine operational need exists.

Incident response

We maintain procedures for identifying, containing and reporting suspected security incidents. Where a breach is likely to result in a risk to the rights and freedoms of individuals, we will notify the ICO within 72 hours and affected institutions without undue delay. Institutions are responsible for notifying affected students where required.

Penetration testing and review

We conduct periodic security reviews of the platform. If you require specific assurance documentation for your institution's procurement or data protection process, please contact us.

Questions or concerns?

If you have a security concern, have identified a potential vulnerability, or need to discuss our security posture for a procurement or DPIA, please contact us directly. We aim to respond within two working days.

[email protected]