Data Protection Officer (DPO) Workflow

---

View the Request Form

Once a data subject request has been opened, it will allow the user to click on the 'View Request' button. The 'View Request' function opens the request form as submitted by the data subject. This form exactly reproduces the data subject's original input in a read-only format, regardless of the specific fields included in the custom form at the time of submission, providing a comprehensive and unmodified view of the request.

Fig. 14. DSR Management - Viewing request

Fig. 14.1 DSR Management - Viewing request

ID Verification

Update the Status of the Verification

Approve Request

If verification isn't automatic, use the "Actions" menu to manually approve the verification.

After selecting a request, initiate ID verification. Verify the requester's identity using information from the submission form, such as the requester's name and email ID.

Fig. 14.2 DSR Approval - ID Verification

When approving a request, the DPO has the option to send an approval email to the data subject. By default, the 'Send Approval Email' checkbox is selected. If unchecked, the request will be approved without sending an email to the data subject.

The approval email template can be customized by selecting a template from the dropdown menu and editing the subject line and email body or through Messaging Templates.

System values such as Data Subject Name, Request ID, and Request Type can be added to the email body using the 'Add System Values' button.

The status will update to "Approved", and will log the Data Protection Officer's (DPO) name and approval date.

These values will appear as tags with a close button and cannot be edited directly. If the 'Send Approval Email' checkbox is unchecked, the request will be approved, but no email will be sent to the data subject.

Fig. 14.2 DSR Approval - ID Verification

Update the Status of the Verification

Approve Request

If verification isn't automatic, use the "Actions" menu to manually approve the verification.

Fig. 14.3 DSR Approval - ID Verification

The status will update to "Approved", and will log the Data Protection Officer's (DPO) name and approval date.

Fig. 14.4 DSR Approval - ID Verification

When approving a request, the DPO has the option to send an approval email to the data subject. By default, the 'Send Approval Email' checkbox is selected. If unchecked, the request will be approved without sending an email to the data subject.

Fig. 14.4(1) DSR Approval - Approve Request Mail

The approval email template can be customized by selecting a template from the dropdown menu and editing the subject line and email body.

Fig. 14.4(2) DSR Approval - Approve Request Mail

System values such as Data Subject Name, Request ID, and Request Type can be added to the email body using the 'Add System Values' button.

Fig. 14.4(3) DSR Approval - Approve Request Mail

These values will appear as tags with a close button and cannot be edited directly. If the 'Send Approval Email' checkbox is unchecked, the request will be approved, but no email will be sent to the data subject.

Reject Request

Fig. 14.4(4) DSR - Rejection Request

When rejecting a request, the DPO has the option to send a rejection email to the data subject. By default, the 'Send Rejection Email' checkbox is selected. If unchecked, the request will be rejected without sending an email to the data subject.

Fig. 14.4(5) DSR - Rejection Mail

The rejection email template can be customized by selecting a template from the dropdown menu and editing the subject line and email body. System values can be added to the email body using the 'Add System Values' button.

Fig. 14.4(6) . DSR - Rejection Message

---

Data Discovery

Once the requester's identity is verified and the request is approved, the system advances to the data discovery stage.

2.1. Data Sources

