
Transcend Consent Management includes the ability to define consent experiences. Consent experiences are a mapping of consent banners and consent purposes based on a site visitor's location. In this way, consent experiences let you select the consent banner and consent purposes for relevant privacy regimes, and map them to geographical regions. This allows for flexibility to decide which consent rights to give site visitors in different locations.

## Elements of Regional Consent Experiences

Consent experiences can be thought of as a way to group, define and configure a set of privacy rights a website user should have. Consent experiences are often synonymous with privacy regimes, like GDPR, CPRA, etc., where the experience groups display, banner and consent choices accordingly and can be mapped to desired geographical regions.

It's worth noting that while consent experiences commonly represent a legal privacy regime, that's not the only use case. For example, it's also possible to define the experience for users that don't fall under any legal privacy regime, or don't have any legal consent rights. Consent experiences are extensible and flexible to meet a variety of use cases.

Consent Regional Experiences include many configuration options. The table below explains each setting and how it contributes to the experience.

| Experience Attribute                | Description                                                                                                                                                                                                                                                                                   | Example Use Case                                                                                                                                                                                                                                                                                                                                                                                                                  |
| ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Name                                | The name of the Consent Experience. This is required.                                                                                                                                                                                                                                         | A common use is to define consent experiences for each legal privacy regime that should be supported. Naming consent experiences `GDPR` and `CPRA` are common examples.                                                                                                                                                                                                                                                           |
| In/Not In                           | The In/Not In setting applies for the regions, languages, and timezones settings. The setting is used to denote whether the defined region(s), language and timezone should be included or excluded for the consent experience. This is required.                                             | As an example, this setting set to `Not in` with a region `California` would mean the consent experience would apply to website visitors that are not in California.                                                                                                                                                                                                                                                              |
| Region                              | The geographical locations this experience applies to. A user's geographical location is inferred by their IP address. This is required.                                                                                                                                                      | As an example, let's take a Consent Experience called `CPRA`. The region could be set to include California, as well as any other regions where users should have a CPRA-experience.                                                                                                                                                                                                                                              |
| Languages                           | The browser languages this experience applies for. When left empty, the site visitor's browser language will not factor in when resolving which consent experience to show. This is optional.                                                                                                 | This is a helpful setting for GDPR-like experiences where there may be an obligation to give EU residents the GDPR experience, even when they are not physically in Europe. In the case where an EU resident is traveling abroad, their timezone and IP address will not show them to be in the EU. Including the browser language can help to ensure EU residents are appropriately identified even when they are not in the EU. |
| Timezones                           | The time zones this experience applies for. The timezone is retrieved from the browser. This is optional.                                                                                                                                                                                     | Use the Timezone setting to further identify which consent experience to show a user.                                                                                                                                                                                                                                                                                                                                             |
| UI View State                       | The UI View State is the consent banner that will display to users for this experience. Select one of the out of the box banners according to the regime and desired experience. Use the `Hidden` option when no consent banner should be displayed automatically to users. This is required. | Different view states are designed for compliance in different regimes and according to different levels of risk tolerance. As an example, the `Notice and Do Not Sell` banner is designed for CPRA compliance.                                                                                                                                                                                                                   |
| Applicable Consent Purposes         | The consent purposes that are included for this experience. A site user will be given the option to opt-in or opt-out of the consent purposes listed here. Users will not be able to make a consent choice for purposes not included here.                                                    | As an example, if the only purpose listed is `SaleOfInfo`, users will only be able to opt-out or in to Sale of Info. This is an example use case for CCPA-like experiences.                                                                                                                                                                                                                                                       |
| Default Disallowed Consent Purposes | This setting defines which consent purposes a user will be _opted-out_ of by default. Consent purposes set in the `Applicable consent purposes` setting that are not included here will be treated as opt-in by default.                                                                      | Some legal privacy regimes require that a user give consent (opt-in) to applicable consent purposes before associated data flows and trackers are allowed to run on the site. This most notably applies for GDPR-like experiences.                                                                                                                                                                                                |
| Display Priority                    | This setting allows to define the priority of how similar experiences will display to users. If the user matches multiple experiences, the experience with the lower number will take precedence. This is required.                                                                           | A consent experience with a display priority of `1` will display over one with `2`, given that both experiences apply for the user.                                                                                                                                                                                                                                                                                               |
| Consent Expiry                      | The time in months after which a user's opt-in consent should be considered expired. Set to 0 to disable consent expiration.                                                                                                                                                                  | A consent experience with a consent expiry of `1` will consider collected consent expired after 1 month, at which point we will apply the configured Consent Expiry Behaviour (see below).                                                                                                                                                                                                                                        |
| Consent Expiry Behavior             | What happens when the user's consent expires.                                                                                                                                                                                                                                                 | `Prompt` will only trigger existing auto-prompt banners to show again, but will not change any consent preferences. `Reset Opt-Ins` only resets the consent preferences for aplicable purposes that were opted in.                                                                                                                                                                                                                |

