Child-Minder: data protection impact assessment

Date: 17 March 2026

Status: Draft outline for completion by the Data Controller

Template basis: ICO DPIA template (ico.org.uk)

Part 1: Identify the need for a DPIA

1.1 What is the project?

Child-Minder is an independent prototype placement tracker (not an official Care Inspectorate system) that enables parents to record their child's placement with a specific childminder. If adopted as a proposed national system, it would allow the Care Inspectorate to cross-reference the number of children placed with each childminder against their permitted capacity limits, as set out in their conditions of registration.

1.2 Why is a DPIA needed?

• The processing involves personal data about children, which the ICO considers to be a factor indicating potentially high risk
• The processing operates at scale across a specific population (approximately 22,000 children in childminding settings across Scotland)
• The processing involves systematic monitoring of childminder capacity

1.3 What prompted this processing?

Cases have demonstrated that childminders can care for significantly more children than their registered capacity permits. The existing self-reporting model provides no independent mechanism for the Care Inspectorate to verify compliance between inspection visits.

Under the current regulatory framework, the Care Inspectorate relies on childminders' self-reporting to verify compliance with capacity limits. There is no mechanism for parents to independently register their child's placement, and no automated system for cross-referencing the number of children against permitted limits.

A national system of this kind would enable this cross-referencing. While concerns have been raised about legal, digital, and data protection requirements, this DPIA demonstrates that the risks are manageable and the measures required are standard.

1.4 Is this processing on the ICO's list requiring a DPIA?

The ICO's published list of processing operations requiring a DPIA includes “processing of personal data of children for the purpose of profiling or automated decision-making or for marketing or offering online services directly to them.” Child-Minder does not profile children, does not make automated decisions about children, does not market to children, and is not an online service offered to children (it is used by parents and inspectors). However, the processing does involve children's data at scale, which is a factor the ICO considers relevant. A DPIA is therefore advisable, even if not strictly mandated by the list.

Part 2: Describe the processing

2.1 What personal data is collected?

2.2 What personal data is not collected (and why)?

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

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?

2.6 How is data used?

1. Age bracket calculation: Birth year and month are used to calculate whether a child falls into the under-1, preschool (not yet at primary school), under-12 or under-16 age bracket for capacity limit purposes
2. Capacity monitoring: Active placements per childminder are counted and compared against the childminder's registered capacity limits
3. Alert generation: When capacity limits are reached or exceeded, automated alerts are generated for Care Inspectorate inspectors to review
4. 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 service.

Part 3: Consultation

3.1 Stakeholders consulted (or to be consulted)

3.2 Data subjects' views

• 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?

Lawful basis: 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).

Not relied upon: Article 6(1)(c) UK GDPR (legal obligation). That basis requires a legal obligation on the controller itself. The Requirements for Care Services (Scotland) Regulations 2011 place duties on childminders as care service providers, not on the Care Inspectorate, and no law obliges the Care Inspectorate to operate this system.

No special category data is processed, so no Article 9 condition is required.

4.2 Is the processing necessary?

• 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)

4.3 Is the processing proportionate?

• 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)

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?

• 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)

4.6 What information is provided to data subjects?

• 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

5.2 Overall risk assessment

1. Extreme data minimisation: No names, addresses, health data, or special category data
2. Pseudonymous identification: Children are identified by system-generated references
3. Database-enforced access control: RLS policies cannot be bypassed by application-layer vulnerabilities
4. No automated decisions: All alerts are reviewed by human inspectors
5. Comprehensive audit trail: Every data operation is logged with user identification and timestamp
6. Voluntary participation: Parents choose to register

Part 6: Identify measures to mitigate risks

6.1 Technical measures

6.2 Organisational measures

6.3 Contractual measures

Part 7: Residual risk assessment

Part 8: Sign-off

Data Protection Officer

Senior Information Risk Owner (SIRO)

Project sponsor

Part 9: Review schedule

• 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