When someone you survey asks to see, correct or delete their personal data, that request lands on a page in Retently instead of only in an email. Go to Settings → Privacy requests.

Each request arrives with a timestamp, a countdown to its response deadline, and the actions you need to answer it. The page is also your record: it keeps what was asked, what you did and when, which is what you show a regulator if you are ever asked.

Every survey email you send carries an Unsubscribe link in its footer. The page that link opens is where a recipient manages their data. Alongside the unsubscribe options there is a link reading Request your data access, edit or removal, which opens a section titled Manage your personal data offering three choices:

Picking one creates a request on your Privacy requests page. Because the person arrived through a personalised link sent to their own inbox, Retently already knows the request genuinely came from them.

Choosing deletion also unsubscribes them from surveys straight away. Access and correction requests do not change their subscription.

Worth knowing. The route runs through the unsubscribe page, so it depends on the unsubscribe link being present. A template with the unsubscribe link switched off gives its recipients no way to reach the data request options from that email. The two settings look unrelated in the editor, but one carries the other.

You can also see requests from two other sources: Manual, if someone on your team adds one after being contacted directly, and API, if your systems create them. Those carry no proof of who made them, which matters for the automatic handling described further down.

If you would rather not offer data requests at all, it is controlled per survey template, under the template's unsubscribe settings.

Everything still open, sorted by deadline, soonest first. The number next to the Requests tab is how many are waiting on you, and it turns red when something is overdue.

Source names the channel the person was surveyed through: Email survey, In-app survey, Feedback button or Link survey, or else Manual or API. A request that could not be verified is labelled unverified on a second line.

You can filter by type and status, tick Overdue only, or search by contact email. The search box matches removed contacts by domain too.

Some people ask for "access, edit or removal" without choosing one, typically from an in-app survey, which does not offer the choice. Retently records that honestly as Unspecified rather than guessing which one they meant. Reach out and ask, then use the matching action once you know.

Unspecified is the only type that accepts either Export data or Remove contact.

The deadline is 30 days from the moment the request arrives. Under GDPR Article 12(3) you must respond without undue delay and at the latest within one month.

The column counts down in plain language (in 12 days, in 3 hours). Hover it to see the exact date. Once it passes, the word Overdue appears above the countdown and the cell turns red.

If a request is genuinely complex you can extend the deadline by two months, using Extend deadline in the row's actions menu. Retently asks you to record why, and the reason is kept with the request as part of the record. An extended row shows Extended under its countdown.

Important. An extension is only valid if you tell the person within the first month. Retently records the reason, but notifying the person is yours to do.

Every open row carries its main action as a button. The rest sit behind the actions menu at the end of the row.

Export data (Access and Unspecified requests). Retently gathers the personal data it holds about that person and emails you a download link. The request stays open afterwards and shows Exported to you, because the file reaching you is not the same as the data reaching them. Once you have sent it on, close the request with Mark as completed.

Review correction (Edit requests). Shows you the exact before-and-after the person submitted, field by field, before you accept it. Covered in Correction requests below.

Remove contact (Deletion and Unspecified requests). Covered in its own section below, because it is the one action you cannot undo.

Mark as completed records that you fulfilled the request yourself. Use it after an export you sent on, or after handling something outside Retently. History shows it as Completed by you, which states that you acted rather than claiming Retently did.

Reject request closes a request without acting on the data, and asks you to choose an outcome: No matching contact, Duplicate request, Outside the request scope, Contact could not be verified, or Withdrawn by the contact. The outcome is kept with the record.

Notes adds a free-text note for your team. The person who made the request never sees it. A row with a note shows a note icon you can hover to read it.

You can select several rows with the checkboxes and act on them together. Extending, rejecting and marking as completed work across a mixed selection. Export data and Remove contact need every selected row to be the same type and still open, because each button has to mean one thing.

If an export, removal or correction fails to complete, the request comes back to this tab marked Needs attention and your DPO users get an email. The row's button changes to Retry. It stays on this tab rather than moving to History, because it is unfinished work, not a conclusion.

Choosing Remove contact does not act immediately. You are asked to type REMOVE to confirm, the request moves to Removal scheduled, and a countdown appears with a Cancel removal button. You have 24 hours to change your mind.

When the countdown ends, Retently:

The request then moves to History with the outcome Contact removed, and the address is cleared from the record itself. What History shows in its place is a masked version, with the local part hidden and the domain intact: c***@yourcustomer.com. You can still see which company a removal came from and search History by domain, but the register does not hold a readable list of the people you removed. A one-way fingerprint of the address is kept alongside it, which is how Retently recognises a repeat request from the same person.

The mask is written at the moment the removal completes, so removals finished before this was introduced show Removed contact instead. The original address cannot be recovered to fill those in.

