Now is the time to ask for the training budget

Making the most of a moment when attention is focused on privacy

5 minute read

Recent events have been a timely reminder that data protection incidents do not always originate from technical vulnerabilities or complex cyber attacks. Sometimes they begin with an individual making a decision, responding to a request, following a process, or simply trying to do their job.

While every incident has its own circumstances, a familiar pattern has emerged. Personal data is not always exposed because someone was careless. It can be the result of persuasion, time pressure, competing priorities, or a request that appears entirely legitimate.

For those of us working in privacy, that poses an important question. If people continue to be one of the main routes through which personal data is compromised, are we investing enough in helping them spot risks, challenge what does not feel right, and know what to do when something seems unusual?

The annual training problem

Most organisations I have worked with require data protection and cyber security training once a year. It sits in the learning portal alongside anti-bribery, health and safety, modern slavery, equality and diversity, and whatever else the year has added. A deadline is set, reminders go out, and completion rates are reported upwards.

Whilst completion rates are useful, they show that the training was done. They tell us very little about whether anyone took something away from it. I suspect most of us have seen, and perhaps been, the person clicking through a module in the gap between meetings so the reminder emails stop. That is no reflection on staff. When everything is mandatory and everything arrives at once, it all starts to blend together.

The attacks in the headlines are not waiting for the annual refresher. A fraudulent request from a convincing domain, or a message from someone who sounds like a colleague or supplier, relies on a moment of trust under time pressure. That is why awareness needs to be reinforced regularly, not just once a year.

Why now is the time to ask

If there has ever been a time for privacy leaders and their teams to ask for more budget, I think it is now. Boards and executive teams have seen these stories. They have seen a share price move on the back of a single push notification, and if your organisation is not already talking about this, I would be surprised. If they are not aware, tell them.  The conversation about what a breach costs is no longer theoretical, and that gives privacy teams an opening that may not stay open for long.

My suggestion, however, is not to lead with the fact that the privacy team is stretched. Most organisations already know their teams are busy, and if that alone has not unlocked additional investment, it is unlikely to do so now.

Instead, make the case for what more could be achieved. Additional resources creates the capacity to spend more time on the preventative work we all know matters, including more meaningful engagement with the business, regular awareness activities, in-person training sessions, open Q&A discussions, and realistic simulations that help people recognise and respond to suspicious requests. In other words, ask for the budget to reduce risk, not simply to manage workload. The extra pair of hands will make that possible.

We all learn from experience

Some people learn best by reading, others by doing. Whilst that is true, most of us learn most effectively through experience. Very few people forget the first time they nearly fell for a scam, or the first time they sat in a room trying to work out whether an incident needed to be reported to the ICO within 72 hours.

That is why awareness should be about more than an annual training module. Regular engagement with the business, in-person discussions, Q&A sessions and realistic exercises all help to bring the risks to life.

Simulation gives people the opportunity to gain that experience without the real-world consequences. In practice, it could include:

• phishing and social engineering exercises, including requests that appear to come from regulators, law enforcement or senior colleagues

• scenario walk-throughs where teams decide whether what they are looking at is a personal data breach

• tabletop exercises that take a breach from discovery through containment, risk assessment, notification and communication with customers

• short, regular refreshers that reflect current events and emerging threats, rather than relying on a single annual training session

If people have already experienced what it feels like to spot a scam, recognise that something has gone wrong, or manage the first hours of a breach, they are far more likely to respond well when faced with the real thing.

Working with cyber security

This is also an opportunity to work more closely with cyber security colleagues. Many security teams already run phishing simulations. Privacy teams bring an understanding of what personal data is at stake, the regulatory obligations and the impact on individuals. Combining the two creates exercises that feel more relevant to the business and better reflects how incidents unfold in practice.

There is another benefit that is easy to overlook. Privacy teams are often small and stretched, and some are a team of one. A workforce that knows what to look for and feels confident raising concerns tends to escalate issues earlier and with better information. That can make a significant difference in the first hours of an incident, when the privacy team is trying to understand what has happened, assess the risks and decide what action needs to be taken.

