Last week at the forum we discussed the statutory requirements for an Article 30 Record of Processing Activities (ROPA). Every organisation with data protection obligations has its equivalent of the Single Central Record (SCR), and in the world of data protection, that’s your Article 30 Record of Processing Activities. The Information Commissioner’s Office (ICO) considers this a crucial document and will often ask to see it during certain types of investigations.

While there are many complex systems available to help you manage this, in all honesty, a well-structured spreadsheet can often suffice. Beware of any vendor claiming their product is a ‘golden ticket’ as there will always be critical, specific fields that only your team can populate accurately.

The Statutory Requirements: What Article 30 Demands

The bare minimum requirements for your ROPA are clearly set out in Article 30 of GDPR. You must include the following mandatory fields:

1. Controller and DPO Details: The name and contact details for the controller, and where applicable, the joint controller, representative, and Data Protection Officer (DPO).
2. Purposes of Processing: A clear statement on why you are collecting the data.
3. Categories of Data: A description of the categories of data subjects (e.g., Pupils, Parents, Staff) and the categories of personal data collected (e.g., Name, DOB, Health data, NI Number).
4. Recipients and Transfers: The categories of recipients who have or will receive the personal data, including those in third countries or international organisations.
5. International Transfers: Details of any transfers outside of the UK (which should also involve considering your data processors’ storage locations), including the identity of the country/organisation and the documentation of suitable safeguards (such as SCCs, adequacy decisions).
6. Erasure Time Limits: Where possible, the planned time limits for erasure for the different data categories (e.g. 6 years, 12 months, or a link to your full retention policy).

Security Measures: Where possible, a general description of the technical and organisational security measures. Here we should be thinking about access controls like passwords, MFA, granular permissions, and locked cabinets.

Elevating Your ROPA: Best Practice Fields

To make your ROPA a truly useful asset, we recommend capturing the following additional, best-practice fields:

• Information Asset Owner: The senior individual responsible for the specific data set.
• Storage Location: Where the data physically resides, such as MIS, CPOMS, or a specific folder within SharePoint or Google Workspace.
• Lawful Basis: The Article 6 Lawful Basis you are relying on.
• Special Category Exemption: The Article 9 special category exemption, if applicable.
• Privacy Notice Details: The name of the privacy notice covering this processing and when it is supplied to the data subject.
• Consent/LIA Location: A link to or a description of where the consent form or Legitimate Interests Assessment (LIA) is stored.
• Access/Sharing: Who has internal access, whether the data is shared, and whether it is published.
• Disposal Responsibility: Who is responsible for disposal and the method (e.g. secure shredding of paper, electronic system disposal).
• Processor Organisation: Details of any processors involved.
• System Details: Comprehensive details of the system storing the data including name, general description, contract status, vendor contact details, format (electronic/hard copy) and how data is transferred out of the system. These should be set up as different columns for ease of reference.

The Underappreciated Benefits of a Complete Register

A completed ROPA offers far more than simply satisfying a legal requirement. It provides underappreciated operational benefits that can significantly strengthen your data protection posture:

• Faster Data Breach Response: It’s a quick reference document to identify the data types involved in a breach without needing to query colleagues or access the system. It helps you quickly identify and reach out to affected colleagues in other schools or business units.
• Improved Privacy Notices: The ROPA clearly outlines the information that must be reflected in your notices.
• Access Reviews: It facilitates regular checks to ensure access controls are adequate and that staff members only have access where there is a legitimate business need.
• Promotes Data Awareness: The process forces colleagues across the organisation to actively think about what personal data they hold.
• Data Location and Retention: You will know exactly where all your personal data is located and who is responsible for ensuring compliance with retention periods.
• DPIA and Processor Tracking: It can highlight the need for further Data Protection Impact Assessments (DPIAs) and provides a mechanism to track and perform due diligence on processors and sub-processors.
• Knowledge Gap Analysis: It exposes areas where colleagues lack understanding such as not controlling disposal, lack of access controls, or processing without a clear lawful basis.
• Sharing and Risk Assessment: It helps you identify when data is being shared without a Data Processing Agreement (DPA) or Data Sharing Agreement (DSA) and whether the sharing method is considered ‘high risk’.