What "removed" means. The contact is gone from your account and unreachable everywhere in Retently. The underlying records are held in a non-accessible state and are destroyed when your Retently account is closed. If you have an obligation that requires certified destruction on a specific date, talk to us before relying on this.

Someone who picks Correct my personal data does not write you a message describing what is wrong. They get a short form, and what they send you is a specific before-and-after change.

The form shows the values you currently hold for seven fields, so they can see what needs fixing:

First name, Last name, Job title, Company, Phone, City, Country.

Their email address is shown above the form for context, but it is not editable. Changing which mailbox a contact belongs to is not a correction, and the address is what proves the request came from them in the first place.

That is everything they see. The form is not a window into their record. It does not show your tags, your team's internal notes, custom attributes or properties you store on the contact, their response history, their scores or comments, topics, sentiment, or anything else. Someone opening this form learns only what those seven fields contain.

Only the fields they actually changed. If someone opens the form, reads it and saves without editing anything, nothing is created and nothing lands in your queue.

Clearing a field is a legitimate correction, not an error. "You have the wrong job title for me and I do not want one recorded" is a valid thing to ask, so a blanked field arrives as a real change and shows as empty in the diff.

Review correction shows you the before-and-after for each field, so you are accepting a specific edit rather than a vague complaint. That diff stays on the record afterwards as evidence of what changed.

Only those seven fields, and only the ones they edited. Everything else on the contact is left exactly as it was: your tags, segments, custom attributes and properties, their responses, and everything your team has recorded about them. A correction cannot reach any of it.

You can still edit the contact yourself afterwards, the same as any other contact. The request moves to History with the outcome Contact updated.

Worth knowing. If you sync contacts from another system, that system stays the source of truth. A later sync can overwrite what the contact corrected here.

An export contains the personal data Retently holds about that one person:

It deliberately does not contain anything your team wrote about them: internal notes, tags, topics, sentiment labels, the status you set on a response, or your replies. That is your own commentary, not their personal data.

The file is JSON, so it can be read as-is or loaded into another system. Exports you run appear on the Import/Export history page alongside your other exports.

Requests you have finished, newest first. It shows when each was received and resolved, and the outcome:

This is the part of the page that serves as your record over time, so it is never cleared.

Contacts you removed appear masked here (c***@yourcustomer.com), as described above. Everyone else appears in full. The search box matches either, so a search for a domain finds removed contacts from that company too.

History has no count next to its tab. The number on Requests tells you how much is waiting on you. A running total of everything ever resolved is not something you act on, so it is left off deliberately. The row count for whatever you have filtered to is at the bottom of the table.

Settings → Privacy requests → Settings.

Three switches, all off by default:

They are separate because the risk is not: sending someone their own data can be repeated, removing a contact cannot, and a correction writes to a record you use to run your business. Authorize any of them, or none. Covered in full in the next section.

While any of them is on, a banner at the top of the Requests tab says so, and the rows Retently will handle are marked Auto with the date it will act. The email you get when a request arrives tells you the same thing. You only need to step in if you want to handle that one yourself.

The address a contact should reach you at about their data. It is set as the Reply-To on anything Retently sends them on your behalf, and is printed in the message, so someone who wants to talk to a person knows where to write.

Leave it empty and replies go wherever replies to your survey emails go, which may not be a mailbox your team watches. Worth filling in if the two are different.

There is deliberately nothing else to configure:

By default, Retently tells you about a request and you answer it. If you would rather not handle them by hand, you can instruct us to answer them for you.

Turn on the switch for what you want us to handle and confirm the authorization for it. Each switch is authorized separately, and applies only to requests that arrive after you turn it on:

Five limits are worth understanding before you enable any of them:

You remain the data controller throughout. Retently acts only on your instruction, which is what turning this on records. You can turn it off at any time, and it stops applying to new requests immediately. Requests already scheduled can still be cancelled from the Requests tab.

Enabling this is a documented instruction under GDPR Article 28(3)(a). It supplements, and does not replace, our Data Processing Agreement.

Worth knowing. If we materially change the terms of that authorization, the switches fall back to manual handling and the tab asks you to review and confirm the new terms. Retently does not keep acting on an instruction you have not actually given.

Anyone in your account with edit permissions can work the queue: export, correct, remove, reject, extend a deadline, add notes and mark requests completed. Analysts cannot open the page at all, and see a Restricted message instead.

Automatic handling is different. Only account admins and the account owner can turn those switches on or off, or change the reply-to address. Everyone else sees their current state but cannot change them. Delegating is an instruction that lets us remove your contacts without anyone looking first, which is a bigger decision than editing a record, so it sits with the people who own the account.

Every change to those switches is recorded: which scopes were authorized, which were revoked, who did it, their IP, and which version of the terms they accepted.