Osano supports receiving Subject Rights Requests (DSARs) via email, giving your team more flexibility to route requests into your standard workflow.
This feature is designed to bring subject rights requests from a dedicated inbox into your formal subject rights request workflow.
While it is technically possible to allow anyone to forward emails to the generated inbox, this is not the intended or recommended use case. Configuring open forwarding is atypical and may create risks around authentication and parsing errors (see escalation and allowlist below)
Each DSAR form in Osano has a unique, auto-generated intake email address, located under the Settings tab of the form. When an email is sent or forwarded to this inbox, Osano can trigger a response to the requestor with a link to a hosted DSAR form.
This response email includes:
A link to the hosted DSAR form
Instructions for completing the form
Pre-filled email field (locked, uneditable by the user)
Requests submitted this way follow the same workflow as any form submitted directly via your website.
Email redirection is the recommended method for routing subject rights requests to a form's inbox.
The original sender remains intact, making it easy to identify the requestor.
No additional setup is required once a form is published.
Emails can be redirected manually or through automated rules:
Large organizations: Ask your Email Administrator to configure routing rules through an admin account.
Smaller teams: Users can manage rules directly, depending on email provider settings.
Note: Some providers require admin privileges for routing rules beyond standard forwarding.
Email forwarding is another supported method.
The original sender becomes your corporate email address.
Osano must parse the body of the forwarded email to determine the requestor.
Osano has enhanced the parsing mechanism used to identify the original requestor to utilize AI for improved accuracy.
To improve parsing accuracy, ensure the body contains only the original requestor's email address -Be sure that there is no additional content that could interfere with the parsing (ex. a signature in the forwarding email address message.)
To allow forwarding, add the form's generated inbox and/or other dedicated emails to the Allowlist, which is located below the generated inbox on the form.
If adding allowed emails, you must also add escalation email addresses to handle cases where Osano cannot identify the requestor.
Configuration Limits:
Up to 10 email addresses in the Allowlist
Up to 10 email addresses in the Escalation list
Important: The same email address cannot be included in both lists.
Forward a single email in Microsoft Outlook (User)
Forward multiple emails in Microsoft Outlook (User)
Forward a single email in Gmail (User)
Forward multiple emails in Gmail (User)
Forward multiple emails in Gmail (Admin)
Here’s how the feature is designed to function depending on configuration:
If the form has an allowlist email:
The requestor emails your team at the allowlist email
A team member or automation on the allowlist forwards the email to the DSAR intake address (e.g., random_id@osano.com)
Osano identifies the original requestor from the forwarded message
The requestor receives a "Further Information Needed" email with a DSAR form link. The email field is auto-filled and locked.
The requestor completes the form and a request is created in Osano.
If the form does not have an allowlist:
The requestor must email the DSAR intake address directly (e.g., random_id@osano.com)
Osano identifies the requestor from the original sender.
They receive the "Further Information Needed" email with a DSAR form link (email field pre-filled and locked).
They complete the form and a request is created.
Requests created via Email Intake will have two additional audit events prior to request creation indicating when the email was originally received by Osano and when the original requester was replied to with a link to the official subject rights form:
Parsing errors occur when Osano cannot determine the original requestor from a forwarded email. This typically happens when multiple, non-whitelisted email addresses appear in the email body. Parsing errors should occur very rarely relative to succesfully forwarded emails.
To resolve:
Remove all non-whitelisted email addresses from the email body.
Ensure the requestor's email is present.
Re-forward the email to the generated inbox.
If unable to parse, the email received by your listed escalation contact will look something like the following: