The Data Map (Privacy Requests)

Your data map is an index of all the personal data in your organization. This includes your databases, SaaS tools, and offline data. You can configure your data map on the Data Map tab →.

This guide describes Transcend's data model. The first section, Anatomy of Personal Data, focuses on the way data is physically stored in your organization, which is relevant to our Data Privacy Infrastructure. The second section, Data Presentation, focuses on the way data is conceptually categorized, which is relevant to how we describe data to your end-users (data subjects) in the Privacy Center. While these sections can be read separately, their concepts are tightly bound.

Anatomy of Personal Data

The fields below describe the concepts relevant to retrieving personal data across your data systems.

Data Silos

A data map has a set of data silos. These are places in your organization where personal data is stored. A silo can be a database, SaaS tool, or any arbitrary data storage location, like a filing cabinet.

You can connect Data Silos → by adding them from our list of supported integrations.

Check out the section "Connecting Data Silos" to learn more:

Datapoints

A data silo contains a set of datapoints, which are labeled fields of data. (e.g. a data silo with HR data may contain the datapoints: Resume, GPA, Education).

We allow you to configure which datapoints are incorporated in an access request, erasure request, or any other request action.

In the context of...

  • A third party SaaS tool: one datapoint is usually the response of one API endpoint.
  • A database: one datapoint is usually one column or the result of a table join
  • Filing cabinet: one datapoint is one file (or zip of files) that is expected to be uploaded

Each datapoint is categorized according to a data collection. When a report is generated about a Data SubjectData Subject - This is a person whose data you control or process. In the context of GDPR, it's typically referring to European citizens. They do not include corporations, only natural persons., the files are displayed according to these data collections, not by data silo. Datapoints do not have types - they can be any arbitrary data, called a file.

Files

When responding to a Data Subject RequestData Subject Request - (DSR) This is a request by the data subject to access, erase, port, or rectify their personal data. It also includes objections to the processing of personal data and requests to restrict the processing of personal data., a file is uploaded for each datapoint. A file can be an actual file or any other type of data, like a number or boolean value. In other words, a file is an instance of a datapoint. These are encrypted, but you can decrypt the file contents for your inspection if you have the appropriate permissions.

Profiles

Sometimes, a data silo will have multiple entries for one person (for example, somebody has multiple accounts). So, a data silo has the concept of a profile. When there are multiple profiles found for a person in a given data silo, multiple profiles may be uploaded to Transcend during a Data Subject RequestData Subject Request - (DSR) This is a request by the data subject to access, erase, port, or rectify their personal data. It also includes objections to the processing of personal data and requests to restrict the processing of personal data.. Each profile contains a collection of files, and is uniquely keyed by a profile_id (such as a username).

In the context of...

  • A database: you may have a "users" table, keyed with a profile_id such as "username" or "email" or some other unique key.
  • A SaaS tool: (for example) Shopify collects shopper data on a model called "customers" that has a Shopify-specific unique shopper "id".

Identifiers

How do you look up a data subject? The primary keys to find a Data SubjectData Subject - This is a person whose data you control or process. In the context of GDPR, it's typically referring to European citizens. They do not include corporations, only natural persons. are called identifiers. These are values that can be used to deterministically look up data for a specific person. These identifiers must be a 1:1 mapping of identifier value to Data Subject. For example, you should not have a "userId" that maps to two different Data Subjects. In the future, we plan to support non-deterministic keys to someone's identity (i.e. a person's name is not always a direct lookup).

You can manage your organization's "Identifier Keys" in the Request Settings → tab.

When a new Data Subject RequestData Subject Request - (DSR) This is a request by the data subject to access, erase, port, or rectify their personal data. It also includes objections to the processing of personal data and requests to restrict the processing of personal data. comes in, Transcend will verify that the Data SubjectData Subject - This is a person whose data you control or process. In the context of GDPR, it's typically referring to European citizens. They do not include corporations, only natural persons. owns each identifier.

Some data silos will require different information to look up a data subject. For example, Shopify can lookup a Data Subject by their "email", but Shopify cannot lookup someone by your organization's native "userId". Transcend can enrich the provided identifiers to get a complete identity picture. This makes it possible for any data silo to find a Data Subject with the primary keys it needs.

Some identifiers we currently support are:

Email

Transcend can look up a Data SubjectData Subject - This is a person whose data you control or process. In the context of GDPR, it's typically referring to European citizens. They do not include corporations, only natural persons. by their email address. This is a commonly used identity key (identifier) in SaaS tools. Transcend has the ability to verify email ownership by sending that email a verification link. The Data SubjectData Subject - This is a person whose data you control or process. In the context of GDPR, it's typically referring to European citizens. They do not include corporations, only natural persons. will need to click on that link to verify they own the inbox and want their request to be processed.

Transcend also allows your organization to verify emails in your own manner. You can do this using Identity Enrichment or by using our DSR Submission API

Google Profile ID

If you use any of Google's products to process personal data (i.e. Google Analytics), they require a concept of a Google Profile Id which you can define native to your own organization. In the case of Google Analytics, you can erase a Data Subject's data by their googleProfileId.

Since this is custom to each implementation, in order for us to propagate requests to Google systems, you will have to either provide this value with the DSR Submission API or by using Identity Enrichment.

Custom

For all other custom identity keys that your organization uses, our custom identifier type is a catch-all which allows you to define any identifier. Some classic examples of these are username or userId.

🚧

Security Tip: Sign and verify identifiers with JWTs

Every time we verify an email, we will create a JWT that you can verify against when we notify your servers. This is our way of attesting that we verified a Data Subject to have access to an email inbox.

When you submit identifiers using the New DSR API or during Identity Enrichment, we recommend that you also sign these identifiers so that you can be certain that your data silos only trust identifiers that your internal authentication service has verified. In fact, if you only use identifiers that your systems have signed, you don't have to trust Transcend at all.

Read More

Core Identifier

The core identifier is a unique user ID derived from authentication. This may be an email or any arbitrary user ID of the data subject. It must be:

  • Verifiable - It can be verified through an identity verification (authentication) flow.
  • Unique - It relates to only one data subject.
  • Immutable - It is unchanging and always relates to only one data subject. For example, if a username can be changed in your platform, it may be an unsafe operation to search for data by username. An unchanging user ID is a better option.

Data Presentation

The fields below describe the concepts relevant to displaying personal data back to your user (Data SubjectData Subject - This is a person whose data you control or process. In the context of GDPR, it's typically referring to European citizens. They do not include corporations, only natural persons.). 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 Data SubjectData Subject - This is a person whose data you control or process. In the context of GDPR, it's typically referring to European citizens. They do not include corporations, only natural persons. about in your Privacy Center and privacy policy.

You can edit your Data Practices on the Privacy Center → tab.

Data Collections (the "Info We Collect")

Data collections are categories of personal data that you collect on a Data SubjectData Subject - This is a person whose data you control or process. In the context of GDPR, it's typically referring to European citizens. They do not include corporations, only natural persons.. 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 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 Data SubjectData Subject - This is a person whose data you control or process. In the context of GDPR, it's typically referring to European citizens. They do not include corporations, only natural persons. directly to your organization.

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

Info we track

This is data that is tracked by you about the Data SubjectData Subject - This is a person whose data you control or process. In the context of GDPR, it's typically referring to European citizens. They do not include corporations, only natural persons. 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 Data SubjectData Subject - This is a person whose data you control or process. In the context of GDPR, it's typically referring to European citizens. They do not include corporations, only natural persons..

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 as to 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