A realistic view

Simulation will not suit every organisation or every environment in the same way. Budgets differ, cultures differ, and some sectors will need to think carefully about how realistic an exercise can be. A simulated phishing exercise can damage trust if it feels like a trap, so it should be approached as a learning opportunity, with support, feedback and no blame. 

Even so, I still think now is the time to push for that little extra. The consequences of a breach, from customer complaints and regulatory scrutiny to media attention and the pressure placed on the people managing the response, are something no organisation wants to experience. Investing in awareness, engagement and practical exercises is often a far smaller commitment than dealing with the aftermath. Not every organisation will have the capacity to do more with its existing team. Sometimes an extra pair of hands can make all the difference, creating the time and space needed to focus on the preventative work that is so often pushed down the priority list. Whether that support comes from within the business or from outside it, investment in meaningful engagement, training and testing is rarely wasted.

The organisations that navigate incidents best are not necessarily those with the biggest privacy teams. They are more likely to be the ones that have invested in helping their people recognise risks early, raise concerns confidently and respond in a way that feels familiar when it matters most.

Creating the space for proactive privacy work

Awareness, engagement, training and testing all take time. If you're looking to create more capacity within your privacy function, an independent perspective can help identify priorities, opportunities and areas for investment. Additional support can also provide the extra pair of hands needed to deliver awareness activities, strengthen governance and progress the preventative work that too often slips down the priority list. The challenge is rarely knowing what needs to be done. More often, it is finding the time and capacity to do it well.

Next, I'll be looking at ‘Who's Watching the Workplace Watchers?’

---

Stay in the loop

If you found this useful, subscribe to the Roseline Data Privacy monthly newsletter and never miss out on our practical data privacy insights, updates, and tips delivered straight to your inbox. No noise, just what matters.

What makes a good DPO?

The real test of a DPO comes when expertise meets organisational reality.

7 minute read

On Tuesday morning, ASOS app users received a push notification that did not come from ASOS. It was addressed to the company’s DPO and IT team, claimed that the sender had “fully compromised the Snowflake instance”, and ended: “Engage with us, or we will leak it.”

At the time this article was drafted, ASOS had confirmed unauthorised activity involving third-party platforms used to communicate with customers and stated that names and contact details may have been exposed. ASOS said it did not believe payment card details or account passwords had been affected. Snowflake also stated that it had found no compromise of its own platform.

The facts are still emerging and I will not speculate about what happened inside ASOS. My thoughts are with the teams working through it, and with the customers wondering what it means for them. Anyone who has managed a serious incident knows how intense those first days are. It is unusual to see a DPO named in the attack itself, and it is a reminder of how much rests on that role when something goes wrong. The DPO is expected to advise quickly, calmly and independently, often on incomplete facts and under real pressure. They can only do that well if they have been properly supported and empowered long before the incident arrives, with clear access to decision-makers, organisational standing, sufficient resources, operational independence, and the backing needed to give difficult advice and have it heard.

I have put together a short carousel on what makes a good DPO, and this week felt like the right time to share it. None of what follows is about blame. It is about ensuring the person in that seat has the access, support and authority they need to be effective when they are needed most.

The question usually gets answered with a list of qualifications. Expert knowledge of data protection law, familiarity with the sector, a working understanding of the organisation's processing. All of that matters, and none of it is optional. Whilst those things are necessary, they are rarely what determines whether a DPO succeeds. In my experience the difference is made by the conditions the organisation puts around the role.

The DPO belongs in the third line of defence

Many organisations treat the DPO as an operational function. The DPO writes the DPIAs, maintains the record of processing, works through the privacy inbox and clears the ticket queue. That is delivery work, and it sits properly in the first and second lines, with the business that owns the risk and the teams that build and run the controls.

Article 39 gives the DPO a different task: to inform, to advise, to monitor compliance and to cooperate with the supervisory authority. That is third line work. It only means something if it is performed independently of the activity being reviewed. If the DPO designs and builds the control, there is nobody left to assess whether the control actually works. Article 38(6) is clear that any other tasks must not give rise to a conflict of interest, and doing the work whilst also assuring it is precisely such a conflict. The person advising on whether to notify the ICO and affected customers should not also be the person whose controls are under review.

Advice given without fear 

Independence is written into the Regulation. Article 38 requires that the DPO receives no instructions regarding the exercise of their tasks, is not dismissed or penalised for performing them, and reports to the highest management level. Article 38(2) requires that the organisation provides the resources necessary to carry out those tasks and to maintain expert knowledge.

In practice, independence is something an organisation grants rather than something a DPO can declare. It looks like a direct reporting line that is not filtered through the function being reviewed. It looks like budget, headcount, tooling, training and protected time. A DPO who is uncertain about the consequences of giving unwelcome advice will, over time, give less of it. That is a quiet risk, and it does not show up on a compliance dashboard. The real test often comes in the first few hours, when a DPO may need to recommend notifying the ICO on incomplete information, or telling customers what has happened and what steps they can take to protect themselves, before the business feels fully ready to do so.

The panned out view

A DPO can only advise on what they can see. That means line of sight across every area of the business processing personal data, including HR, marketing, product, sales, procurement, security, finance and data teams, as well as the third parties acting on the organisation's behalf and the platforms they provide.

The ASOS incident, as reported so far, appears to involve third-party platforms used to communicate with customers. Customer engagement tools, push notification services, CRM systems and cloud data platforms can hold significant volumes of customer data, and responsibility for them may sit across marketing, digital, data and technology functions. If a DPO does not have visibility of which vendors process customer data, what information they hold, and who can access those systems, it becomes far harder to assess risk in advance or help scope and respond to a breach when one occurs.

Where responsibility for AI governance sits with the DPO, the same principle applies. Seeing the completed assessment is not the same as understanding how use cases are identified and approved, how the model inventory is maintained, what triggers a DPIA or fundamental rights impact assessment, where training data comes from, or how human oversight is demonstrated. A DPO reviewing the output of a governance process without visibility of the process itself can offer only limited assurance.

Presence across the organisation matters

An advisory role runs on influence, and influence is built long before it is needed. It helps to be a familiar face around product, change, procurement, security and HR forums rather than simply another name on the mailing list. Building relationships early creates trust and, over time, a group of listening ears when difficult conversations need to happen. The first interaction with a team should not be during an incident or compliance escalation. When an incident does land, those relationships are what get the DPO accurate facts from marketing, security and the vendor in hours rather than days. Advice is also more likely to be acted on when it is expressed in terms the business already understands, such as risk, cost, timelines and customer trust, and when it helps teams find a safe path forward rather than simply pointing out the limits.

It also helps to make the work itself visible. A risk-based annual workplan, agreed at the highest level, helps the organisation understand the DPO's priorities and the reasons behind them. Regular attendance at team meetings and governance forums provides valuable insight into evolving risks, levels of understanding, and where additional support or training may be needed. It also creates opportunities to gather meaningful data and metrics that demonstrate trends, resource pressures, and the case for further investment in privacy and governance. A short quarterly report to the board helps keep privacy on the agenda throughout the year, not just when an incident occurs. Maintaining a written record of advice given, including advice that was not followed, supports accountability and protects all parties. Just as importantly, the DPO should highlight the good privacy practices being adopted across the organisation, not just the risks, incidents and poor practices that have been identified and addressed.

Empower the role, then assess its impact

The most effective DPOs are involved early, when ideas are taking shape and changes can still be made quickly and at relatively low cost. A regular seat at change, product, AI and vendor governance forums is often more valuable than any job title. So too is access to the information needed to do the role properly: systems, records of processing activities, contracts, incident logs and the risk register, together with a clearly defined role in the incident response plan and sufficient budget for training, tooling and specialist advice.

Reporting then becomes important. Rather than focusing on isolated snapshots, organisations should look at trends over time and the direction of travel. Useful metrics for a DPO to report on include:

