Data Subject Requests

Data Protection Officers, compliance officers, and privacy analysts use the Data Subject Requests screen to register, track, and close every formal rights request — from access and erasure to portability and objection — ensuring your organisation never misses a statutory response deadline.

The Data Subject Requests screen is your team's single source of truth for every rights request an individual has formally submitted to your organisation. Whether someone wants to know what data you hold about them, asks you to delete it, or objects to how you're using it, this screen is where you log the request, assign ownership, track the legal countdown, and coordinate the internal work needed to respond on time. It sits between the moment a request lands in your inbox and the moment your formal response goes out — and it connects directly to tasks, documents, and approval workflows so nothing falls through the cracks.

How to open it

In the main left-hand navigation sidebar, look for the Data Subject area and click Data Subject Requests. This takes you straight to the list of all requests.

You need at least read access to this module to see anything here. Users with full read access see all requests; users with restricted read access see only requests where they are listed as the responsible person. Creating or editing requests requires the corresponding create or edit permission. If you land on an "Access Denied" page, ask your DPMS administrator to check your permissions.

What you see

The screen has two main states: the list view and the detail view.

In the list view, the top of the page shows a row of status filter tabs — All, Active, Draft, Inactive, and Review — followed by a search bar and filter controls to the right, and a Create button in the top-right corner. Below that sits the main table, where each row is one request. The table has seven columns: Identifier, Type, Remaining Days, Elapsed, Request Date, Responsible Person(s), and Status. The Remaining Days column is colour-coded so that requests approaching or past their deadline stand out immediately. Avatar chips rather than plain names appear in the Responsible Person(s) column.

When you click a row, you enter the detail view. Here the screen splits into a narrow left-hand tab menu — General, Log, Tasks, Documents, and Reviews & Approvals — and a wider content area on the right. Across the top of the content area, a breadcrumb shows you exactly where you are, with left and right chevron arrows so you can step through requests one by one. Just below the breadcrumb, a sticky action bar lets you change the status or responsible person inline, without opening the full edit form.

Working with this screen

Registering a new request for the first time

When a data subject sends you an access request, erasure request, or any other formal rights request, the first thing to do is create a record in DPMS so the clock starts ticking.

Click the Create button at the top right of the list view, then choose Create Data Subject Request from the dropdown.
The creation form opens. At the very top, the action bar lets you set the Status (it defaults to "Open") and pick one or more Responsible Person(s). Assign yourself or a colleague now — whoever will own the response.
The ID field is pre-filled with an auto-generated reference number (for example 5821-4490-3317). You can leave this as-is or type your own reference code if your organisation uses a specific numbering scheme. Important: once you save, this ID cannot be changed.
Use the Type multi-select to describe what kind of request this is — for example "Access Request" or "Right to Erasure". You can select multiple types if the request covers more than one right. If the list is empty, your administrator needs to add DSAR type tags under Compliance Settings first; you can also type a new tag directly in this field to create one on the fly.
Enter the requestor's name or identifier in the Requestor field.
The Request Date defaults to today. If the request actually arrived earlier (say, via post), change this to the actual receipt date — it affects the deadline countdown.
The Response Period defaults to 30 calendar days, which matches the standard GDPR window. If your regulation or internal policy requires a different number, change it here. The combination of Request Date and Response Period determines the deadline shown in the list view.
In the Content field, write a summary of what the requestor is asking for. This is a multi-language rich text area; if your DPMS has AI translation enabled, you can use the AI helper to translate into other working languages.
If you have a scanned copy of the original request (an email printout, a letter, a web form submission), drag it into the file upload area at the bottom of the form. Only one file can be attached at creation time; you can link more documents later via the Documents tab.
Click Save. DPMS creates the record and takes you straight to the detail view, where you will see the countdown showing how many days remain to respond.

Monitoring deadlines and prioritising your workload

The list view is designed for daily triage. The colour-coded Remaining Days column lets you scan at a glance which requests are healthy (plenty of time left) and which are urgent or already overdue (negative numbers, highlighted in a warning colour).

To focus on the most urgent work:

Click the Active tab to filter to only currently open, active requests — hiding drafts and closed ones.
Open the filter builder (the advanced filter icon next to the search bar) and add a rule: field = "Remaining Days", operator = ≤, value = 5. The table now shows only requests with five or fewer days left.
Click through each critical request using the rows, review what still needs to happen, and either update the status or assign a follow-up task.
When you need to share this list with management or include it in a weekly report, click the Export button and choose XLSX to download the current (filtered) table as a spreadsheet.

Heads up: Remaining Days can go negative. If a request is not formally closed, DPMS will continue counting downwards past zero (showing, for example, -3 days) to signal that the deadline has been missed. The system does not automatically change the status to overdue — you need to update it manually.

Reviewing and updating a request in progress

Once a request is created, day-to-day handling happens in the detail view. Click any row in the list to open it.

At the top of the screen you will see the sticky action bar with the current status badge and the responsible person(s). You can change either of these inline — just click the status badge to open the dropdown and pick a new status, or click the people selector to reassign ownership. DPMS saves these changes immediately in the background; there is no separate Save step.

The left-hand tab menu gives you access to everything attached to this request:

