Data Protection Impact Assessment

The Future Skills Passport — Data Protection Impact Assessment

Spark2 Education  ·  Draft v1, May 2026  ·  Internal record — for the September 2026 launch
DRAFT — for review.

This is a working Data Protection Impact Assessment, prepared before the Future Skills Passport is used by real pupil classes. It should be reviewed and signed off by a data protection professional, and the bracketed fields completed, before launch.

The short version

The Future Skills Passport processes a small, pseudonymous set of children’s data — a first name or nickname, an age number, an avatar, and lesson progress. Because it is used by children, a DPIA is appropriate. This assessment finds the main risks are identification of a child and unauthorised access to data; with the measures described — data minimisation, row-level security, encryption, UK/EU hosting and Children’s Code-aligned design — the residual risk is assessed as low, subject to professional review and sign-off.

1Why a DPIA is needed

A Data Protection Impact Assessment (DPIA) is required under Article 35 of the UK GDPR where a type of processing is likely to result in a high risk to the rights and freedoms of individuals. The Information Commissioner’s Office (ICO) expects a DPIA to be carried out where a service is used by, or aimed at, children, and the use of children’s data is one of the screening criteria the ICO lists.

The Future Skills Passport is an online learning programme for primary-school pupils. It therefore processes the personal data of children — a vulnerable group. This DPIA has been carried out before the programme is used by real pupil classes, and will be kept under review.

2Describing the processing

Nature of the processing

The Future Skills Passport is a web-based programme through which a pupil works through twelve life-skill “strands”. A teacher creates a class; pupils join it by scanning a QR code or following a link, then choosing a display name and an avatar. As a pupil completes lessons, their progress and end-of-strand scores are saved so the work is not lost and follows them between devices. A teacher can see the progress of their own class and produce a class progress report.

Scope of the processing

The personal data processed is: from a pupil — a display name (a first name or nickname), a single age number, a chosen avatar, and lesson progress and scores; from a teacher — an email address and the names of classes they create. There is roughly one record per pupil per class. No surnames, dates of birth, addresses, contact details, photographs of children, or special category data are collected. Data is retained for the school year: a class is archived and deleted at year end, or earlier on the teacher’s instruction.

Context of the processing

The data subjects are primary-age children (typically Key Stage 2 / Year 6) and their teachers. Children are a vulnerable group and may not fully understand the risks of sharing data, so the processing is treated with particular care. Where a school uses the programme, the school is the controller and Spark2 Education is the processor under a written Data Processing Agreement. The processing is novel only in being a new product; the data itself is limited and the design follows the ICO’s Age Appropriate Design Code (the “Children’s Code”).

Purposes of the processing

To deliver life-skills education to pupils; to save each pupil’s progress so it is not lost; to let a teacher see their class’s progress and produce evidence of personal-development (PSHE / RSHE) provision; and to keep the service secure and working. The data is not used for advertising, is not used to profile children, and is never sold.

3Consultation

The following consultation has informed this assessment, or is planned:

  • The Spark2 Education team, who designed the data model and the security measures.
  • Teachers and schools, whose feedback on the programme and on ease of use has shaped the join flow and the minimal data collected.
  • Outstanding: review and sign-off by a data protection professional before launch.
  • Outstanding: consideration of the views of pupils, parents and carers — for example through the plain-language privacy notice and feedback from pilot schools.

4Necessity and proportionality

Lawful basis

Where a school uses the programme, the school is the controller and determines the lawful basis — commonly the performance of a public task for maintained schools, or another appropriate basis for independent schools. Spark2 Education acts as the school’s processor and does not need its own basis for that data. Where a family uses the programme at home, Spark2 Education is the controller; the lawful basis is to be confirmed with professional advice (likely legitimate interests, or performance of a contract entered into by the parent or carer), with the Children’s Code applied. No special category data is processed, so no Article 9 condition is required.