• DPIAs raised and completed, including any occasions where DPO advice was not followed.

• Time taken to respond to data subject requests and close incidents, including more complex or higher-risk cases.

• Oversight of third-party providers and international data transfers.

• AI use cases assessed, compared with those in active use across the organisation.

• Training completion rates, recurring themes and repeat issues.

• Privacy and governance maturity, tracked over time.

Maturity that is not measured is difficult to demonstrate, whether to a board, a client or a supervisory authority.

In short 

A good DPO is knowledgeable, independent, properly resourced and able to see the whole picture. Three of those four are given by the organisation, and incidents like this week’s are when they are tested, in public and at speed. Get the conditions right and the DPO stops being seen as a barrier to the business and becomes an early warning system for it.

The carousel below brings these points together across ten slides. If you find it useful, please feel free to share it with colleagues.

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

Is your DPO function set up for success?

A capable DPO can only be effective when the right governance, reporting lines, access and support are in place. If you would like an independent review of your current arrangements, I would be happy to help identify gaps, clarify priorities and suggest practical next steps.

Next, I'll be looking at ‘Now is the time to ask for the training budget’

---

Stay in the loop

If you found this useful, subscribe to the Roseline Data Privacy monthly newsletter and never miss out on our practical data privacy insights, updates, and tips delivered straight to your inbox. No noise, just what matters.

Lessons from the Rise of AI-Drafted DSARs

None of them are novel. What has changed is the requests themselves. They now arrive drafted with the help of AI: longer, more detailed, and often requesting information that may fall outside the scope of the right of access.

10 min read

Individuals are increasingly using AI to draft their subject access requests, and the results are long, structured and confident. They arrive with numbered sub-requests and sections asking for material that was never going to be disclosable; another person’s data, legally privileged advice, or simply more than any organisation must hand over. This post examines the common patterns and process challenges exposed by AI-drafted Data Subject Access Requests (DSARs), together with practical steps for addressing them.

Most organisations do not fail a subject access request because they are careless about privacy. They fail it because nobody put a timetable behind the deadline, or the search was scoped by whoever happened to be free that week, or the redactions were made defensively at 5pm on the final day.

The rules have recently changed, and the Data (Use and Access) Act 2025 (DUAA) rolled it out in phases. February 2026 gave statutory footing to two things: the ability to pause the response clock whilst awaiting clarification, and the standard that a search need only be reasonable and proportionate, not exhaustive. Both matter far more now a single DSAR runs to several pages. The complaints duty followed in June 2026.

Here are the patterns I see most often. Four come back to the standard operating procedure (SOP) that many organisations either drafted once and rarely revisited, or never quite got around to documenting in the first place. An AI-drafted request creates no new failures. It finds the ones you already had, faster.

LESSON ONE · PLANNING

No timetable behind the deadline

Every organisation knows a DSAR has to be answered within a month. Far fewer can tell you what has to be true by day five, day twelve, or day twenty. Nobody discovers the schedule has slipped until the final week, by which point there is no way to recover it. Length makes this worse. The instinct on receiving eight pages of numbered demands is to put it down and come back to it properly, which is exactly what there is no time for later.

THE MITIGATION

On logging, generate the dated milestones: dissect and scope, clarification decision, search complete, review and redaction complete, sign-off, and dispatch. Give the dissection its own milestone, ahead of the clarification decision, because a long request takes real time to read properly.

Give every milestone a named owner rather than a team. Escalate on a missed milestone rather than a missed deadline, because once the deadline itself has gone, all that is left is an apology.

Bonus tip. Set your own deadline a week ahead of the statutory one. Something will go wrong on some requests, and every mishap then costs you the buffer rather than the deadline.

LESSON TWO · CLARIFICATION

Using clarification to buy time instead of to understand the request

The DUAA put “stopping the clock” onto a statutory footing, and it is a genuinely useful provision. Where you process a large volume of information about someone and you reasonably need them to narrow the request, the month pauses while you ask and resumes when they reply.

