Account Deletion & Data Access Requests - Workflows

Overview

This document contains instructions on how to process each type of Account Deletion or Data Access request. It is split into two stages; Submission Handling and Request Processing, to be followed in that order. Each request will go through the same flow from opening to completion that is outlined in the chart below. All requests must be fulfilled within 30 calendar days.

graph TD
    A(Valid Request Received)-->B
    B(Perform Account Verification)-->E
    E(User Passed Account Verification Process?)-->|Yes|I
    E-->|No|H
    H(Apply Account Verification Failed Label)
    I(Create Delete Meta Issue)

Stage 1: Submission Handling

We are only able to process Account Deletion and Data Access requests if they are submitted through the official Personal Data Request form. If a request is received via any other method, we will close it and direct the user to open a request through the form.

When a user submits a request through the form, an issue is automatically created in the Personal Account Requests Service Desk, even for invalid requests. Comments made in the issue will be emailed to the user. You will communicate with the user through the issue on the progress of their request.

The purpose of this stage is to instruct you on how to close out invalid requests.

Zendesk Submissions

When a request is received through Zendesk as a support ticket, do one the following:

• If the ticket is regarding an Account Deletion request, apply the Support::SaaS::Gitlab.com::Account Deletion Instructions - GitLab.com macro, and mark the ticket as solved.

• If the ticket is regarding a Data Access request, apply the General::Personal Data Access Request Instructions macro, and mark the ticket as solved.

• If the ticket is regarding a combination of both, use a variation of both macros above, and mark the ticket as solved.

Direct Email Submissions

If a request to the Personal Account Requests Service Desk is submitted directly via email, add the account-deletion::invalid label, add a comment to the issue with the snippet below, then close the issue.

NOTE: Requests sent in through the official form will include a copy of the form entries in the initial description of the issue.

Spam Submissions

If the request submitted is spam, apply the label Invalid Request::Spam, then close the issue.

Duplicate Form Submissions

If a user has submitted multiple requests via the form, apply the /duplicate quick action to the duplicate issues, and respond with the following before closing the duplicates:

Stage 2: Request Processing

Find the appropriate workflow below to process requests submitted to our Personal Account Requests Service Desk, based on their request type.

• Deletion Requests
• Data Access Requests
• Data Export (Right to Portability)
• General Questions

As a reminder, before processing a request you should make sure that you have already Streamlined Your Workflow to make requests easier to process.

Deletion Requests

The following are the types of requests that a user can file. Click the link for each to jump to the associated workflow for processing that request.

• GitLab.com Account Deletion (delete the GitLab.com account only)
• GitLab.com Account Deletion - Deceased User (delete users data that belongs to deceased owner)
• Portal Account Deletion (delete data in customers.gitlab.com only)
• Full Deletion (delete everything across all systems)
• Marketing or Sales Account Deletion (delete marketing and sales-related data only)

Currently, only GitLab.com Account Deletion or Full Deletion requests are auto-checked upon form submission.

GitLab.com Account Deletion and Full Deletion

This workflow applies to both GitLab.com Account Deletion and Full Deletion requests. When a request is submitted for either of these types, the following form entries are verified using built-in automated checks:

• Username (must exist)
• Email address (must exist)
• Username and email must match for the same account
• Account is not part of a paid namespace
• User checked the box confirming their intent to delete (deletion requests only)

After submission, the automated checks will either fail or succeed.

You Should Know:

If any of the automated checks fail, the user will receive an auto-generated response detailing the reason we are unable to process their request. The issue created will be marked as invalid with "Invalid Request Received" noted in the title. These issues are scheduled to automatically close, and the label "account-deletion::invalid" will be applied. No action is required.

Step 1: Await Challenges

If all of the automated checks succeed, the user will receive a set of Verification Challenge questions in an auto-generated response. Users have a total of 7 calendar days to respond to the challenge questions.

At this stage, do the following:

1. If the account in question is a FREE account, add the account-deletion::personal label to the issue. If the account is tied to a paid namespace with a signed contract in Salesforce (a corporate request), add the account-deletion::corporate label to the issue. If the user has added comments in their form submission that reference lost 2FA or loss of access to the email address connected to the account, add the RequestReason::lost_2fa or RequestReason::lost_access labels, as appropriate.
2. Add the Awaiting::Challenge Answers label and wait for the user to reply with the answers to the questions. If they do not reply within 7 calendar days, proceed to No Response. If they do reply within 7 calendar days, proceed to Step 2: Evaluate.

No Response

If the user fails to respond within 7 calendar days, close it using the following snippet (note the 3 labels that are set: Account Verification Failed deletion request::denied and denied-reason::no_response and 1 label is removed: Awaiting::Challenge Answers):

