Handle Privacy Requests in Privacy Center
Learning Objectives
After completing this unit, you’ll be able to:
- Identify how to handle individual privacy requests in Salesforce Privacy Center.
- Create and run a right to be forgotten policy.
- Create and run a data subject access request policy.
Introduction
In this unit, you explore how Privacy Center handles privacy requests, the privacy principles that Privacy Center can assist you with, as well as the data request access lifecycle.
Data Subject Request Compliance in Privacy Center
Privacy Center can directly assist you with the following principles that are common in many data privacy statutes.
Data portability: An individual’s right to ask a controller to provide their personal data in a structured, commonly used, and machine-readable format. For example, the information can be transmitted to the individual in a CSV or JSON file.
Right to erasure, or the right to be forgotten (RTBF): An individual’s right to request that a data controller delete or remove their personal data in situations when the data is no longer needed for the original purpose and when the data subject withdraws consent, or when the data subject objects to the processing and the controller has no overriding legitimate interest in the processing.
Right to opt out: An individual’s right at any time to tell businesses to stop selling their personal information.
Now, let’s see how Privacy Center can help you manage the entire data access request lifecycle.
What Is the Data Subject Request Lifecycle?
When a company receives data subject access requests, they need to ensure they receive, verify, execute, and respond to all requests accurately and in a timely fashion. We go through these four steps one at a time, and talk about how you might use Privacy Center to help you manage the lifecycle.
Receive
The receive step occurs when you receive a request from a data subject. Privacy Center lets you track requests with the Privacy Request object. Since every company is unique, this object is flexible by design, and you can customize it to match your internal processes. For example, you might need to track compliance with industry or regional privacy requirements.
Matt built out the Privacy Request object to ensure that Cumulus meets its requirement to process requests within 30 days. As he addresses the request, he updates the relevant fields on the record such as Status, Start Date, and Time of the request.
Verify
The verify step confirms that the requestor is indeed the named data subject, the request is valid, and the data doesn’t have a legal or other hold. As in the receive stage, you establish verification steps according to your org’s needs.
For example, Cumulus Cloud needs to confirm the validity of each request it receives and ensure that the data doesn’t have legal or operational holds before complying with the request. So Matt builds out the Privacy Request object to track the approval status of verifications.
As we mentioned, the process is customizable. There are many ways in which businesses might authenticate a Privacy Center request’s validity, for example through email or a portal.
Execute
The execute step addresses the request with the appropriate type of policy.
For Cumulus Cloud, once its verification process is complete, it can process the request. Depending on the nature of the request, Cumulus Cloud can run different policies. If the request comes from a data subject who wants a copy of their data, the company runs a portability policy. If the subject wants masking or erasure, Cumulus Cloud can run an RBTF policy. (More on how Cumulus Cloud set up these policies in a moment.) While this is fairly simple for Cumulus Cloud, some businesses can have more complex data request situations, such as external vendors who handle managing data on their behalf.
Respond
The respond step notifies the data subject that their request was completed and shares any relevant files the subject requested, or tells the subject why the request wasn't processed.
For the respond step, Cumulus shares a URL link to a PDF file containing the information that the data subject requested.
Privacy Holds
If there's ongoing litigation or an active audit, companies are often obligated to preserve any relevant information and prevent it from getting deleted or anonymized. The Privacy Hold and Hold Reasons allow you to mark Individual, Person Account, Lead, Contact, or User records as being on hold, and to document the reason for the hold. You use this information in Privacy Policy filters to block records from being processed.
Privacy Holds ensure that sensitive data remains intact while providing transparency and control over its lifecycle.
Portability Policies and Right to Be Forgotten Policies
Now let’s go back to the execute step of the data access request lifecycle, and see how Matt uses two Privacy Center features to help Cumulus Cloud honor customer data requests.
-
Right to be forgotten (RTBF) policies honor customer requests by deleting or masking their data in specific records.
-
Portability policies compile and deliver personal data to customers who make data subject access requests.
Create a Right to Be Forgotten Policy
When Matt sets out to create an RTBF policy, his first step is to define the relevant customer information to process for deletion.
As we mentioned previously, setting up an RTBF policy in Privacy Center is similar to creating a data management policy. But there’s one important difference: You can choose only one top-level object for data portability and RTBF requests. This is because RTBF requests are tied to a single human through a record ID, and not a filter. Even so, RTBF policies can process a granularly defined personally identifiable information (PII) footprint of data by supporting child-object and cross-object queries.
To create an RTBF policy, Matt:
- Defines a parent object (for example, an Individual object) in the RTBF Requests tab.
- Includes multiple levels of related child objects. For example, he selects the Individual object as the parent object, and then packages any Person Account, Contact, Lead, User, and related records.
As a best practice, test your RTBF policy in a sandbox with data so you understand the full impact of the policy before implementing it in your organization.
Respond to Right to Be Forgotten Requests
Matt can process individual right to be forgotten requests from the RTBF Request tab in Privacy Center, or he can set up the RTBF daily job to run requests automatically. If he’s using the Privacy Request object, he can also track the progress of his response there, using Status, Date and any other custom fields he’s set up.
Create a Portability Policy
Next, Matt gets to work defining a portability policy. This policy provides a copy of the data subject’s PII data and generates custom files in response to a data subject access request (DSAR).
To create a portability policy, Matt:
- Defines a parent object.
- Includes multiple levels of related child objects as needed.
Respond to Data Subject Access Requests (DSAR) for Portability
Once Matt sets up a portability policy, it’s easy for Cumulus Cloud to provide individual customers with a copy of their personal data, if they request it. Here’s how.
- Select the portability policy you want to run from DSAR Policy Manager in Setup.
- Enter a record ID (for example, an individual record ID) to generate the PII file.
- Access the JSON file using the link in the Portability Log in Setup for 60 days.
- If using the Privacy Request object, track the status of the response there.
Note: Your organization’s specific requirements determine how you communicate and send portability files to your customer. This is because retrieving DSAR requests depends on how your organization receives that request to begin with.
Sum It Up
In this unit, you learned about the Privacy Center’s data access request lifecycle, its Privacy Hold features, and how you can use Privacy Center to comply with privacy principles. You also saw how to create RTBF policies. Now it’s time to take the last quiz and earn a shiny new badge!