Phonic Zoom Data Protection Impact Assessment (DPIA)
Step 1: Identify the need for a DPIA
Explain broadly what project aims to achieve and what type of processing it involves. You may find it helpful to refer or link to other documents, such as a project proposal. Summarise why you identified the need for a DPIA.
The software supports children in their learning of phonics, spelling and reading by providing a suite of games and engaging features designed to make them want to learn more. The system is available through an installable mobile app as well as a web-based version of that application through a secure website. Schools and Parents need to be able to identify their own children within the application and that requires us knowing the children’s names and classes so they can be grouped and reported on appropriately and securely.
We will separately be storing parent and staff names and email addresses to support them accessing the system as well as using Stripe as a third party payment processor to ensure all payment details are as secure as possible.
Step 2: Describe the processing
Describe the nature of the processing: how will you collect, use, store and delete data? What are the sources of the data? Will you be sharing data with anyone? You might find it useful to refer to a flow diagram or other way of describing data flows. What types of processing identified as likely high risk are involved? Does your service involve any profiling, automated decision-making, or geolocation elements? What are your plans (if any) for age-assurance? What are your plans (if any) for parental controls?
Data is added to the system by schools or parents. Where schools use our system they are the Data Controller using us as the Data Processor. They can enter this data via our administration panel that only certain authorised staff members have access to. All data is stored securely within the UK at secure locations that can only be accessed by specific employees and sub-processors named on our DPA.
Where Parents use our system we offer a Privacy Policy that explains their rights and our data processing.
We do not process any data considered to be ‘high risk’, but treat all data confidentially and in line with processes compliant with ISO 27001, CE+ and other such standards.
The service involves no profiling, automated decision making or geolocation functionality.
Child-related Data will only ever be processed within the UK and is never transferred internationally for any purpose unless a customer or their child themselves is accessing the application from an international location.
Adult-related Data will sometimes be processed outside of the UK through one of the third party processors we use for processing of payments, Customer Relationship Management and marketing. We have chosen these systems as they are industry leaders in their respective fields.
Data can be deleted by the Data Controller using their access to the administration panel or a deletion can be processed via submitting a request to our support team.
Any element of age assurance is on the Data Controller. We do not specify an age limit for the application, but would expect that it is used by children over the age of 4.
Parents have ultimate control over their own accounts as well as those of their children. Because the application itself is so well sandboxed there is no need for parental controls beyond this
Wherever adult-related data is processed it is done so in line with our Terms of Service. We will never use their data for purposes other than those to which they have agreed and do not profile, make automated decisions or geolocate adults either.
Describe the scope of the processing: what is the nature of the data, and does it include special category or criminal offence data? How much data will you be collecting and using? How often? How long will you keep it? How many individuals are affected? What geographical area does it cover?
The data relates to the names, roles, voice recordings of the Customer’s staff and the names and class groups of the Customer’s children/pupils as outlined in our DPA
Adult-related data will include staff names, parent names and email addresses for staff and parents.
We will not be processing any special category or criminal offence data.
We will keep it for the periods outlined in our Privacy Policies and Data Processing Addendum agreed to by the Data Controller upon subscription to the service.
The number of individuals affected depends on the number of pupils and staff in a given school or under a given parental account, but an average Data Controller might be asking us to process ~300 individuals’ data.
Describe the context of the processing: what is the nature of your service? Are you designing it for children? If not, are children under 18 likely to access it anyway? What is the likely age range of your users? How much control will they have? Would they understand and expect you to use their data in this way? Does your service use any nudge techniques? Are there prior concerns over similar services or particular security flaws? Is your service novel in any way? What is the current state of technology in this area? Are there any current issues of public concern that you should factor in, particularly over online risks to children? Are there any relevant industry standards, codes of practice or public guidance in this area? What responsibilities do you have under the applicable equality legislation for England, Scotland, Wales and Northern Ireland. Is there any relevant guidance or research on the development needs, wellbeing or capacity of children in the relevant age range? Are you signed up to any approved code of conduct or certification scheme (once any have been approved)?
We only ever ask for the bare-minimum of data in order to allow Schools (the Data Controller) or Parents to administer our service on behalf of their children / pupils.
The likely age range of the end users of the application is between 4 and 18 years old, with all administrative functionality used by those over the age of 16.
The adults using the application will only have access to their own data and those of the children for whom they are responsible and only for the purposes of supporting them in using the application, applying specific challenges or for analytics on a child’s learning.
The children using the application will have minimal control over the settings within the application, only able to alter volume and display settings and will not be able to interact, with one another, communicate or transmit anything to other users.
Schools and Parents can choose to use aliases for their children should they wish. We only offer the functionality to include first names and surnames to aid them in their tracking of children’s progress and usage.
Describe the purposes of the processing: what do you want to achieve with your service? What is the intended effect on individuals? What are the benefits of the processing – for you, and more broadly? What are the specific intended benefits for children?
We want to make the process of logging in and accessing a suite of engaging games an easy and fun process for children. We believe it should straightforward to access games and tasks that they find fun and aim to support those elements with some collectable features that they can work towards. We only capture their names and classes to support Schools and Parents in managing children’s accounts and anonymise their names where they are shown in leader boards or anything similar. In engaging with these features we hope that children will become more engaged in the process of learning phonics, practicing spelling and short-form reading.
For adults using the application the service aims to make it easy to support children in their learning around phonics, spelling and short-form reading. The benefits for them of us processing their names and emails is an easier administrative process and them being able to support the children for whom they have teaching responsibility.
We don’t process children or adult data for any other purpose than those specified in our DPA and Privacy Policies and any processing of their data is in line with above goals and uses.
Step 3: Consultation Process
Consider how to consult with relevant stakeholders: describe when and how you will seek individuals’ views – and specifically how you will seek the views of children and parents – or justify why it’s not possible to do so. Who else do you need to involve within your organisation? Do you need to ask your processors to assist? Do you plan to consult experts in children’s rights and developmental needs? If not, why not? Do you plan to consult any other experts?
As parents and former educators ourselves we have already undertaken a thorough review of what we believe to be acceptable in terms of the processing of Personal Data of Children.
During the process of developing specifications and developing the application we have made sure we work to the strictest standards of data security and protection. A School or Parent could subscribe to the application without ever giving us the names of any children at all and the child could still see the benefits outlined above.
In discussions with Schools and Parents we have found the level of data we process to be fully acceptable and have made adjustments to ensure that we process even less of that data should a School (Data Controller) or Parent require it.
Step 4: Assess necessity and proportionality
Describe compliance and proportionality measures, in particular: what is your lawful basis for processing? Does the processing actually achieve your purpose? Is there another way to achieve the same outcome? How will you prevent function creep? How will you ensure data quality and data minimisation? If you use AI, how will you avoid bias and explain its use? What information will you give individuals? How will you help to support their rights? What measures do you take to ensure processors comply? How do you safeguard any international transfers?
Any Personal Data entered onto our system is done by a School (Data Controller) or Parent on the lawful basis of consent for their staff, pupils or children. We only offer the functionality to input Personal Data to support those adults in getting the most from the application when supporting their children. We do not intend to add any additional functionality that would go beyond the current processing of Personal Data, but should this change we would undertake thorough review and update relevant policies, notifying the Customer before and during this process.
Should we develop any functionality that uses AI it will be developed in such a way that it is fair and accurate, with any resulting reporting or functionality put to strict tests and checks prior to being used. Whenever considering any new functionality we assess whether there is a requirement for any additional data to be provided by the Data Controller or parent and always work on the basis of data minimisation being the goal.
We will ensure Customers are kept informed of the uses for any AI and will ensure its usage doesn’t breach our Terms of Service, Privacy Policy or data protection legislation. We ensure any third party processors we use adhere to the same strict data protection processes as us and do not transfer data internationally other than when an end user accesses the system from an international location.
Describe how you comply with the age-appropriate design code: what specific measures have you taken to meet each of the standards in the code?
We have ensured that the code was considered during the specification and development process for the system and application and have outlined our assessment of this as part of our response to the Children’s Code, which can be found at https://www.phoniczoom.com/childrens-code
Step 5: Identify and assess risks
Describe source of risk and nature of potential impact on individuals. Include as a minimum an assessment of particular risks to children as listed in the DPIA standard in the age appropriate design code. You may need to consider separately for different age groups. | Likelihood of harm | Severity of harm | Overall risk |
Individual child names are maliciously accessed | Remote | Significant | Low |
Individual adult names are maliciously accessed | Remote | Minimal | Low |
Individual child names are associated with a named school | Remote | Significant | Low |
Individual adult names are associated with a named school (as they often already are on school websites) | Remote | Minimal | Low |
Class group data is exposed to other children in that same group (game scores, names) | Probable | Minimal | Low |
Step 6: Identify measures to reduce risk
Identify additional measures you could take to reduce or eliminate risks identified as medium or high risk in step 5 |
Risk | Options to reduce or eliminate risk | Effect on risk | Residual risk | Measure approved |
None Identified as being High Risk |
|
Step 7: sign off and record outcomes
Item | Name/position/date |
Measures approved by: | Rob Parry CEO 01/09/2024 |
Residual risks approved by: | Hannah Hayes Director 02/09/2024 |
DPO advice provided: | Complete |
DPO advice accepted or overruled by: | N/A |
Consultation responses reviewed by: | Hannah Hayes |
This DPIA will kept under review by: | Rob Parry |