Right to Erasure GDPR: What UK Schools Must Do When a Prospect Requests Deletion

Under UK GDPR, a prospective student who asks your institution to delete their personal data must receive a substantive response within one calendar month. The right to erasure — codified in Article 17 of UK GDPR — is not conditional on the prospect providing a reason: the obligation to act falls on your institution from the moment the request arrives. Schools and universities that process prospect data through CRMs, AI chatbots, email platforms, and shared drives must be able to locate, assess, and delete (or justify retaining) that data within that deadline.

For the complete framework governing prospect data at your institution, see our GDPR guide for student data.

What the Right to Erasure Means Under UK GDPR

The right to erasure — also called the "right to be forgotten" — entitles an individual to request that a data controller deletes their personal data without undue delay. Under UK GDPR Article 17, six grounds trigger the right. For schools and universities handling prospective student data, the three most commonly encountered are: the prospect withdraws consent on which processing was based; the data is no longer necessary for the purpose for which it was collected; or the prospect objects to processing and there are no overriding legitimate grounds to continue.

The Information Commissioner's Office (ICO) is the UK supervisory authority responsible for enforcing this right. Its Right to Erasure guidance sets a clear ceiling: institutions must respond within one month of receiving the request. For complex or multiple simultaneous requests, this can be extended by a further two months — but the individual must be notified of the extension, and the reason for it, within the first month. Failure to respond in time is itself a breach of UK GDPR, separate from any failure to actually delete the data.

Who is covered? Any individual whose personal data your institution holds. This includes prospects who contacted you via a UCAS open day, a chatbot on your website, an email enquiry form, a QR code scan at an education fair, or a social media lead generation campaign. The right is not limited to enrolled students or formal applicants.

The right applies regardless of how the data was collected. A prospect whose email address was added to a nurture sequence after a Clearing call has the same rights as one who submitted a detailed online application form.

When Does the Right Apply to Prospective Student Data?

The right to erasure applies to prospect data in three principal scenarios. Understanding each is essential for admissions and marketing teams, because the legal analysis differs — and so does the appropriate response.

Consent withdrawal is the clearest trigger. If your institution collected a prospect's contact details and they gave consent for marketing communications — nurture emails, open day invitations, programme updates — and they then withdraw that consent, you must stop processing their data for that purpose and delete the data unless another lawful basis independently justifies retention. Note that unsubscribing from emails is not automatically a withdrawal of consent to hold the data: the prospect may have a separate right to object to their data being held at all.

Data no longer necessary arises from the storage limitation principle (Article 5(1)(e) of UK GDPR). The ICO's storage limitation guidance confirms that institutions should not retain prospect data longer than necessary. In practice, 3 years from the last active contact is the ICO-consistent outer limit for prospect data — after which no justifiable recruitment purpose can be sustained. Data held beyond this window is already in breach; an erasure request simply makes the breach visible.

Right to object under Article 21 applies where processing is based on legitimate interests. A prospect can object to being held in your CRM "for follow-up purposes" if you have not obtained explicit consent. Your institution must then show compelling legitimate grounds that override the prospect's interests — a high threshold for marketing and recruitment data.

When Can You Lawfully Refuse?

The right to erasure is not absolute. Article 17(3) of UK GDPR sets out circumstances in which a controller can refuse a deletion request in whole or in part.

Freedom of expression and information is rarely applicable to prospect data, but can arise in edge cases involving published testimonials a prospect submitted during their application.

Legal obligation is more relevant. If your institution is required to retain certain records to comply with a regulatory requirement — for example, UKVI audit trails for international student recruitment, or financial records required under the Companies Act — erasure of that specific data can be refused. The refusal must be scoped precisely: you cannot retain an entire CRM record because one field relates to a legal obligation.

Legal claims provide a ground for refusal where data is needed for the establishment, exercise, or defence of legal claims. If a prospect has raised a formal complaint about your admissions process, retaining their file until the complaint is resolved is lawful. Once the claim is settled, the ground for refusal lapses.

Partial refusal is both permitted and frequently the correct answer. If a prospect's record contains some data that must be retained (for example, a record that they lodged a formal complaint) and other data that serves no purpose (a marketing preference profile, behavioural scoring in the CRM), you can and should delete the latter while retaining only what is genuinely necessary. Blanket refusal where partial erasure is possible is an error — and the ICO has made clear it will scrutinise over-retention in the education sector (see ICO education sector guidance).

Always document the legal basis for any refusal and communicate it clearly to the individual within one month.

A Five-Step Process for Handling Erasure Requests

Step 1 — Acknowledge the request (Day 1). Confirm receipt immediately, even before your investigation begins. The one-month clock starts from the date you receive the request — not the date you begin processing it. Your acknowledgement should confirm you have received it, identify a reference number, and state the deadline by which you will respond (30 days from the date of receipt).

Step 2 — Verify identity (Days 1–3). Confirm that the person making the request is who they say they are. You may ask for reasonable verification — a reply from the email address you hold on file is usually sufficient. Do not request disproportionate documentation. The ICO is clear that identity checks should not be used to delay compliance.

Step 3 — Map the data (Days 3–10). Identify every system where the prospect's data is held: CRM records, email platform subscriber lists, chatbot conversation logs, shared folders, event attendance sheets, Excel files, marketing automation tags. This step exposes the real complexity: data about a single prospect can live across 8–12 systems in a mid-sized institution.

Step 4 — Apply the legal analysis (Days 10–20). For each data set, ask: is there a ground under Article 17(3) that allows retention? Is there a separate lawful basis (legal obligation, legal claims) that independently justifies keeping this specific data? Document your analysis. If erasure is required, schedule deletion. If partial retention is justified, scope it precisely.

