DSR Automation Overview

Transcend DSR Automation is a comprehensive and configurable end-to-end process that finds, deletes, returns, or modifies your customers’ data or privacy preferences across your entire tech stack. We support DSR workflows whether you are operating on data that your business owns, or whether you are processing data on behalf of another business.

With Transcend's DSR Automation, you can easily configure different workflows for each type of data subject and data action, across your entire system.

The detailed list of data subject request types supported by Transcend can be found here.

Transcend's DSR Automation product supports workflows for both data processors and data controllers. The terms "data processor" and "data controller" are common terms used in the European GDPR to describe ownership and responsibility over data.

Most B2B businesses operate as a data processor over some types of data that is processed. An example of a business that may act as a data processor would be Twilio. Twilio is a B2B SaaS company that offers APIs to other businesses for programmatically sending text messages. If a company called "Acme Corp" were to be a customer of Twilio, and Acme Corp used Twilio as a vendor to send text messages to Acme Corp users, then Twilio would be the data processor for any data that is collected on behalf of Acme Corp in order to perform the services of texting that user.

But every business, in one form or another, is a data controller for some types of data. Even Twilio would be a data controller for any personal data that was collected on Twilio employees or for marketing data that Twilio collects in order to acquire new Twilio customers.

Using Transcend, B2B companies can encode different workflows for deleting and accessing data for both data processor and data controller use cases, as well as anything in between.

Transcend Product Architecture for DSRs for data controllers
Transcend Product Architecture for DSRs for data processors

Handling data subject requests at an organization involves several steps, such as authentication of the data subject, processing the request against your systems, and keeping record of the request to ensure it is continiously respected. Every workflow that you set up in Transcend will contain the following modules:

  1. DSR Ingestion: Requests can be received directly by data subjects via the Privacy Center, indirectly by your existing systems via API, or manually into Transcend via the Admin Dashboard.
  2. Preflight Jobs and Identity Enrichment: After ingestion, there are several checks that can be performed on the request, such as specific authentication methods, legal holds, waiting periods, or enriching the identifiers provided with any additional identifiers that match the data subject internally (email, phone, advertising_id, user_id, etc.)
  3. DSR Jobs: Encode the system-by-system rules to be executed for that DSR. For deletion jobs, you can encode the ordering in which those jobs run in the situation where one system syncs data to another system, and for Access requests, you can configure integrations to enable redactions on Access reports.
  4. Report Delivery: Upon completion of the request, a report of the request is generated and in the case of access reports, can be sent to the requestor.

To see the state of a request in this lifecycle, you can click on a specific DSR from the "Incoming Requests" tab of the Admin Dashboard.

Status tab of a specific data subject request in the Admin Dashboard

The status of the request along the pipeline can be found under the "Status" tab of the request. The full set of DSR statuses that exist in the platform today include:

LabelEnumDescription
Request MadeREQUEST_MADEThe DSR was just submitted.
Verification FailedFAILED_VERIFICATIONEmail or phone 2FA failed. The request was canceled because it was not confirmed.
CanceledCANCELEDThe request was canceled by an administrator or webhook rule.
RevokedREVOKEDThe request was canceled by the data subject.
PreflightENRICHINGPreflight jobs are actively being run. This includes business-logic checks and identity enrichment
On HoldON_HOLDThe request has been placed on hold and is pending manual review by a member of your team.
WaitingWAITINGThe request is in a waiting state to give an opportunity for the request to be canceled if a mistake.
CompilingCOMPILINGThe request is looking up any data on the user and/or apply any user preferences across the stack.
Waiting for approvalAPPROVINGThe request has compiled and is pending a manual review before completion.
CompletedCOMPLETEDThe request has been fully processed and completed across the stack.
DownloadableDOWNLOADABLEAccess only: the compiled data is available for download by the data subject over a 2-week period.
View categoriesVIEW_CATEGORIESAccess only: the request is not available for download, but its associated data collection categories are made available to the data subject for review over a 2-week period.
Delaying executionDELAYEDErasure only: request is pending deletion. The data pending deletion can be downloaded by the data subject, and the deletion request can be canceled.
Approval after data removedSECONDARY_APPROVINGErasure only: the data deletion is completed but notification to data subject is pending approval.
Removing dataSECONDARYErasure only: the deletion jobs are being executed across the stack. At this point, the deletion cannot be canceled.
Data removedSECONDARY_COMPLETEDErasure only: deletion request has been successfully completed in full.

We offer several methods of ingesting data subject requests, wether you are processing DSRs as a data processor, or a data controller.

If you act as a data processor for another company, that company will need to send you data subject requests that they reieve from their end-users. DSRs of this type are most often received via the following options:

  • Transcend's API
  • A CSV upload of requests from another data processor or other source
  • Through your Transcend support team
  • On your own Admin Dashboard

When these requests are fulfilled, you can either serve the results via your API or have them be downloaded by your support team. For erasure jobs, there will simply be a confirmation that deletion has completed; for access requests, you can download and propagate the access report generated.

For B2C organizations, the most common way to get requests is through the Privacy Center. Your business is the data controller that decides how to process your customers' personal data. For requests not received through the Privacy Center, a team member of your organization can manually make a request through the Admin Dashboard or the DSR API. Upon completion, a report is sent via email, or made available for review and download directly in the Privacy Center.

Request Origin Types