Achieving the purpose proportionately

  • Data minimisation — only the minimum data needed for the lessons to work is collected. No surname, date of birth, address, contact detail or photograph of a child is requested.
  • Pseudonymous by design — a pupil is known by a first name or nickname and an avatar; a single age number is used rather than a full date of birth.
  • Purpose limitation — the data is used only to run the lessons and produce progress reports. It is not used for advertising, profiling or any unrelated purpose, and is never sold.
  • Storage limitation — data is kept for the school year only; classes are archived and deleted at year end, and a teacher can delete a class or a pupil at any time.
  • Rights — access, rectification and erasure requests are handled via the school as controller, supported by Spark2; for home use, directly with Spark2.

5Risks identified

The table below records the risks to individuals before the mitigating measures in Section 6 are taken into account. Likelihood and severity are each rated low / medium / high; the overall risk level reflects the two combined.

Risk to individualsLikelihoodSeverityRisk level
A pupil sees another pupil’s progress or dataLowMediumLow
A child is identifiable from their data — for example they enter their full real name as their display nameMediumMediumMedium
Unauthorised external access to the databaseLowHighMedium
A teacher account is accessed by someone other than the teacher, exposing a whole classLowMediumLow
A personal data breach occurs at a sub-processor (e.g. the hosting provider)LowHighMedium
Personal data is transferred outside the UK / EULowMediumLow
Personal data is kept for longer than is neededMediumLowLow
Children are nudged into providing more data than necessaryLowMediumLow

6Measures to reduce risk

The table below sets out the measures in place to address each risk and the residual risk once those measures are applied.

RiskMeasures in placeResidual risk
A pupil sees another pupil’s dataRow-level database security keys every record to its owner; a pupil session can only read and write that pupil’s own row, and cannot read the class table at all. The rules are verified by an automated data-isolation test before launch.Low
A child is identifiable from their dataThe design asks only for a first name or nickname — no surname field exists. Joining guidance, and the teacher setup guide, encourage the use of first names or nicknames. The privacy notice explains this to parents and teachers. A single age number is used, not a date of birth.Low
Unauthorised external access to the databaseData is encrypted in transit; access to production systems is restricted and authenticated; row-level security applies even if a request reaches the database; the publishable key alone returns no pupil data.Low
A teacher account is misusedTeacher sign-in uses a one-time email link — there is no reusable password to guess or leak. A teacher only ever sees the classes they created.Low
A breach at a sub-processorA reputable hosting provider is used; the Data Processing Agreement flows down equivalent obligations to each sub-processor and requires breach notification within 48 hours; the sub-processor list is kept current.Low
Transfer outside the UK / EUData is hosted in UK / EU data centres; the Data Processing Agreement prohibits transfers outside the UK / EU without authorisation and an appropriate transfer mechanism.Low
Data kept too longClasses are archived and deleted at the end of the school year; a teacher can delete a pupil or a class at any time; deletion cascades to the pupil records within a class.Low
Children nudged into over-sharingThe programme follows the Children’s Code: privacy-protective settings by default, plain-language information, no advertising, no tracking, no profiling, and no design techniques that encourage children to provide more data.Low

7Sign-off and outcomes

This section records the decisions taken. It is to be completed and signed before the programme is used by real pupil classes.

ItemDetail
Measures approved by[Name and role — to be completed]
Residual riskAssessed as low, subject to review and sign-off by a data protection professional.
Data protection adviser’s advice[To be completed. Spark2 Education is not required to appoint a statutory Data Protection Officer, but the advice taken should be recorded here.]
Prior consultation with the ICO needed?No — the residual risk is not assessed as high. To be confirmed at professional review.
This DPIA to be reviewedBefore launch; on any significant change to the data collected or how it is used; and at least once a year.
Date and versionDraft v1 — May 2026. [Sign-off date to be completed.]

Contact

Questions about this assessment or about how data is handled: hi@spark2.org.