How the DSR process works

This article explains how a Data Subject Request (DSR) moves through the Privacy Culture Platform, from setting up the form through to completing the request. It is written for the privacy team members who review and manage requests. The platform calls these users Approvers (also referred to as Handlers in some cases).

The DSR Intake Form and its workflow are built from a Template, and Templates are configurable. Your organisation’s form may use different section names, ask additional questions, or leave out some of the sections described here. The overall process is the same.

The process at a glance

Stage	Status	What happens
DSR Intake Template	n/a	A Template is set up, starting from the standard Template or configured for your organisation.
Public Link	n/a	A Public Link is created. This provides the URL, naming and branding used to publish the form, and sets the Approvers.
New DSR Intake Form	Not Started	Someone opens the link, or a platform user selects New. A new DSR Intake Form is created and the timer starts.
Filling in the form	In Progress	Responses are being entered. The form can be returned to using the same link.
Form submitted	Under Review	The data subject or reporter confirms their responses and submits. The form is locked to them and the Approvers are notified by email.
Email verification (optional)	Under Review	The data subject clicks a link sent to their Correspondence email to confirm they hold that account.
Privacy team review	Under Review	Approvers work through the handling sections in Approver Mode.
Request completed	Complete	The Approver submits the form a final time. The timer stops and the request is recorded as complete.

Progress across all requests can be seen at any time on the DSR dashboard. See the related article at the end of this page.

Before you start: Template and Public Link

Two things need to exist before any requests can be captured. These are normally set up once by an administrator.

The DSR Intake Template. The Template defines the form. It consists of the Data Subject section, which is the part the data subject or reporter completes, followed by a number of handling sections completed by the privacy team. You can start from the standard Template or configure one for your own purposes.

The Public Link. A Public Link is not a form in itself. It provides the URL, naming and branding needed to publish the form, for example on a company website or an intranet page. The Approvers are also defined when the Public Link is created. Every DSR Intake Form created through that link inherits them automatically.

How a request starts

There are three ways a new DSR Intake Form can be started. Your organisation may use any or all of them.

Public Link on a website. The data subject opens the link and fills in their own details.

Public Link on an intranet. Internal teams use a link published internally to log a request on a data subject’s behalf, for example one that arrived by email, phone or post.

New, from within the platform. A logged-in user goes to DSR Management, then DSRs, and selects New. A form started this way does not inherit Approvers from a Public Link. Select them manually in the Approver box.

All three routes follow the same path and the same statuses. Email verification can be applied to any of them.

Note: A request is valid however it reaches your organisation. If one arrives outside the form, log it promptly using an internal route.

Request statuses

Status	What it means	Who is acting
Not Started	A DSR Intake Form has been created but no responses have been entered.	Nobody yet
In Progress	Responses are being entered. The form has not been submitted.	Data subject or reporter
Under Review	The form has been submitted. Email verification takes place at this point if enabled, alongside review by the privacy team.	Data subject (verification only) and Approvers
Complete	The Approver has submitted the form for the final time.	Approver

The first two changes of status happen automatically. The move to Complete is a deliberate step taken by the Approver.

Filling in and submitting the form

As soon as the first response is entered, the form moves to In Progress. The person completing it can leave and come back at any time using the same link, so it is worth advising them to keep a copy of the URL.

When they have finished, they are asked to confirm their responses and submit. Once submitted, the form moves to Under Review and is locked. The data subject or reporter cannot change their answers after this point, but they can still view them using the same link.

Because the link gives access to the responses both before and after submission, data subjects should treat it as confidential and avoid sharing it.

Email verification

Email verification is optional and is switched on at Template level.

When enabled, an email is sent automatically when the form is submitted. It goes to the Correspondence email given on the form. This may be different from other email addresses the data subject has provided as part of their request, such as an address from a former employment.

The data subject clicks the link in the email to confirm they hold that account. At that point their part of the process is finished.

Approvers are notified when the form is submitted, which is before the data subject has verified. To check whether verification has been done, look for Email Validation Complete in the form. If you already have the form open, refresh it to see the latest position. Requests awaiting verification are also shown on the DSR dashboard.

Email verification confirms control of an email address only. It is not a full identity check. Where your organisation requires further proof of identity, this is recorded in the ID Verification section.

If the data subject never verifies

The platform does not chase the data subject or expire the request. It stays on Under Review until an Approver acts on it.

A submitted form is still a request your organisation has received, whether or not the email was verified. Review these regularly. You can contact the data subject, or confirm their identity another way and record this in the ID Verification section. Delete the form only once you have concluded the request is not genuine.

Timings and deadlines

The timer starts when the DSR Intake Form is created. That is the moment the link is opened, or a platform user selects New, so the timer is already running while the form is on Not Started and In Progress. It stops when the Approver completes the request.

The platform times each request against a standard period of 30 days from that point. This is the basis for the timing figures on the DSR dashboard.