Finally, if you conduct internal audits, the ROPA serves as a valuable reference document. You can conduct sample checks on rows to ensure the data in the ROPA matches the live system, enabling a process of iterative improvement.

Q&A Session

In many instances completing a ROPA is a retrospective exercise. It relies on unravelling the complex web of data flows and contracts whilst at the same time reacting to new processing activities across a range of areas. How do we make this more manageable?

The initial population of a ROPA can be a daunting and laborious task. Given that the requirement to populate came into force in May 2018 many organisations are now completing this retrospectively. It’s easy to get bogged down with the subprocessors and in turn their own subprocessors which can lead to losing sight of the purpose of the document. Analysis of the subprocessor tree is better suited for documenting within your due diligence vendor assessments and any DPIA’s that you conduct. For the purpose of the register focus on the locations (both electronic and hardcopy) where personal data is held and then work backwards from there documenting the information within those systems. If you are using a spreadsheet then don’t overload each row. For example it’s often easier to split data sets into separate entries on your register when:

• They are stored in multiple locations (have a row for the pupil data in your MIS and another for the same data you might have in Google Workspace / Share Point)
• There are physical copies as well as electronic (you’ll have different storage locations and access controls for each).
• The classes of data subject require different lawful bases for the processing (you might want a row for the employee data in the MIS as well as a separate row for Pupil/Parent data).

Remember to document the main system that the data is stored in and the processor of that data. There’s no need to add extra rows to cover sub-processors which may have access to small subsets of the overall data set. Realistically this should be information on the processor’s information asset register.

To make population and maintenance more manageable:

• Simplify the Process: If you are using a spreadsheet, use data validation features to create drop-down menus for fields with a limited number of possible options.
• Delegate Responsibility: This is an organisational responsibility, not solely the burden of the DPO and their team. Unless your Trust retains complete control over all systems, you should not attempt to do it all yourself.
• Appoint Leads: For medium-sized Trusts and above, we strongly recommend appointing a data protection lead in each academy and business unit. These individuals should be responsible for populating the types and locations of data as a bare minimum.

Provide Guidance: Prepare an example sheet illustrating best practice for both your academies and Central Business Units.

Final Thoughts

Creating and maintaining an effective ROPA isn’t about chasing perfection or compiling every conceivable detail. It’s about establishing a clear, accurate, and functional picture of how personal data moves through your organisation. By focusing on statutory essentials, enhancing your register with practical best practice fields, and keeping the process simple and collaborative, you transform the ROPA from a compliance obligation into a powerful operational tool. With defined responsibilities, sensible structure, and ongoing engagement across teams, your register becomes a living document that strengthens governance, sharpens awareness, and supports confident, proactive data protection practice.

Join us next month where we’ll be looking at how your organisation can use automation to improve your data protection and AI governance processes. To register for the AI & Data Protection form on Friday 5 December please click this link!

Last week at the forum we discussed how to construct a privacy notice, considering both statutory required inclusions and other useful information. Whilst we discussed privacy notices generally there was an underlying focus on changes that may be required for organisations adopting AI systems and AI features that have gone live in their current systems.

Setting the Ground Rules: The Importance of Transparency

Privacy notices are how organisations comply with the transparency principle set out in Article 13 & 14 UK GDPR. Being open and upfront about what you do with people’s personal data helps you deal with them in a clear and transparent way. This makes good sense for any organisation and is key to developing trust with individuals

There is no prescriptive legislative description of how a privacy notice should be set out although it does need to include the following types of information:

• The name and contact details of your organisation
• The contact details of your data protection officer
• The purposes of the processing
• The lawful basis for the processing
• Explain which lawful basis you are relying on in order to collect and use people’s personal data and/or special category data.
• The legitimate interests for the processing
• The recipients, or categories of recipients of the personal data
• The details of transfers of the personal data to any third countries or international organisations
• The retention periods for the personal data
• The rights available to individuals in respect of the processing
• The right to withdraw consent and how
• The right to lodge a complaint with a supervisory authority
• Tell people that they can complain to a supervisory authority.
• The details of whether individuals are under a statutory or contractual obligation to provide the personal data
• Tell people if they are required by law, or under contract, to provide personal data to you, and what will happen if they don’t provide that data.
• The details of the existence of automated decision-making, including profiling. This is particularly important when AI is being used for placing pupils in capability related classes, exam levels and similar decisions which have a significant effect on a pupil.

