Security-first infrastructure
for sensitive data.

Transport security

All connections use modern TLS. HTTP requests are redirected to HTTPS. HTTP Strict Transport Security (HSTS) is enforced with preload and includeSubDomains. SSL session tickets are disabled. OCSP stapling is enabled. Database connections require encrypted transport.

Password storage

Passwords are hashed with a strong adaptive algorithm and a random salt. They are never stored in plaintext or recoverable form. Password validators enforce minimum length, reject common passwords, and flag passwords similar to user attributes. Password reset tokens have a defined expiry period.

Multi-factor authentication

MFA is enforced for all staff and administrator accounts platform-wide. Supported second factors include TOTP authenticator apps (e.g. Google Authenticator, Authy, 1Password) and passkeys / security keys (WebAuthn / FIDO2). Recovery codes are generated at enrolment. Staff accounts cannot access student data until MFA is configured. The per-institution MFA policy can be tightened but not relaxed below the platform default.

Encryption at rest (field level)

Sensitive fields such as bank account numbers and sort codes are encrypted individually in the database using AES-256-GCM-SIV authenticated encryption. GCM-SIV is nonce-misuse resistant - a property that makes the scheme robust against implementation and hardware faults that would be catastrophic with standard AES-GCM. Each stored value uses a unique derived key and a fresh random salt. Key rotation is supported without downtime. The database volume is stored on an encrypted disk.

Session security

Sessions have a short inactivity timeout and are invalidated when the browser is closed. Session and CSRF cookies are set HttpOnly, Secure, and SameSite in production. Sessions are maintained in a server-side store; no sensitive data is stored in the cookie itself.

Tenant data isolation

All application data carries a tenant identifier and is queried through a base class that scopes every database query to the current institution. The middleware layer validates the requesting user's institution against the subdomain on every request, logging and redirecting any cross-tenant access attempt. Subdomain resolution is validated against a strict allowlist format before any database lookup. Tenant resolution is cached to reduce database pressure.

Role-based access control

Staff permissions are managed through named roles at the institution level. Eleven granular permissions cover view, review, decision, evidence management, financial data, payment management, data export, messaging, cohort configuration, staff management, and institution settings. Roles can be customised per institution. Individual permission grants and denials can be applied on top of a role. The principle of least privilege is enforced - institution settings management is never granted by default.

Evidence file storage

Uploaded documents are stored in private cloud object storage with no public URLs. Access is controlled by short-lived signed URLs generated on request, scoped to the requesting user's institution. Files are stored with Cache-Control: private, no-store. File uploads are validated for type and size before acceptance.

Audit trail

Application decisions, payments, document management, staff changes, and other significant actions are recorded in an immutable audit log. The delete operation is blocked at the model level - log entries cannot be removed. Logs are retained for a minimum of six years in line with DfE bursary audit requirements. Each log entry records actor, action, entity, timestamp, tenant, and IP address.

Rate limiting and abuse prevention

Authentication endpoints are rate-limited at both the application layer and the web server layer. The public contact form is protected by Cloudflare Turnstile bot challenge, verified server-side before processing.

Browser security headers

All responses include a Content Security Policy (nonce-based scripts, frame-ancestors 'none', strict base-uri and form-action), HSTS with preload, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and a Permissions-Policy disabling all browser APIs not required by the application (WebAuthn is explicitly permitted for passkey login).

Infrastructure and hosting

The platform runs on cloud infrastructure in the UK/EEA. The database is stored on an encrypted volume with SSL-only connections. The cache and task queue require password authentication. All services run as a non-root system user and are not directly reachable from the public internet - only the web gateway is exposed. Static and media assets are served via Cloudflare's CDN. Cloudflare is a US-headquartered company; transfers rely on the UK Addendum to the EU Standard Contractual Clauses. See our Privacy Policy for the full international data transfer assessment.

Secrets and configuration management

No credentials are hardcoded in the codebase. All secrets - database passwords, encryption keys, API keys - are injected as environment variables at runtime and are required at startup. Production images are built with a multi-stage pipeline that strips developer tooling, local configuration, and version-control history from the final image.

Dependency management

Python dependencies are managed with a lockfile that pins exact versions and is enforced during builds. Dependencies are reviewed and updated regularly. The codebase uses a curated set of well-maintained, security-reviewed packages. A linter with security-relevant rules runs in the development workflow.

Monitoring and error reporting

Application errors are captured by an error monitoring service configured to exclude personal data from reports. Structured application logging captures security-relevant events including cross-tenant access attempts and MFA enforcement. All services are health-checked and restart on failure.

Incident response

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

Security reviews

We conduct periodic security reviews of the platform. If you require specific assurance documentation, penetration test summaries, or a completed vendor security questionnaire for your institution's procurement process, please contact us.

UK GDPR & Data Protection Act 2018

