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.

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.

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.

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.

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 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.

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.

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.

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.

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.

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).
• 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.

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.