Step 5 — Execute, confirm, and document (Days 20–30). Delete all data for which no retention ground exists, across every system. Confirm to the individual in writing that the erasure has been completed, specifying what was deleted and — where relevant — what was retained and why. Retain a record of the request and your response (without retaining the deleted personal data itself) for accountability purposes under Article 5(2).

If you cannot complete the full process within one month, notify the individual before Day 30 of the extension and the reason for it. The maximum extension is two further months.

Data Retention Periods for Prospective Students

The ICO's storage limitation principle requires that personal data is kept no longer than necessary for the purpose for which it was collected. For UK schools and universities, the ICO-consistent retention periods for prospect data are as follows.

First-contact data (enquiry form, chatbot conversation, fair registration): 12 months from the last active contact if the prospect has not progressed to a formal application. Beyond 12 months, the educational project is most likely abandoned and retention requires specific justification.

Active prospect in the recruitment pipeline (open day attendee, brochure requester, partially completed application): up to 24 months from last engagement, aligned with the two-year UCAS cycle.

Formal application data (rejected or withdrawn): 6 months after the outcome notification. The Data Protection Act 2018 Schedule 2 exemptions for educational records apply to enrolled students — not to prospects whose applications were rejected.

Marketing consent records: retained for as long as needed to demonstrate compliance — typically 3 years from the consent event or its withdrawal, whichever is later. This is not a justification for retaining the prospect's personal data itself; it is a record that consent was given and subsequently withdrawn.

The 3-year outer limit — meaning 3 years from the last active contact — is the ICO-consistent ceiling for any prospect data. Data held beyond this limit carries regulatory risk and makes erasure requests more complex to handle (because the institution is already in breach of the storage limitation principle).

Proactive purging, configured in your CRM, reduces the volume of erasure requests by removing stale prospect data before anyone needs to ask. This is the most operationally efficient approach.

AI Chatbot and CRM Implications

Erasure requests expose the multi-system nature of modern school recruitment data. A prospect who contacted your institution via an AI chatbot may have data distributed across: the chatbot platform (conversation logs), your CRM (a lead record created from the chatbot handoff), your email marketing platform (a subscriber record created when the prospect opted in to updates), and your analytics platform (behavioural data linked to a persistent identifier).

Schools using Skolbot manage a median of 195 qualified leads per month (Source: Skolbot Benchmark 2024–2025, panel of 18 institutions). At that volume, even a 1% erasure request rate generates approximately 2 requests per month — and each request requires a cross-system investigation. Institutions without automated data-mapping tools routinely miss one or more systems during the erasure process.

Four technical requirements are essential for handling erasure requests on chatbot and CRM data:

1. A unified prospect identifier. Every system that holds data about a prospect must use a common identifier (typically an email address or CRM ID) so that a single erasure request can be mapped across all platforms without manual cross-referencing.

2. A data inventory. Your Record of Processing Activities (Article 30) should document every system holding prospect data, the data categories held in each, and the retention period. This is your map for Step 3 of the erasure process.

3. Deletion API access or documented manual procedures. Most CRM and email platforms provide API endpoints for deleting individual records. For chatbot platforms, verify before deployment whether conversation logs can be deleted by individual user or only in bulk.

4. A data processing agreement (DPA) with every provider. Under Article 28 of UK GDPR, your contracts with CRM providers, chatbot vendors, and email platforms must specify that the processor will assist you in responding to data subject rights requests — including erasure. Without this clause, you are both exposed and potentially unable to fulfil your obligations. See our guide on protecting prospect data under GDPR for the full subprocessor framework.

For cookie-related data (advertising pixels, tracking cookies, analytics profiles), erasure obligations interact with consent management. Our cookie consent GDPR guide for schools covers these intersections in detail.

FAQ

Does a prospect need to give a reason for an erasure request?

No. Under UK GDPR, individuals are not required to justify an erasure request. They simply need to make the request clearly. Your obligation to respond within one month applies regardless of whether a reason is given. Where you intend to refuse, the burden of justification is on your institution — not on the individual.

What if the prospect requests erasure but also has an open complaint?

You may retain data necessary for the establishment, exercise, or defence of legal claims under Article 17(3)(e). An open admissions complaint qualifies. However, retention must be limited to the data genuinely needed for the complaint. Once the complaint is resolved, the legal claims ground lapses and the data must be deleted unless another ground applies.

Are prospects who enquired via UCAS Clearing covered by the right to erasure?

Yes. Data collected during UCAS Clearing — phone numbers, email addresses, notes taken during telephone conversations — is personal data held by your institution as a controller. The UCAS platform holds its own data separately; requests relating to UCAS records must be directed to UCAS as a separate controller. Your institution must handle requests relating to the data it holds.

Can we charge a fee for handling erasure requests?

Generally no. Responding to data subject rights requests must be free of charge. The ICO permits a reasonable fee only where requests are "manifestly unfounded or excessive" — a high threshold. Charging in other circumstances is a breach of UK GDPR.

What if we cannot identify the prospect in our systems?

If you cannot locate any data matching the individual's identity, you should respond confirming that you hold no data about them (or no longer hold any, if the data has already been purged under your retention policy). This is itself a valid response to an erasure request. Do not ask the individual to provide more information than is reasonable to establish their identity.

To formalise your institution's end-to-end GDPR compliance — covering governance, consent, security, subprocessors, and AI Act obligations — use our GDPR audit checklist for schools.