General — shows all the core fields (ID, type, requestor, dates, content, remaining and elapsed days). Click Edit to open the full edit form and change any of these values.
Log — an internal diary for the request. Add log entries to document every action you've taken: who you contacted, what you verified, what response you prepared. These entries are separate from the system activity log.
Tasks — link internal to-do items to this request, assign them to colleagues, and set due dates. Linked tasks also appear in the global Tasks module with a reference back to this DSR.
Documents — attach additional files from the Policies & Documents module as supporting evidence.
Reviews & Approvals — assign a structured approval workflow if the request requires sign-off from multiple reviewers before the response is sent.

Use the ‹ and › arrows in the breadcrumb bar to step to the previous or next request in your current filtered list, so you can process a batch of requests without constantly returning to the index.

Auditing changes and maintaining accountability

Whenever you need to know who changed a request — what field they changed, what the old value was, and when — click the clock icon (Activity Log) in the top-right corner of the detail view. A slide-in panel opens showing a full timestamped audit trail of every modification to the record.

This is particularly useful during an audit or a supervisory authority inquiry, where you may need to demonstrate that a request was handled correctly and in good time.

Tip: The Activity Log is not the same as the Log tab. The Log tab is for your own internal notes and process documentation. The Activity Log drawer (clock icon) is a system-generated, tamper-proof record of every field change — it cannot be edited.

Starting a review workflow for a complex request

For sensitive or legally complex requests — for example, a right-to-erasure request that requires multiple teams to confirm deletion — you can assign a formal approval workflow.

Open the request's detail view and click Reviews & Approvals in the left-hand tab menu.
The Workflow Overview sub-tab shows any workflows already assigned. If there are none, click the trigger button within that tab to assign a workflow template.
Select the appropriate template and save. DPMS creates the workflow instance and notifies the assigned reviewers.
Reviewers open the request, navigate to Reviews & Approvals → Required Action, and complete their step — approving, rejecting, or adding comments.
Once all approval steps are complete, the workflow closes and you can proceed with sending the response.

Field reference

ID — The unique reference number for this request. Auto-generated on creation (format: dddd-dddd-dddd). You may overwrite it before saving, but you cannot change it afterwards. Use your organisation's reference scheme if you have one.
Type — One or more request type tags (e.g. "Access Request", "Right to Erasure"). Drawn from DSAR type tags configured in Compliance Settings. Not strictly required, but strongly recommended for filtering and reporting.
Requestor — The name or identifier of the individual who submitted the request. Free text; no length limit.
Request Date — The date (and time) the request was received. Defaults to today. This is the start of the deadline countdown — if you receive a request on a Friday but only log it on Monday, set this to Friday.
Response Period — The number of calendar days within which you must respond. Defaults to 30. Change this if your regulation or internal policy requires a different window (GDPR allows up to 90 days for complex cases with notification).
Content — A full description of what the requestor is asking for. Supports multiple languages; AI-assisted translation is available if enabled for your organisation.

How this connects to the rest of DPMS

The DSR module sits at the centre of several cross-cutting workflows. Here is what depends on what you do here:

Tasks module: Tasks you link to a DSR appear in the global task list with a back-reference to the request. Colleagues assigned a task will see the DSR context directly.
Policies & Documents module: Documents linked on the Documents tab are visible from both the DSR detail view and the document's own detail view — evidence travels with both objects.
Workflow / Reviews & Approvals engine: Approval workflows triggered on a DSR create notifications in the reviewing team members' queues across the whole platform. Completing a Required Action step updates both the workflow status and the DSR record.
Compliance Settings: The Type tags and custom status options you see on this screen are configured in Compliance Settings → Attributes (for DSAR types) and Compliance Settings → Statuses (for custom DSR statuses). If those aren't set up yet, contact your DPMS administrator.

After creating a request, your next steps are typically: link or create tasks for internal follow-up → attach supporting documents → monitor the deadline daily → update the status when the response is sent → add a log entry documenting what you did.

Tips & common pitfalls

Heads up: The ID cannot be changed after you save. Double-check your organisation's reference numbering convention before clicking Save for the first time.

Heads up: The file upload area on the creation form accepts only one file and disappears once the record is saved. For everything else, use the Documents tab.

Remaining Days will go negative without any alert. DPMS does not automatically flag or change the status of an overdue request. Check the colour-coded Remaining Days column in the list view regularly, especially after weekends or public holidays.
The 30-day default is a starting point, not a legal guarantee. GDPR allows extensions in some cases, and other regulations may set different windows. Always confirm the correct response period for the specific type of request before saving.
Custom status options only appear if they've been configured. If the status dropdown shows only a handful of basic options, your administrator needs to add custom DSR statuses under Compliance Settings → Statuses.
DSAR type tags must exist before they can be selected. If the Type field is empty, go to Compliance Settings → Attributes and create the DSAR type tags your organisation uses. You can create tags on the fly from the form field, but it is better to define them centrally first so all records use consistent terminology.
The Activity Log clock icon is hidden on shared/consulted records. If a record was shared with your organisation from another entity, the audit trail belongs to the originating organisation — you will not see the clock icon even with read access.