# FAQ: Data Subject Requests

*Audience: Prospects, new customers*

Plain-language answers to the questions that come up most in evaluations and early implementations. For deeper detail, each answer links to the relevant doc in this set.

## What is the Relyance DSR module, in one paragraph?

It's the system that takes a data subject request - "show me my data," "delete my data," "stop selling my data" - from intake through fulfillment through audit-ready proof it was done, without your team maintaining spreadsheets or manually hunting through a dozen systems:

- A branded **Privacy Portal** handles intake and identity verification.
- Configurable **workflows** route the request to the right sequence of steps for its jurisdiction and request type.
- Those **steps** call your connected systems automatically (or create a tracked manual task where automation isn't possible).
- Every action along the way is **logged**.

See [Overview & Implementation Guide](/docs/data-subject-requests/overview-and-implementation-guide/).

## How much manual work does this actually eliminate?

That depends entirely on how many of your systems have a native or custom-built connection:

- Where a system supports it, access and deletion can run automatically with no one touching a spreadsheet.
- Where a system doesn't expose an API for a given operation (common for deletion in particular - some vendors only support automated access/export), the workflow falls back to a manual task that's still tracked and audited inside the same request, rather than living in someone's inbox.
- In practice, most customers see the bulk of their manual effort collapse for well-covered systems (their CRM, HRIS, support desk, common SaaS tools) while a smaller set of internal or long-tail systems still need a human step.
- Beyond the pre-built connectors, Relyance also supports pointing a workflow step at your own custom endpoint (a **Custom DSR Task** connection), so an internal system or a vendor without a native connector isn't necessarily stuck on manual work either - see [Technical Implementation Guide](/docs/data-subject-requests/technical-implementation-guide/#custom-dsr-task-and-custom-dsr-trigger-task).

Check with your Relyance contact on coverage for your specific stack, and don't assume "1-click, fully automated everywhere" for a system you haven't confirmed.

## Does deletion get automated for systems without a Relyance connector?

- If a system has a pre-built connector, or you've built a Custom DSR Task connection against its API, yes.
- If a system has no deletion API at all (this depends entirely on that vendor, not on Relyance), the workflow uses a manual task as the fallback - still tracked as part of the same request and audit trail.

## What does the data subject actually receive?

For an Access request, a consolidated, downloadable **Access Report**, accessible through the Privacy Portal after identity verification, containing:

- Their request details.
- A table of contents.
- A summary.
- The compiled data itself (structured data shown as readable tables, documents/images embedded inline).

See [Admin Configuration Guide](/docs/data-subject-requests/admin-configuration-guide/#the-access-report).

Beyond the report itself, admins can configure email communications at any point in a workflow via Send Email steps and email templates - for example, confirming a request was received and is being processed, or confirming a deletion or opt-out was completed. See [Admin Configuration Guide](/docs/data-subject-requests/admin-configuration-guide/#email-templates).

## How fast do we need to respond, and does the platform track that automatically?

- Deadlines vary by jurisdiction - anywhere from about 15 days to 45+45 days depending on the law.
- Relyance tracks a deadline per request based on its jurisdiction and surfaces "time remaining" (and overdue status) on both the request list and dashboard.

See [Regional & Jurisdiction SLA Reference](/docs/data-subject-requests/regional-and-jurisdiction-sla-reference/) for the jurisdiction-by-jurisdiction reference - confirm current statutory requirements with counsel, since these change.

## Can we extend a deadline if we're not going to make it in time?

- Yes - an admin can extend a request's deadline directly from the request detail page, optionally notifying the data subject (and authorized agent, if applicable) that the deadline moved.
- The tool itself doesn't cap the extension at whatever your specific law allows (e.g., GDPR's two-month extension window) - that judgment call is on your team, not enforced by the platform.
- Every extension is logged with the old date, new date, and who made the change.

See [Legal & Compliance Guide](/docs/data-subject-requests/legal-and-compliance-guide/#managing-requests-assignment-deadlines-and-cancellation).

## How do we manage a growing queue of requests day to day?

- Each request has a status (In Progress, Awaiting Manual Tasks, Needs Attention, Error, etc.), a single assignee, and a deadline, all visible and filterable from the request list - so a team lead can triage by what's overdue, unassigned, or stuck, rather than working requests in creation order.
- Reassigning a request, extending its deadline, or canceling it (with a required, auditable reason) are all done from the request detail page and logged automatically.

See [Admin Configuration Guide](/docs/data-subject-requests/admin-configuration-guide/#managing-requests-from-the-list).

## Can someone submit a request on behalf of someone else (an authorized agent)?

- Yes - the platform supports a dedicated authorized-agent submission path requiring an authorization document (e.g., power of attorney) upload before the request proceeds.
- Separate email templates are available for the data subject vs. the agent.

See [Admin Configuration Guide](/docs/data-subject-requests/admin-configuration-guide/#authorized-agent-submissions).

## We operate multiple brands/legal entities - can each have its own intake portal?

- Yes - Relyance supports running multiple independently branded Privacy Portals under one tenant, each with its own subdomain and enable/disable state.
- Workflows, auth methods, and the request list can all be scoped by business entity.

See [Admin Configuration Guide](/docs/data-subject-requests/admin-configuration-guide/#multi-portal-multiple-business-entities).

## What happens if an integration breaks mid-flight (e.g., expired API credentials)?

- The affected step fails, and the failure - along with the exact HTTP status and response from the target system - is captured in that request's audit log, so your team can diagnose it without needing engineering to reproduce the call.
- If you've turned on workflow-failure notifications (off by default - turn them on), you'll be alerted rather than discovering it when a deadline is close.
- Fixing it is usually a matter of updating the connection's credentials; queued/errored requests can then be bulk-retried.

See [Audit Logs, Troubleshooting & Reporting](/docs/data-subject-requests/audit-logs-troubleshooting-and-reporting/#troubleshooting).

## Can we route requests differently depending on the outcome of an earlier step (conditional branching)?

- A workflow runs the same sequence of steps every time it's matched - it doesn't dynamically choose a different *path* of steps at runtime.
- Individual steps can, however, be conditionally skipped based on whether an earlier step in the same workflow succeeded, failed, or was itself skipped (see [Technical Implementation Guide](/docs/data-subject-requests/technical-implementation-guide/#advanced-config-step-json-reference)).
- If a sub-case genuinely needs a materially different sequence of steps, build it as its own, more narrowly-scoped workflow rather than expecting one workflow to branch internally.

## Is there a full audit trail we can hand to a regulator or auditor?

Yes, at the request level:

- Every step's outcome.
- Every email sent.
- Every comment and attachment change.
- Critically, the complete raw request/response for every call made to a third-party system.
- All of the above timestamped and attributed to a user or automation.

See [Audit Logs, Troubleshooting & Reporting](/docs/data-subject-requests/audit-logs-troubleshooting-and-reporting/#the-two-audit-log-surfaces).

## Does every user with DSR access see every request, or can we restrict visibility by region/team?

- Today, DSR visibility is module-level, not row-level - any user with access to the module can see all requests, not just ones in their region or assigned to their team.
- If segregation of duties by region is important to your process, build that into your internal assignment/review procedures rather than relying on platform-enforced visibility restrictions.