The platform does not calculate your statutory deadline. The standard 30 days is not adjusted for:

the jurisdiction or the type of right, which can carry different time limits
an extension, even where one has been recorded in the Deadlines and Extensions section
the date a request was originally received, where it arrived by another channel and was logged on the platform later

Approvers are responsible for working out the deadline that applies to each request and for meeting it. Record the applicable deadline, any extension and the reasons for it in the Deadlines and Extensions section. If your Template includes a received date field, complete that too.

Note: Because extensions do not change the platform’s timings, a request with a valid extension can still appear as overdue on the dashboard. The record in Deadlines and Extensions is your evidence that the extended deadline applied.

Reviewing a request in Approver Mode

When a form is submitted, its Approvers are notified by email. They can open the form from the link in that email, or from DSR Management, then DSRs, in the platform.

After submission the form opens in Approver Mode, which is shown at the top of the form. Approver Mode displays a longer version of the form. The data subject’s responses appear first, and the handling sections appear below them.

The handling sections depend on the Template in use. The standard Template includes the following.

Section	What it is for
Intake and Assignment	Recording how the request was received and who is responsible for handling it.
Right Classification	Recording which right or rights the request relates to, such as access, erasure, rectification, restriction, objection or portability. In the standard Template this section also holds Jurisdiction.
ID Verification	Recording identity checks beyond email verification, such as documents supplied by the data subject or proof of authority where someone is acting on their behalf.
Deadlines and Extensions	Recording the applicable response deadline, and any extension applied, with the reasons for it.
Third-Parties and Scope	Recording the scope of the request, the systems and teams involved in the search, and any third parties that need to be contacted.
Exemptions and Refusal	Recording any exemption relied on, or a decision to refuse the request in whole or in part, with the reasoning.
Resolution and Closure	Recording the outcome, the date the response was sent, and how it was delivered.
Regulatory Escalation	Recording any complaint or regulator involvement connected to the request.

The sections do not need to be completed in one sitting. Complete them as the request progresses, so the record reflects what was decided, when, and why.

Whether a field is mandatory depends on the Template. Three fields should always be completed, because the DSR dashboard relies on them: Right Type, Exemptions and Jurisdiction. If they are left blank, the request will be missing from the corresponding dashboard charts.

Review and redaction

Searching for, reviewing and redacting the data subject’s information is done outside the platform. The platform does not perform review or redaction.

Use your organisation’s usual tools and process for this stage, then record the relevant decisions in the handling sections, for example any exemptions applied or third-party data withheld.

If you need support with review and redaction, contact Privacy Culture. A managed DSAR Review and Redaction service is available.

Responding and completing the request

The response to the data subject is sent outside the platform, using your organisation’s normal channel for secure correspondence.

Once the response has been sent:

Open the DSR Intake Form in Approver Mode.
Complete the Resolution and Closure section.
Check that Right Type, Exemptions and Jurisdiction are filled in, and that the other sections reflect what was done.
Select Submit.

This final Submit finalises the form, stops the timer and moves the request to Complete.

Reopening a request

Approvers can revert a request to an earlier status, for example to correct the record after completion. Every form has a History view, which records each access, change of status and change to a field value, so a reverted request keeps a full audit trail.

Reverting a status affects the timings recorded for that request and the figures on the DSR dashboard. Approvers are responsible for the effect of a reversion on their own timings. Only revert a request where there is a genuine need, and note the reason in the form.

Forms that are never submitted

Not every form that is started will be submitted. The privacy team should review these periodically. They count towards the open totals on the DSR dashboard and, because the timer starts when a form is created, a form left long enough may also show as overdue.

Not Started. A DSR Intake Form is created as soon as the link is opened, so some will be opened and never filled in. Automated traffic is filtered to keep these to a minimum. They contain no information and can be deleted.

In Progress. Approvers can read the responses entered so far. Check stalled forms before deleting them. A partly completed form that identifies the person and makes clear what they are asking for may already amount to a valid request, even though it was never submitted. Where that is the case, handle it as a request.

Deleting stale forms is normally the responsibility of the privacy team.

What the platform does and does not do

The platform does	The platform does not
Capture the request through a public or internal route	Search your systems for the data subject’s information
Verify the data subject’s Correspondence email, where enabled	Review or redact documents
Notify Approvers when a form is submitted	Send the final response to the data subject
Track status and time each request against a standard 30 days	Calculate the statutory deadline or adjust for extensions
Hold the record of classification, identity checks, deadlines, scope, exemptions, outcome and escalation	Chase or expire requests where the email is never verified
Keep a full history of access and changes on every form
Report on all requests through the DSR dashboard

Customising the process

The Template, the handling sections and the use of email verification can all be tailored to your organisation. If the form you see differs from this article, that is expected. To request a change, contact Privacy Culture.

Reading the DSR dashboard

How the DSR process works