Two rights, one calm process
Access and correction feel scary the first time because they arrive as a demand with a deadline. They stop being scary when you have a workflow: intake the request, locate the data, respond within the clock, refuse only for a permitted reason - in writing. That is the whole session. Build the workflow once and every future request becomes routine instead of a fire drill.
The access request 9 min live
Under s.21, an individual can ask what personal data you hold about them and how you have handled it. Your job is to locate the data, gather the usage story, and respond on time - or refuse for a reason the law allows. This flow is the shape of every access request.
LiveWhat you must provide3 min▶
An access request under s.21 has two halves, and people forget the second one. You must give the individual:
- Their personal data that is in your possession or under your control - the actual data you hold about them.
- The usage story: information about the ways the data has been or may have been used or disclosed in the year before the request. Not "everything you ever did" - the past-year window.
- A reasonable form. Provide it in a way the individual can understand. You do not have to hand over raw database rows - a readable extract is fine as long as it is complete and accurate.
The past-year usage half is the one teams miss. If Marina disclosed a customer's data to a delivery partner and an SMS aggregator, the access response should say so - not just list the fields.
LiveThe 30-day rule3 min▶
The clock is the part everyone fears and the part that is simplest once stated plainly.
- Respond as soon as reasonably possible. The default expectation is prompt, not last-minute.
- The 30-day backstop. If you cannot respond within 30 days, you must notify the individual in writing within 30 days of the date by which you will respond. The clock does not just lapse - you owe a written heads-up.
- A reasonable fee may be charged. You may charge to recover the cost of responding, but you must give a written fee estimate first, and you cannot charge for merely submitting the request.
| Situation | What you owe |
|---|---|
| Can respond in time | The data + usage story, as soon as reasonably possible |
| Cannot respond within 30 days | Written notice, within 30 days, of the date you will respond by |
| Responding costs real effort | A written fee estimate before you do the work |
Self-studyA reasonable fee, done well3 min read▶
A fee is allowed to keep access sustainable, not to deter people. In practice, a well-run fee policy is boring on purpose:
Estimate the cost of locating, retrieving, and preparing the data before starting.
Send the individual a written fee estimate and wait for them to agree before doing the billable work.
Keep the fee to genuine cost recovery - the PDPC expects it to be reasonable, not a revenue line.
Most straightforward requests are handled without a fee at all. Reserve fees for genuinely large or effort-heavy retrievals, and document how you calculated them.
Correction and refusals 9 min live
Correction (s.22) is the quieter twin of access: fix the error, then make sure the fix travels to the people you already shared the wrong data with. Refusals for both rights are narrow and specific - and on any rejection there is a small duty to preserve the data.
LiveCorrect it, then pass it on3 min▶
When an individual points out an error or omission in their data, s.22 asks you to:
- Correct the error as soon as practicable, unless you are satisfied on reasonable grounds that a correction should not be made.
- Send the corrected data to every other organisation you disclosed it to in the year before the correction - unless that organisation does not need it for a legal or business purpose. The fix has to travel.
- If you disagree, you can annotate the data with the correction the individual requested rather than overwrite it, so the disputed point is recorded either way.
The past-year disclosure list is why Marina's data-flow map from earlier sessions pays off here: if you know who you shared data with, passing on a correction is a two-line email, not an investigation.
LivePermitted and required refusals3 min▶
You cannot refuse just because a request is inconvenient. Refusals are limited to specific, prescribed situations. Access may be refused - and in some cases must be refused - where providing it would:
- Reveal another individual's personal data (unless that person consents or it can be reasonably severed).
- Reveal evaluative or opinion data held for an evaluative purpose - for example, an interview assessment or a promotion decision.
- Threaten someone's safety or health - the individual's or another person's.
- Be prohibited by law, or reveal confidential commercial information in prescribed circumstances.
Marina handles a request. A customer emails: "Send me everything you have, and who you shared it with." Marina locates the profile, purchase history, and the past-year list of disclosures (a delivery partner, an SMS aggregator). But the file also contains a staff note naming another customer in a dispute. Marina severs that line - it would reveal a third party - provides everything else, and responds well inside 30 days. One request, handled calmly, because the workflow already existed.
LiveOn rejection, preserve for 30 days2 min▶
If you reject an access request, there is a small but important duty: preserve the relevant data for at least 30 calendar days after rejecting, so the individual has time to ask the PDPC to review your decision. Do not delete the data the moment you say no - that would take away their route to recourse.
Draft Marina's access-request workflow ★ 10 min
The point of this session is a process you can hand to whoever opens the inbox on Monday. Draft it now, in four steps, so the next request runs itself.
Intake. Where do requests land, who owns them, and how do you verify the requester is who they say they are before releasing any data? Write the single intake channel.
Locate. List every system that could hold customer data, and note the past-year disclosure list you would attach. This is where your data-flow map earns its keep.
Respond within 30 days. Set the response template: the data, the usage story, any severed third-party lines, and the plan for a written notice if you will run past 30 days.
Refuse safely. Write the short list of permitted grounds and the rule: refuse in writing, name the ground, preserve the data 30 days. Reflect - which ground is most likely to come up at Marina, and is your team ready to apply it?
Before session b7 ◐ 40 min total
- Write your organisation's access-request intake: the channel, the owner, and how you verify a requester's identity before releasing anything.
- Pull one real customer record and draft the "usage story" you would attach - how their data was used or disclosed in the past year. Can you actually reconstruct it?
- Draft a one-paragraph refusal template that names a permitted ground and states the 30-day preservation step.
- Read: PDPC Advisory Guidelines on Key Concepts, Chapter 15 (Access and Correction), plus the Guide to Handling Access Requests.
Official sources covered
Taught from the PDPC's own access and correction guidance. This page covers the working core of both obligations - the finer edge cases live in the guides linked below.
Three questions before you go 🎯 ◐ 90 seconds
1 · An access request under s.21 requires you to provide the individual...
Access has two halves: the data itself, and the usage story for the past year. Teams often deliver the data and forget the year of use-and-disclosure information.
2 · You cannot respond to an access request within 30 days. You must...
You respond as soon as reasonably possible; if you cannot meet 30 days, you owe a written notice within 30 days stating the date you will respond by. The clock does not just expire.
3 · You reject an access request. What must you do with the relevant data?
On rejection you must preserve the data for at least 30 days, because the individual's route to recourse is asking the PDPC to review your decision - and they need the data to still exist.