Step 1.5: Blocked or Banned Accounts

If the user account is not blocked or banned, skip this section.

If the user is blocked due to a user deleting their own account (see the admin note on the account):

For all other blocked or banned reasons, proceed to step 2 first.

Step 2: Evaluate

Evaluate the answers to the challenge questions that the user has provided using the Account Verification workflow with a data classification of RED along with the Risk Factor (GitLab internal) for data and privacy requests to confirm if the verification passes or fails.

• If the verification passes, proceed to Step 3: Create Meta Issue.

• If the verification passes, but the account is blocked/banned, proceed to Step 2.5: Verification Passed - Unblock User.

• If the verification fails and the user is not the sole owner of the groups and projects in their account, proceed to Verification Failed.

• If the verification fails and the user is the sole owner of the groups and projects on their account, proceed to Verification Failed (Sole Owner Exception).

Verification Failed

If the user fails the challenge questions, apply the Account Verification Failed and deletion request::denied labels, and respond with the following snippet before closing the issue:

Verification Failed - Sole Owner Exception

If the user fails the challenge questions, but they are the sole owner of groups and projects, we can consider approval for an exception by working through the following:

1. Validate that the user is the only owner of any top-level groups and that any projects associated with their account are in their personal namespace.
2. Check that the user has not logged in for at least 1 year.
3. Check that the projects and groups owned by the user have not been updated in at least 1 year.
4. Reach out to the #privacy-team_help Slack channel to engage a Support Manager and Privacy for review and approval (approver will add Deletion Request::Exception Approved to the issue if approved).
5. Proceed with the deletion process.

Note: If a situation requires further review, and falls outside of the above criteria for a sole owner, please reach out to the #privacy-team_help Slack channel to discuss approving an exception with a Support Manager and the Privacy team.

If the above conditions are not met, respond with the following before closing the issue:

Step 2.5: Verification Passed - Unblock user

1. Ensure that the user has passed the challenge questions and has been properly evaluated.
2. Proceed to follow the reinstating a blocked account workflow. Generally, this means opening a Trust and Safety issue for evaluation.
3. Reply to the user to let them know.

If the account is unblocked or unbanned, let the user know, then follow the rest of the process as normal. If needed, include other information about the verification process in the next reply.

If the account stays blocked or banned, apply the Account Verification Failed and deletion request::denied labels to the issue, and close it with the following:

Step 3: Create Meta Issue

Proceed with processing the request by doing the following:

1. Let the customer know they have been verified and that you are initiating the deletion process by leaving a comment on the issue with the following snippet. Take care to replace TYPE_OF_REQUEST with the appropriate type of request.

1. Create a new confidential issue in the Personal Account Requests Service Desk using one of the following templates, depending on the request type, and populate the issue title with the email address of the original request:

   • Deletion Meta Issue - Full for Full Deletion requests.

   • Deletion Meta Issue - GitLab-com for GitLab.com Account Deletion requests.

2. Follow the instructions in the top of the template, then complete each step in the issue that begins with Support Engineer: in order.

GitLab.com Account Deletion - Deceased User

Use this workflow for requests to delete user data where the sole owner of that data is deceased. No automated checks will take place with this request type.

The requestor will receive an initial reply with a set of verification challenges and documents to provide in an auto-generated response. The requester will have 10 calendar days to provide the requested information when the request was initially made. Once they have responded with the details, follow the steps below.

IMPORTANT NOTE: If at any point you are unsure of next steps or have any questions or concerns about the information in which the requester has provided, please reach out to the #privacy-team_help Slack channel for help.

1. Add the Awaiting::Challenge Answers label, and wait for the requestor to reply.
   1. If no response is received after 10 calendar days, apply the Account Verification Failed deletion request::denied and denied-reason::no_response labels to the issue, and close it using the following snippet:

1. Notify #privacy-team_help of the request so that they can begin review of the evidence provided by the requester proving their authority to act on behalf of the deceased account owner.
2. If the user has access to the account and provided answers to the Verification Challenge questions, then evaluate answers for verification.
   1. If the user fails verification, please reach out to the #privacy-team_help Slack channel for further direction.
   2. If the requester fails the challenge questions, and you get instruction from #privacy-team-help to proceed to verification fail, apply the Account Verification Failed and deletion request::denied labels, and respond with the following snipped before closing the issue:

1. If the requester passes the challenge questions, or #privacy-team-help has provided instruction to continue with this request:
   1. Comment on the gitlab#330669 feature request to note that we’re having to manually process a relevant request.
   2. Let the requester know they have been verified and that you are initiating the deletion process by leaving a comment on the issue with the following snippet.