The system identifies all data sources associated with the request. It uses the attributes provided by the requester (e.g., first name, email ID, Social Security Number, and driver's license) to match and identify the requester's data within these data sources.

Fig. 14.5 DSR Approval - Data Discovery - Data Sources

2.2. Attributes Detection

If the system is able to establish the user's identity based on the provided attributes, it lists all detected attribute instances for this entity.

Detected attributes are those that match the information provided by the requester, as viewed in the Entity 360 view.

Fig. 14.6 DSR Approval - Data Discovery - Attribute Instances Detected

2.3. Attributes Validation

This process ensures the accuracy and completeness of attribute instances and validates the ones detected by the system. It also uncovers any additional information related to the data subject that might have been initially overlooked.

To read detailed data validation workflow DSO, refer to DSO Data Validation.

1. Initiation of Validation Requests

To initiate the validation process, the system dispatches validation requests, termed as "tickets," to all the appropriate DSOs.

These tickets instruct the DSOs to individually verify their data sources for any relevant information pertaining to the data subject i.e. the user who submitted the request.

Fig. 14.7 DSR Approval - Data Discovery - Attribute Instances Validated

1. DSO Validation Process

The DSOs then proceed to verify any attribute instances associated with the data subject within their respective data sources.

For instance, if a DSO oversees a data source storing phone numbers, they are tasked to verify whether the phone number attributed to the data subject exists in their data source and if it corresponds with the phone number supplied by the data subject.

1. Additional Data

As part of the validation process, DSOs are also mandated to inspect their data sources for any additional information linked to the data subject that was not initially identified by the system but could still be present in their data sources.

They then prepare a comprehensive report encompassing all detected attribute instances and any supplementary data discovered during the validation process.

1. Submission and Confirmation of Validated Data

Upon completion of the validation process, DSOs submit their reports to the system.

The system, in turn, confirms the attribute instances as validated only when each DSO completes their validation tasks and submits their findings.

---

Ticket Assignment (Requesting Data from Data Source Owners)

As seen in #2.3.-attributes-validationonce the relevant data sources are selected, administrators can assign tickets to the respective Data Source Owners (DSOs) for data validation.

1. For this, the DPO can click on the Assign Ticket button for the respective datasource.

Fig. 15. DSR Approval - Ticket Assignment

1. This will open a Ticket Assignment Form, where the DPO can edit the following fields:

• Data Source Owner(s): This will enlist the email ids of the owners for the given data source, and the administrator can add/delete email id(s) from this field.

• Email body: This field contains a default message addressed to the DSOs which can be edited.

• Due Date: This is the date by which the DSOs are expected to complete and submit the Ticket.

Fig. 15.1 DSR Approval - Ticket Assignment Form

1. Once the ticket assignment is complete, an automatic email notification is sent to the DSOs, detailing the data subject's request.

Fig. 15.2 DSR Approval - DSO Request Email

DSOs are expected to validate the attributes related to the data subject within their allocated data sources.

1. After the mail has been sent, it will change the Data Validation Status of the datasources to “Ticket Assigned”.

Each ticket is allocated with a specific Ticket ID, Due Date and Status, enabling efficient tracking of the validation progress.

Fig. 15.3 DSR Approval - Ticket Assignment

Actions on Tickets by DPO

Send Reminder

Revoke Assignment

Reassign Ticket

Assign New Ticket

Bulk Action on DSR Requests

Bulk Assignment of Tickets

Associated Tickets Column

Filter

---

Datasource Response Review

Following the receipt of responses from various DSOs for a DSR, the Data Protection Officer (DPO) can review them in the Datasource Response Review. Here, the DPO is presented with a detailed summary of the data sources and their attributes connected to the specific request.

This explains the process of detecting, reviewing, and validating attributes related to a particular request and is divided into three main tabs:

1. Data Sources:

The 'Attributes' subsection within the 'Data Sources' tab allows you to contrast the number of attributes detected by LightBeam with those validated by the Data Source Owner (DSO).

Fig.20. Datasource Response Review

For instance, LightBeam identified 16 attributes in Slack, but the DSO validated 17 attributes. This indicates that the DSO added an extra attribute not originally detected by LightBeam.

Fig.20.1 Datasource Response Review

1. Attribute Instances Detected: This tab of the interface involves reviewing the detected attribute instances. It shows the data originally discovered by LightBeam. Each attribute instance identified by LightBeam is listed here for review and comparison.

For example, if LightBeam detected 16 attributes from Slack, these will be presented in this tab.

1. Attribute Instances Validated: This final tab displays attribute instances that the DSO has confirmed to be accurate.

For instance, if an address detected by LightBeam was updated by the DSO, the updated address will appear in this tab. It also presents any additional instances manually added by the DSO.

In the 'Attribute Instances Validated' tab, the DPO can decide whether to exclude or include each individual instance in the final report.

Fig.20.2 Datasource Response Review

Let's look at a case where LightBeam finds an SSN 'L44123' in a workspace. This SSN is present in Slack while another SSN 'L450011' is found in 4 other data sources.

Each unique attribute value will have its own row, i.e. 'L44123' will have its own row, as will 'L450011'. The row for 'L450011' will also mention it's found in 4 places.

The 'Attribute Instances Detected' and 'Attribute Instances Validated' tabs work in a similar way. Both allow the DPO to pick which instances to add to the final report.

The 'Detected' tab shows what LightBeam found, while the 'Validated' tab shows values confirmed by the DSO.

Fig.20.3 Datasource Response Review

Data Validation Form

When all tickets reach the "Completed" status, the DPO can access the Data Validation Form by clicking on the corresponding entry under the column.

The form, available in read-only format, includes comprehensive details about the data source, including Purpose, Remarks, and more.

The form also has a dedicated section, 'Data Subject Information,' where you can review the specific values and instances that have been reported and validated by each Data Source Owner (DSO).

Fig.21 Data Validation Form

Extend Request

In cases where the information from the DSO is incomplete or needs further details, the DPO can ask for an extension for the request.

When extending a request, the DPO has the option to send an extension email to the data subject. By default, the 'Send Extend Request Email' checkbox is selected.

The extension email template can be customized by selecting a template from the dropdown menu and editing the subject line and email body.

System values can be added to the email body using the 'Add System Values' button.

Fig. Extend request mail

---

Report Generation

Upon the successful verification and validation of all data, the Data Protection Officer (DPO) can transition to the report generation phase. This phase is carried out within the 'Report' tab of the DSR Processing workflow.

Fig.22 Report Generation

The tab provides a comprehensive summary of the Data Subject Request (DSR) Report:

1. Customization Details:

• Attributes Detected

• Attributes Validated

• Datasource Responses

• Identifier Visibility

1. Report Customization:

The DPO has considerable flexibility in tailoring the report to their needs.

• Email Customization: The DPO can personalize the content of the email that accompanies the report upon sharing. This feature allows for specific, context-based messaging to be delivered alongside the report.

• Endnote Addition: An additional field is available where the DPO can input any closing notes or comments relevant to the report. This section can be utilized to provide further clarifications, insights, or highlights from the DSR process.

• Company Logo Inclusion: For a personalized touch and better brand visibility, the DPO can add their company's logo to the report.

1. Report Sharing & Distribution:

Post customization, the DPO has two options for the distribution of the report:

• Share the Report: This feature allows the DPO to email the report directly from the LightBeam platform to the data subject. Upon clicking 'Share Report,' a PDF version of the report is sent to the data subject's email ID.

When sharing a report, the DPO will see two email templates: one for sharing the report and another for sharing the password. Both templates can be customized by editing the subject line and email body. System values can be added to the email bodies using the 'Add System Values' button.

• Download the Report: The DPO can also choose to download a PDF copy of the report. This option is particularly useful for maintaining offline records or for situations where the report needs to be shared through other channels.

Fig.22.1 Report Generation

The report is shared with Data Subject on their verified email ID

Fig.23 DSR Email sent to Data Subject

Fig.23.1 DSR Email sent to Data Subject

---

Closure

The 'Closure' tab serves as the final phase of the DSR process, acting as an audit log for the request.

This tab records all significant actions and events associated with a particular request, providing a transparent and chronological record for audit purposes.

Key events captured include the Opening of the Request, Sending Email Verifications, and Verification of the Data Subject's ID.

Each event is logged with a specific type and timestamp, providing a granular level of detail for tracking and audit purposes.

Fig.24. DSR Closure

When closing a request, the 'Send Extend Closure Email' checkbox is unchecked by default. This means that the request will be closed, but no email will be sent to the data subject.

Fig.24.1 DSR Closure

The mail will look as shown in Fig.24.2

Fig.24.2 DSR Closure

---