What it is not is a way to buy three extra weeks. If the request was clear enough to action as received, a clarification email does not stop anything. Sent in week three, it gains you very little.

What an AI-drafted request looks like

Requests now tend to arrive with extensive detail, not ambiguity. It often spans several pages, cites Article 15 and the DUAA, and requests every record and piece of correspondence relating to the individual, regardless of format or whether they are identified by name. It reads as though written by somebody who knows exactly what they want, and that is the difficulty, because they usually do not. Somewhere in those pages is one specific thing they are worried about. Clarification is how you find it. The rest belongs to the model.

Break the request down before deciding whether to clarify

Start by taking the request apart. I group it four ways (see below), which helps identify whether clarification is needed and provides the framework for the search plan discussed in lesson three.

Table 1. A practical framework for breaking down a DSAR and planning proportionate searches.

You can then send a clarification request that is actually useful: these are the systems and records we hold, and the periods available; please confirm which information you would like us to search and over what timeframe. Simply asking someone to "Please clarify your request" is not a question anyone can meaningfully answer or be helpful.

Determining whether information should be disclosed

An AI-drafted request will often ask for things it cannot have, which is no reason to treat the whole of it with suspicion. Take each category on its own terms. The categories below are common examples, but each should be assessed carefully and documented on a case-by-case basis.

Table 2. Common categories of information that may fall outside the scope of disclosure or require further assessment.

THE MITIGATION

Use the SOP’s “dissect and scope” milestone as the test: can you dissect the request and identify where to search? If yes, do not ask for clarification. If not, ask that day and be specific.

Group the request before you answer it (as per table above). The grouping is your clarification question and the first draft of your search schedule. Ask about the period if you ask about nothing else.

Record the reason the request could not be actioned as received. If the pause is later challenged, that note is your evidence.

LESSON THREE · SEARCH

An undocumented search

The reasonable and proportionate standard is now in statute. You are not required to search every system you have ever owned. You are required to make an effort proportionate to the circumstances: the volume of information, how hard it is to locate, and the resources available.

The trap is assuming a reasonable search speaks for itself. If you cannot show what was searched and why, it is hard to prove the search was reasonable. A long request will also try to pull you off the standard, because a list of sixty numbered items invites you to answer sixty numbered items. The grouping you did at scoping and clarification is what lets you describe the search you actually ran.

THE MITIGATION

A documented scoping framework promotes consistency across DSARs, helps colleagues understand where to search and where exclusions may apply, and makes it easier to provide a clear, defensible explanation of how the request was handled. Maintain a standing list of common systems, stakeholders and search approaches, then record any request-specific variations alongside it to create an audit trail of your decision-making.

Where a request arrives as a numbered list, note which grouping answered which item. Answering in the requester’s own order shows nothing was quietly dropped.

LESSON FOUR · REVIEW

Blanket third-party redaction

Information about other people is the hardest part of most disclosures, and the defensive instinct is to black out every name that isn’t the requester’s. That is not what the law says. You do not have to disclose information that would identify another individual unless they consented, or it is reasonable to disclose without consent. 

Over-redaction is a disclosure failure in its own right. It is also, in my experience, the thing most likely to convince a requester that you are hiding something. That challenge becomes harder as volumes increase. A request designed to capture every mention of an individual can generate substantial amounts of third-party information, making late-stage review impractical. 

THE MITIGATION

Keep a redaction schedule in the SOP (see table above): the recurring categories, each with its reason, then apply the judgement per instance. If you cannot articulate in a sentence why a category is withheld, that is a strong signal it should not be. The rationale you do record can then be carried through into the response letter.

For each third party, work through the three questions: can the information be provided without identifying them, by removing the name but keeping the substance? Have they consented? If not, is disclosure nonetheless reasonable?

Keep legal professional privilege as its own line in the schedule. It is decided on different grounds, and where a requester is in dispute with you it is the category most likely to be challenged.

LESSON  FIVE · RESPONSE

Treating the response as the end

