Data protection impact assessment

Print or save as PDF

Version 1.0 · 23 September 2026 · en-GB · prepared by The Code Guy Ltd for adoption by the controller

How to use this

You are the controller. This assessment describes the product accurately, so the sections about what the app does, where data goes and what controls exist are done. Three things are yours to fill in: who you consulted (section 3), anything your setting does that is not described here, and the sign-off at the end. Review it when you change how you use the app, and at least annually.

1. Identify the need for a DPIA

The processing is of children's personal data, including health data and safeguarding records, on a new system, partly on mobile devices used outdoors, with a portal that gives parents access to their own child's record. Children are vulnerable data subjects and special category data is involved, so a DPIA is required under Article 35(3)(b) of the UK GDPR and is expected by the ICO's list of processing likely to result in high risk. It is also expected of a school by its own safeguarding and data protection arrangements.

The system being assessed is the Forest School App, produced by The Code Guy Ltd: a web application used in the office and a field app used on a phone or tablet in the woods, with no signal, which syncs back when it has one.

2. Describe the processing

2.1 Nature: what happens to the data

Staff enter children's details, either by typing them in or by a parent completing your booking form. Consents, emergency contacts, medical details and dietary needs sit on the child's record. A term of sessions is planned, with risk-benefit assessments attached to each. On the day, a leader opens the session on a phone, takes the register, records a dynamic risk check, notes observations and any accident, incident or medication, and takes photographs where the child's photo consent allows. A safeguarding concern, if one is raised, goes to a separate place that only the Designated Safeguarding Lead can open. Records are stored in a UK database; photographs and documents in UK object storage. Parents you invite can see their own child's record and shared observations through a portal. Records are erased on the schedule in section 7, or on request.

The field app holds an offline copy of the children and sessions the device needs, because the woods have no signal. It syncs by adding and updating records, each one carrying an id the device generated, so a sync that runs twice cannot duplicate anything. Signing out of the field app wipes the copy. Safeguarding concerns are never held on a device belonging to anyone but the DSL, and leave the device the moment there is a connection.

2.2 Scope: what data, about whom, how much

Data subjects	Personal data	Special category or criminal offence
Children attending sessions	Name, preferred name, date of birth, group, photograph, attendance, observations and development notes, consents, field notes, booking answers	Allergies, medical conditions, medication, dietary needs, care plan notes, SEND and EHCP notes, medication administered, accidents and incidents, safeguarding concerns
Parents, carers and emergency contacts	Name, relationship, phone, email, whether they may collect, messages	None
Staff, volunteers and helpers	Name, email, role, qualifications, policy and assessment sign-offs	DBS check existence, date, number and status; first aid certification
People booking a place	Name, email, amount paid, references	None. Card details never reach the app

Volume: the number of children on your roster, plus one session record per session run. Data is held for as long as section 7 says and then removed. It is collected from you, from parents through your booking form and the family portal, and from leaders in the field.

2.3 Context

Children have limited ability to exercise their own rights, and parents act for them. The relationship is one your families already have with you: this replaces a paper register, a lever-arch file of risk assessments and a phone camera roll. It does not introduce a new relationship or a new party. There is no automated decision-making and no profiling. Nothing is used to train a model, to advertise, or to build anything beyond the service to you. The processing is not novel: it is the same record keeping done on paper, with the additional risk and the additional protection that come from doing it on a device.

2.4 Purposes

• Keeping children safe: knowing who is present, who is collecting them, what they are allergic to, and what the ratio is.
• Meeting your statutory duties: attendance, accident and incident records, medication records, safeguarding records.
• Recording what each child gained, and sharing that with their family.
• Taking bookings and payment for places, where you charge for them.

3. Consultation

Complete this for your own setting. Record who you consulted and what came of it: your Designated Safeguarding Lead, your data protection officer or data protection lead, the forest school leaders who will use it, your governors or trust board, and parents. Record whether you asked parents' views on photographs and on the family portal, or why you decided not to. The Code Guy Ltd can answer questions on the product in writing at dpo@thecodeguy.co.uk.

4. Necessity and proportionality

4.1 Lawful basis

Processing	Article 6	Article 9 or 10, where applicable
Registers, session records, ratios, risk assessments	Public task, or legitimate interests for a private provider	Not applicable
Medical details, allergies, care plans, medication administered	Vital interests, and public task or legitimate interests	Article 9(2)(b) or 9(2)(c), with a DPA 2018 Schedule 1 condition
Safeguarding concerns	Legal obligation, or public task	Article 9(2)(b) with DPA 2018 Schedule 1 paragraph 18, safeguarding of children
Photographs of children	Consent	Not applicable
DBS status of staff	Legal obligation	Article 10, with a DPA 2018 Schedule 1 condition
Bookings and payment	Contract	Not applicable

Confirm these against your own privacy notice and record of processing. Photo consent is the one the app enforces directly: a child without active photo consent cannot be photographed, and the block is applied on the device and checked again on the server.

4.2 Is it necessary and proportionate

