Overview and Implementation Guide

About this document set

This is the entry point to Relyance's Data Subject Request documentation. Start here, then branch out to the guide that matches your role:

What is the Relyance DSR module?

The Relyance DSR module automates the intake, tracking, fulfillment, and audit trail for data subject requests - access, deletion, correction, and related privacy rights requests - across every regulation your business operates under (GDPR, CCPA/CPRA, and the growing list of US state privacy laws, among others).

At a high level, it gives you:

1. A white-label intake surface - the Privacy Portal - where a data subject (or someone acting on their behalf) submits a request, verifies their identity, and later downloads their results.
2. Configurable workflows that route each incoming request to the right sequence of steps based on jurisdiction, data subject category, request type, and (for tenants running Multi-Portal, our multi-brand support) business entity.
3. Steps that do the actual work: calling a vendor's API to fetch or delete data, pausing for human review, creating manual tasks, sending emails, or hitting a custom webhook you control.
4. A management console - the request list, dashboard, and detail view - where your team tracks status, deadlines, assignees, and works any manual tasks a workflow generates.
5. An audit trail that records every logged action taken against a request - see the full catalog in the Audit Logs guide - including the full request/response of every third-party API call a workflow makes, so you can demonstrate compliance to a regulator or auditor.

Because discovery, workflow execution, redaction, and audit logging are part of one connected system, a request that requires calling five different vendor systems, pausing for legal review, and then compiling a report is tracked, logged, and reportable as a single unit of work - not five disconnected tickets.

How the pieces fit together

Submission Forms        Workflows              Steps                    Privacy Portal        Audit Log
(what an intake form   (match request to  ->  (the actual work: -> (data subject's -> (every action,
 asks the subject,       the right sequence     webhook calls,       verification,        every third-party
 per jurisdiction/       of steps, by            manual tasks,        result download,      request/response,
 subject category)       jurisdiction/type/      pauses, emails,      request status)       recorded)
                         category)               redaction)

• Submission Forms define what a data subject is asked when they submit a request, and how form fields map back to subject attributes (email, phone, custom preferences). See Admin Configuration Guide.
• Workflows are the routing layer: each workflow is scoped to a request type + data subject category + jurisdiction (+ business entity, where Multi-Portal is enabled), and Relyance actively prevents you from saving a workflow whose scope overlaps another published workflow - conflicts are caught at configuration time, not guessed at runtime. See Admin Configuration Guide.
• Steps are the building blocks of a workflow - webhook calls to third-party systems, manual tasks, pauses, emails, and custom rule webhooks. See Admin Configuration Guide and Technical Implementation Guide for how third-party connections are configured.
• The Privacy Portal is what the data subject actually interacts with: submitting the request, verifying their identity, and downloading their completed Access Report. See Admin Configuration Guide.
• The Audit Log captures everything - see Audit Logs, Troubleshooting & Reporting.

Implementation roadmap

A typical rollout moves through six phases. Legal/privacy, IT/engineering, and day-to-day admins are all involved at different points.

Phase 1 - Define your workflows

Owner: Legal/privacy, with admin support. Decide how many distinct workflows you need. A workflow is scoped by request type (Access, Delete, Update, Info Request, File Complaint, Opt Out, and - where enabled - Opt In), data subject category (Customer, Employee, Vendor, Job Applicant, etc.), and jurisdiction. Map out your jurisdictions against Regional & Jurisdiction SLA Reference before you start building, since jurisdiction scoping determines both legal deadlines and which workflow a request falls into.

Phase 2 - Connect your systems

Owner: Engineering/IT, with admin support. For every system that holds data about your data subjects (CRM, HRIS, support desk, marketing platform, internal databases), either use a pre-built connector or configure a Custom DSR Task against a system's own API. See Technical Implementation Guide. Coverage depends entirely on what each target system's API exposes - some systems support automated deletion, some only support automated access/export, and some require a manual task as the fallback.

Phase 3 - Build workflows and steps

Owner: Admin. In the workflow editor, add steps in the order they should run: fetch/delete webhook steps against your connected systems, pause steps for manual review (recommended before any delete executes), manual task steps for systems without an API connection, and email steps to notify the subject or your team. Independent steps can be set to run in parallel rather than strictly in sequence, which is useful when several unrelated systems need to be queried and there's no reason to wait on one before starting the next. Configure redaction templates on any access step whose output might contain another person's data. See Admin Configuration Guide.

Phase 4 - Configure intake and identity verification

Owner: Admin, with legal review on copy. Build your submission form(s), choose an authentication method for the Privacy Portal (email magic-link, OAuth, or parameter-based), and design the portal's branding. Legal should review any required disclosures and jurisdiction-specific language before publish.

Phase 5 - Test

Owner: Admin + engineering. Use the built-in step-testing tool to run a synthetic request through a single step before it goes live, and review the results in the scoped step-testing audit log. Confirm workflow matching resolves the way you expect for each jurisdiction/category combination you configured.

Phase 6 - Go live & monitor

Owner: Admin/compliance, ongoing. Once live, monitor the DSR Dashboard for volume, overdue requests, and average fulfillment time. Turn on workflow-failure notifications (email and/or in-platform - both are off by default) so your team hears about a stuck workflow before a deadline is missed. Periodically review the audit log and export request-list data for internal reporting or external audit.

Who should read what

• New to the product / evaluating it? Start with this doc, then FAQ.
• Legal, privacy, DPO? Read Legal & Compliance Guide and keep Regional & Jurisdiction SLA Reference handy.
• Integrating via API or building a custom connection? Go straight to Technical Implementation Guide.
• Configuring workflows and forms day-to-day? Admin Configuration Guide is your reference.
• Investigating a stuck request or preparing for an audit? Audit Logs, Troubleshooting & Reporting.