Add enterprise-user waiting-period operator guidance

- Email address (must exist)

- Username (must exist)

- Username and email must match for the same account

- Account is not an [Enterprise User](https://docs.gitlab.com/user/enterprise_user/).

- Account is not an Enterprise User ([Badged](https://docs.gitlab.com/user/enterprise_user/) nor [Support defined Enterprise User](https://gitlab.com/gitlab-com/content-sites/handbook/blob/main/content/handbook/support/workflows/gitlab-com_overview.md#enterprise-users)).

- Account [does not have an active subscription](#step-3-check-non-enterprise-user-paid-subscription-status)

After submission, the automated checks will return a risk rating if a GitLab account is found. The risk rating is used to determine whether additional verification is needed to delete the user account. Support Engineers can review the method by which the risk rating is calculated in the [Support Workflow page](https://internal.gitlab.com/handbook/support/workflows/data-subject-requests/) *(internal only)*. If the automated checks do not find a user account, the user will be notified via email message generated from the system.

1.2 Review Risk Rating

When a risk rating of medium or high is generated by the automated checks, the user should be sent either the `Medium Risk GitLab Account Verification Question` message or the `High Risk GitLab Account Verification Question` message ONLY IF the user has any private projects. If there are no private projects, do not send the additional verification questions. Users have 7 calendar days to respond to those questions. The `Support Engineer (GitLab Deletion)` task should remain open during this time.

Add a note to the task that `Risk Verification Question message sent, 7-day end date is <date>`.

###### No Response

If the user is blocked due to a user deleting their own account, send the `Blocked Account Deletion Request` message, then mark the `Support Engineer (GitLab Deletion)` task as Complete.

If the account is blocked or banned, proceed with the `Account Reinstatement` workflow by opening an issue with Trust and Safety for [reinstating a blocked account](/handbook/support/workflows/reinstating-blocked-accounts/#blocked-accounts); however, if the block or banned state is for regulatory reasons, such as free user blocks in China, then the Support Engineer should also request review from the Privacy team in #help-transcend. The `Support Engineer (GitLab Deletion)` task will need to remain open until a determination is made. You should add a note to the task to indicate that a security review has been requested. Send the `Security Review Requested` message to the data subject.

Send the `Security Review Requested` message to the data subject, leave the task Open.

If the account is unblocked or unbanned, send the `Security Review Complete` message to the data subject, then follow the rest of the process as normal.

If the account remains blocked or banned, send the `Security Review Denied` message to the data subject, then mark the `Support Engineer (GitLab Deletion)` task as an Exception under Step 3.

If the account remains blocked or banned, send the `Security Review Denied` message to the data subject, then mark the `Support Engineer (GitLab Deletion)` task as an Exception.

###### **Step 3:** Check non-Enterprise user paid subscription status

- Username and email must match for the same account

- Account is an Enterprise User

GitLab is not the Controller of enterprise users. Therefore, an [Enterprise User](https://docs.gitlab.com/user/enterprise_user/) account cannot be deleted without the permission of the enterprise account owner. However, upon submission the automated checks will run and return a risk rating if an account is found and confirmed to be an enterprise user. There may be instances where the request is submitted as an `Enterprise User` data subject type, but the automated checks verify the account is NOT an enterprise user; in which case the request should be treated as though it was submitted by an individual user. The risk rating is used to determine whether additional verification is needed to delete the user account. Support Engineers can review the method by which the risk rating and risk score are calculated in the Support Workflows *(internal only)*.

Enterprise users can be identified from a domain verification [Enterprise User](https://docs.gitlab.com/user/enterprise_user/) badge, or from fitting the [support definition of enterprise users](https://gitlab.com/gitlab-com/content-sites/handbook/blob/main/content/handbook/support/workflows/gitlab-com_overview.md#enterprise-users). GitLab is not the Controller of enterprise users. Therefore, an enterprise user account cannot be deleted without the permission of the Top-level Enterprise Group owner. However, upon submission the automated checks will run and return a risk rating if an account is found and confirmed to be an enterprise user. There may be instances where the request is submitted as an `Enterprise User` data subject type, but the automated checks verify the account is NOT an enterprise user; in which case the request should be treated as though it was submitted by an individual user.

Check whether the enterprise user has an existing Zendesk ticket describing account access or similar issues that can be resolved through reinstatement instead of deletion. Follow the appropriate resolution process for the issue, either on the existing ticket or on the outbound ticket to the group owner in Step 1 below.

###### **Step 1:** Obtain Permission

When a deletion request is for an enterprise user, send the `Enterprise User` message to the data subject. The data subject has 7 days to respond back and indicate if they want us to attempt to contact the organization system administrator.

When a deletion request is for an enterprise user, send the `Enterprise User` message to the data subject. The data subject has 7 days to respond back and indicate if they want us to attempt to contact the organization system administrator. Leave a note on the Action Item noting that the `Enterprise User message sent, 7-day end date is <date>`. Leave the request Open.

- If the data subject does not respond within 7 days AND the organization administrator has not provided written instructions to delete the account through a Support Ticket, send the `No Enterprise Admin Permission-Deletion` message and mark the task as an Exception.

- If the data subject asks for us to attempt to contact the organization administrator to obtain permission to delete the account, this should be done utilizing `Step 5. Contact Owner` in [this workflow](/handbook/support/workflows/account_changes/#request-from-an-enterprise-user-that-may-or-may-not-be-part-of-the-group) for contacting the owner of an enterprise user account. Give the administrator 10 calendar days to respond.

  - If permission is granted, add a note to the `Support Engineer (GitLab Deletion)` task with a link to the Support Ticket, then proceed to delete the enterprise user account as below.

  - If permission is not granted, add a note to the `Support Engineer (GitLab Deletion)` task with a link to the Support Ticket to document no permission was received, then mark the task as an Exception.

  - If permission is granted, add a note to the `Support Engineer (GitLab Deletion)` task with a link to the Support Ticket, then proceed to delete the enterprise user account as detailed in Step 2 below.

  - If permission is not granted, send the `No Enterprise Admin Permission - Deletion` message. Add a note to the work item with a link to the Support Ticket to document no permission was received, then mark the task as an Exception.

###### **Step 2:** Proceed with Deletion