Data subject requests
How visitors and staff ask to see, correct or delete their data, and how your Owners and Admins answer them in the Console.
Agoo is in early access. This page describes the feature as it ships to early-access organisations; screens are illustrative.
Under the Data Protection Act, 2012 (Act 843), people can ask what personal data you hold about them, ask you to correct it or delete it, and object to how you use it. These are data subject requests. Your organisation, as controller, answers them. Agoo gives you a page where people ask, an inbox with a due date for each request, and the record that you answered. It's on every plan, Free included.
How someone makes a request
A visitor, contractor or member of staff can ask in two ways:
- Online, from Your data in the footer of every one of your visitor pages (
https://{your address}/privacy). They choose See my data, Correct my data, Delete my data or Stop a use of my data, say how they know you, and give their name and email (their phone is optional). They confirm the email with a six-digit code we send it, and the request arrives in your inbox. They're emailed a reference and the date you'll answer by. - Through your organisation, by email, letter, phone or at the front desk, using the contact details in your privacy notice. Record these in the inbox with Record a request, so every request has a due date and a record.
Put the page's link in your privacy notice: Console → Settings → Data & privacy → Data requests shows it with a Copy link button. If someone asks Agoo about data your organisation holds (Agoo has its own request page, at agoohq.com/legal/privacy/request), we pass the request to you and help you answer.
When it's due
Each request gets its due date when it arrives:
| Request | Answer by |
|---|---|
| See my data (access) | 40 days after it came (Act 843, section 35) |
| Correct or delete it | 30 days after it came (Act 843, section 33) |
| Stop a use of it | 30 days after it came (Act 843, sections 20, 39) |
The inbox puts open requests first, soonest due, and marks the overdue ones.
Reminders
So nothing runs late:
- The bell in the Console counts the open requests that are overdue or due within seven days, and Data & privacy in the menu shows how many are open.
- Seven days before a request is due, whoever it's assigned to is emailed. When nobody has it, the Owners and Admins are.
- Once it's overdue, the Owners and Admins and whoever it's assigned to are emailed, once.
Each person chooses these emails in Account → Notifications, under Data requests: A data request arrived, A data request is due soon and A data request is overdue. Turning them off stops the email only; the bell still counts.
Answer a request
Open Console → Settings → Data & privacy → Data requests
Owners and Admins are emailed when a request arrives online. Owners, Admins and Auditors can read the inbox; Owners and Admins act on it. Assign a request to whoever will answer it.
Check who they are
A code to their email proves the address, not the person. Before you share or change anything, check who they are with details you already hold: call back the number on their visits or staff record, reply from the contact details you already had, or see them in person. Ask for no more than you need. Record how you checked in Identity: a request can't be completed until you have.
Find their data
The request links to their visits in Visitors → History (by their email or phone) and to the directory for a member of staff. People with the same name may be different people: match the email or phone.
Act on it
- Access: in History, filter to their visits and choose Export, with their form answers and any signed copies, and send it to them.
- Correction: change the details that are wrong where they're kept, then tell them what you changed.
- Erasure: delete what you're no longer entitled to keep. Once you've checked who they are, the request's page shows Erase their records: the visitor records with the request's email or phone, exactly (names alone never match), with how many visits each has. Choose the ones that are theirs, choose Erase the chosen records and confirm. Owners and Admins erase. A visitor who's on site now, or whose records are under a legal hold, can't be erased until they leave or the hold is lifted. Each erasure is noted in the request's trail.
- Members of staff who match are listed too, but aren't erased from here: you keep their records while they work for you, and their attendance, leave and payroll for as long as employment and tax law require. Once they've left, deactivate them in People, and your retention schedule deletes the rest.
- Objection: stop the use they object to, unless you have a stronger reason to carry on, which you tell them.
Use Email it to them to reply from the request: it goes from your organisation, with the reference, and is kept in the request's trail. Add a note keeps a note for your team.
Close the request
Choose Completed with what you did, or Refused with why. They're emailed the outcome. Every step, note and reply is in the request's trail and in the audit trail.
What erasure does and doesn't remove
- Removed: their name, phone number, email, photos, ID details and form answers, and, from the documents they accepted or signed, the name they typed, their signature, and the IP address and browser they used.
- Kept as a record: the audit trail notes that an erasure took place and who carried it out, and each document they agreed to keeps the record that a version was agreed to, and when. Its copy then shows "The visitor (erased on request)" in place of their name and signature.
- Not removed while a legal hold applies (Enterprise). Records under a hold stay until it's lifted.
If you must keep some data by law, such as a signed contractor agreement or a watchlist entry after a serious incident, say what you're keeping and why in the outcome.
How long requests are kept
A request and its trail are kept for two years after it's closed, as your record that you answered, and then deleted. They're in your full organisation export.
For developers
If you handle requests in your own systems, on Pro and Enterprise you can erase a visitor through the API with DELETE /visitors/{visitor_id}, which needs the visitors:delete scope, and listen for the visitor.erased webhook event to update other systems. See the developer platform and webhooks.