1. You are here:
2. Handbook
3. Support Team Handbook
4. Support Workflows
5. Account Deletion & Data Access Requests - Workflows

Maintained by:

On this page

• Overview
• Stage 1: Submission Handling
  • Zendesk Submissions
  • Direct Email Submissions
  • Spam Submissions
  • Duplicate Form Submissions
• Stage 2: Request Processing
  • Deletion Requests
    • GitLab.com Account Deletion and Full Deletion
      • Step 1: Await Challenges
        • No Response
      • Step 1.5: Blocked or Banned Accounts
      • Step 2: Evaluate
        • Verification Failed
        • Verification Failed - Sole Owner Exception
      • Step 3: Create Meta Issue
    • Portal Account Deletion
    • Marketing or Sales Account Deletion
  • Data Access Requests
  • General Questions

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.

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::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
• 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)
• 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.
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, apply the Account Verification Failed and deletion request:: denied labels to the issue, and close it using the following snippet:

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:

1. Follow the reinstating a blocked account workflow. Generally, this means opening a Trust and Safety issue for evaluation.
2. 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 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 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 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.

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. 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.
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 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 have 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 label 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.

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.