Updating GDPR process to include request authentication

GitLab Support: Process Change Rollout Plan

Updating GDPR process to include request authentication

The Story

In gitlab-org/gitlab#230579 (closed) a concern was raised that we weren't authenticating GDPR requests and could delete an account based on a spoofed email.

We'll update the process to require users to reply to the initial email and take no action without this step:

The Roles

Role Description
Champions managers
Users All support engineers to process GDPR requests (primarily the same folks who focus on GitLab.com tickets), Users who want to delete their account
Impacted Non-Users Security, Legal

Schedule

  • Rollout to begin on 2020-08-12
  • Will the rollout be phased, such as by team or region? No.
  • Adoption complete by 2020-08-12

Training

What do the users need to learn and how will they learn it? Do managers need to deliver training? Are there videos or tutorials or handbook pages or other materials?

No training required, the process is documented in the meta-issue that agents use to track progress. It will be reinforced with each time we process a request.

Success Determination

Explain here how and what you will be monitoring to determine the success of the change. These are typical questions you might want to answer here:

  • What will success look like?
  • How will you track change adoption?
  • Is there a level of adoption that is required?
  • How will you measure success?
  • What are your targets (measured values that equate to success)?

This feels small enough and documented enough that we don't need strict follow-up? Maybe I'm wrong?

Action Plan

  1. Announce the change and include The Story in the SWIR on 2020-08-14
  2. Post a message in the #support_team-chat slack channel (or other support channel as appropriate) announcing the change and pointing to the SWIR announcment on 2020-08-12 (Posted in .com channel)
  3. Announce the change and tell The Story in Team meetings by date
    • EMEA team meeting
    • AMER team meeting
    • APAC team meeting
  4. Other communications channels
    • Discuss in 1-1s, telling The Story, by date
    • Announced in GitLab.com meeting
    • Other communications channels, if required - for example, post to a TAM channel if the TAMs will be impacted non-users
  5. Report back on change adoption, concerns, etc. by date

Follow-Up Plan

How will you follow-up to understand the results of the change, to make adjustments appropriately, and to rollback if necessary? These are typical questions you might want to answer here:

  • How will results be captured? By whom and by when?
  • What is the plan for considering and making quick improvements?
  • What is the plan should the change be deemed unsuccessful?
    • Is a rollback feasible, and if so how will it happen?
Edited by Lyle Kozloff