Data Protection Impact Assessment

1. Why we have a DPIA

SoloCogs processes children's personal data, including SEND register flags and accessibility-feature telemetry that reveals a learner's working pattern. Article 35 of the UK GDPR requires a Data Protection Impact Assessment for "any processing of children's personal data that involves automated decision-making or extensive profiling, or processing of special-category data."

We treat the DPIA as a live document: it gets reviewed annually, when the schema changes materially, and whenever a new sub-processor is added. The current version is summarised on this page; schools and tutoring companies can request the signed PDF (with our risk-scoring methodology) from hello@solocogs.co.uk.

2. Scope

This DPIA covers all personal data processed by SoloCogs in delivery of the platform. It explicitly addresses:

• Account data (parent / tutor / staff / student names, emails, school).
• Learning data (quiz attempts, Required Practical submissions, resource progress, Knowledge Check scores, XP / level / element progression).
• Accessibility telemetry (which a11y features a student uses, when, how often - feeds the "normal way of working" panel).
• SEND register flags (demographic_tags JSONB: SEN-K / EHCP, EAL, PP, LAC, YC, access arrangements, SENCo notes).
• Wellbeing data (Zones of Regulation entries, optional self-rated confidence ratings on quizzes).
• Anonymised analytics (Google Analytics 4, opt-in only).

This DPIA does not cover Stripe-handled card data; that processing sits under Stripe's own PCI DSS attestation.

3. Necessity and proportionality test

For each processing purpose we documented the lawful basis (typically contract for service delivery and consent for analytics), the minimum data required, and whether the same outcome could be achieved with less data. The biggest discipline this exercise produced was the student_accounts_safe view - a database view that excludes demographic_tags so a student session cannot read their own SEND register entries. The principle: a learner should never discover from the platform that they are on the SEND register.

4. Risk matrix (summary)

Risks are scored by likelihood × impact before and after safeguards. Below is the public summary; the full table including residual-risk justifications is in the requestable PDF.

Risk	Before safeguards	Safeguards applied	Residual
Unauthorised access to another student's progress	High	Row-level security (RLS) on every table; enforced at the database, not the application. Penetration-tested.	Low
Student discovers their own SEND register entry	Medium	student_accounts_safe view excludes demographic_tags; student sessions hit the view, not the table.	Low
School staff sees students from another school	High	RLS keyed on tenant + parent / school assignment; staff sessions only see rows their assignment grants. Reviewed quarterly.	Low
Personal data leaves the UK / EU	Medium	All data hosted in West Europe / London (Supabase, eu-west-2). UK residency. No US data flows. Analytics (GA4) configured for IP truncation + EU-only collection where available.	Low
Safeguarding disclosure inside a free-text answer is missed	High	SoloSpell keyword detection on submitted answers; flagged content surfaces in the staff dashboard's safeguarding queue. DSL escalation pathway documented in policy-safeguarding.html.	Medium
Data retained beyond necessity	Medium	Soft-delete + 90-day purge on cancellation; daily backups retained 30 days; admin_delete_user RPC available on request for irreversible removal.	Low
Account compromise (weak password / phishing)	Medium	Minimum 10 characters on student accounts (12 on adults), Pwned-password (HIBP) check enforced for adults at signup, length-only complexity rule (NCSC modern guidance). Staff-generated password resets are one-time passphrases with a force-change-on-first-login flag, so the staff member never knows the long-term password.	Low
Student locked out, no adult immediately available to reset	Medium	Opt-in student-self-recovery via a parent-confirmed third-party email (typically the child's school email). Off by default. Each reset attempt fires an audit row and an email notification to the parent / carer so the adult is never out of the loop. Rate-limited to 3 attempts per hour per username to block enumeration / brute force.	Low
Recovery email misused (sent without consent, used for marketing)	Medium	Recovery email is opt-in, off by default, with a documented purpose-limitation clause in the privacy policy. Used only for (1) initial confirmation, (2) reset link to the student, (3) reminder cadence to the parent (Day 3 / 7 / 14 then quiet). Never shared with analytics, advertising, or third parties. Hard-deleted within 30 days of toggle-off or account closure.	Low

5. Sub-processors

Same list as section 9 of our GDPR & Data Residency one-pager. Material changes notified at least 30 days in advance to all paying customers.

6. Consultation

The DPIA has been reviewed by the data controller (Portsdown Tuition, Jazz McCullough) and by a qualified data-protection consultant. Where children's data is processed, we additionally consulted with two parent advisors (one neurodivergent parent, one parent of a child with an EHCP) on the design choices around the SEND register storage. The DPIA is reviewed annually and after any material change.

7. Decision

After applying the safeguards above, the residual risk is judged acceptable for the purposes of the platform. We do not require ICO consultation under Article 36(1) of the UK GDPR for the current processing footprint. We will re-consult and update this DPIA if the processing footprint expands materially (e.g. if SoloCogs adopts any form of automated decision-making with legal effect, or onboards a non-EU sub-processor).