Since 19 June 2026, organisations must give individuals a way to make data protection complaints directly, acknowledge those complaints within 30 days, and respond without undue delay. Privacy notices need to say so. A dissatisfied requester now has an internal route, and if you have not built one their route is the ICO. That matters most where the request was large and the disclosure partial.

THE MITIGATION

Make the response letter the start of a process rather than the end of one. State plainly what was searched, what is enclosed, and what has been withheld and why. Where you answered a grouped version of a longer request, show the grouping. Name the internal complaint route and how to use it. Then mention the right to complain to the ICO, in that order. 

If your DSAR procedure has not been updated for the DUAA, it is out of date. It is also worth asking whether it was written for the length of requests you are now receiving.

None of these five fixes require new technology or headcount. Four of them require a single document to be doing its job, an SOP with a timetable attached, a search schedule that grows with every request, and a redaction schedule that carries its own reasoning. The fifth is the internal complaint route. None of them require you to hold a view on AI. A machine-drafted request changes the volume and the tone, and nothing about the standard you are held to.

Is your DSAR procedure current?

If your process predates February 2026, it may not yet reflect the current legal position, including the complaints duty introduced in June 2026. I would be glad to review your DSAR procedure against the current position and leave you with a documented one. If you are holding one of these longer AI-drafted requests and are not certain how much of it you must answer, that is a week-one conversation rather than a week-three one.

---

Stay in the loop

If you found this useful, subscribe to the Roseline Data Privacy monthly newsletter and never miss out on our practical data privacy insights, updates, and tips delivered straight to your inbox. No noise, just what matters.

Sources & further reading

1. Information Commissioner's Office, A guide to subject access

2. Data (Use and Access) Act 2025, commencement of data protection provisions, February 2026

3. Data Protection Act 2018, Schedule 2, Part 3, paragraph 16, Protection of the rights of others: general

4. Data Protection Act 2018, Schedule 2 Part 4, paragraph 19, Legal professional privilege.

5. UK GDPR Article 12(5), manifestly unfounded or excessive requests

Back to school transition: protecting children's data after the Reddit fine

As children head back to the classroom, organisations might consider a quick revision session of their own, and review the first place regulators look when marking your homework.

10 minute read

September means packed lunches, forgotten PE kits and the annual scramble for new school shoes. For many children, particularly those starting secondary school, it also means a first smartphone, new group chats and a growing collection of online accounts.

While parents are focused on uniforms and timetables, organisations should be paying attention to something else; a fresh intake of young users entering the digital world. When children start using new apps and services, questions about age assurance, privacy by design and children's rights move from theory to practice very quickly.

This year, those conversations are happening against a very different regulatory backdrop. The Information Commissioner's Office has moved from encouragement to enforcement, the Government has committed to restricting social media for under 16s from spring 2027, and the technologies being deployed to check children's ages are themselves artificial intelligence systems that need governing. I thought it would be useful to set out what has actually changed, and what organisations can sensibly do between now and then.

The ICO's Lessons for Organisations

In February 2026 the ICO fined Reddit £14.47 million for failures relating to children's personal information. Days earlier it had fined MediaLab, the owner of Imgur, £247,590 on similar grounds. On 18 August the regulator published a progress update on its Children's Code strategy, confirming that it had also secured commitments from Snapchat to strengthen age assurance, improved transparency from Instagram and Snapchat on location sharing, completed risk reviews of fourteen age assurance providers, and opened a review of the mobile gaming sector.

The Reddit findings are worth reading closely, because they are interesting. Reddit's terms said that under 13s were not permitted. Until July 2025 there was no mechanism to check. The ICO found a significant number of children under 13 using the platform, with no lawful basis for processing their information. Separately, Reddit had not carried out a Data Protection Impact Assessment (DPIA) addressing risks to children before January 2025, despite knowingly serving 13 to 18 year olds. As the ICO noted when announcing the enforcement action, relying on users to self declare their age is not enough where children may be at risk.

Neither Reddit nor Imgur is a children's service. That is precisely why the decisions matter. The Children's Code applies to information society services likely to be accessed by children, which is a far wider category than services designed for them. Whilst many organisations still assume the Code is somebody else's problem, the key question is not "Was this built for children?" but "Are children using it?".

