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 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 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.
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:
Delete
Respond to a data subject access request (DSAR)
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.
Note
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.
You should take steps to ensure that your downstream (and upstream) processes have completed their own delete actions before allowing those sources to provide updated data to Amperity.
You may wish to use Amperity to identify which records belong to a consumer. If the strategy field is set to connected_pii**, records appear that are connected through 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¶
The following steps describe how to enable a privacy rights workflow on your tenant:
Configure inbound requests¶
Inbound requests for compliance actions are provided to Amperity as a file that defines a list of unique email addresses. For each email address, a delete action and a compliance strategy are specified.
Supported file formats¶
You may use the following file formats to provide to Amperity a list of customers against which the privacy rights workflow will be applied:
CSV
JSON
TSV
The following example shows an inbound request in the form of a CSV file:
customer id,type,strategy,email
1,delete,email,justinc@amperity.com
2,delete_pii,connected_pii,pauljackson@amperity.com
3,dsar,email,johnsmith1984@amperity.com
Required fields¶
Each inbound request file must have a field that defines:
The unique ID for the inbound request.
Tip
Ensure that the compliance/request-id semantic tag is applied to the the field that contains the unique ID for the corresponding inbound request.
The action type values:
delete: Use this action type to delete data from all tables in which customer profile data was discovered.
delete_pii: Use this action type to delete the customer information that is marked as pii from all tables in which customer profile data was discovered.
dsar: Is the default value. Use this action type to identify inbound requests that are associated with a data subject access request (DSAR). A DSAR typically requires a response to be sent by a downstream workflow. This action generates reports, but does not delete data from Amperity tables.
Note
Customers can use the delete_pii action when they need to keep certain data on a row. For example, if they need to keep non-identifiable sales data.
Important
If the customer intends to do column-based deletion using the delete_pii action type, then they will need to apply the compliance/pii semantic tag to all fields in all tables that contain PII.
This semantic tag is required to support the delete_pii action type and is not used by the delete or dsar action types.
The strategy for this delete action. Possible values: email or connected_pii.
Use the email strategy to search against all rows in all tables where the email customer profile semantic tag is applied. The returned rows contain the matching email addresses; however they are case insensitive.
Important
The email customer profile (PII) semantic tag is primarily applied to tables that are input to Stitch, so that it can be used as during ID resolution.
However, email addresses may be found in tables that are not made available to Stitch. If the email customer profile (PII) semantic tag is added to these sources, such as for sources that contain orders or items, this will ensure those tables can be searched for compliance.
Use the connected_pii strategy to find all rows in all tables in which an email address matches exactly and also to all rows that share an Amperity ID with that email address.
The email address used to identify all of the customer records across all tables.
Configure non-stitched tables¶
Apply the email semantic tag to all columns in all tables in which customer email address values are located, even if a table is not made available to Stitch. This will ensure that all records in all tables are available to privacy rights delete PII or DSAR actions.
Important
A table will not be available to privacy rights delete PII or DSAR actions if one of the following events occurs:
The email semantic tag is not applied to the column in which email address values are located.
The table is input to Stitch with the connected_pii strategy enabled.
A linkage table has rows connected to a table that fits the scenarios listed above.
Run database¶
After compliance semantic tags have been applied to files associated with inbound requests and any necessary updates to customer profile semantic tags have been made, run your customer 360 database. This will generate a standard table named Unified_Compliance.
Unified_Compliance table¶
The Unified_Compliance table identifies all records across all tables that are configured for the privacy rights workflow that matched an email address in the inbound request file.
Important
The Unified_Compliance table may contain customer records that are not made available to Stitch.
The Unified_Coalesced table only contains records that are made available to Stitch.
When the privacy rights workflow identifies records to include in the Unified_Compliance table, those records are excluded from the Unified_Coalesced table and will not be available to any downstream process that depends on the Unified_Coalesced table.
The use of the Unified Compliance table to suppress data only works for delete requests. Once this suppression occurs, it will prevent consumers from being involved in any further marketing activity.
Add reports tables¶
After the delete processes is enabled, add the following tables to your customer 360 database:
Note
You will need to work with Amperity Support to enable the delete process.
Tip
If your privacy rights workflow has downstream dependencies, such as providing a DSAR response within a 30-day window, you can build queries against the report tables that return data to be sent to these downstream workflows.
Important
Customer profile data is stored in the Compliance_Detailed_Reports and Compliance_Overview_Reports tables until the next time the delete process is run. If your delete process follows the recommended frequency, the data in these tables is deleted on a weekly basis.
Overview reports table¶
The Compliance_Overview_Reports table contains a row for each inbound request that matched customer records, and then confirms the actions that were performed against those records.
Add this table as a passthrough and use the “Compliance_Overview_Reports” template.
Note
The Compliance_Overview_Reports table is available from the drop-down menu after the delete process has been enabled. Ask your Amperity Support representative to enable the delete process, after which you can add this table.
Detailed reports table¶
The Compliance_Detailed_Reports table contains a row for each record that was matched to an inbound request. Use this table to build queries that send data to downstream workflows, such as those that provide DSAR responses.
Add this table as a passthrough and use the “Compliance_Detailed_Reports” template.
Note
The Compliance_Detailed_Reports table is available from the drop-down menu after the delete process has been enabled. Ask your Amperity Support representative to enable the delete process, after which you can add this table.
Ad hoc or automated?¶
The privacy rights workflow can be run against files that are uploaded to Amperity ad hoc or by an automated process. Use the approach that fits best with your upstream workflow and the volume of individual delete actions that your organization expects to manage.
To upload files ad hoc, use the Load new data option for the feed, Truncate the table or multiple tables, and then upload the new file that contains the updated list of compliance actions.
To use an automated workflow, configure a courier and courier group to define the location from which the file can be pulled, and then define the frequency to occur at least one day before the delete action is performed by Amperity.
Apply to custom domain tables¶
A tenant may require the deletion of a record from a custom domain table. If there is no other configuration, the system can not delete items from the input tables that are used to create the custom domain table. Without any input table deletion, the custom domain table regenerates with the problematic records.
A custom domain table is a domain table that defines its schema using Spark SQL.