• Could you achieve the purpose another way? The alternative is paper. Paper in a rucksack in a wood is lost, soaked, left in a car, and readable by anyone who picks it up. It also cannot enforce a photo consent or tell a leader that a child's inhaler changed this morning.
• Is the data minimised? Each field exists because a leader needs it on the day. Dietary needs are recorded separately from allergies so that a preference is not treated as an emergency. Medical detail is not shared with a parent who holds a report-only link. A child's full name is not sent to the payment provider: the first name only.
• Is it accurate and kept up to date? Parents can propose a change to medical details, which waits for a staff member to approve it rather than changing the record silently. A note heard at the gate is recorded as a note, not as an edit, and the office folds it in. Emergency contacts can be corrected at the gate, and a stale device cannot roll back a correction made in the office that morning.
• Are people told? You tell them, in your own privacy notice. The producer's role is described at /privacy.
• Can people exercise their rights? An owner can export one child's whole record as a file, and erase it, from within the app, without contacting the producer. Parents you invite can see their own child's record.

5. Risks and measures

Likelihood and severity assessed as remote, possible or probable, and minimal, significant or severe. The overall rating is after the measures described.

#	Risk	Likely	Severity	Overall
1	A member of staff sees a safeguarding concern they should not see	Remote	Severe	Low
2	Another organisation's staff see your children's records	Remote	Severe	Low
3	A photograph of a child without photo consent is taken or shared	Remote	Significant	Low
4	A device carrying the offline copy is lost or stolen	Possible	Significant	Medium
5	A member of staff who has left keeps access to children's records	Remote	Severe	Low
6	The wrong adult is given access to a child's record through the family portal	Remote	Severe	Low
7	A photograph or document is reachable by anyone with the link	Remote	Severe	Low
8	The producer's own staff read children's records	Remote	Severe	Low
9	Records are kept longer than needed	Possible	Significant	Medium
10	An erasure request is not fully carried out	Possible	Significant	Medium
11	Data is lost through corruption, a bad change or an accidental deletion	Remote	Significant	Low
12	Personal data is exposed to a third-party service, an analytics tool or a log	Remote	Significant	Low

6. Measures

What reduces each risk, and what is left for you to do.

Risk 1: a member of staff sees a safeguarding concern

Concerns are held in a separate store from children's records, so a routine read of a child can never surface one. Access comes only from the Designated Safeguarding Lead permission, which the organisation's owner grants to a named person and which is recorded when granted. It is not part of being an owner or an administrator: an owner who is not a DSL has no access. Three independent checks enforce it, at the page, at the endpoint and at the storage layer, and any one of them refusing is enough. Every read and write is written to an insert-only access log naming the person, the concern and the time. Concerns appear in no export, no PDF, no email and no operator view.

Your action: name your DSL, and review who holds it each term.

Risk 2: another organisation sees your records

Every read and write carries your organisation's identity and is filtered by it at a single point in the code, which also stamps your organisation onto anything written, so a record cannot be created in the wrong place even if a device claims otherwise. There is one query path that spans organisations, reserved to the producer's operator tier, and it has no method that returns a child's record. Automated tests assert the separation before every deployment.

Risk 3: a photograph without consent

Photo consent is recorded per child and is the single source of truth for the camera. A child without active consent cannot be photographed: the block applies on the device, offline, and is checked again on the server when the photo arrives. A learning journey PDF checks the consent of every child in a photograph, not only the child the document is about, and drops any photo where another child's consent has lapsed. The parent portal applies the same check on every request rather than at the point of sharing, so withdrawing consent takes effect at once.

Your action: collect photo consent from parents, and record a withdrawal promptly.

Risk 4: a lost or stolen device

The field app holds only what the device needs. Signing out wipes it. Credentials are held in the device's own secure storage, never in the app's files. The app is excluded from Google's automatic Android backup, so the offline copy is never copied to a personal Google Drive. A staff member removed from your team has their device session ended at its next request to the server, and their saved sign-in revoked. Safeguarding concerns are not held on a device belonging to anyone but the DSL, and leave the device as soon as there is a connection.

Residual risk, and your action: the offline copy relies on the device's own encryption. Require a screen lock and device encryption on any phone or tablet used in the field, enrol them in your mobile device management if you have one, and tell staff to report a lost device the same day so the account can be suspended.

Risk 5: a member of staff who has left keeps access

Removing someone ends their access without waiting for them to sign out: an open browser session is signed out within five minutes, and a field-app session is refused at its next request to the server. A role change reaches an open browser on the same cycle. Removal, a withdrawn DSL grant and a password change all revoke the saved sign-in on their devices.

Your action: remove leavers from the team list on their last day.

Risk 6: the wrong adult is given access through the family portal

A family link is created by your staff, or requested by a parent and approved by your staff. A public booking that matches a child you already have does not create a link on its own: it raises a request for you to approve. Login codes are short-lived, hashed, capped for attempts and rate limited. A commissioning body given a report-only link sees the development report and nothing else: no contact details, no consents, no medical or dietary information, no bookings.

Your action: check who you are approving. The app will not know that a name is the wrong adult.

Risk 7: a photograph reachable by a link

