Children's Privacy, Safeguarding & Responsible Data
Privacy, safeguarding, data protection and the dignity of the child are fundamental principles of 'We Can Do It,' Says Larry. This section establishes how we approach them — strategically and by design.
Larry should only collect information about a child when there is a clear reason for doing so, and that information should always be treated with care, respect and appropriate protection.
This is a strategic and governance section. It does NOT replace the website Privacy Policy, Safeguarding Policy, Terms & Conditions or other formal legal documents.
Quick Navigation — 28 Sections
Our Commitment
As "We Can Do It," Says Larry develops its SEND/SEN support tools, personalised profiles and resources for families and schools, protecting children must remain central to every decision.
The platform may eventually allow parents/carers, children and authorised education professionals to record information that helps them understand and support an individual child.
This could include information about:
- Communication preferences
- Sensory needs
- Learning preferences
- Emotional regulation
- Strengths and interests
- Things a child finds difficult
- Helpful support strategies
- Accessibility requirements
- SEND-related support information
- Goals and achievements
- Information a child wishes trusted adults to understand about them
Some information may constitute personal data, special-category data or otherwise highly sensitive information.
For this reason, privacy and safeguarding must be designed into the platform from the beginning.
Privacy by Design
Apply Privacy by Design and Default principles throughout the development of all Larry profile, personalisation and information-sharing systems.
This means:
- Privacy settings should default to the most protective appropriate setting.
- Child profiles must be private by default.
- Information must not automatically become publicly visible.
- Personal information must only be collected where there is a defined purpose.
- The minimum information necessary should be requested.
- Access should be limited according to role and permission.
- Security and privacy requirements must be considered before new features are released.
Privacy must be part of product design rather than an additional compliance layer added afterwards.
Parent/Carer Registration & Authorisation
Develop an appropriate parent/carer registration and authorisation process before enabling storage of identifiable child information.
The system should distinguish between:
Parent/Carer Account
Child Experience
Teacher/Education Professional Access
Do not assume that registering an account automatically provides permission to access every part of a child's information.
Granular Consent & Acknowledgements
Do not use one blanket checkbox to cover every type of processing or sharing.
Where consent is the appropriate legal basis, develop separate, understandable choices for different activities.
Examples may include:
Consent and acknowledgement mechanisms must be specific to the actual processing activity and must not be presented misleadingly.
Where another lawful basis is relied upon instead of consent, this should be identified appropriately within the platform's data-protection documentation.
Child-Friendly Privacy Information
Create a dedicated "Your Information & Larry" child-friendly privacy area.
Explain privacy in language appropriate to children. Cover:
- What information Larry may collect
- Why Larry might need it
- Who can see it
- What parents/carers can control
- What teachers may be able to see
- How information is protected
- How a child can ask questions
- How they can tell a trusted adult if something worries them
Use:
Avoid legal terminology within the child-facing explanation wherever possible.
Children's Voice & Dignity
A child's profile should not simply become a record of difficulties, diagnoses or things adults believe the child cannot do.
Design profiles around the whole child. Include areas such as:
Where developmentally appropriate, children should be encouraged to contribute to how they are represented.
The platform must promote dignity, agency and strengths-based support.
Private by Default
All individual child profiles must be PRIVATE BY DEFAULT.
Do not make child profiles:
- Public
- Searchable
- Discoverable by other users
- Automatically shared with schools
- Automatically shared between professionals
- Accessible through public links
Sharing must require an intentional action through an appropriate parent/carer or authorised-user process.
Permission-Based Sharing
Develop a clear permissions architecture.
Parents/carers should be able to understand:
Where technically appropriate, allow permissions to be limited to specific profile sections rather than requiring the entire profile to be shared.
Example
Withdrawing Access
Parents/carers must have a simple mechanism for withdrawing sharing permissions where applicable.
Include a "Manage Sharing" area within the parent/carer account. Show:
- People/organisations currently authorised
- Information being shared
- Date permission was granted
- Available permission controls
- Option to revoke access
Withdrawal should be straightforward and clearly explained, subject to any legal or safeguarding requirements that may require particular records to be retained.
Data Minimisation
If Larry doesn't need the information, Larry shouldn't ask for it.
Every proposed profile field must have a defined purpose. Before introducing a new data field ask:
- Why do we need this information?
- How does it benefit the child?
- Can the feature operate without it?
- Is there a less intrusive way of achieving the same result?
- How long does it need to be retained?
- Who genuinely needs access?
Avoid collecting personal information simply because it might become useful later.
Special Category & SEND Information
Recognise that some information families may choose to record could constitute special-category personal data under UK data-protection law, particularly information relating to health, disability or related needs.
Examples could include:
- Diagnoses
- Health-related information
- Neurodevelopmental information
- Disability information
- Therapy/support information
- Relevant medication or medical-support information
The platform must therefore establish the appropriate lawful basis and, where applicable, special-category processing condition before such information is collected or processed.
Do not enable collection of sensitive information simply because a technical profile field can be created.
Safeguarding by Design
Create a formal "Larry Digital Safeguarding Framework."
This should address situations where a child may enter information indicating:
- They feel unsafe
- Bullying
- Abuse
- Neglect
- Exploitation
- Serious emotional distress
- Harm from another person
- Other safeguarding concerns
Important
Before enabling open-text child communication features, determine:
- Whether the feature is necessary
- Whether content is monitored
- Who receives safeguarding alerts
- How concerns are assessed
- Escalation procedures
- Response responsibilities
- Record keeping
- Training requirements
- Out-of-hours arrangements
- How expectations are communicated to children and parents
No open-ended child disclosure functionality should be deployed until its safeguarding implications have been assessed.
Age-Appropriate Design
Review the platform against the principles of the UK Age Appropriate Design Code (Children's Code) and other applicable requirements.
Design decisions should consider:
The objective is not simply legal compliance. The objective is to create a platform families can trust.
Data Protection Impact Assessment
Complete a formal Data Protection Impact Assessment — Child Profiles & Personalisation before identifiable sensitive information relating to real children is introduced at scale.
The DPIA should consider:
Maintain the DPIA as a living document and review it when significant functionality changes.
Retention & Deletion
Create a documented data-retention schedule. Do not retain children's information indefinitely without justification.
Define:
- How long active profile information is retained
- What happens when an account becomes inactive
- What happens when a child leaves the platform
- How parents request deletion
- Which information can be deleted immediately
- Whether any information must legally be retained
- Backup deletion arrangements
- Processor/subprocessor deletion arrangements
Provide parents/carers with accessible controls for managing and deleting information where appropriate.
Security & Access Control
Any system storing identifiable child information must use appropriate technical and organisational security measures.
The development specification should consider:
Security requirements should be reviewed before sensitive child-profile functionality goes live.
Base44 / Technology Provider Due Diligence
Before storing sensitive identifiable information relating to real children, obtain and document appropriate information from the platform/technology provider regarding:
What security measures protect stored and transmitted information?
What role does the provider perform and what contractual data-processing terms apply?
Where is information stored and processed?
Could information leave the UK, and what safeguards apply?
Which third parties may process platform information?
How are backups created, secured, retained and deleted?
What happens technically when information is deleted?
What notification and response procedures exist?
Which provider personnel can potentially access information and under what controls?
Can Larry export user information where necessary?
Ensure appropriate processor terms and Data Processing Agreements are in place where required.
Record this assessment as part of the Larry data-protection governance framework.
Independent Data-Protection Review
Before allowing real children's sensitive information to be stored within the platform, commission an independent review by an appropriately qualified UK data-protection professional.
The review should consider:
Where appropriate, specialist safeguarding advice should also be obtained separately.
Data Breach & Incident Response
Create a documented Data Protection & Security Incident Response Procedure. Define:
- How incidents are identified
- Who must be informed internally
- How systems are secured
- How impact is assessed
- How affected children and families are protected
- How incidents are documented
- When regulatory notification may be required
- When individuals may need to be informed
- How lessons are incorporated into future development
Children's information should receive particularly careful consideration when evaluating potential impact.
Research & Future Partnerships
Larry may eventually work with:
Participation in research must never automatically follow from having a Larry account.
Any research use of identifiable or potentially identifiable information must undergo separate assessment covering purpose, lawful basis, ethics, transparency, data minimisation and appropriate consent or other legal requirements.
Where possible, research should use appropriately anonymised information.
AI & Automated Personalisation
If Larry later introduces AI, recommendations, automated personalisation or intelligent support tools involving children's information, these features must undergo additional assessment before deployment.
Consider:
- What information the system uses
- Whether information is used to train models
- Whether information leaves Larry's controlled environment
- Whether automated decisions are being made
- How recommendations are generated
- Whether profiling occurs
- Human oversight
- Bias and discrimination
- Explainability
- Children's rights
- Ability to opt out where appropriate
Critical
Governance & Accountability
Establish clear internal responsibility for:
Maintain a documented governance framework so responsibility does not become unclear as Larry grows.
Build Gates
Introduce formal development gates.
CURRENT DEVELOPMENT
General Larry website content, resources, activities and non-sensitive functionality may continue development.
PROFILE DEVELOPMENT
Profile architecture may be designed and tested using fictional/test information.
PRIVACY & SAFEGUARDING REVIEW
Complete DPIA, Safeguarding assessment, Privacy documentation, Children's privacy information, Permission architecture, Retention schedule, Technology-provider assessment, Security review.
INDEPENDENT REVIEW
Obtain appropriate professional data-protection review before introducing sensitive identifiable information relating to real children.
CONTROLLED RELEASE
Release profile functionality through a controlled implementation and monitor for privacy, security, usability and safeguarding issues.
Strategic Positioning
Privacy should not be presented simply as a compliance obligation. It should become part of the Larry proposition.
Develop the strategic message:
DESIGNED AROUND THE CHILD — INCLUDING THEIR PRIVACY
"We Can Do It," Says Larry believes children deserve more than engaging resources.
They deserve digital environments that respect their privacy, their safety, their individuality and their voice.
As Larry grows, we are committed to building privacy, safeguarding and responsible use of information into the platform from the beginning.
Our aim is to create technology that supports children without unnecessarily collecting information about them.
Because supporting a child also means protecting them.
Trust with Parents & Carers
Create a visible trust message for parents/carers:
Your Child. Their Information. Your Control.
Explain clearly that Larry is being developed around principles of:
Do not make absolute security claims such as "100% secure" or "completely safe".
Trust with Schools & Professionals
Within About & Strategy, explain that the privacy framework is intended to make Larry suitable for responsible engagement with:
The long-term objective should be for organisations considering Larry to immediately recognise that children's privacy, safeguarding and responsible data use have been considered at platform level rather than added retrospectively.
The Larry Privacy Promise
Eight principles that guide how we handle children's information.
CHILD FIRST
The child's best interests guide our decisions.
PRIVATE BY DEFAULT
A child's information should not automatically be shared.
COLLECT LESS
We only seek information where there is a clear reason.
EXPLAIN CLEARLY
Children and adults should understand what happens to their information.
GIVE CONTROL
Appropriate controls should allow families to manage sharing.
PROTECT INFORMATION
Security must be built into the technology.
SAFEGUARD CHILDREN
Digital features must be assessed for safeguarding implications.
KEEP REVIEWING
Privacy and safeguarding must evolve as Larry develops.
Building Trust From the Beginning
Larry's ambition is to become a trusted support ecosystem for children, families, teachers and professionals.
That trust cannot be built through characters, activities and technology alone. It must also come from how we treat children and their information.
That is why privacy, safeguarding, dignity and responsible technology are being designed into "We Can Do It," Says Larry as the platform develops.
We want every parent, school and professional using Larry to understand one fundamental principle:
The child comes first.
Not only in what Larry teaches.
But in how Larry is built.
Supporting a child also means protecting them — their privacy, their dignity and their voice.
— Larry™
Questions about children's privacy?
We welcome questions from parents, schools and professionals about how we approach children's privacy and safeguarding.
