Privacy Requests Overview

Transcend Privacy Requests is a comprehensive, end-to-end procedure that deletes, returns, or modifies your customers’ data or preferences across your entire tech stack. We support all types of businesses, whether you are operating on data that your business owns, or whether you are processing data on behalf of another business. If your business processes data on different types of users (e.g., customers, contractors, employees), you can define different workflows for each type of user. Those workflows may be overlapping, or completely independent, depending on your business needs and legal requirements.

The full list of privacy request types supported by Transcend can be found here.

Transcend's Privacy Request product is flexible enough to support 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 are 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.

The role of a data processor under the law is to support the data controller. Most privacy laws will hold the data controller responsible for any misuse or personal data. If any one of the data controller's sub-processors caused a compliance failure, the data controller is no longer compliant themselves. Because the risk is assumed by the data controller, it is common to encode the requirements of the data processor into a "Data Processing Agreement (DPA)". In such an agreement, the data processor is agreeing to uphold their responsibilities that will enable the data controller to stay compliant with whatever privacy laws they wish to comply with.

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.

Every workflow that you set up in Transcend will contain the following modules:

  1. Request Ingestion: What are the different intakes methods for receiving the Privacy Request? How is the request authenticated?
  2. Preflight Jobs and Identity Enrichment: Are there additional business logic checks that should before the workflow can be run? Do we need to enrich a set of identifiers (email, phone, advertising_id, user_id, etc.) that will be needed in order to process that request across all systems in your stack?
  3. Privacy Request Jobs: Encode the system by system rules to be executed for that privacy request. For deletion jobs, you can encode the ordering in which those jobs run in the situation where one system syncs data to another system.
  4. Report Delivery: Upon completion of the request, provide some notification that the request has been completed.

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

When Transcend processes a privacy request, each request will have a status that encodes where it is in the above workflow. The full set of privacy request statuses that exist in the platform today include:

LabelEnumDescription
Request MadeREQUEST_MADEThe privacy request was just submitted.
Failed VerificationFAILED_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.
EnrichingENRICHINGPreflight 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.
ApprovingAPPROVINGThe 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.
DelayedDELAYEDErasure only: request is pending deletion. The data pending deletion can be downloaded by the data subject, and the deletion request can be canceled.
SecondarySECONDARYErasure only: the deletion jobs are being executed across the stack. At this point, the deletion cannot be canceled.
Secondary CompletedSECONDARY_COMPLETEDErasure only: deletion request has been successfully completed in full.

DSRs are received differently depending on whether the request is coming directly from a data subject, or whether it has been received by one of your data processors and is being forwarded to you.

When a data processor receives a DSR and has confirmed that it is coming from one of their customers, they will forward the DSR to your organization. As opposed to requests coming in through the Privacy Center, DSRs of this type can be 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 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, Transcend will export downloadable files.

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, and end users, or "data subjects," can access, preview, and download their data directly in the Privacy Center.

Request Origin Types

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

LabelEnumDescription
APIAPIThe privacy request 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 well-equipped to be fulfilled. During this step Transcend runs a set of customizable checks which include the following, and can be edited in the Admin Dashboard:

Currently, the most common way to set up a preflight check is to bind a webhook. For more information, review the API reference and enrichment webhook guides.

In order to fully process the DSR, Transcend next fans out the request and looks up the user’s data in all the different relevant systems (i.e., data silos) in parallel. 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 which systems you are still waiting on for a given DSR by going to the "Integrations" tab of that request in the Admin Dashboard.

In the case of troubleshooting systems, we normally recommend investigating and fixing issues as soon as possible to ensure that your organization is still within compliance of relevant privacy laws. 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. It is also common to switch a request to “Silent Mode” to disable future emails from being sent to the data subject, which allows Transcend to retry the errors until the issue is fixed, and the request can properly complete.

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 in the “Email Templates” section of the Admin Dashboard. In the case of erasure requests, you will receive a confirmation that the data erasure is complete.