A Data Subject Request (DSR) is the series of rights a user has to their data in any system. There are several different types of data subject rights, and these will vary by region and regulation.
This article dives into:
- Submitting a DSR via the Ethyca Privacy Center
- Managing the DSR lifecycle in your Control Panel
- Approving a Request
- Denying a Request
- Flagging Users with Duplicate Requests
- Processing a Subject Request
- Filtering and Sorting Best Practices
- Troubleshooting an Errored Request
- Approving Multiple Requests
- Subject Request Admin Glossary
Within your Ethyca Privacy Center, a subject can put in a request download their data, delete their data, and manage their consent settings.
For additional detail around each request, please see below:
|Download Your Data or Subject Access Request (SAR)||A request to view the data the business holds on an individual.|
|Delete Your Data or Right to Forget (RTF)||A request to scrub all the data a business holds on the individual.|
|Consent||Under GDPR, a request to opt into different processing activities (or data use cases). Under CCPA, a request to opt-out of all sales of data to 3rd parties ("Do Not Sell My Personal Information")|
After receiving a request, you will need to validate the data subject's identity. Ethyca takes care of this step for you! After the subject has selected the action they would like to take, the identity verification process begins with a pop-up asking for an email address to verify their identity. For a recap of the end-to-end consumer experience, click here.
After a subject puts in their request in your Privacy Center and completes the identity verification process, the Download Your Data and Delete Your Data requests will be visible in your Control Panel's Subject Request Admin section. For information regarding Consent Management click here."
Once the data subject request is logged in the "For Review" queue, Ethyca sets the time to complete the request to 45 days.
It is important to note SLA's differ across jurisdictions. For example, under the CCPA, a business has 45 days to fulfill a request, while under GPDR, a business has 30 days. We recommend setting a business-wide SLA to simplify the data management process.
Within the Control Panel, you have the option of approving or denying a request.
Once you click "Yes"you will receive the prompt depicted below. In order to move forward with the approval, you will want to select "Confirm" to complete the request approval.
Once you click "Confirm" you will be prompted again to "Approve and Skip Email" or "Approve". Ethyca typically sends an email on completing of the data subject request processing. If you'd like the email to send automatically select the green "Approve" button. If you'd like to manage email communication outside of Ethyca, select the "Approve and Skip Email" button.
After your team has approve a subject's request, it will move to the "Processing" tab after your team has approved this user to access their data. "Processing" means that Ethyca's automated data subject request engine is working on fulfilling the request and generating a response. Once that process is complete, the user will be sent a copy of this data via email and the request will be moved to the "Complete" tab.
If you choose to deny a request, you will want to select "No" in the status column. When denying a request, you will be prompted to provide a reason for denying the request in the "Note" field provided. This is typically due to the user's details not being found in your company's databases or if a request is deemed to be beyond the scope of what is required to satisfy data privacy law compliance. In the "Rejected" tab, you can view all requests that were denied by your business.
CCPA requires a business to include the basis for the denial of the request if the request is denied in whole or in part, so we also store this information in your Reports section for record keeping purposes.
Whatever you write in the Note field will be included in the email response back to the user, so you want to make sure this language is client-facing.
Under the CCPA, a business is not obligated to fulfill information requests for the same consumer more than twice in a 12-month period (note: there are no limits on deletion and do not sell requests). While, under the LGPD and GDPR, there's no limit to number of requests a subject can make.
We make this visible in the "For Review" column where you will find a warning symbol present next to a customer's email when the request has already been processed and/or approved within the past 12 months. If you hover over the warning symbol, it will read: "This is a duplicate request". From there, you can determine as a business if you will move forward with approving or denying the request.
The Processing tab of the Subject Request Management section allows you to see which Subject Requests are actively making the corresponding requests and queries to either retrieve or delete subject data. The need for a Control Panel user to go in and manually process a Subject Request, depends on the type of integrations you have configured within the Control Panel. See our article on "Automated and Manual Subject Request Processing" for an overview of these types and how that affects the experience when processing Subject Requests. The table below summarizes the experience at a high-level:
Type of Connections configured
Subject Request Processing Experience
Automatic Integrations + Atlas Connections
Once the Subject Request is approved, the Ethyca platform will automatically fulfill this request by leveraging the Automatic Integrations that have been set up in the Integrations section of the Ethyca application AND the connections that have been set up in Atlas.
This may take some time depending on how much data the Ethyca connections have to sift through to perform the necessary actions.
Only Manual Integrations
Once the Subject Request is approved, , the Ethyca platform will require a Control Panel user to enter data into the Subject Request on the Processing Tab of the Subject Request management area of the application.
A combination of both Automatic and Manual Integrations
Here is where you will be introduced to the Hybrid Subject Request where the Ethyca Platform will automatically process data for Automatic Integrations and will also require a Control Panel user to enter data into the Subject Request on the Processing Tab of the Subject Request management area of the application.
Only Atlas Connections
If there are only Atlas connections set up and no Integrations to third party apps, then only Atlas will run to either retrieve or delete (according to your designated masking strategy) data to fulfill the request.
Please see the following articles for more information:
Across each tab in the Subject Request Management section, you can both Filter By and Sort through any of the available columns.
Click on any of the options in the Navigation Bar (e.g. User ID, Type) to begin sorting through requests. Some available options for sorting include:
- Sorting by the User ID column, so your subjects appear in alphabetical order
- Sorting by Type (SAR or Right to Forget)
- Sorting by Timestamp and Time to Complete
- Sorting by Requested Timestamp
- Sorting by Approved By Timestamp
- Sorting by Rejected By Timestamp
To filter, simply type into the "Filter By" box with any of the word, string, number, etc that would be helpful for managing requests. For example:
- Filtering by any subject's email address in the User id column
- Filtering by "SAR" to only see subject access requests
- Filtering by "Right to Forget" to only see erasure requests
- Filtering by Date e.g. 02/02
- Filtering by the business user who approved the request
- Filtering by the business user who denied the request
Pro tip: If a subject puts in multiple requests (e.g. Right to Forget and SAR), we'd recommend approving the SAR first so all personal data is returned to the user and then processing the Right to Forget, so subsequently their data is removed. If you approve the Right to Forget first, no data would be returned to the subject in the the SAR download package. Sort by "Type" or filter by "SAR" to streamline this process!
If for some reason the data subject request failed, it will automatically populate in the "Error" tab.
In order to view more detail on the error, you can open drawer to the left of the User ID to see the exact error log.
Once you have determined the cause of the error and resolved the issue, you can go ahead and reprocess the request by clicking on the circular arrow highlighted below.
You will then get the prompt: "Are you sure you'd like to retry this Subject Request?" and, once confirmed, the request will go back into the "Processing" queue.
Looking to approve multiple data subject requests at one time? You can do so in two ways:
1. Select User ID at the top of the table to bulk approve all subject requests in your "For Review" queue
2. Or if you would like to approve requests individually, select the check-box to the left of the User IDs you wish to approve
Looking to view the details of a subject request that has been processed? You can do so by selecting the View icon in the Completed Tab.
This will take you to a detail view that summarizes what happened throughout this request.
The table below summarizes the terms that are available on this screen:
Subject Request ID
Unique identifier associated with this individual subject request
The username of the Control Panel user who Approved or Rejected this Subject Request.
The timestamp of when the Control Panel user Approved or Rejected this Subject Request.
For Subject Requests that require manual inputs from custom integrations, a Control Panel user must ensure that any manual data is entered and the Subject Request is completed/submitted. This field represents the username of the Control Panel user who submitted the request.
For Subject Requests that require manual inputs from manual integrations, a Control Panel user must ensure that any manual data is entered and the Subject Request is completed/submitted. This field represents the timestamp that the Control Panel user submitted the request.
The timestamp of when the Subject Request officially finished processing.
This field is included and different than the Submitted At timestamp because some automated integrations take time to complete, which indicates that the Subject Request could finish processing at a different time then when manual data was entered.
The custom name of either the Manual or Automatic integration that was accessed to complete this subject request.
The name of the third party application that was accessed to complete this subject request.
Data Entered By
In the case of manual inputs for manual-type integrations, this represents the username of the Control Panel user who entered in the subject's data.
Data Entered At
In the case of manual inputs for manual-type integrations, this represents the timestamp that the Control Panel user entered in the subject's data.
The status of the automatic-type integrations
Each stage of the Subject Request lifecycle will include a mix of the following terms described in the table below:
|Approve/Status||An option to "Yes" approve the subject requests or "No" deny the subject requests (this will require a customer-facing description)|
|Approved By||The email address of internal user who approved the request|
|Complete||A list of completed requests along with details around approvals|
|Received On||The date and time at which the subject's request was made (in the timezone you're in)|
|Approved On||The date and time at which the subject's request was approved (in the timezone you're in)|
|Error||A list of error'd requests along with an error message and option to Reprocess the request|
|For Review||A list of all pending subject requests|
|Processing||A list of subject requests currently processing in the queue prior to completing. Here you can see if the request is "In Integration" or "In Atlas"|
|Reason||The customer-facing reason for which the subject's request was denied|
|Rejected||A list of denied requests along with details around who denied the request and why|
|Rejected By||The email address of internal user who denied the request|
|Rejected On||The date and time at which the subject's request was denied (in the timezone you're in)|
|Reprocess||The option to re-run the request|
|Status||Current data retrieval status|
|Time to Complete||A 45 day countdown to the requests' due date|
|Type||An Erasure ("Delete Your Data") and Access ("Download Your Data) request|
|User Email||The subject's email address|
|ID||The unique identifier associated with this Subject Request|
If you have any questions regarding the data subject approval process, please contact [email protected].
Updated 8 months ago