What a data subject request is
A data subject is the person whom personal information is about. In many places, privacy laws give people rights over their data, and a data subject request is a person exercising one of those rights. Typical requests include:
- asking what information an organization holds about them, and for a copy
- asking for inaccurate information to be corrected
- asking for their data to be deleted
- asking the organization to stop or limit certain uses, such as marketing
- asking for data in a portable format to take elsewhere
Which rights exist, and the conditions attached, depend on the law that applies. This article describes a general process and is not legal advice. Whoever handles legal and privacy matters in your organization should decide how the rules apply.
Why IT is involved
Requests are not an IT problem alone, but IT does much of the hard work: finding a person’s data across systems, extracting it, correcting or deleting it, and proving it was done. If an organization cannot say where personal data lives, a simple request can turn into a scramble. The better the groundwork, the easier the response.
The usual steps
1. Recognize and log the request
Requests do not always arrive through the official form. They may come through email, a support ticket, social media or a phone call to the help desk, and they rarely use legal terms. Front-line staff, especially at the IT help desk, should know to recognize “can you tell me what you have on me?” or “please delete my account” as possible formal requests and route them to the right team quickly.
Logging each request with the date received is important because laws commonly set a response deadline, often measured in weeks or about a month, with limited extensions in some regimes. The clock typically starts on receipt, not when someone gets around to it.
2. Verify identity
Handing someone’s data to the wrong person is itself a breach. Before releasing anything, the organization should be reasonably confident that the requester is the person concerned, or is authorized to act for them. Verification should be proportionate: asking for a lot of extra personal detail to prove identity would go against data minimization, so where possible use information already on file or existing authenticated accounts, such as a request made from a logged-in session.
3. Clarify and decide
Sometimes a request is vague. It is reasonable to ask what the person is after, as long as this does not become a delaying tactic. The privacy lead then decides whether the request is valid, which right it falls under, and whether any exemption applies. Exemptions might protect other people’s information, legal privilege, or data the organization must keep by law. Partial responses are common: some data can be provided or deleted and some cannot.
4. Search across systems
This is where a data inventory pays off. Places to look often include:
- customer and HR databases
- email and file storage
- support ticket systems and call recordings
- marketing and analytics platforms
- logs, where they hold identifiers
- backups and archives
- systems run by vendors and other third parties acting on the organization’s behalf
Search by several identifiers, such as email address, account number and name variants, since records are often inconsistent. Poor data hygiene, such as duplicates and typos, makes this harder, which is one reason data cleaning has privacy value.
Third parties holding data for you may need to be told to act too, so contracts should require their help with requests.
5. Act and compile the response
What happens next depends on the request:
- Access: gather the data, remove information about other people where required, and present it in a clear, readable form.
- Correction: update the record everywhere it appears, not just in the main system.
- Deletion: remove data from live systems and, where feasible, schedule removal from backups or make sure it is not restored. Document any data that must be kept and why.
- Restriction or objection: apply a flag so that systems stop the relevant use.
- Portability: export in a common, structured format.
Send the response through a secure channel. Emailing a spreadsheet of personal data to an unverified address undoes the purpose of the exercise. Data encryption or a secure download link is a sensible choice.
6. Record the outcome
Keep a record of the request, the decision, what was done and when, without keeping more personal data than necessary. This supports accountability and helps if the person complains or a regulator asks.
Preparing before requests arrive
- Maintain a data inventory that shows what personal data is held and where.
- Write a short procedure with named roles, deadlines and templates.
- Train help desk and customer-facing staff to spot and forward requests.
- Check that your tools can search and export by person, and that deletion actually deletes.
- Include request support in vendor contracts and in your service level agreements with internal teams if they are involved.
- Practice with a test request, so gaps show up when nothing is at stake.
Mistakes to avoid
- Treating a request as a nuisance or ignoring it. Missing deadlines can lead to complaints.
- Releasing data without verifying identity.
- Deleting from one system and forgetting copies in spreadsheets, exports or tickets.
- Disclosing another person’s data inside the response.
- Charging fees or adding obstacles without checking whether the law allows it.
- Making promises like “your data is gone everywhere” if backups or legal holds mean it isn’t.
Handled calmly and consistently, requests are a normal part of running a system that holds personal information, and a good response is often as much about clear communication as technology.