ID DataWeb supports integrating AXN Verify workflows with OneTrust "Data Subject Access Request (DSAR)" workflows. This allows you to verify the identity of requesters before providing them access to and/or deleting their data in compliance with GDPR, CCPA, CPRA, LGPD, and other privacy regulations.
Note: this Postman project is ubiquitous for all types of DSAR-integrated verification workflows; we've included the attributes necessary for verifying a user via MobileMatch.
1. The end user completes a data subject access request (DSAR) form via OneTrust.
2. OneTrust calls ID DataWeb's /token endpoint for authorization followed by the /email endpoint to generate and send the authorized identity verification link (for details on how to handle generating and sending the authorized identity verification link manually, see the "Manually Verifying Requests" section), including the following:
- Credential featuring the request ID and subtask ID. The credential is a non-sensitive unique identifier that A) is used by OneTrust at the end of the workflow to update the status of the request event and B) can be used within ID DataWeb's admin portal to track and review verification events.
- Email address that will be sent the authorized link. Note that this is the recipient email address and that an email address can be federated separately for verification. For additional details and considerations regarding requiring the user to use the email address registered to the account versus a current email address they have access to, see the Account Email Address vs. Current Email Address section.
- Email template that will be used when sending the authorized link, passed as an ID. Custom email templates can be created using HTML/CSS to seamlessly brand the user experience (and accommodate differing languages or content).
- Full name that will be pre-filled and locked within the authorized link. This is the minimum personal data that needs to be collected and federated from OneTrust in order to securely associate the verification event with the request event. The additional data necessary to verify users can be federated or collected within the verification workflow. For additional details and considerations regarding how and what PII can and should be collected, see the "Data Collection & Context" section.
3. The end user receives the email and clicks on the verification link, initiating the identity verification process and establishing their possession and control of that email at the same time. The verification workflow has a default 30 minute timeout period (customizable) that starts when the user clicks the link.
4. ID DataWeb posts the results of that identity verification process via webhook, including the credential. You can configure your webhook by creating and deploying a change from the admin console. Work with your OneTrust representative regarding the webhook URL, authorization token, and any encryption or response body formatting preferences.
5. OneTrust updates the status of the request using the request ID and subtask ID included within the credential. Now your team can do its part processing the request knowing it's doing so on behalf of a privacy-conscious user and not a bad actor.
There are two primary types of data subject access requests and they do differ in terms of 1) what end users (and regulators) may deem reasonable and 2) what you may deem necessary:
Access Only Requests and Access & Deletion Requests involve providing a user the data you have about them / and then deleting it; a streamlined process that allows someone to get access to another user's data without permission is what every fraudster dreams of and that's precisely why robust identity verification is critical for these types of requests. Users generally accept that access is sensitive and/or can be educated accordingly and be willing to engage in robust identity verification. Access requests should always be verified to an IAL2 standard.
Deletion Only Requests involve solely deleting the data you have about a user. Understandably, this is a far less compelling opportunity for fraudsters. Inversely, users submitting a request to have you delete their data are obviously going to be less than pleased about providing more data about themselves so that...there is less data about themselves. The best way to address this is to use the simplest, least intrusive identity verification methods supported for your user population (e.g. MobileMatch, which requires a full name, phone number, and home address, i.e. your average conversation at a college bar versus BioGovID, which requires a full name and photos of your face before your first cup of coffee and a government document featuring your face after your fourth cup of coffee). The second best way to address this is to verify against malicious behavior rather than verify for identity. For more details about what that looks like, see the Passive Risk Analysis page.
In the context of a data subject access request, particularly a deletion request, the email address associated with the account may no longer be accessible; most of us can think of at least one account lost to the ages because it's connected to an old email address. While it is obviously critical to associate the request with the email address associated with the account for purposes of servicing the request, it is not necessary to rely on this email address for identity verification. We recommend collecting an account email address via the DSAR form for your own records and to service the request but to allow the user to specify a "current email address" if different and configure your OneTrust workflow to pass that email address as the desired recipient.
Different methods of identity verification and different verification goals require collecting and/or providing different PII. See the pages for each of our recommended identity verification workflows to understand the minimum data required by each. Information that you collect on the DSAR form can be federated to us when calling the /email endpoint (which will pre-fill PII into the verification workflow using the authorized link's login_hint; these fields can be left editable or locked, as should always be the case for full name). Customers typically see the most success when collecting the minimum PII on the DSAR form and relying on the identity verification workflow to collect the rest of what's necessary incrementally (users are typically more understanding given the context).
That said, as alluded to in the Verifying Access / Access & Deletion vs. Deletion Requests section, collecting more data than is necessary within the context of DSARs can result in more problems rather than more security. We generally recommend MobileMatch to BioGovID as the ideal starting point for DSAR verification workflows.
In any event in which an edge case falls outside what you've automated across ID DataWeb and OneTrust, you can make use of our admin portal to close the gap: to recreate the flow manually from the /email endpoint onward, head to the "Workflows" tab, click the dropdown, and click "Send Email With Link" or "Copy Link" to generate and send an authorized link to the user directly via email or just generate the authorized link (and deliver another way), respectively. In both cases, you'll want to input all details of the request at the following step ("Send Email With Link" will also require you to select the correct email template if you're using more than one and provide the recipient's email address). It's important to input the credential as it's configured to be sent from OneTrust automatically to close the loop, otherwise you'll have to manually return to check on the verification event as opposed to the system automatically updating the request in OneTrust upon completion. The "Copy Link" function is also available via the /link endpoint.
Reach out to [email protected] for more information. In under an hour, you can deploy a new OneTrust DSAR-configured verification workflow and begin complying with major user privacy regulations.
Are you in compliance with the following major privacy regulations?
OneTrust offers four solutions directly addressing GDPR, CCPA, CPRA, and LGPD and recognizes that none of them are complete without identity verification. ID DataWeb is the add-on that isn't optional to deliver best-in-class privacy management automation.
Updated 5 months ago