Aligned with. Data is processed lawfully, kept for defined retention periods, and protected by appropriate technical and organisational measures as required under Article 32. A Data Processing Agreement (DPA) is provided to all institutions, establishing the controller–processor relationship. We are registered with the ICO. A Legitimate Interests Assessment and Privacy Policy are published.

Cyber Essentials

Aligned with the technical controls. The platform satisfies all five Cyber Essentials control areas in practice: boundary firewalls, secure configuration, access control, malware protection, and patch management. Formal Cyber Essentials certification is planned.

OWASP Top 10

Mitigations in place across all current OWASP Top 10 categories: injection (ORM parameterised queries), broken authentication (MFA enforcement, rate limiting, email verification), sensitive data exposure (field-level encryption, private file storage, HTTPS everywhere), security misconfiguration (hardened headers, least-privilege containers, secrets via environment variables), XSS (template auto-escaping, CSP with nonces), and others. Periodic OWASP-aligned reviews are conducted.

ISO 27001

Principles followed. Key Annex A controls are implemented: access control policy, cryptographic controls, information transfer, secure development, operations security, supplier relationships, and incident management. Formal ISO 27001 certification requires an external audit and is a planned milestone.

NIST Cybersecurity Framework

Aligned with. Controls map across the five NIST CSF functions: Identify (asset management, risk awareness), Protect (access control, encryption, hardened headers), Detect (logging, monitoring, alerting), Respond (incident response procedures), and Recover (backups, service restart policies).

How is student data encrypted?

All data is encrypted in transit via modern TLS. Sensitive fields such as bank account details are additionally encrypted at the field level inside the database using AES-256-GCM-SIV authenticated encryption - even with direct database access, those values are unreadable without the encryption keys. The database volume is stored on an encrypted disk. Uploaded documents are stored in private cloud storage with no public access path.

Who at myBursary can access our students' data?

Access to production systems is restricted to a small number of authorised personnel on a strict need-to-know basis. We do not grant routine access. Where we access data to support your institution, this is covered by the Data Processing Agreement. We do not sell or share student data with third parties beyond our essential infrastructure providers (listed in our Privacy Policy and DPA).

How are uploaded documents protected?

Evidence documents (payslips, benefit letters, etc.) are stored in private object storage with no public URL. To access a document, a user must be authenticated, belong to the correct institution, and have appropriate permissions. Access is delivered via a signed URL with a short expiry. Files cannot be accessed by other institutions or reached by URL guessing.

Can one institution see another institution's data?

No. Tenant isolation is enforced at the database query level and verified at the middleware layer on every request. Cross-tenant access attempts are logged and redirected. This isolation applies to applications, evidence, student records, staff profiles, payment schedules, cohort configurations, and audit logs.

Do you support SSO or SAML?

Not currently. Authentication uses email and password with mandatory MFA for staff. Passkeys (WebAuthn) are supported as a passwordless second factor. SAML/SSO integration is on the product roadmap. If this is a requirement for your procurement, please contact us to discuss timing.

How are backups handled?

The database is backed up regularly. If you require specific backup and recovery commitments in your data processing agreement, please contact us.

Are audit logs available to institutions?

An internal audit trail records all significant actions (decisions, payments, document uploads, staff changes) with actor, timestamp, and IP address. These logs are accessible to institution administrators within the platform and are retained for six years. Institution-facing audit log export is on the roadmap.

How do you handle discovered vulnerabilities?

We welcome responsible disclosure. If you have found a potential vulnerability, please report it to [email protected] with a description and steps to reproduce. We aim to acknowledge reports within two working days and provide a remediation timeline within five. Please keep findings confidential until we have had a reasonable opportunity to investigate and fix the issue.

Is myBursary Cyber Essentials certified?

Not yet certified, though our technical controls align with all five Cyber Essentials categories. Formal certification is planned. If this is a requirement for your institution's procurement, please contact us.

Do you have a Data Processing Agreement?

Yes. A Data Processing Agreement (DPA) is included in the standard subscription agreement and is available to review before signing up. The DPA sets out our obligations as data processor under UK GDPR, including sub-processor notification, security obligations, breach notification, and data deletion on contract termination. Contact us if you need a copy before signing.

How to report

Email [email protected] with a clear description of the issue, steps to reproduce, and the potential impact. Include your contact details if you would like updates as we investigate.

What to expect

We will acknowledge your report within two working days and provide a remediation timeline within five. We will notify you when the issue has been resolved. We ask that you keep findings confidential until we have had a reasonable opportunity to investigate and remediate.

Scope

In scope: mybursary.org and all tenant subdomains, the myBursary web application, authentication flows, data access controls, file storage, and API endpoints. Out of scope: denial-of-service attacks, social engineering, physical attacks, and vulnerabilities in third-party services we do not control.