Before the Bell Rings: A Children's Privacy Refresher

The Children's Code is a statutory code issued under section 123 of the Data Protection Act 2018. It is not a separate regime with separate penalties. It is the lens through which the ICO reads the obligations you already hold under the UK GDPR, which is why the Reddit penalty is a UK GDPR penalty. The clearest way to approach compliance is therefore to work through the seven principles in Article 5 and ask what each one means when the data subject is nine years old. 

Lawfulness, fairness and transparency. Article 8 sets the age at which a child can consent to the processing of their personal data in relation to information society services at 13 in the UK. Where a child is under 13, consent must be authorised by a person with parental responsibility. If your chosen lawful basis depends on consent, but you cannot establish whether the user is old enough to provide it, you may be unable to rely on that lawful basis. Transparency must also be age appropriate, meaning privacy information should be presented in a way that children can understand.

Purpose limitation. Data collected to provide a service to a child should only be used for that purpose. Using the same information for advertising, increasing engagement, or training AI models are separate activities that require their own clear justification.

Data minimisation. This is where age assurance creates a genuine balancing act. Organisations should collect the minimum information needed to determine a person's age, not retain copies of passports, driving licences or other documents where a less intrusive solution would achieve the same result.

Accuracy. An incorrect age is not a minor error. It determines which protections a child receives, which defaults apply, and whether profiling is switched on. 

Storage limitation. Information collected to verify a user's age should not be kept any longer than necessary. Once the age check is complete, identity documents, facial images and similar evidence should normally be deleted. Retention of age assurance data is one of the simplest areas to get right, yet it is often overlooked.

Integrity and confidentiality. A breach involving children's location data, school information or images carries a severity that adult equivalents do not. Security decisions should reflect that weighting. 

Accountability. This is the principle Reddit fell foul of most visibly. The ICO found that risks existed, and that the organisation had never assessed them. 

Before Class Begins: The DPIA

Standard 2 of the Children's Code requires a data protection impact assessment for services likely to be accessed by children. In practice, the DPIA is where compliance comes together on paper, and it is often the first document a regulator will ask for.

A children's DPIA needs to go further than a standard template. It should record how you determined that children are likely to access the service, what age ranges you are designing for, what the best interests of the child require in your specific context, and why your default settings, geolocation, profiling and nudge techniques are set as they are. Where you have chosen not to apply a standard, the reasoning belongs in the document. 

Age Assurance: Full Marks Aren't Easy

On 25 March 2026 Ofcom and the ICO issued a joint statement confirming what many had suspected. Services meeting the Online Safety Act's highly effective age assurance duties must simultaneously satisfy the UK GDPR and the Children's Code. Age assurance processing is permitted where it is necessary and proportionate to the risk.

The tension is real. To establish that someone is not a child, you generally process more personal data, not less. Facial age estimation, digital identity and one time photo matching are the methods the ICO currently identifies as viable. Each involves a meaningful expansion of processing in the service of protection. The ICO's review of fourteen age assurance providers found compliance gaps in the supply itself, which is a useful reminder that buying a solution does not transfer the accountability. Under Articles 24 and 28 the controller remains answerable for the processor's conduct.

The Next Lesson: What the Under-16 Restriction Means for AI Governance

In summer 2026, the Government announced plans to prevent under 16s from holding social media accounts from spring 2027. The restrictions are expected to be introduced through secondary legislation, using powers created by amendments to the Online Safety Act 2023 under the Children's Wellbeing and Schools Act 2026.

The Government's consultation on the proposals closed in May, attracting around 116,000 responses. Ofcom is expected to provide further clarity on the practical implementation of children's online safety measures during autumn 2026, including issues closely linked to age assurance and age-related protections. The proposed restrictions are expected to apply to social media platforms that facilitate user interaction and rely on algorithmic content feeds. Services focused primarily on private messaging, education or online commerce are expected to fall outside their scope. The proposals go beyond restricting social media accounts for under 16s. They are also expected to introduce limits on livestreaming by children, stronger protections against contact from strangers, and a minimum age of 18 for the use of romantic companion chatbots.

