Privacy rights¶

A privacy rights workflow can help your organization stay in compliance with data protection and privacy regulations, such as those required by California Consumer Privacy Act (CCPA) or General Data Protection Regulation (GDPR).

The California Consumer Privacy Act (CCPA) is a law that covers data protection and privacy in the state of California. It gives control to individuals over their personal data and addresses the transfer of personal data, including providing for the ability to request removal of data.
The General Data Protection Regulation (GDPR) is a law that covers data protection and privacy in the European Union (EU) and the European Economic Area (EEA). It gives control to individuals over their personal data and addresses the transfer of personal data outside the EU and EEA areas. GDPR simplifies the regulatory environment for international business by unifying regulation within the EU.
The Australian Privacy Principles (APP) is a law that covers data protection and privacy in Australia. It governs a broad set of standards, including rights and obligations around the collection, use and disclosure of personal information, the integrity and correction of personal information, and the rights of individuals to access their personal information.

This topic describes how to configure Amperity to support a self-service privacy rights workflow that deletes consumer profile data based on inbound delete requests and requested compliance actions.

Note

General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA) compliance is the obligation of each customer, including interpreting and determining how to comply with each request made by a user. As such, each customer must define the process by which inbound requests for General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA) compliance are made available to Amperity.

Each customer is encouraged to seek legal counsel regarding California Consumer Privacy Act (CCPA) compliance and should not rely solely on General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA) workflows within Amperity to ensure that compliance.

Important

This topic does not constitute legal advice to third parties regarding General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA) compliance, nor does it imply that steps taken by Amperity will satisfy these compliance requirements.

Customers are encouraged to seek legal counsel regarding General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA) compliance and should not rely solely on Amperity for compliance.

Request types¶

You can configure Amperity to support the following compliance actions:

Respond to a data subject access request (DSAR)

Note

A data subject access request (DSAR) is a written request made by an individual to ask for their data to be handled according to General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA) regulations. A Data Subject Access Request (DSAR) requires a response within a pre-defined time window, typically 30 days.
Delete rows of records
Delete personally identifiable information (PII) from rows of records

Important

Amperity deletes data when requested, but does not maintain a list of prior delete actions. Amperity is unaware when previously deleted customer records re-enter the system.

Your brand should take steps to ensure that your upstream processes have completed their own delete actions before allowing those sources to provide updated data to Amperity.

Request strategies¶

You can configure compliance actions to support the following request strategies:

Find all rows that exactly match the compliance request.
Find all rows that exactly match the compliance request along with any row in a stitched table that shares an Amperity ID with those records.

Important

You may wish to use Amperity to identify which records belong to a customer. If the strategy field is set to connected_pii, records are connected by the Amperity ID using probabilistic Stitch. The detailed report contains those records. Send these results to your downstream workflows to locate data that should be deleted from other systems.

Enable privacy rights workflows¶

A privacy rights workflow requires the following steps:

Configure inbound requests table.
Apply semantic tags to tables with desired deletes.
Create linkage tables if necessary.

Inbound requests table¶

An inbound request table contains information about compliance requests. It must contain at least one field that is used to identify matching records: this is most commonly email address, but phone number, address, and custom fields such as a customer key or loyalty ID can also be used.

Note

If multiple identification fields exist, they are treated as though they are separate requests, identifying source domain records that can be matched to ANY of the identification fields.

Note

An address group is a single entity. A compliance action must match all fields within the address group: address, address2, city, state, postal, and country. It is important for addresses in incoming data to be standardized before they can be used for matching in compliance requests.

It also contains information about the request type and request strategy.

Tip

You may use a custom domain table to transform an inbound request table into the needed format. If you intend to use only a single request_type or request_strategy, those can be hard-coded in the custom domain table, rather than be included as part of the inbound request.

Inbound request table columns

An inbound requests table may have the following columns. compliance/request- semantics are used to identify the fields.

Column	Description
id	Required Semantic tag: compliance/request-id A unique identifier for an inbound request. This identifier is used for validation purposes, allowing compliance actions to be easily linked to specific requests.
type	Required Semantic tag: compliance/request-type The request type for the compliance action. May be one of: dsar Default. Generate a report without deleting data. delete Delete rows that are found by the request strategy. delete_pii Delete only personally identifiable information (PII) from rows that are found by the request strategy. Important The delete_pii request type will only delete columns that are tagged with the compliance/pii semantic tag.
strategy	Required Semantic tag: compliance/request-strategy The request strategy for the compliance action. May be one of: exact Default. Find all rows that exactly match the compliance request. connected_pii Find all rows that exactly match the compliance request along with any row in a stitched table that shares an Amperity ID with those records.
email	Optional Semantic tag: compliance/request-email Find all records that match an email address. This action is case-insensitive. The values in this field will be checked against any source table that has the email semantic tag.
phone	Optional Semantic tag: compliance/request-phone Find all records that match a phone number. The values in this field will be checked against any source table that has the phone semantic tag.
address	Optional Semantic tags: compliance/request-address compliance/request-address2 compliance/request-city compliance/request-state compliance/request-postal compliance/request-country The values in these fields will be checked against any source table that has the address, address2, city, state, postal, and/or country semantic tags. If a source table only has some of these values tagged, the missing values will be treated as NULL. Note An address group contains multiple fields, but is a single entity for a compliance action. In order to match to records in source tables, ALL values must match. Address standardization should be applied upstream of Amperity so that address can be reliably used to identify source records.
custom-key	Optional Semantic tag: compliance/request-custom-key Find all records that match a custom value. This action is case-insensitive. The values in this field will be checked against any source table that has the compliance/custom-key semantic tag.

