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.
Transcend's DSR Automation product supports workflows for both and . 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 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.
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:
- : 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.
- : 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.)
- : 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.
- : 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.
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:
|Request Made||The DSR was just submitted.|
|Failed Verification||Email or phone 2FA failed. The request was canceled because it was not confirmed.|
|Canceled||The request was canceled by an administrator or webhook rule.|
|Revoked||The request was canceled by the data subject.|
|Enriching||Preflight jobs are actively being run. This includes business-logic checks and identity enrichment|
|On Hold||The request has been placed on hold and is pending manual review by a member of your team.|
|Waiting||The request is in a waiting state to give an opportunity for the request to be canceled if a mistake.|
|Compiling||The request is looking up any data on the user and/or apply any user preferences across the stack.|
|Approving||The request has compiled and is pending a manual review before completion.|
|Completed||The request has been fully processed and completed across the stack.|
|Downloadable||Access only: the compiled data is available for download by the data subject over a 2-week period.|
|View Categories||Access 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.|
|Delayed||Erasure only: request is pending deletion. The data pending deletion can be downloaded by the data subject, and the deletion request can be canceled.|
|Secondary||Erasure only: the deletion jobs are being executed across the stack. At this point, the deletion cannot be canceled.|
|Secondary Completed||Erasure 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:
- A CSV upload of requests from another data processor or other source
- Through your Transcend support team
- On your own
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 . Your business is the 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 or the . 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:
|API||The DSR was received through the submitted.|
|Privacy Center||The user authenticated themselves and submitted the request through your|
|Admin Dashboard||The request was by an admin or other employee.|
Before processing begins for a DSR, the DSR is validated by a series of 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 :
- Email verification (magic link)
- Phone number verification via SMS (magic link)
- Post to a Server (Webhook)
- Notify a Person
- Region Matcher
- RegExp Match
- Auto Approve
- Legal Hold Check
- Wait Period
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:
|Queued||The job is queued for processing.||N/A|
|Waiting on Response||The job is waiting for the system to run some asynchronous processes||24 hour|
|Skipped||Processing was skipped because the record was no longer found (if skipping continuously occurs, there may be a deeper issue).||N/A|
|Error||An error has occurred.||24 hours|
|Ready||The job has run successfully for that stage of the request.||N/A|
|Action Required||The job requires attention.||7 days|
|Processing||The job has been ingested by our SQS task queue and is in line to be processed.||12 hours|
|Waiting on Dependencies||The job is waiting for some dependencies to be resolved before continuing,||N/A|
|Integration Disconnected||The data silo has disconnected and cannot begin processing.||N/A|
|Waiting on Request Transition||The request cannot begin processing yet.||N/A|
|Canceled since Request Closed||The request is not in a building state, so all jobs are canceled.||N/A|
|Waiting on Manual Entry||The 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.
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.
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:
- Return everything without redactions,
- Return redacted data, or
- Return counts only.
To configure an integration to return redacted files:
- Navigate to "Infrastructure > Integrations".
- Search and select the integration that you would like to configure.
- Click on the "Manage Datapoints" tab and scroll to the right until you see "Export Mode".
- Click and select "Export Mode > Redacted" for the datapoints you wish to review and redact for that integration.
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:
- Navigate to "DSR Automation > Incoming Requests".
- Click on the access request that you would like to redact from.
- Click on the "Integrations" tab.
- Click on the integration that you would like to review / redact from.
- Click on "Show Redactions".
- Highlight the text that you would like to redact from the access report.
- When complete, click on "Approve all suggested".
- Click on "Mark as Ready" to confirm all the redactions for that integration.
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 , or provide a downloadable report that is also accessible to the data subject via the . The data subject can be notified via , for which templates can be customized in the “Email Templates” section of the Admin Dashboard.