AI & Privacy Notices: New Challenges

For any AI systems that process personal data, they must be included in the recipients and international transfers sections at a minimum. If a system is entirely AI, you should explain what the system is used for, who the vendor is, and the name of the system. It may be easier and more user-friendly to add a separate AI section addressing these systems. If AI features have been added to existing systems, you should expand the section of your notice that refers to that system/processor to explain the feature. This might include transcribing tools in Teams/Google Meet or grading in edTech systems for example.

For any systems used for automated decision-making and/or profiling, there are extra legal provisions to comply with. You should confirm your use of AI-enabled decisions, when you use them, and why you choose to do this, including which systems and vendors are involved. It is important to include a “human-in-the-loop” for decisions that have legal or similar effects, as Article 22 gives individuals the right not to be subject to a solely automated decision.

Article 21 of the UK GDPR also gives individuals the right to object to any profiling that you carry out on the basis of legitimate interests or a public task. In these cases, an individual can object on grounds relating to their particular situation. This applies to all systems and not just those which use AI.

If you do not use AI for automated decision making and/or profiling it can be useful to state this within your privacy notice but you would need to be certain that edTech systems aren’t being used in this way in any of your schools. Given that vendors are rushing to introduce AI in their systems it might not be possible to confidently state this in your privacy notice.

Q&A Session

A great debate emerged during our Q&A session about centralised control versus academy-level autonomy when it comes to privacy notices. Privacy notices are the responsibility of the ‘data controller,’ which in a multi-academy trust (MAT) is the Trust itself, not the individual academies. While there’s nothing stopping a Trust privacy notice from having a section relating to processing at each individual academy, this may be redundant.

The question to consider is what school-specific information would be included that couldn’t already be part of the Trust notice. If this relates to the use of systems, it may be worth adding in a paragraph for a specific school under the relevant section.

It’s also worth splitting your privacy notices into separate documents for different classes of data subjects, as a single notice can become quite large. This could include separate notices for pupils, parents/guardians, staff, governors/trustees, and suppliers/contractors. You might also consider a visitor notice, especially if you have CCTV on site.

Final Thoughts

Privacy notices and the implications of AI are complex topics, and these are just some of the key takeaways from our forum discussion. As we move forward, we’ll continue to explore new challenges. Our next session will be on 14 November at 12:45 pm, where we’ll be diving into the latest on Article 30 Record of Processing Activities including what’s required and recommended process for populating

I look forward to seeing you there!

Click here to add it to your Google Calendar or download the attached .ics file at the bottom of this blog post.

Thanks again to everyone who joined the session. See you at the next one.

Please feel free to reach out if you would like to find out more about our range of data protection, information governance & AI governance services.

Earlier this month, I had the pleasure of hosting attendees at our first AI & Data Protection Forum of the academic year. The forum is a practical and open space for professionals in the education sector to come together and discuss real-world questions about AI, governance, and data protection. While we’ve talked a lot about AI recently, this session focused on another critical topic: efficiently handling subject access requests (SARs).

Acknowledge and set expectations

When you receive a SAR, the first step is to acknowledge it. This is also your chance to set expectations and make things easier for your organisation. Here’s what you should include in your acknowledgment correspondence:

• Clarification: If any part of the request is unclear, this is the time to ask for clarification.

• Privacy Information: You should attach a copy of the relevant privacy notice for the data subject (e.g. parent, pupil, or staff). It’s also helpful to include a link to your Data Protection Policy, as it contains additional useful information for the data subject.

• Legal Rights: The acknowledgment should inform the data subject of their right to file a complaint with the ICO. It’s also beneficial to mention their right to enforce their request through the courts via s.167 of the DPA 2018.

• Response Deadline: You should provide a deadline for your response if possible. Keep in mind that the time limit is extended until you receive clarification or ID from the requester.

Pupil Information: It’s important to note that Regulation 5 of The Education (Pupil Information) (England) Regulations 2005 does not apply to multi-academy trusts. If a request is made under this legislation, you should inform the requester that it will be processed as a SAR instead.

