Skip to content

Legal

Data Processing & Security

Written for university IT, procurement, and data protection teams. This page sets out what Allotix does with institutional and student data, and the controls that protect it.

Last updated: July 13, 2026

You are the controller. We are the processor. Your institution decides what student data enters Allotix and why. PankoByte processes it only to run the service on your instructions — not for our own purposes, not to train models, and never for advertising.

1. Scope of processing

Subject matter: providing the Allotix elective allocation system.

Duration: for as long as your institution's subscription is active, plus the deletion window in section 8.

Purpose: configuring allocation events, importing academic data, collecting student preferences, running allocation, producing and publishing results, sending the notifications you configure, and providing support.

Categories of data subject: your staff and administrators, and the students participating in an allocation event.

Categories of personal data: staff account details; student identifiers and enrolment records, department and programme, eligibility attributes, submitted course preferences, and allocation results. Allotix does not require special-category data, and we ask you not to upload it.

2. Our commitments as processor

  • We process institutional data only on your documented instructions — in practice, your use of the product and any written agreement between us.
  • We do not use your student data for our own purposes: no model training, no analytics products, no sale, no advertising.
  • People with access to your data are bound by confidentiality obligations.
  • We assist you with data subject requests, breach notification, and impact assessments, so far as you reasonably need us to.
  • We delete or return institutional data at the end of the engagement, as set out in section 8.

3. Security controls

Access control

Allotix separates roles, so administrators, department staff, and students see only what their role permits. Data is scoped to the allocation event it belongs to, which stops one event's records leaking into another.

Backend enforcement

Authorisation is enforced on the backend, on every protected route — not in the browser. Hiding a button in the UI is not a security control, so we do not treat it as one.

Encryption

Data is encrypted in transit using TLS, and encrypted at rest by our cloud infrastructure.

Infrastructure

Allotix runs on Google Cloud and Firebase — managed infrastructure with its own physical security, patching, and compliance programme. We do not run student data on self-managed hardware.

Operational practice

Access to production data is limited to the people who need it to operate the service and support you. Credentials and secrets are held in managed secret storage, not in source code.

4. Sub-processors

We use a small set of providers to deliver Allotix. Each is bound to protect the data it handles:

  • Google Cloud Platform / Firebase — application hosting, database, and storage.
  • Email delivery provider — sending the allocation notifications and transactional email you configure.
  • Payment provider — processing credit purchases. It handles billing contact and payment details, not student data.

If we add a sub-processor that handles institutional data, we will give you notice, and you may object on reasonable data protection grounds. For the current list in writing, ask [email protected].

5. Data location and transfers

Institutional data is processed on our cloud provider's infrastructure, which may span regions. Where data crosses borders, we rely on the transfer safeguards our providers offer, such as standard contractual clauses.

If your institution has a data residency requirement — data confined to a named region — raise it with us before deployment. Tell us early enough and we can usually accommodate it; after go-live it is considerably harder.

6. Incident response

If we become aware of a personal data breach affecting your data, we will notify you without undue delay, and give you what we know: what happened, which data and how many people are affected as best we can tell, what we are doing about it, and what we recommend you do. We will not sit on it while we investigate.

As controller, you decide whether the breach must be reported to a regulator or to affected individuals. We will support that decision with the information you need.

7. Data subject requests

Students and staff normally direct requests — access, correction, deletion — to their institution, since the records belong to you. If a request reaches us directly, we will not action it ourselves; we will pass it to you and help you respond, using the export and edit tools in the product.

8. Retention, export, and deletion

Institutional data is retained while your subscription is active, so you can refer back to previous allocation cycles. Allotix includes export tools for academic data and allocation results — export what you need to keep before you leave.

After termination we keep your data for a 30-day window so you can retrieve it, then delete it from active systems. Residual copies in routine backups age out on our provider's backup cycle. If you need deletion confirmed in writing, or sooner than the standard window, ask us at [email protected].

9. Audit and due diligence

We will answer reasonable security questionnaires and due-diligence requests from your IT and procurement teams, and provide the information you need to satisfy yourself that we meet your obligations. Get in touch at [email protected] and tell us what your process requires.

10. A signed agreement

If your institution requires a signed data processing agreement in its own form, or one incorporating specific regulatory clauses, we will work through it with you. Write to [email protected] to start that. This page describes our standard practice, and it works alongside our Privacy Policy and Terms & Conditions.