Legal and Compliance Guide

Audience: Legal, privacy counsel, DPOs, compliance teams

Not legal advice. This document explains how Relyance's DSR module is built and what it lets you configure. It is not a legal opinion on what your organization is required to do in any jurisdiction. Work with your own counsel to determine your specific obligations, and use the configuration guidance described here as a starting point, not a compliance guarantee.

This guide explains the DSR module in the terms that matter to a privacy program: what rights it covers, how deadlines are tracked, what the audit trail actually proves, and - just as importantly - what it does not yet do, so you can build compensating process around any gap rather than discover it during a regulatory inquiry.

For the technical mechanics behind everything described here, see Technical Implementation Guide and Admin Configuration Guide. For jurisdiction-by-jurisdiction deadlines, see Regional & Jurisdiction SLA Reference.

Request types covered

The module supports the following request types out of the box, each configured as its own workflow scope:

A single legal request (e.g., "I want a copy of my data and I want you to delete it") is typically handled as two DSRs - one Access, one Delete - each following its own workflow and deadline.

How jurisdiction, subject category, and workflow routing work together

Every workflow is scoped by request type + data subject category + jurisdiction (and, for tenants running Multi-Portal, business entity). Request type, subject category, and business entity are exact-match filters - a request either falls within a workflow's configured set for each or it doesn't. Jurisdiction is the one dimension with a fallback: Relyance resolves the most specific match first (an exact state+country match, then a country-only match), falling back to a workflow scoped to Global if neither matches. Configure your Global workflow deliberately - it's the catch-all for any jurisdiction you haven't explicitly addressed, not a placeholder.

Critically, Relyance does not silently pick a "best guess" workflow when two published workflows could both apply to the same request - the platform actively blocks you from saving a workflow configuration that would create that ambiguity, showing a conflict dialog naming every workflow it overlaps with until you either narrow the new workflow's scope or retire the conflicting one. This prevents non-deterministic routing - you'll never have two published workflows silently competing for the same request. It does not, however, guarantee a workflow exists for every request - if you haven't configured one covering a given request type + subject category + jurisdiction combination, that combination simply has nowhere to route to. Make sure your workflow coverage is deliberately complete, not just conflict-free.

Identity verification

Before a subject can access their Privacy Portal request, they must authenticate. Supported methods are email magic-link, OAuth-based authentication, and parameter-based authentication; your admin team configures which method(s) apply per data subject category. See Admin Configuration Guide.

Authorized agents - a person submitting a request on a data subject's behalf - are supported via a dedicated submission path that requires an authorization document upload (e.g., power of attorney) before the request proceeds. See Admin Configuration Guide for how to configure this, and Technical Implementation Guide for the API pattern.

Redaction and disclosure - protecting third parties in an Access response

A common legal risk in fulfilling an Access request is inadvertently disclosing another person's personal data that happens to appear alongside the requester's own records (e.g., a colleague's name in a shared email thread, a manager's notes in an HR file). Relyance addresses this with manual and template-driven redaction:

• Any field or attachment returned by a data-fetch step can be manually redacted or disclosed by an admin reviewing the result before it's included in the subject's Access Report.
• Redaction templates let you pre-configure which fields (by JSON path) should be redacted by default for a given data source, so reviewers aren't redacting the same fields by hand on every request.
• Disclosure is the explicit override - marking a redacted field as safe to share, which is logged the same as any redaction action.
• Once a DSR is published (i.e., the Access Report is finalized and made available to the subject), the redacted/disclosed state is locked - a subject cannot retroactively see something that was redacted at publish time, even via a direct download link. This lock is enforced server-side, not just in the UI.

Every redaction and disclosure action is individually recorded in the audit log with the user who made the change - see Audit Logs, Troubleshooting & Reporting.

What the audit trail actually proves

For every step in a request's workflow, Relyance logs: when the step started, its outcome (success, failure, timeout, skipped), and - for any step that calls a third-party system - the complete raw HTTP request and response exchanged with that system. Request creation, cancellation, deadline extensions, comments, manual attachments, and every email sent are also logged with a timestamp and the responsible user (or "system"/workflow trigger, where the action was automated).

This is generally strong evidence for demonstrating what happened and when on a per-request basis. It is not, on its own, a substitute for your organization's broader recordkeeping obligations.

Managing requests: assignment, deadlines, and cancellation

Operationally, each request has a single assignee, a status, and a deadline, all editable from the request detail page - see Admin Configuration Guide for the mechanics. A few things worth knowing from a compliance standpoint:

• Deadline extensions are an admin-discretion tool, not a jurisdiction-aware legal calculation. The extension dialog lets an admin add any number of days (up to 900) to a request's deadline - it does not know or enforce what your applicable law actually permits as a maximum extension (e.g., GDPR's two-month extension, CCPA's 45-day extension). It's on your team's process, not the platform, to ensure an extension actually taken is one your jurisdiction allows. Every extension is logged with old date, new date, and the user who made the change.
• Cancellation requires a documented reason - Excessive, Internal Error, Manually Cancelled by Data Subject, or Manually Cancelled by Authorized Agent - selected from a fixed list, which gives you a consistent, auditable record of why a request didn't complete normally rather than free-text (or no) justification.
• A canceled or completed request cannot be reopened. If a data subject or your team needs further action after closure, a new DSR must be created - meaning the original and the follow-up are two separate records in your metrics and audit trail, not one continuous thread. Plan your internal tracking accordingly if this matters for your reporting.
• Assignment is single-owner, not role- or region-scoped. Any user with module access can see and reassign any request - there's no built-in restriction limiting who can be assigned a request based on region or team. If your compliance program requires segregation of duties by region or business unit, that has to be enforced by internal process rather than the platform.

Statutory deadlines

Relyance tracks a deadline per request (visible as "Time Remaining" in the request list and dashboard) based on the jurisdiction the request falls under. See Regional & Jurisdiction SLA Reference for the underlying statutory timeframes by jurisdiction - these are provided as a reference starting point; confirm current statutory requirements with counsel, as privacy law changes frequently.