# 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:

| Document | Audience | What's in it |
|---|---|---|
| **00 - Overview & Implementation Guide** (this doc) | Everyone | What the DSR module is, how the pieces fit together, rollout plan |
| [Legal & Compliance Guide](/docs/data-subject-requests/legal-and-compliance-guide/) | Legal, privacy counsel, DPOs | Regulatory coverage, redaction/disclosure posture |
| [Technical Implementation Guide](/docs/data-subject-requests/technical-implementation-guide/) | Engineers integrating via API or connecting systems | DSR API reference, authentication patterns, Custom DSR Task/Trigger integrations |
| [Admin Configuration Guide](/docs/data-subject-requests/admin-configuration-guide/) | Privacy/compliance admins working in the Relyance platform | Workflows, steps, submission forms, email templates, the Privacy Portal, authentication methods |
| [Audit Logs, Troubleshooting & Reporting](/docs/data-subject-requests/audit-logs-troubleshooting-and-reporting/) | Compliance, auditors, support/CS, admins | What's logged for every step (especially third-party/integration steps), how to view and export it, common failure modes and fixes |
| [Regional & Jurisdiction SLA Reference](/docs/data-subject-requests/regional-and-jurisdiction-sla-reference/) | Legal + admin | Statutory response-deadline reference by jurisdiction |
| [FAQ for Prospects & Customers](/docs/data-subject-requests/faq-data-subject-requests/) | Prospects, new customers | Common questions in plain language |

## 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](/docs/data-subject-requests/audit-logs-troubleshooting-and-reporting/) - 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](/docs/data-subject-requests/admin-configuration-guide/#submission-forms).
- **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](/docs/data-subject-requests/admin-configuration-guide/#workflows-and-conflict-resolution).
- **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](/docs/data-subject-requests/admin-configuration-guide/#steps) and [Technical Implementation Guide](/docs/data-subject-requests/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](/docs/data-subject-requests/admin-configuration-guide/#the-privacy-portal).
- **The Audit Log** captures everything - see [Audit Logs, Troubleshooting & Reporting](/docs/data-subject-requests/audit-logs-troubleshooting-and-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](/docs/data-subject-requests/regional-and-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](/docs/data-subject-requests/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](/docs/data-subject-requests/admin-configuration-guide/#steps).

### 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](/docs/data-subject-requests/faq-data-subject-requests/).
- **Legal, privacy, DPO?** Read [Legal & Compliance Guide](/docs/data-subject-requests/legal-and-compliance-guide/) and keep [Regional & Jurisdiction SLA Reference](/docs/data-subject-requests/regional-and-jurisdiction-sla-reference/) handy.
- **Integrating via API or building a custom connection?** Go straight to [Technical Implementation Guide](/docs/data-subject-requests/technical-implementation-guide/).
- **Configuring workflows and forms day-to-day?** [Admin Configuration Guide](/docs/data-subject-requests/admin-configuration-guide/) is your reference.
- **Investigating a stuck request or preparing for an audit?** [Audit Logs, Troubleshooting & Reporting](/docs/data-subject-requests/audit-logs-troubleshooting-and-reporting/).