### Resolving User Location

A website user's location is inferred from their IP address, and optionally their browser language and browser timezone. The IP address is used to identify if the user falls in one of the _regions_ mapped to a consent experience. Browser language and timezone settings are optional, but can be used to further identify when to show someone a consent experience. Transcend supports these additional options beyond IP address to locate someone for compliance with privacy laws that give consent rights to users beyond their current physical location. For example, under GDPR law, you may be required to provide the same consent experience to EU users even when they are not physically in the EU. Relying only on IP address to identify the user's location could leave compliance gaps in this example, but incorporating the user's browser language can help identify when EU users are not in the EU.

The _Region_ setting defined for a consent experience uses the website visitor's IP address to determine a match. If the consent experience includes settings for _browser language_ and _Timezone_, only one of three has to be matched for a user to be shown the consent experience. For example, if a consent experience has these settings and the user is identified as:

|                    | Region (Based on IP) | Browser Language     | Timezone                            |
| ------------------ | -------------------- | -------------------- | ----------------------------------- |
| Consent Experience | EU                   | French, German, etc. | N/A                                 |
| User               | US:California        | French               | Pacific Standard Time (Los Angeles) |

Then the user will be shown this consent experience, as they match at least one of the region/language/timezone settings.

## Default Regional Experiences

Transcend Consent’s default UI includes ready to use, compliant regional experiences. The table below shows the default experiences.

<DefaultRegionalExperiences />

The following default experiences are available out of the box: `GDPR`, `LGPD`, `nFADP`, `US_DNSS` and `Unknown`. The U.S. state specific experiences, `CPRA`, `CDPA`, `CPA` and `NEVADA_SB220` are also available, but are not automatically enabled given their overlap with U.S. Do Not Sell/Share (`US_DNSS`). These experiences can be enabled in the Transcend Dashboard Consent Management > Regional Experiences > Add Experience Form via Experience Presets.

### A Note on the Unknown (Default) Consent Experience

The default consent experience represents refers to the case when no defined consent experience applies for a user. This typically applies where no applicable privacy legal regime is detected for a user. This is also referred to as the "Unknown" consent experience. It's worth noting that _unknown_ doesn't mean that the user's location is unknown. In this case no Consent UI is shown by default. This is reflected in the table above for the “Unknown” experience.

## Creating Custom Consent Experiences

