Security and Data Protection at Oxonia: Answers for IT Directors

What universities trust us with

Oxonia holds some of the most sensitive records a university has: Council and Senate papers and votes, lecture and meeting recordings, exam scripts and marks, staff records and regulator returns, fee accounts and hardship applications, theses and ethics applications.

The university is the data controller for all of it. Oxonia is its processor and acts only on the university's documented instructions, under our data processing agreement. Records the university puts in, or adopts from an AI draft, belong to the university.

This article explains how the platform is built to protect those records. It describes design and terms, not a certification; we do not claim certifications we do not hold. More detail is on our security overview and data protection pages.

Sign-in: your directory, our checks

People sign in once with the Oxonia Academy ID, which uses OpenID Connect with RS256-signed tokens. When keys are rotated, the previous public key is kept so that sign-ins do not break mid-session.

The Academy ID connects to the university's own sign-in. Universities can use Microsoft Entra ID, Google Workspace, another OpenID Connect provider, or SAML 2.0, which covers Shibboleth. Oxonia does not need to hold staff and student passwords.

Two-factor authentication with an authenticator app is required for privileged roles. Each person gets ten single-use recovery codes, stored as keyed hashes and encrypted at rest. Codes cannot be replayed.

Each university's data kept apart

Every record carries the university it belongs to. Isolation is enforced twice: in the application, and in the database itself through PostgreSQL row-level security that is forced on every university's tables. A bug in one screen cannot show one university's records to another.

Data is encrypted in transit with TLS 1.2 or higher, and at rest, with per-university keys for documents. Secrets the university gives us, such as its payment account key, are encrypted at rest and never shown again. AI keys are shown only by their last four characters.

Each person sees only what their role allows. A student sees their own results. A Senate member does not receive confidential items, or any item where they have declared a conflict of interest. Secret ballots are stored with no link between a member and their vote.

An audit trail for everything that matters

Oxonia keeps append-only audit logs of sign-ins, access, approvals, votes, exports, AI runs and impersonation, inside the university's own space. Changes to who can use which product are shown at the foot of the admin console.

Where a regulator has oversight and the university has switched it on, every time the regulator looks inside the university is written to the university's own audit log. Nothing about a regulator's view is hidden from the university being viewed.

Official records are protected too. Signed minutes carry a hash of the exact text signed, and signed regulator returns are locked. Approved minutes are never changed by Oxonia; any change is made by the university's staff and logged.

AI with guard rails

Every Oxonia product is AI-enabled, and the rules are the same everywhere:

• AI output is labelled as a draft until a person with the right role adopts it. Anything that becomes an official record needs human approval.
• We don't use your content to train AI models, and our AI providers work under business terms that don't allow training on it. AI services are engaged as sub-processors and named on our sub-processors page.
• Answers are drawn only from records the person asking may see; permission filtering happens before anything is ranked.
• Where configured, personal data can be redacted before a request is sent to an external model.
• No decision with legal or similar effects about a person is made by automated means alone.

Product-level checks add to this. Mark, for example, flags an exam answer that appears to address the AI marker and sends it to a person.

Consent, retention and the end of a contract

Recording needs consent. Scribe saves evidence of each confirmation: who confirmed, when, for which session and the words agreed to. A viva cannot be recorded until the candidate and every examiner agree.

Live meeting audio is deleted after a set period, 30 days by default, and each university sets its own retention for other records. The platform includes export and deletion tools to help answer data subject requests.

If a personal data breach affects the university, we notify it without undue delay and within 48 hours at the latest. We give at least 30 days' notice of a new sub-processor. At the end of the agreement, the university can export its data for at least 30 days, after which we delete it, including from backups in their normal rotation.

The laws we design for

Our data processing agreement is designed to meet the processor requirements of the Nigeria Data Protection Act 2023, the UK GDPR and the EU GDPR. For Nigerian universities we publish a statement mapping each NDPA principle to how the platform supports it, and the university records its own lawful basis in its own notices.

Universities in Malaysia, Turkey, the Gulf and elsewhere have their own laws. The same controls apply everywhere, and each university should confirm its own obligations with its data protection officer. We are happy to answer their questions.

If you find a security weakness, please tell us through our vulnerability disclosure page. For sign-in specifically, read one login for every university system.

Security questionnaires are a normal part of buying software, and we expect them. The fastest route is to send yours early, with the products you are considering, so that answers can cover the parts of the platform you will actually use.

Products in this article

Questions people ask