Data processing terms

1. Roles

Where a university licenses BodyAnswers Study for its students, the university is the controller of its students' personal data and BodyAnswers acts as processor, processing that data only on the university's documented instructions.

There are processing activities for which BodyAnswers is an independent controller, and they are listed here rather than obscured. Being a processor for the licensed service and a controller for our own records is the normal position for a platform of this kind; the point of naming them is that the obligations differ.

• Account records for individuals who subscribe directly, outside any institutional contract.
• Our own security and audit logging, which we retain to meet our own legal and security obligations and which a university cannot instruct us to delete while an investigation is open.
• Aggregate, non-identifying usage measurement used to operate and improve the platform.
• Correspondence with a university's own staff, as business contacts.

2. Subject matter, duration and purpose

The subject matter is the provision of an online revision and reference platform to the university's students. Processing continues for the term of the licence and for the retention period set out in the contract, and then stops.

The purpose is limited to delivering the service: authenticating students, serving licensed content, recording their own progress, providing the aggregate reporting the university has asked for, and keeping the platform secure. It does not extend to profiling for any purpose other than sequencing a student's own revision, and it does not extend to marketing to students.

3. Categories of data subject and personal data

Data subjects are the university's students and the staff it nominates as administrators, lecturers or course leads.

The categories of personal data are deliberately narrow. We do not ask for a date of birth, a home address, a phone number, a photograph or any special-category data, and there is nowhere in the product to enter them.

• Identity and contact: email address (normally the university-issued address), and a display name the student chooses.
• Institutional: the organisation, the university's own student reference where it supplies one, programme of study, academic year and cohort membership.
• Authentication: a hashed password held by our identity provider, and session tokens.
• Learning activity: questions attempted, whether each was correct, time taken, study days and saved topics.
• Technical and security: truncated source network prefix and administrative action records in the audit trail.

4. No special category data

The platform is not designed to hold Article 9 data and must not be used to record any. In particular, a student's own health information is not collected, and there is nowhere in the product to enter it.

If a university identifies a need to record something that would constitute special-category data, that is a change requiring a data protection impact assessment before, not after, it is built.

5. Security measures

The technical and organisational measures are described in full in the security overview, which forms part of these terms. In summary: tenant isolation enforced in the database rather than in application code, authorisation resolved server-side on every request, encryption in transit and at rest, an append-only audit trail the application cannot edit, and rate limiting on authentication and data export.

6. Subprocessors

The current subprocessors are published, with what each of them can see and where they hold it. We will give notice before engaging a new one, and a university may object on reasonable data protection grounds.

Each subprocessor is engaged under written terms imposing obligations equivalent to these. Where a subprocessor's own operations involve a transfer outside the United Kingdom or the European Economic Area, that transfer relies on Standard Contractual Clauses with the UK Addendum, and is identified individually.

7. International transfers

Student personal data is stored in the United Kingdom or the European Economic Area. We do not transfer it elsewhere for storage, and the database region is a commitment rather than a default we happened to inherit.

Limited operational processing by a subprocessor may involve access from outside that area — request logs are the practical example. Those instances are listed on the subprocessor page with the safeguard relied on.

8. Assisting with data subject rights

A student's rights are exercised against their university as controller. Where a request reaches us, we refer the student to their university and notify the university's nominated contact rather than acting unilaterally.

We will assist with access, rectification, erasure, restriction and portability requests without undue delay. Practically, this is supported in the product: an administrator with the appropriate permission can export a student's own record in a machine-readable form and can initiate erasure, and both actions are recorded in the audit trail.

9. Personal data breaches

We will notify the university's nominated data protection contact without undue delay and in any event within 24 hours of becoming aware of a personal data breach affecting its data, so that the university can meet its own 72-hour obligation to the Information Commissioner with time to spare.

The notification will describe what happened, when, which categories and approximately how many data subjects are affected, the likely consequences, and the measures taken. Where the full picture is not yet known we will say what is known and update, rather than delay the first notification until an investigation is complete.

10. Retention and deletion

Retention is set per contract rather than platform-wide, because a university's own records-management schedule is what should govern its students' data. The default is three years from the end of the academic relationship, which reflects the period in which an assessment record may be needed for an appeal.

On termination we will, at the university's choice, return its data in a machine-readable format or delete it, and delete it in either case within 90 days — except where we are required to retain something by law, in which case we will say what and why. Suspending or ending a licence removes access immediately; it does not delete data, because a contract lapsing during a negotiation must not destroy a cohort's progress.

11. Audit and inspection

We will respond to a university's reasonable information security questionnaire, and will make available the documentation published at the trust centre together with any independent test reports once they exist. Where a university requires an on-site audit, we will agree a scope and a date rather than refuse.

12. Under-18 students

Some university students are under 18, so the Information Commissioner's Age Appropriate Design Code may apply to them. Our position is that the design decisions the Code asks for are ones we should make for every student regardless: privacy-protective defaults, no behavioural advertising, no profiling beyond sequencing a student's own revision, data minimisation, and no attempt to encourage the sharing of personal data.

There is no separate under-18 experience, and no age is collected. This is a considered position rather than an oversight — collecting a date of birth in order to determine which protections apply would itself increase the personal data held, to no benefit if the protections apply to everybody.

13. Educational software, not a medical device

The platform is educational. It does not diagnose, does not recommend treatment for an identified patient, and includes no clinical decision support. It contains no tool that computes a figure about a named patient.

This boundary is deliberate and worth stating in a contract: functionality that computed a recommendation for a specific patient could bring the product within medical device regulation, and would be a decision requiring regulatory advice rather than a feature request.