Data Protection Impact Assessment -- Child-Minder
Outline and Draft Content
Date: 17 March 2026
Status: Draft outline for completion by the Data Controller
Template basis: ICO DPIA template (ico.org.uk)
Part 2: Describe the Processing
2.1 What personal data is collected?
| Data Item | Source | Data Subject | Special Category? |
|---|
| Parent email address | Provided by parent at registration | Parent | No |
| Child birth year | Provided by parent when registering child | Child (via parent) | No |
| Child birth month | Provided by parent when registering child | Child (via parent) | No |
| System-generated child reference (e.g., Child-Minder-A7K9M2) | Auto-generated by system | Child | No |
| Childminder registration number | Selected by parent from public register | Childminder (already public data) | No |
| Placement start date | Provided by parent | N/A (event date, not personal data per se) | No |
| Placement end date | Provided by parent | N/A (event date) | No |
No special category data is collected. No names, addresses, health data, ethnicity, religion, photographs, biometric data, or financial information is collected about children or parents.
2.2 What personal data is NOT collected (and why)?
| Excluded Data Item | Reason for Exclusion |
|---|
| Child's name | Not needed for capacity checking. Pseudonymous reference sufficient. |
| Child's full date of birth | Only year and month needed for age bracket calculation. Day of birth adds identifiability without utility. |
| Child's address | Not needed for capacity checking. |
| Parent's name | Not needed. Email sufficient for authentication. |
| Parent's address | Not needed for any register function. |
| Parent's phone number | Not needed. Email is the sole communication channel. |
| Health data | Not needed for capacity checking. This data is held by the childminder under their own legal obligations. |
| Photographs | Not needed for any register function. |
2.3 How is data collected?
- Parents create an account using their email address
- Parents register children by entering birth year and birth month only
- Parents select a childminder from a list populated from the Care Inspectorate's public register
- Parents record placement start and end dates
- The system automatically generates a pseudonymous child reference
All data is provided voluntarily by the parent. No data is obtained from third parties, scraped from other systems, or inferred.
2.4 How is data stored?
- All data is stored in a PostgreSQL relational database hosted on Supabase (cloud-hosted, UK-region servers)
- Data is encrypted at rest (AES-256) and in transit (TLS 1.2+)
- Row-Level Security (RLS) policies enforce access control at the database engine level
- An audit table records every INSERT, UPDATE, and DELETE operation with timestamp and user identification
2.5 Who has access to the data?
| Role | Access Level | Enforced By |
|---|
| Parent (authenticated) | Own children's records only. Own placements only. No access to other parents' data. | Database RLS policy: `parent_id = get_profile_id()` |
| Inspector (authenticated) | Childminder capacity overview (aggregate counts, age brackets, alert status). Pseudonymous child references. No access to parent email addresses. | Database RLS policy: `is_inspector() = true` |
| System administrator (service role) | Full database access for maintenance and support | Supabase service role key, restricted to authorised personnel |
| Data processors (hosting provider) | Infrastructure-level access only, under data processing agreement | Contractual and technical controls |
2.6 How is data used?
- Age bracket calculation: Birth year and month are used to calculate whether a child falls into the under-5, under-12, or under-16 age bracket for capacity limit purposes
- Capacity monitoring: Active placements per childminder are counted and compared against the childminder's registered capacity limits
- Alert generation: When capacity limits are reached or exceeded, automated alerts are generated for Care Inspectorate inspectors to review
- Inspector review: Inspectors review capacity data and alerts to identify potential non-compliance for further investigation
2.7 Data flows
Parent (browser) --[HTTPS]--> Application Server --[encrypted]--> Database
|
Inspector (browser) --[HTTPS]--> Application Server --[RLS filtered]--+
|
Audit Log <--+
No data flows to any external system. No data is shared with third parties. No data is exported or transmitted outside the register.
---
Part 3: Consultation
3.1 Stakeholders consulted (or to be consulted)
| Stakeholder | Interest | Consultation Method |
|---|
| Parents of children in childminding | Direct interest in capacity compliance and child safety | Public consultation recommended prior to launch |
| Parents of children in childminding (general) | Users of the proposed register | Public consultation recommended prior to launch |
| Registered childminders | Subject to capacity monitoring; registration data used | Consultation via Scottish Childminding Association (SCMA) recommended |
| Care Inspectorate | Proposed data controller and operator | Internal assessment required |
| Care Inspectorate DPO | Data protection compliance | DPIA review and sign-off required |
| Information Commissioner's Office | Supervisory authority | Prior consultation under Article 36 if residual high risk remains after mitigation (unlikely given data minimisation) |
| Scottish Government | Policy owner; responsible for legislative framework | Ministerial briefing recommended |
| SCMA (Scottish Childminding Association) | Representative body for childminders | Consultation on implementation approach |
| Local authorities | Commission funded childminding places; Quality Improvement Officers interact with childminders | Consultation on integration with existing processes |
3.2 Data subjects' views
The register is designed around voluntary participation by parents. Parents choose whether to register their child. This voluntary model provides parents the ability to register without imposing an obligation to do so. However, the register's effectiveness increases with participation. A public consultation should explore whether registration should be:
- Voluntary (parent chooses)
- Encouraged (childminder asks parents to register as part of their onboarding process)
- Required (as a condition of the childminding arrangement, potentially backed by regulation)
---
Part 4: Assess Necessity and Proportionality
4.1 What is the lawful basis?
Primary: Article 6(1)(e) UK GDPR -- processing is necessary for the performance of a task carried out in the public interest (the Care Inspectorate's statutory regulatory function under the Public Services Reform (Scotland) Act 2010).
Alternative: Article 6(1)(c) UK GDPR -- processing is necessary for compliance with a legal obligation (monitoring compliance with the Requirements for Care Services (Scotland) Regulations 2011).
No special category data is processed, so no Article 9 condition is required.
4.2 Is the processing necessary?
Yes. The current regulatory framework relies on childminder self-reporting for compliance with capacity limits. Cases have demonstrated that this self-reporting mechanism can fail, with childminders caring for significantly more children than permitted without detection. An independent cross-referencing mechanism is necessary to verify compliance.
There is no less intrusive way to achieve the same objective. The alternatives are:
- More frequent unannounced inspections: More intrusive (inspectors entering homes more often), more expensive (inspector time), and still relies on the number of children present at the moment of inspection (children may not all be present at the same time)
- Reliance on parental complaints: Parents have reported being afraid to raise concerns for fear of retaliation, creating a cultural barrier to effective oversight.
- Financial cross-referencing (HMRC): More intrusive (involves financial data), slower (annual tax return cycle), and less precise (income alone does not prove the number of children)
The register is the least intrusive mechanism that provides reliable, real-time capacity monitoring.
4.3 Is the processing proportionate?
Yes. The data collected is the absolute minimum necessary:
- No names (pseudonymous reference sufficient)
- No full DOB (year and month sufficient for age bracket)
- No addresses (not needed)
- No health data (not needed)
- No special category data (none)
The processing achieves a legitimate aim (child safety through capacity monitoring) using the least amount of personal data possible. The data subjects (parents) voluntarily provide the data. The processing does not result in any automated decision about any data subject.
4.4 How is data quality ensured?
- Parents are responsible for the accuracy of the birth year and month they provide
- Childminder registration numbers are validated against the Care Inspectorate's public register
- Capacity limits are imported from the Care Inspectorate's registration records
- Parents can update or correct their children's records at any time
- Parents can end placements and delete records
4.5 How is data minimisation achieved?
The register was designed from inception around the principle of data minimisation (Article 5(1)(c) UK GDPR). The design question was: "What is the absolute minimum data needed to check whether a childminder has more children than their registration permits?" The answer:
- Which childminder? Registration number (already public)
- How many children? A count of active placements (requires child records, but not names)
- Which age bracket? Birth year and month (not full DOB, not name, not address)
Everything else was excluded by design.
4.6 What information is provided to data subjects?
A full privacy notice compliant with Articles 13/14 UK GDPR is provided (see `privacy-notice.md`). It explains:
- What data is collected and why
- The lawful basis for processing
- Who has access to the data
- How long data is retained
- Data subjects' rights (access, rectification, erasure, restriction, objection, portability, complaint)
- Contact details for the DPO and the ICO
---
Part 5: Identify and Assess Risks
5.1 Risk Register
| # | Risk | Likelihood | Severity | Overall Risk | Justification |
|---|
| R1 | Unauthorised access to child records by another parent | Very Low | Medium | LOW | RLS policies enforce parent-only access at database level. Even application-layer compromise cannot bypass database-enforced access controls. |
| R2 | Data breach exposing child records | Low | Low | LOW | Breach would expose pseudonymous references (e.g., Child-Minder-A7K9M2), birth year/month, and placement dates. No names, addresses, or health data. Identifiability from birth year/month alone is very low. |
| R3 | Inspector misuse of capacity data | Low | Medium | LOW | Inspectors see aggregate capacity data and pseudonymous references. They cannot identify specific children or parents without cross-referencing with external data they do not have access to through the register. Audit trail records all inspector access. |
| R4 | Function creep (register expanded beyond original purpose) | Medium | Medium | MEDIUM | Governance controls needed to prevent the register being expanded to collect additional data (names, addresses, health data) beyond its original minimal scope. Requires Change Advisory Board approval for schema changes. |
| R5 | Inaccurate data leading to false capacity alerts | Medium | Low | LOW | Parents may not update placements promptly when they end, leading to inflated counts. Alerts are reviewed by human inspectors before any action is taken. No automated enforcement. |
| R6 | Re-identification of children from combined data | Very Low | Medium | LOW | Birth year/month + childminder registration number + placement dates could theoretically narrow identification, but without names or addresses, positive identification would require access to external data (e.g., the childminder's own records). The register itself does not provide sufficient data for re-identification. |
| R7 | Loss of data availability | Low | Low | LOW | Database backups, redundancy, and disaster recovery are standard features of the hosting platform. Loss of availability would temporarily prevent parents from registering placements but would not affect child safety (the register is a monitoring tool, not a safety-critical system). |
| R8 | Non-participation reducing effectiveness | Medium | Medium | MEDIUM | If few parents register, the capacity monitoring is incomplete. This is a programme risk, not a data protection risk, but it affects whether the processing achieves its stated purpose. |
5.2 Overall Risk Assessment
The overall data protection risk of Child-Minder is
LOW. This is primarily because:
- Extreme data minimisation: No names, addresses, health data, or special category data
- Pseudonymous identification: Children are identified by system-generated references
- Database-enforced access control: RLS policies cannot be bypassed by application-layer vulnerabilities
- No automated decisions: All alerts are reviewed by human inspectors
- Comprehensive audit trail: Every data operation is logged with user identification and timestamp
- Voluntary participation: Parents choose to register
The single medium-risk item (R4, function creep) is an organisational governance risk that requires policy controls rather than technical controls.
---
Part 6: Identify Measures to Mitigate Risks
6.1 Technical Measures
| Risk | Measure | Status in Prototype |
|---|
| R1 (unauthorised access) | Row-Level Security policies enforcing parent-only access to own records | Implemented |
| R1 (unauthorised access) | Supabase Auth with email/password authentication and JWT tokens | Implemented |
| R2 (data breach) | Encryption at rest (AES-256) and in transit (TLS 1.2+) | Implemented (platform default) |
| R2 (data breach) | Data minimisation: no names, addresses, or health data stored | Implemented by design |
| R2 (data breach) | Pseudonymous child references instead of names | Implemented |
| R3 (inspector misuse) | Audit trail logging all data operations with user ID and timestamp | Implemented |
| R3 (inspector misuse) | Inspector role limited to SELECT access on relevant tables | Implemented |
| R5 (inaccurate data) | Unique constraint preventing duplicate active placements | Implemented |
| R5 (inaccurate data) | Human review of all capacity alerts before action | Implemented (alerts are informational) |
| R6 (re-identification) | No names or addresses stored; birth year/month only (not full DOB) | Implemented by design |
| R7 (availability) | Database backups and platform redundancy | Platform default |
6.2 Organisational Measures
| Risk | Measure | Status |
|---|
| R3 (inspector misuse) | Inspector access linked to active Care Inspectorate employment; revoked on departure | To be implemented |
| R3 (inspector misuse) | Quarterly access reviews by information governance team | To be implemented |
| R4 (function creep) | Schema changes require Change Advisory Board approval and DPIA addendum | To be implemented |
| R4 (function creep) | Annual review of data collected against stated purposes | To be implemented |
| R4 (function creep) | DPO sign-off required for any extension of data collected | To be implemented |
| R5 (inaccurate data) | Periodic reminders to parents to update placement status | To be implemented |
| R8 (non-participation) | Communication campaign to childminders and parents | To be implemented |
| All | Staff data protection training for all users with inspector access | To be implemented |
| All | Data breach response procedure (Articles 33/34 UK GDPR) | To be implemented |
| All | Data retention schedule with automated deletion | Architecture supports; policy to be implemented |
6.3 Contractual Measures
| Risk | Measure | Status |
|---|
| R2, R7 | Data processing agreement with hosting provider (Supabase) compliant with Article 28 UK GDPR | To be executed |
| R2, R7 | Data processing agreement with application hosting provider (Vercel) | To be executed |
| R2 | Requirement for data processor to notify data controller of breaches without undue delay | To be included in DPA |
---
Part 7: Residual Risk Assessment
After the measures identified in Part 6 are implemented, the residual risk profile is:
| # | Risk | Residual Risk | Notes |
|---|
| R1 | Unauthorised access | Very Low | Database-enforced RLS; authentication required |
| R2 | Data breach | Very Low | Even if breached, minimal PII exposed (no names, addresses, health data) |
| R3 | Inspector misuse | Low | Audit trail, access reviews, employment-linked access |
| R4 | Function creep | Low | CAB approval, DPO sign-off, annual review |
| R5 | Inaccurate data | Low | Human review of alerts; no automated enforcement |
| R6 | Re-identification | Very Low | Insufficient data for identification without external sources |
| R7 | Availability | Very Low | Platform redundancy and backups |
| R8 | Non-participation | Low-Medium | Communication strategy; consider regulatory encouragement |
No residual high risks remain. Prior consultation with the ICO under Article 36 UK GDPR is therefore not required, though voluntary engagement with the ICO is recommended as good practice.
---
Part 8: Sign-Off
Data Protection Officer
| Field | Value |
|---|
| Name | [To be confirmed] |
| Title | Data Protection Officer, Care Inspectorate |
| Date | [To be confirmed] |
| Decision | [Approve / Approve with conditions / Refer to ICO] |
| Comments |
| Signature |
Senior Information Risk Owner (SIRO)
| Field | Value |
|---|
| Name | [To be confirmed] |
| Title | [To be confirmed] |
| Date | [To be confirmed] |
| Decision | [Approve / Approve with conditions / Do not proceed] |
| Comments |
| Signature |
Project Sponsor
| Field | Value |
|---|
| Name | [To be confirmed] |
| Title | [To be confirmed] |
| Date | [To be confirmed] |
| Acknowledgement | I confirm I have read the DPIA and accept the residual risks identified |
| Signature |
---
Part 9: Review Schedule
This DPIA should be reviewed:
- Before launch: Final review incorporating any changes made during development
- 6 months after launch: Review actual usage patterns, any incidents, and whether the risk profile remains as assessed
- Annually thereafter: Standing annual review
- On any material change: Any change to the data collected, the access model, or the hosting infrastructure triggers a DPIA review
---
_This is a draft DPIA outline prepared for the Child-Minder prototype. It follows the ICO's recommended DPIA structure and would require completion by the Care Inspectorate's Data Protection Officer, including formal sign-off, before the register could go live. The technical measures marked as "Implemented" refer to the prototype's database schema and application architecture. Organisational and contractual measures marked as "To be implemented" are standard items that would be addressed during a production deployment._