Apply semantic tags source tables¶

Semantic tags are used to identify records and fields eligible for compliance actions.

Identify records eligible for compliance actions¶

Inbound requests must include at least one field that can be used to identify records belonging to a person, such as email. If this field is tagged with the compliance/request-email semantic, it will be checked against any source table that has a field tagged with the email semantic.

In addition to email, phone number and physical address can be used to identify records belonging to a person.

Note

An address group contains multiple fields, but is a single entity for a compliance action. In order to match to records in source tables, ALL values must match. Address standardization should be applied upstream of Amperity so that address can be reliably used to identify source records.

Custom fields can also be used to identify records. If the inbound request table is tagged with the compliance/request-custom-key semantic, the values in there will be checked against any source table that has a field tagged with the compliance/custom-field semantic.

Identify fields to delete¶

Note

This section only applies if the delete_pii request type is used.

The delete request type acts on entire rows of source tables, but it is possible to only delete PII from a record, while leaving the rest of the data intact.

Any field that is tagged with the compliance/pii semantic will be replaced with NULL if its record is eligible for compliance actions and an inbound request with the delete_pii request type is ingested.

Create linkage tables¶

A linkage table is used to trace records in a custom domain table back to their corresponding source table records so that privacy compliance actions can be applied.

If a compliance request cannot be directly linked to a source table, but can be linked to a custom domain table, create a linkage table to identify the source table records and ensure compliance actions are applied to them.

To add a linkage table

Open the Sources page.
Under Custom domain tables open the menu for a custom domain table that contains email addresses, phone numbers, and/or physical addresses that may be the subject of a DSAR or delete request, and then select Create linkage table.
Optional: Customize linkage table.

Important

The default linkage table will connect back to all source tables that are referenced by the custom domain table. This may cause too many records to be indicated as subject to compliance. For example: if the custom domain table references a mapping file, its mapping record may be subject to deletion even if it does not contain PII and can be applied to many people.
Click Next.

Note

Semantic tags for the data source and primary keys are applied automatically and should not be modified.
Click Activate.

Note

Linkage tables identify which source table records were used to create a custom domain table record. They do not trace individual fields, so compliance/pii semantic tags should be applied directly to the source tables, not on the custom domain tables, if the delete_pii compliance type is used.

Reports tables¶

Amperity generates the following reports tables as part of a Stitch run. Each table contain the results of the most recent privacy rights workflow. These tables may be empty when no requests were made.

Unified Compliance Overview¶

The Unified Compliance Overview table contains an overview of the results of data subject access requests (DSAR) and customer delete requests, including the number of records found, the time at which the request was completed, and the type of request.

The Unified Compliance Overview table contains the following columns:

Column name	Data type	Description
Request Datasource	String	The location (database and table) from which the request to find matching records originated.
Record Completion Date	Datetime	A timestamp that indicates when the request was completed.
Request ID	String	An identifier for the request.
Request Type	String	The request type for the compliance action. May be one of: delete, delete_pii, or dsar.
Request Strategy	String	The request strategy for the compliance action. May be one of: exact or connected_pii.
Request Email	String	Optional The email address used to match to source table records, if provided.
Request Phone	String	Optional The phone number used to match to source table records, if provided.
Request Address	String	Optional The street address used as part of an address group to match to source table records, if provided.
Request Address2	String	Optional The the address2 used as part of an address group to match to source table records, if provided.
Request City	String	Optional The city used as part of an address group to match to source table records, if provided.
Request State	String	Optional The state used as part of an address group to match to source table records, if provided.
Request Postal	String	Optional The postal code used as part of an address group to match to source table records, if provided.
Request Country	String	Optional The country used as part of an address group to match to source table records, if provided.
Request Custom Key	String	Optional The custom key used to match to source table records, if provided.
Rows Found	String	The number of matching records that were discovered by the request.

Unified Compliance¶

The Unified Compliance table supports privacy rights workflows and contains the search results for data subject access requests (DSAR) and customer delete requests. A row is added to the the Unified Compliance table for each matching record.

The Unified Compliance table contains the following columns:

Column name	Data type	Description
Request Datasource	String	The location (database and table) from which the request to find matching records originated.
Request ID	Integer	An identifier for the request to find matching records.
Request Type	String	The request type for the compliance action. May be one of: delete, delete_pii, or dsar.
Request Strategy	String	The request strategy for the compliance action. May be one of: exact or connected_pii.
Request Semantic	String	The type of PII used to search for matching records. For example: email, address, or phone.
Request Semantic Value	String	The value that was used to search for matching records. For example: paul.jackson@amperity.com.
Amperity ID	String	The unique identifier that is assigned to clusters of customer records that all represent the same individual. The Amperity ID does not replace primary and foreign keys, but exists alongside them within unified profiles.
Datasource	String	The location (database and table) in which the matched record was found.
PK	String	The primary key for the matched record.
PII columms	String	A series of column names. Each added PII column matches the name of a column in which matching records were found.