Last updated: 4 September 2026 · Status: draft, pending DPO/legal sign-off
This is a summary of our own Data Protection Impact Assessment (DPIA) for The School Gallery, published so your school can draw on it for your own — you remain the data controller, and UK GDPR Article 35 still expects you to carry out your own assessment for how you use the platform; this document is support for that, not a substitute for it. It was prepared with AI assistance from our own system design and hasn't yet had a solicitor's or a named DPO's sign-off — treat it as a working draft rather than a finalised compliance record until it has.
The platform involves systematic, large-scale processing of photographs and personal data belonging predominantly to children — one of the categories the ICO's own screening criteria flags as needing an assessment before processing begins, regardless of how the data is used afterwards.
Nature: a cloud-hosted, multi-tenant platform. School staff upload event photos and tag which pupils appear in each one. A photo only becomes downloadable once every tagged pupil's family has granted consent — a single denial removes it permanently for every family, not just the one that denied it.
Scope: one school's data is isolated from every other school's by default at the database query level, not left to individual code paths to remember to filter correctly.
Context: UK primary and secondary schools; the data subjects are predominantly children, with parents acting as the decision-maker for consent.
Purpose: to let a school share event photography with parents in a way that's auditable and enforceably consent-gated, sync pupil rosters from the school's MIS, and — optionally — offer print ordering and staff single sign-on.
This draft was prepared internally. Before relying on it for certification purposes, we intend to have it reviewed by a named Data Protection Officer and, where appropriate, external legal counsel. A school adopting the platform should consult their own DPO as part of their own DPIA for this specific use.
Data collection is scoped to what the service needs, not the maximum available: pupil name, date of birth, and year group are synced for tagging purposes, not health, special educational needs, or other special category data. GPS location and other embedded metadata is stripped from every photo automatically on upload — a photo taken at a school never carries the address it was taken at once it reaches this platform. Email addresses are stored encrypted with a one-way lookup index, so day-to-day operation never needs to decrypt the readable value.
The lawful bases relied on: consent for releasing any individual photo; contract performance for operating an account on the school's behalf; legitimate interest for security logging, weighed against the individual's right to privacy; and legal obligation for records the law requires us to keep (billing, audit trails).
The core design risk of the whole service. Mitigated structurally, not just procedurally: a photo's full-resolution original is never reachable until every tagged pupil's family has actively granted — one missing decision blocks it for everyone. Pre-consent, only a low-resolution, visibly watermarked preview is ever served. Every download also carries an invisible, per-viewer forensic mark, so a leaked copy can still be traced back to who downloaded it.
Tagging is staff-controlled and editable after upload; changing a photo's tags re-triggers a fresh consent decision for anyone newly tagged, rather than silently exposing an already-consented photo to someone who's never been asked.
Every tenant-owned record is scoped to its school by a global query rule applied automatically, not a per-query convention a future change could forget. The one deliberate exception — our own support staff impersonating an account for diagnostics — is fully and separately audited, recording both the impersonated identity and the real member of staff behind it.
Multi-factor authentication is available on every account type; every login is rate-limited per account and per network address; passwords are checked against known-breached password lists at set time; every login, view, and download is logged against the account that performed it. Residual risk is rated medium rather than low because MFA enrolment itself isn't yet mandatory for every role — an account that never turns it on carries more risk than one that does.
Each sub-processor (see the register) receives only what it needs to do its specific job — for example, our accounting provider never receives a single parent's personal data, and our payment provider never routes card details through our own servers at all. Each engagement sits under its own data processing terms. This risk can never fall to zero while sub-processors exist at all, which is exactly why the register stays public and current.
Photo retention is configurable per school and enforced automatically — photos are permanently deleted once the period lapses, with a reminder email first if a consented photo hasn't been downloaded yet. Security and audit logs are pruned on a rolling schedule rather than kept indefinitely.
The service is currently parent-mediated by design — every consent decision runs through a verified parent account. That's a deliberate, lower-risk starting posture, but it does mean a pupil's own record can't be erased on a single parent's say-so alone; that has to go through the school directly. Worth revisiting if the platform ever offers pupils their own direct login.
On the basis of the measures above, the processing is assessed as proceeding with residual risk managed to a level proportionate to its purpose — subject to the formal review noted at the top of this page. We'll update this assessment whenever we make a material change to how photos or pupil data are processed, and welcome a school's own DPO reviewing it alongside their procurement decision.
Contact support@jamitd.co.uk — we're glad to walk your DPO through any part of this alongside our sub-processor register and privacy policy.