Applying Exemptions: A Crucial Step

Once you have gathered all the data, you can begin applying exemptions. It’s crucial to gather all relevant data first and not preemptively exclude information based on potential exemptions.

You may refuse a request entirely if it’s considered manifestly unfounded or manifestly excessive.

• A request is manifestly unfounded if the individual has no intention of exercising their right of access, such as offering to withdraw the request for a benefit. It can also be considered unfounded if the request has a malicious intent, like harassing the organisation.

A request is manifestly excessive when it’s “clearly or obviously unreasonable”. This judgment should be based on whether the request is proportionate to the burden and cost of handling it. This often applies when a request largely repeats previous ones and a reasonable amount of time hasn’t passed since the last request.

Common Exemption to Consider in the Education Sector:

• Third-party data – Schedule 2, Part 3, paragraph 16(1): You will likely need to redact third-party data as it’s rare for data sources in the education sector to not include data relating to other individuals. Remember there is a “presumption of reasonableness” for disclosing the names of teaching staff in pupil data requests but this doesn’t apply to other individuals like parents or staff.
• Child abuse data – Schedule 3, Part 5, paragraph 21(3) of: Child abuse data is personal data consisting of information as to whether the data subject is or has been the subject of, or may be at risk of, child abuse. For this purpose, “child abuse” includes physical injury (other than accidental injury) to, and physical and emotional neglect, ill-treatment and sexual abuse of, an individual aged under 18. This exemption only applies if the request comes from someone who has parental responsibility.
• Serious Harm – Schedule 3, Part 4, paragraph 19: The serious harm test can apply to any class of data subject whenever complying with the request would be likely to cause serious harm to the physical or mental health of any individual. This exemption overrides the “presumption of reasonableness” for disclosing the names of teaching staff in pupil data
• Legal privilege – Schedule 2, Part 4, paragraph 19: If legal professional privilege applies to the data then it is exempt from disclosure to a data subject.
• Exam data – Schedule 2, Part 4, paragraph 25: For pupil data, you must redact an individual’s answers from exam scripts but keep the examiner’s marks and comments. This exemption extends the response period to five months from the request date or 40 days from the announcement of exam results, whichever is earlier. You need to inform the requester of this extended deadline in your acknowledgment.
• Staff data: You may need to apply exemptions for confidential references, records of potential negotiations, or management data such as redundancy or restructure considerations.

When responding, you must include details of the exemptions that have been applied, citing the relevant sections of the Data Protection Act 2018. When applying the serious harm test or the child abuse data exemption, you do not need to confirm you even hold the data and it is acceptable to refer to the exemption by the schedule alone. For example you could use the phrase “The Trust does not process the data which has been requested” or that “The data that you have requested is subject to an exemption under Schedule 3, Data Protection Act 2018.

The High Court decision in Ashley v HMRC [2025]

Ashley v HMRC [2025] offers important insights into what constitutes “disproportionate effort” in responding to a SAR. The court found that this isn’t limited to the time spent searching for data but can also include other difficulties in complying with the request. This may include time spent applying exemptions or redacting data

However, the ruling also clarified that time alone isn’t proof of disproportionate effort. In this case, HMRC’s argument of spending 150 hours on a request was challenged, as the time was largely spent on applying erroneous exemptions and dealing with poor data systems.

This decision highlights the need to have efficient systems and to ensure that any time spent on a SAR is necessary and justifiable when arguing that the request is disproportionate.

Final Thoughts

Subject access requests can be complex, and these are just some of the key takeaways from our forum discussion. As we move forward, we’ll continue to explore new challenges. Our next session, on Friday 10 October at 12:45pm will delve into the statutory requirements of your organisation’s privacy notices, particularly as the education sector continues to adopt AI features.

Click here to add it to your Google Calendar or download the attached .ics file.

Thanks again to everyone who joined the session—you made it what it was. See you at the next one.

Please feel free to reach out if you would like to find out more about our range of data protection, information governance & AI governance services.

Matthew

Starting with application code built for a specific CMS, the process of transforming it to CMS-agnostic is what, in this article, I will call “abstracting code”. The more abstract the code is, the more it can be re-used to work with…