Photographs and documents are in a private container with anonymous access disabled, under non-guessable names, and no shareable link is ever generated. Every request goes through the application, which resolves the file inside your organisation and checks the reader's permission before a byte is served, so a guessed address from outside your organisation returns nothing. Responses carrying a child's file are marked not to be stored by the browser, so they do not linger on a shared laptop after sign-out. Uploads are identified by their contents rather than their name, and vector graphics are never served inline.

Risk 8: the producer's own staff read children's records

The operator view returns organisations, subscriptions, staff names and counts, and has no method that returns a child's record, an observation, an incident or a medical detail. Support sessions that view the service as one of your staff are time-boxed, require a written reason and are recorded page by page. Safeguarding access is always stripped from such a session. Access to the production database and the hosting subscription is held by a named person and reviewed quarterly.

Your action: ask for the operator access log covering your organisation whenever you want it.

Risk 9: records kept longer than needed

The retention schedule in section 7 is applied by a routine that scrubs a departed child's record, cascading across their sessions, observations, photographs, medication and bookings, and ages out accident and incident forms. Safeguarding concerns are excluded from it and keep their statutory retention.

Your action: remove a child from the roster when they leave, which is what starts their clock, and tell us if your own retention policy is shorter than the schedule.

Risk 10: an erasure request is not fully carried out

Erasure runs through one documented routine, so it reaches the same places every time: the child's record, their attendance, observations, photographs and the stored image files, medication, development notes and bookings. Accident and incident records are kept and de-linked from the child where the law requires the record to survive. Safeguarding concerns are excluded, which is the lawful-basis carve-out, and are removed only on their own schedule. Erasure is confirmed by a second click, and is irreversible once the 35-day backup window has passed.

Your action: record the request and the date you carried it out in your own log.

Risk 11: data loss

Continuous point-in-time backup of the database, restorable to any moment in the last 35 days, with a written restore runbook covering stopping writes, restoring, bringing the data across and verifying. Photographs and documents are held in storage that keeps three copies within the UK region, and a deleted photograph or document is recoverable for 30 days, so both halves of your data are recoverable and not only the records half. Emergency contacts are merged one at a time, newest first, so a phone that has been offline for a week cannot roll back a correction the office made this morning.

Risk 12: exposure through a third party, analytics or a log

The sub-processor list at /procurement is complete, and children's records reach only the hosting provider and, in a notification you choose to send, the email provider. Product analytics runs cookieless with identifiers masked, and the public booking form, where a child's name appears on the page, is excluded from capture. Children's names, dates of birth, medical text and safeguarding text are excluded from logs, analytics and error reports, and every release is checked against that rule. The weather forecast sends the site's coordinates and a date, and the postcode lookup sends the site's postcode; neither carries a person.

7. Retention

Record	Kept for
A child who has left: profile, medical, contacts, consents, observations, photographs, attendance, medication	One year after leaving
Accident, incident and near-miss forms	Three years
Safeguarding concerns	Twenty five years, excluded from routine erasure
Session records, registers, plans, risk-benefit assessments	While the account is open
Staff accounts and compliance records	While the person's link to the organisation is live
The whole organisation after the account closes	Deleted within 30 days
Database backups	35 days rolling
Deleted photographs and documents	Recoverable for 30 days, then gone

8. Safeguarding and Keeping Children Safe in Education

Keeping Children Safe in Education 2026, in force 1 September 2026, expects a named Designated Safeguarding Lead to hold the safeguarding record, staff to raise concerns to that person, concerns to be written down promptly and kept securely, information to be shared with the right people and no one else, and records to be retained. This is how the app is built.

What your arrangements expect	What the app does
A named designated safeguarding lead holds the safeguarding record	DSL is granted to a named person by your owner, separately from every other permission, and recorded when granted. It is not a job title and not part of being an administrator
Any member of staff can raise a concern, straight away	A leader raises a concern from the session on their phone, offline. It goes to the DSL and is not readable by the person who raised it
Concerns are recorded promptly, in writing, with dates	The concern carries who raised it, when, the category, the detail, a status of open, monitoring, referred or closed, and an append-only timeline of what was done
Records are kept securely and access is limited	A separate store, three independent checks, no access without the DSL grant, and no export, PDF, email or operator route that reaches one
You can show who has accessed a record	Every read and write is written to an insert-only access log naming the person, the concern, the action and the time
Records are retained beyond the child leaving	Concerns are excluded from erasure and from the retention sweep, and keep their own long retention
Safeguarding information is not shared with a supplier	The producer's operator tier cannot read a concern, and the support session that views the service as one of your staff always has safeguarding stripped from it

Cross-reference this table to your own child protection policy when you adopt the assessment. The 2026 edition expects all staff to read the whole of Part one.

9. Outcome and sign-off

Residual risk	Low, with two mediums: a lost device, and records kept longer than needed. Both are reduced by actions listed against risks 4 and 9 and both sit with the controller
Prior consultation with the ICO	Not required. No residual high risk remains after the measures above
Measures approved by	Complete on adoption
Review date	One year from sign-off, or sooner if how you use the app changes

Questions about anything in this assessment go to dpo@thecodeguy.co.uk, and we will answer in writing. The data processing agreement and the rest of the procurement pack sit alongside it.