1. Create a new confidential issue using the Deletion Meta Issue - Deceased.md template, populating the title with the email address of the original request.
2. Complete each step in the issue that begins with Support Engineer: in order.

Portal Account Deletion

Use this workflow for requests to delete user data from the Portal (customers.gitlab.com).

1. In the Personal Account Requests Service Desk, create a new confidential issue using the Deletion Meta Issue - Customers Portal template, populating the title with the email address of the original request.
2. Follow the instructions in the top of the template, then complete each step in the issue that begins with Support Engineer: in order.

Marketing or Sales Account Deletion

Use this workflow for requests to delete user data from Sales or Marketing systems.

1. No confirmation or verification is required for this request type under data privacy laws. Unless the user responds back in the issue that they did not submit the request, proceed with the workflow.
2. In the Personal Account Requests Service Desk, create a new confidential issue using the Deletion Meta Issue - Marketing template, populating the title with the email address of the original request.
3. Follow the instructions in the top of the template, then complete each step in the issue that begins with Support Engineer: in order.
4. Let the requester know the deletion process is complete by leaving a comment on the original issue with the following snippet.

Data Access Requests

Users can request the following to obtain information about their data. Use this workflow for requests to access full details about what data we have on the user.

• Data Access Request (provide all data from all systems GitLab has related to the user)
• General Questions (any other inquiries related to the users data)

Use the following workflows based on the type of request submitted.

1. Support Engineer: Ensure the user has replied from the same email on the request issue. If the user fails to respond within 7 calendar days, close the issue using the following snippet, and apply the Account Verification Failed data-access-request::denied and denied-reason::no_response labels to the issue:

1. Review the requested data by the user. If the requested data is out of scope, apply the data-access-request::denied label to the issue:

1. In the Personal Account Requests Service Desk, create a new confidential issue using the personal_data_access_request template, populating the title with the email address of the original request.
2. Follow the instructions in the top of the template, then complete each step in the issue that begins with Support Engineer: in order.

Data Export Requests (Right to Portability)

Use this workflow for data export request submissions. Note that we can only action on this if the request is for personal namespace projects, or projects in groups where the user is the only member. This workflow cannot be completed if the request indicates the user’s country is Cuba, Iran, North Korea, Syria, Russia, Belaru or the Crimea, Donetsk or Luhanks regions of Ukraine as these are embargoed countries and we are not permitted under Trade Compliance laws to engage with individuals in those locations. You can visit the #privacy-team_help Slack channel if you have any questions.

1. The user will receive an auto-response directing them to the project export steps for self-serve. Keep this issue opened for 7 days and close after that time if there are no further updates. Apply the Export Request::self-serve label.
2. If the user is located in an embargoed country they will receive an auto-response informing them that GitLab is unable to fulfill their request and the Issue will be auto-closed
3. If the user runs into any issues using the self-serve steps, they can reply to the auto-response with more details about the error they are receiving. If they reply after the issue has been closed, re-open the issue.
4. Before we continue to assist, we must validate their identity. Manually send the customer the Verification Challenge questions through the issue. Users have a total of 7 calendar days to respond to the challenge questions.
5. Follow the same steps we use for account deletion requests to validate their account:
   • Await challenges
   • Evaluate answers
6. Only if the user passes account validation, start the process to get them project exports.
   1. If the user cannot sign in, export project using the UI or the API.
   2. If there are errors, follow the project exports workflow. You can also search ZenDesk for examples of past project export tickets from paid customers for additional troubleshooting help and ideas.
7. Upload the project exports to a new folder in the “Personal Data Requests” shared drive. Share the request specific folder with the user and let them know they should download the files within 7 days.
8. After 7 days, unshare the request related folder and ask them to confirm they have the files.
9. Once their issue is resolved, close the issue and apply the Export Request::complied label.

Important Note: Because we can not deny free users from support to export their data if they run into a problem, we will need to assist them through the issue (not ZenDesk).

General Questions

Use this workflow for general question submissions.

1. If the question is something Support can answer, respond to the user’s inquiry.
2. If needed, engage a Support Manager or the Privacy team for guidance and messaging. You can visit the #privacy-team_help Slack channel to ask for help.
3. Close the issue once the users question(s) have been answered.

Escalating to the Privacy Team

While processing a request, certain scenarios may arise that necessitate the escalation of the request to the Privacy team. The most common of these scenarios can be found in the Privacy Escalation Meta Issue template. If a request needs to be escalated to the Privacy team, do the following:

1. Create a new related issue using the Privacy Escalation Meta Issue template.

If you’re ever unsure if a particular scenario requires escalating, reach out to the Privacy team via the #privacy-team_help Slack channel.

View page source - Edit this page - please contribute.