Taken together, these measures point to a future in which organisations will need to be much more confident about the age of their users, while ensuring that the technologies used to make those assessments are fair, proportionate and appropriately governed. That, in turn, brings a new set of AI governance challenges into focus.

The first is that age assurance technologies are themselves AI-driven inference systems. Facial age estimation does not determine a person's age with certainty. Instead, it generates a probability based on the available data. That becomes particularly challenging around age thresholds, where distinguishing between a 15-year-old and a 16-year-old is often far more difficult than distinguishing between a child and an adult. If accuracy varies across characteristics such as skin tone, disability or other protected characteristics, both fairness and equality considerations come into play. Organisations therefore need processes that allow children who are wrongly excluded to challenge the decision and obtain meaningful human review.

The second is recommendation. Standard 12 of the Code expects profiling to be off by default for children. Recommender systems are profiling, and a service that cannot reliably identify which of its users are children cannot reliably switch them off. 

The third, where generative AI features such as companions, tutors and image-generation tools are used by, or accessible to, children, organisations should assess them through a combined children's privacy and AI governance lens. Viewing these as separate compliance exercises can result in duplicated effort and gaps in risk management. A single, integrated framework is often better placed to identify and address the full range of risks.

What does this mean for sports organisations?

The Reddit case may involve a social media platform, but the message for organisations is much broader. Sports clubs, governing bodies and community programmes increasingly engage with children through apps, membership platforms, coaching portals, ticketing systems and online communities.

Many organisations may not consider themselves providers of children's services. However, the regulator's focus is increasingly on whether children are likely to access a service, rather than whether it was specifically designed for them. Sports organisations that collect information about junior athletes, academy players, participants or young supporters may therefore wish to consider whether their approach to children's privacy aligns with the standards expected under the Children's Code.

Getting Your Homework Done Before Spring 2027

The time between now and spring 2027 is best spent focused on a handful of practical steps:

• Establish, and record, whether children are likely to access your service. Use actual evidence rather than assumption.

• Complete or refresh a children's DPIA, including the best interests assessment and your reasoning on each standard.

• Review defaults. High privacy, geolocation off, profiling off, non-essential notifications off, unless you can justify otherwise.

• Map every point at which you infer, estimate or record a user's age, and identify the lawful basis and retention period for each.

• Ask your age assurance vendor for accuracy and bias testing by age band and demographic group, and record what they tell you.

• Bring AI systems that touch children into the same governance record as your children's data processing.

• Rewrite privacy information into language the youngest likely user can follow, and test it with someone that age.

• Watch the Ofcom implementation guidance this autumn and the draft regulations that follow.

The organisations that struggle in 2027 will mostly be those that decided in 2026 that none of this applied to them. Reddit and Imgur reached that conclusion too.

If you would find it useful to talk through whether your service falls within scope, or to review an existing children's DPIA, I would welcome the conversation.

Does your children's privacy homework pass the test?

As regulatory expectations continue to develop, now is a good time to revisit your approach to children's data protection, age assurance and AI governance. I would be happy to review your current framework and provide practical, documented recommendations for improvement.

Next, I'll be looking at ‘Five DSAR Mistakes Organisations Keep Making’

Stay in the loop

If you found this useful, subscribe to the Roseline Data Privacy monthly newsletter and never miss out on our practical data privacy insights, updates, and tips delivered straight to your inbox. No noise, just what matters.

Sources & further reading

1. ICO, Children's code strategy progress update, August 2026

2. ICO, Reddit issued with £14.47m fine for children's privacy failures

3. ICO, FAQs on the 15 standards of the Children's code

4. ICO, Code standards

5. Ofcom and ICO joint statement on age assurance, March 2026

6. GOV.UK, Social media to be banned for under-16s

7. Ofcom, Making life safer online: our priorities for the year ahead