Playbook, university
Data requests on a university site, and why silence is the failure
A university holds records for applicants who never enrolled, students who left decades ago, and staff in between, and requests about all of them arrive through whichever channel is easiest to find. That is often a chat widget. The one outcome that must not happen is the request being answered as an FAQ and going no further.
Why this is not the general answer
The handling pattern for data deletion requests holds across every trade. What follows is the part that does not.
- The records span applicant, student and alumni systems that are separate internally, and a request rarely says which one it means.
- Retention here is unusually long and is often set by academic regulation rather than by preference, so a straight deletion is frequently not possible and the honest answer says why.
- Requests from former students about assessment records overlap with academic appeals, which is a different process with its own deadline.
- There is a statutory response window, and it starts when the request is made rather than when somebody notices it.
How it arrives
- how do i delete my application data
- can i get a copy of my student record
- how long do you keep my data after i graduate
- i want you to remove my details from your mailing
- how do i correct my name on my record
- who is your data protection officer
What has to be indexed for this to work
| The privacy notice for each audience | Applicants, students and alumni usually have separate notices. Index all of them, because the assistant cannot pick the right retention answer from a general notice. |
|---|---|
| How to make a request, and to whom | The named route and the address it goes to. This is the single most important line on the page, and it is the one most often written as a link with no address behind it. |
| Retention schedule in plain terms | What is kept, for how long, and what is kept because a regulation requires it. Somebody asking to be deleted deserves to know which parts cannot be. |
| Marketing preferences, kept separate | Most requests that arrive as deletion requests are really about stopping email, and separating the two lets the assistant solve the easy one immediately. |
The reply
You can ask us to delete data we hold about you, and the route and the address are on our privacy notice. Some records have to be kept for a set period under academic regulations, and the retention schedule says which. If what you actually want is to stop receiving email from us, that is a separate and faster process. Tell me which and I will point you at the right one, or pass your request on.
It separates the two requests hiding inside one, states plainly that some records cannot be deleted rather than promising and then disappointing, and ends with an offer to route rather than a link and a full stop.
Where it stops
The trigger. Any actual request, as opposed to a question about the process. The moment somebody says they want their data deleted, that is a request with a clock on it.
I will pass this on as a request rather than leave you to send it again. If you give me your name and an email, it goes to the team who handle these, and they will confirm receipt.
It stops answering before it guesses, says who will pick it up, and asks for the one thing that makes a reply possible. Nothing about it reads as a dead end.
Never say this here
Out of bounds
- That data has been deleted, or will be, since the assistant cannot know and cannot do it.
- A specific response deadline, unless the institution publishes one.
- That records can be deleted when a retention rule requires them kept.
- Anything that discourages somebody from making the request.
Questions
- Is it risky to let an assistant near this at all?
- The risk runs the other way. These requests already arrive on whatever channel is easiest to find, and today many of them are answered by nobody. An assistant that reliably routes them is an improvement on an inbox that loses them.
- Should it collect the request itself?
- It should collect a name, an email and the request, and hand that to the team. It must not present itself as the mechanism, because a person who believes the request is filed will not follow up when it is not.
- How do we handle requests about a third party?
- Straight to a person. A parent asking about an adult student's record is a question about consent and identity, and neither is answerable in a chat window.
Keep reading
- Everything for a universityApplicants and enrolled students ask different things. What a university assistant can answer about entry, fees and visas, and what it must never predict.
- Handling data deletion requests in generalA deletion request is a request with a clock on it, not a question. The characteristic failure is silence, so it always has to reach a person.
- The three things a university assistant must never try to handleWellbeing, visas and anything about an individual application. Three triggers that must be rules rather than judgements on a university site.
- Two university waiting lists that behave nothing like each otherA hall waiting list and a full module are two queues with two owners. What can be said about each, and what the guarantee does not cover.
- A first visit to a campus that is not in one placeWhich site, which building, the shuttle between them and what a new arrival needs on the day. All published, usually on four unlinked pages.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.