You can filter requests in the "Incoming Requests" tab of the Admin Dashboard based on how the request was received, also known as its origin. The origin can be one of the following:

LabelEnumDescription
APIAPIThe DSR was received through the Transcend API submitted.
Privacy CenterPRIVACY_CENTERThe user authenticated themselves and submitted the request through your Privacy Center
Admin DashboardADMIN_DASHBOARDThe request was submitted manually by an admin or other employee.

Before processing begins for a DSR, the DSR is validated by a series of preflight jobs to ensure that it is legitimate and ready for processing. During this step Transcend runs a set of customizable checks which you can read more about here:

  1. Email verification (magic link)
  2. Phone number verification via SMS (magic link)
  3. Post to a Server (Webhook)
  4. Notify a Person
  5. Region Matcher
  6. RegExp Match
  7. Auto Approve
  8. Database
  9. Looker
  10. Legal Hold Check
  11. Wait Period

For more information, review the Preflight Checks & Identity Enrichment section of our documentation.

In order to fully process the DSR, Transcend first matches the user’s data in all the different relevant systems (i.e., data silos). During this data processing step, our integrations submit the request on behalf of the user to those different remote systems and make the corresponding API call to act on the data (download, delete, opt out, etc.).

Each data system can be in one of the following states:

LabelDescriptionRetried After*
QueuedThe job is queued for processing.N/A
Waiting on ResponseThe job is waiting for the system to run some asynchronous processes24 hour
SkippedProcessing was skipped because the record was no longer found (if skipping continuously occurs, there may be a deeper issue).N/A
ErrorAn error has occurred.24 hours
ReadyThe job has run successfully for that stage of the request.N/A
Action RequiredThe job requires attention.7 days
ProcessingThe job has been ingested by our SQS task queue and is in line to be processed.12 hours
Waiting on DependenciesThe job is waiting for some dependencies to be resolved before continuing,N/A
Integration DisconnectedThe data silo has disconnected and cannot begin processing.N/A
Waiting on Request TransitionThe request cannot begin processing yet.N/A
Canceled since Request ClosedThe request is not in a building state, so all jobs are canceled.N/A
Waiting on Manual EntryThe job is waiting on some manual entry.Depends on the integration. Default is 30 days.

* If left in this state for too long, the job will be retried at a maximum after this amount of time. In some cases, it may be retried sooner.

For status updates, we will periodically poll a given data silo to check if the job has completed; your organization will not receive a direct webhook from that data silo, and all requests are initiated by Transcend and proxied through your gateway.

You can view the status of each system by going to the "Integrations" tab of that request in the Admin Dashboard.

Integrations tab of a specific data subject request in the Admin Dashboard

Transcend's operations relay on several connections with your internal and external systems. It is important to ensure that each system is communicating properly with Transcend to prevent delays in processing. You can find some troubleshooting steps below, depending on the connection type.

If the issue is with a SaaS connector, you can contact our team for help. We typically patch issues or give recommendations within a few hours.

For internal system connectors, ping the system owner to see if they know why the data silo is not reporting properly; you may do so via email through the Transcend platform.

When reconnecting systems, it is also common to switch a request to “Silent Mode” to disable future emails from being sent to the data subject, until Transcend fixes the issues, and the request can properly complete.

Modal to toggle on Silent Mode when manually making a data subject request through the Admin Dashboard

Transcend's DSR Automation facilites the redaction of data from access reports before returning the report to the data subject.

This feature is particularly useful when returning unstructured data, where certain files might contain personal information belonging to someone else, or other proprietary information that should be excluded from the report.

To use this feature, you will need to configure an integration to return redacted data, rather than the full report. Supported integrations can be configured to return data in three ways:

  1. Return everything without redactions,
  2. Return redacted data, or
  3. Return counts only.

To configure an integration to return redacted files:

  1. Navigate to "Infrastructure > Integrations".
  2. Search and select the integration that you would like to configure.
  3. Click on the "Manage Datapoints" tab and scroll to the right until you see "Export Mode".
  4. Click and select "Export Mode > Redacted" for the datapoints you wish to review and redact for that integration.
Integrations > Manage Datapoints export mode screenshot

Now that you have configured an integration to return redacted data, you will be able to redact portions of the files before returning them. To do so:

  1. Navigate to "DSR Automation > Incoming Requests".
  2. Click on the access request that you would like to redact from.
  3. Click on the "Integrations" tab.
  4. Click on the integration that you would like to review / redact from.
  5. Click on "Show Redactions".
  6. Highlight the text that you would like to redact from the access report.
  7. When complete, click on "Approve all suggested".
  8. Click on "Mark as Ready" to confirm all the redactions for that integration.
Incoming Requests > Integrations Redactions complete screenshot

Below the redaction UI, There are some options to quickly undo all redacted data, redact all, or reset to default. If you'd like to undo or modify the redaction on a specific part of the data, simply select that portion of the text again.

Once the redactions have been finalized, the redacted report is queued to be returned to the data subject.

Once all jobs have completed and the request has been fulfilled, you can either serve the results via your API, or provide a downloadable report that is also accessible to the data subject via the Privacy Center. The data subject can be notified via email, for which templates can be customized under "DSR Automation" > "Email Settings" > "Email Templates” section of the Admin Dashboard.

Email Templates tab of the Admin Dashboard to customize communications with data subjects