The default experiences can be customized and further configured from the out of the box settings. The consent experience attributes for default experiences can be adjusted directly in the Transcend Dashboard. The available view state options (consent banners) are available for preview [here](https://github.com/transcend-io/consent-manager-ui). New consent experiences can also be created to fit additional use cases in the Dashboard.

To create a new regional consent experience, navigate to the [Regional Consent Experiences](https://app.transcend.io/consent-manager/regional-experiences) page in the Transcend Dashboard and select _+ Add Experience_ and configure the experience attributes as desired.

Consent experiences can be edited in-line from the dashboard.


Consent Experiences


## What is Data Retention for DSRs?

Data Subject Requests need to collect personal information to process requests across several systems. To ensure compliance with data minimization practices and to improve the security of this personal data, Transcend allows customers to define a retention period for the data collected to process DSRs. After this retention period has elapsed, all personal information collected is fully deleted.

This page describes how our DSR retention schedules work and helps you appropriately configure them for your needs.

![DSR Automation > Request Settings > Data Retention](/public/docs/screenshot/2024-07-16-dsr-automation-retention-schedule-main.png)

## Operation

There are multiple options for how to process the request data once the retention period has elapsed.

![DSR Automation > Request Settings > Data Retention Dropdown](/public/docs/2024-07-16-dsr-automation-retention-schedule-operation-drop-down.png)

1. **Delete requests and identifiers** - Deletes the record of the request and all associated data.
2. **Delete only identifiers** - Retains the request record but deletes the related personal information.
3. **Do not delete any data** - Does not delete any record or data.

Your selected operation will be performed on any request that falls outside of the retention period that you define below.

## Retention Period

You can define your retention period by entering the number of days to wait before the deletion operation is performed. Once a day, the system will check your platform for any requests that fall outside of the retention window. For each request older than the defined period, the selected operation above will be performed.

> Note that by default, all accounts that pre-date this feature have their retention period set to 5 years, and any new organization created after this release will have a retention period of 3 years. These periods are preset but can be modified as needed.

You have now successfully configured your data retention period for DSRs.


Data Subject Request Retention Schedules


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.

Transcend DSR Automation fully handles the end-to-end process of a data subject request: receiving the request, authenticating requestors, running preflight checks to confirm the request can be processed, and executing an export or deletion job across all data systems. It also synchronizes user opt-outs across disparate tooling (such as syncing unsubscribes across email marketing systems).

Transcend DSR Automation works with every data system. For unstructured stores, like Slack, Transcend scans for personal data and helps you redact messages in bulk. 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 catalog of pre-built connectors, you can quickly encode these workflows across your backend and vendor stack. They run with precision and can execute autonomously. Unless you have a manual step in your process, such as an admin approval, you can expect Transcend to execute your requests in minutes.

> ### Types of DSR Automation
>
> The detailed list of data subject request types supported by Transcend can be found [here](/_docs/dsr-automation/configuring-requests/data-subject-requests.mdx#data-actions).

## DSR Lifecycle

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](/_docs/dsr-automation/overview.mdx#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](/_docs/dsr-automation/overview.mdx#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](/_docs/dsr-automation/overview.mdx#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](/_docs/dsr-automation/overview.mdx#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](/public/docs/screenshot/2023-11-29-dsr-incoming-requests-details-status.png)

### DSR Ingestion

Transcend can receive DSRs from a variety of methods including:

- [Transcend's DSR API](/_docs/dsr-automation/api-integration/using-the-api-for-data-subject-requests.mdx)
- [Self Service Privacy Center](/_docs/privacy-center/privacy-center.mdx)
- [Manually submit a Data Subject Request through the Admin Dashboard](/_docs/dsr-automation/processing-requests/submission.mdx)
- [Upload a CSV of Data Subject Requests through the Admin Dashboard](/_docs/dsr-automation/processing-requests/uploading-privacy-requests.mdx)
- [Forward from your support tool e.g. Zendesk](/_docs/dsr-automation/api-integration/webhook-in-zendesk.mdx)

We offer several methods of ingesting data subject requests, wether you are processing DSRs as a data processor, or a data controller. For more detail, refer to our [Data Processor vs Data Controller](/_docs/dsr-automation/data-processor-vs-data-controller.mdx) article.

### Preflight Jobs and Identity Enrichment

Before processing begins for a DSR, the DSR is validated by a series of [preflight jobs](/docs/api-reference/webhook/new-preflight-request-job) to ensure that it is legitimate and ready for processing. During this step Transcend runs a set of customizable checks. For more information, review the [Preflight Checks & Identity Enrichment](/_docs/dsr-automation/preflight-and-enrichment/preflight-and-identity-enrichment-overview.mdx) section of our documentation.

![Email Templates tab of the Admin Dashboard to customize communications with data subjects](/public/docs/screenshot/2023-12-14-dsr-email-templates.png)

### DSR Jobs

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.).

See the full list of DSR statuses [here](/_docs/dsr-automation/dsr-job-integration-statuses.mdx).

### Report Delivery

Once all jobs have completed and the request has been fulfilled, you can either serve the results via your [API](/_docs/dsr-automation/api-integration/using-the-api-for-data-subject-requests.mdx), or provide a downloadable report that is also accessible to the data subject via the [Privacy Center](/_docs/privacy-center/receiving-data-subject-requests.mdx). The data subject can be notified via [email](/_docs/dsr-automation/configuring-requests/email-templates.mdx), for which templates can be customized under "DSR Automation" > "Email Settings" > "[Email Templates](https://app.transcend.io/privacy-requests/email-settings/templates)” section of the Admin Dashboard.

![Email Templates tab of the Admin Dashboard to customize communications with data subjects](/public/docs/screenshot/2023-12-14-dsr-email-templates.png)

## General Troubleshooting

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](/public/docs/screenshot/2023-11-29-dsr-incoming-requests-new-request.png)


DSR Automation Overview


<>{frontMatter.excerpt}</>

![Transcend Pathfinder](/public/docs/product/pathfinder.svg)

## Pathfinder is currently in exclusive Beta. Please contact [pathfinder@transcend.io](mailto:pathfinder@transcend.io) if you would like learn more.

<TableOfContents tocEntries={tocEntries} />


Pathfinder


## Background

[Transcend's out-of-the-box Consent Implementation](/_docs/consent-management/configuration/consent-experiences.mdx) configuration provides a user experience for data subjects to provide their consent across the purposes: `Functional`, `Marketing`, `Analytics`, and `SaleOfInfo`.
These are the four most common consent preferences needed to comply with global laws like the GDPR, LGPD or CPRA.

This guide details how the default consent purposes can be extended with additional custom purposes that can enable users to manage a larger set of preferences that relate to your business.

Some common use cases include

1. Opt in/out of SMS, email, and/or push notifications
2. Opt in to newsletter or demo
3. Opt in/out of sensitive information (note: you may also choose to use the `Analytics` purpose for this use case)
4. Opt in/out of [SNAP Privacy Protection](https://www.federalregister.gov/documents/2011/05/16/2011-11924/supplemental-nutrition-assistance-program-privacy-protections-of-information-from-applicant) for session recording technologies.

In addition to the more standard use case, you can use custom purposes to achieve the following setups:

5. Always block a data flow, cookie, regardless of consent preferences.

- This can be done globally, or in a specific experience.
- An example of blocking a data flow in a specific experience could be blocking Google Analytics in specific EU countries that do not allow for Google Analytics.

See [here](/_docs/consent-management/reference/consent-use-cases.mdx) for a complete guide on this specific use case.

## Additional Reading

For step-by-step instructions on setting up custom consent purposes, refer to our [Configuring Custom Consent Purposes for Preference Management article](/_docs/preference-store/configuring-custom-purposes-for-preference-management.mdx).


Preference Management Overview


## Overview

The Privacy Center is a pre-built and custom-branded interface your end-users interact with to understand their personal data and make choices about it. It's a one-stop-shop where users can understand how their data is being used, access/erase/modify their data, view your privacy policy, and set any other privacy preference relevant to personal data. Users simply visit privacy._company_.com.

While the _Anatomy of Personal Data_ from the core [Concepts Guide](/_docs/overview/concepts.mdx) focuses on the way data is physically stored in your organization, which is relevant to our Data Privacy Infrastructure, _Data Presentation_ focuses on the way data is described to your end-users (data subjects) in the Privacy Center. While these sections can be read separately, their concepts are tightly bound.

## Data Presentation

The fields below describe the concepts relevant to displaying personal data back to your user (<GlossaryItem term="data subject" />). These concepts are purely cosmetic and have no bearing on your data systems.

### Data Practices

In the Privacy Center, Transcend presents data to data subjects in a way that is more refined than a raw representation of your systems. The ways in which you collect and process user data are collectively known as your Data Practices. This is the information that you inform a <GlossaryItem term="data subject" /> about in your [Privacy Center](/_docs/privacy-center/privacy-center.mdx) and privacy policy.

You can edit your Data Practices on the [Privacy Center →](https://app.transcend.io/privacy-requests/privacy-center) tab.

![The Privacy Center's configuration page, showing the data practices tab.](/public/docs/screenshot/2023-11-30-privacy-center-data-practices.png)

### Data Collections (the "Info We Collect")

Data collections are categories of personal data that you collect on a <GlossaryItem term="data subject" />. These are groupings of `datapoints` put in a more digestible format. For example, a set of `datapoints` called "clicks", "page views", and "visits" may be put in a Data Collection called "Analytics". These will be displayed on your [Privacy Center](/_docs/privacy-center/privacy-center.mdx) and are often already listed in your privacy policy.

We group Data Collections into three categories:

#### Info you give us

This is data that is given by the <GlossaryItem term="data subject" /> directly to your organization.

e.g., Support Tickets, Messages, Email, Address

#### Info we track

This is data that is tracked by you about the <GlossaryItem term="data subject" /> while they are interacting with your service.

e.g., Pages You View, IP Address

#### Info shared by others

This is data that is acquired from third parties about the <GlossaryItem term="data subject" />.

e.g., Employment information from LinkedIn, data enrichment from Clearbit

### Data Applications

Ways in which you use personal data are called Data Applications. They encode the intent for which you collect a certain category of data. Every Data Collection has a set of Data Applications.

We group Data Applications into two categories:

#### How we use it

These are ways in which you use that data within your organization.

e.g., Personalize your experience, Market to you, Securely identify you

#### Who we share it with

These are categories of people/organizations/processors that you share the data with. You can use your discretion whether you want to list specific vendors, or whether to group them into categories.

e.g., Companies we own, Partners, Amazon Web Services, Google Analytics


Privacy Center Concepts


In order to keep your Data Inventory up to date, Transcend automatically detects new data systems at your company, through our set of Silo Discovery plugins.

## Plugins

Transcend's Silo Discovery plugins are the easiest way to ensure your Data Inventory is both comprehensive and up-to-date on an ongoing basis. We’ve built plugins to detect new data systems as they appear in your organization—all you need to do is connect the plugin, turn on Silo Discovery, and we’ll begin scanning for systems.

Some examples of where Transcend can scan for new data systems:

- Your **single-sign-on provider** (like Okta) to detect data systems your team can sign in to.
- Your **cloud-hosting provider** (like AWS) to detect data systems like databases, buckets, and warehouses.
- Your **customer data platform** (like Segment) to detect your source and destination connections.
- Your **codebase** (like a JavaScript repo's `package.json`) to detect vendor SDKs.
- Your **websites** to detect new ad pixels, analytics tools, your monitoring stack, and any other client-side tracking technologies.

You can view the full list of integrations that support Silo Discovery in [Integrations](https://app.transcend.io/infrastructure/integrations/new?filters=%7B%22plugins%22%3A%5B%22DATA_SILO_DISCOVERY%22%5D%7D).

The authentication process may be different from system to system, but the controls for turning on Silo Discovery are the same. Let’s use [Okta](https://transcend.io/integration/okta) as an example.

### Plugin Concepts

There are two options for hooking your system up for Silo Discovery:

1. Transcend can either connect to a system directly and query it (**pull-based plugins**), or
2. You can query/scan your system yourself and upload the results to Transcend (**push-based plugins**).

An example of a **pull-based plugin** is our `Segment` integration. You can connect this integration and have Transcend query the Segment API to sync your Segment Connections to Transcend.

An example of a **push-based plugin** is our `JavaScript package.json` integration. Connecting this integration on Transcend will give you further instructions on how you can use our CLI tool to scan your JavaScript project dependencies for new data silos. Our CLI will scan for vendor SDKs in any `package.json` files it finds, and upload the entries to the Transcend backend to be classified. Using this approach, it's simple to integrate the Transcend CLI into your CI process.


Introduction to Plugins


## Introduction to Structured Discovery

![Transcend Structured Discovery](/public/docs/product/structured-discovery.svg)

Transcend Structured Discovery continuously detects and classifies all objects and properties inside a given database, moving you deeper in your company's mapping intelligence and giving your team unparalleled, real-time visibility. This feature operates by first scanning and discovering the schema of your data stores before classifying the identified datapoints.

## Introduction to Unstructured Discovery

![Transcend Unstructured Discovery](/public/docs/product/unstructured-discovery.svg)

Unstructured Discovery identifies and maps personal data within unstructured data stores. Unstructured data stores are those that don't have a predefined schema or order, such as file systems. This feature operates through a two-step process, whereby we first scan and discover the files in your unstructured data store, and then scan and classify the content of those files.


Structured and Unstructured Discovery Overviews


## Overview

Transcend's Web Auditor operates as a real user on your website. It uses a real web browser, records session data, and analyzes this data for compliance issues.

## Scan Details

Each Web Auditor scan utilizes an actual browser to visit your website and collect information.

These are some crucial points regarding how we conduct each scan:

- The scan is carried out from a data center in California
- A headless Chromium browser is used
- We imitate a user opting out of tracking by activating GPC and DNT signals in the browser.

For scans with different configurations, please contact your account manager.

## Interested in a Sample Scan?

If you haven't yet started using Web Auditor and want to test it, our accounts team is ready to provide a sample scan of your website. You can contact your account manager, or if you're not a Transcend customer yet, you can [contact us online](https://transcend.io/contact/?utm_source=docs&utm_medium=website&utm_campaign=).


Overviews & Concepts