How we protect data
Security overview
This overview explains, in plain words, how Oxonia is designed to keep university data safe. It is written for IT and information security teams.
About this page
Last updated: 10 October 2026.
This page describes how the Oxonia platform is designed to work. It is not a certification or an audit report. Our contractual commitments are in each university's order form, the data processing agreement and the service level agreement.
What we protect
Oxonia holds some of a university's most sensitive information:
- Lecture recordings, captions and study packs.
- Tutorial transcripts and reports.
- Exam scripts, marks and appeals.
- Council and Senate papers, votes and minutes.
- Staff records and regulator returns.
- Fees, payment plans and scholarship applications.
- Theses, research bids and ethics applications.
The platform is designed on the basis that all of it needs protecting, and some of it, such as marks, health-related hardship requests and unpublished minutes, needs extra care.
Sign-in and identity
People sign in with the university's own account through the Oxonia Academy ID: Microsoft, Google, or SAML and Shibboleth. Oxonia does not hold their university passwords. The university's own rules, such as a second step at sign-in, apply. See Access controls and 2FA.
Least access by default
Each person has one or more of five roles: leader, admin, lecturer, student and researcher. Roles decide which products and records they can see. A student sees their own results, not anyone else's. External examiners sample scripts blind. Auditors in Oxonia Policy get time-limited access to the audit room. See Roles and permissions.
Protecting data in transit and at rest
The platform is designed to encrypt data as it travels between devices and our service, and while it is stored. Details of the methods used are on the encryption page. AI keys that a university connects are treated as secrets. See Bring your own AI keys.
Records of who did what
Important actions are designed to be recorded: sign-ins, role changes, approvals of marks and minutes, and changes to settings. See Audit logs.
Resilience and testing
Data is designed to be backed up and recoverable. See Backups and recovery. The platform is to be tested by independent specialists; see Penetration testing. Anyone who finds a weakness can report it; see Vulnerability disclosure.
What we do not claim
This overview does not claim any security certification or completed audit. Where an independent certification is achieved, it will be named here with its date and scope. Questions from your security team are welcome when you book a demo.
Related