Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Security Practices

On this page

Information security encompasses a variety of different working groups. These security best practices support the functions of business operations, infrastructure, and product development, to name a few. Everybody is responsible for maintaining a level of security to support compliance (available internal-only), while raising the bar of our security posture.

Zero Trust

As part of raising that bar, GitLab is implementing Zero Trust, or the practice of shifting access control from the perimeter of the org to the individuals, the assets and the endpoints. You can learn more about this strategy from the Google BeyondCorp whitepaper: A New Approach to Enterprise Security.

In our case, Zero Trust means that all devices trying to access an endpoint or asset within our GitLab environment will need to authenticate and be authorized. Because Zero Trust relies on dynamic, risk-based decisions, this also means that users must be authorized and validated: what department are they in, what role do they have, how sensitive is the data and the host that they are trying to access? We’re at the beginning stages in our Zero Trust roadmap, but as we move along in the journey, we’ll document our lessons learned, process and progress in our Security blog.

To learn more about the concept of Zero Trust and our roadmap for implementation, see GitLab Sr. Security Director, Kathy Wang, explain at GoogleNext19:

For a look back at the historical incidents and industry shifts that led to Zero Trust:

Identity is a critical element of the implementation of a Zero Trust framework. GitLab is moving forward with an implementation of Okta to allow us to standardise authentication for Cloud Application access and implement user-friendly SSO. See our Okta page for more details.

Contact GitLab Security

The GitLab Security Teams are available 24/7/365 and are ready to assist with questions, concerns, or issues you may have.

External Engagement

The Security Teams can be contacted at External researchers or other interested parties should refer to our Responsible Disclosure Policy for more information about reporting vulnerabilities. The email address also forwards to a ZenDesk queue that is monitored by the security team.

For Security Team members, the private PGP key is available in the Security 1Password vault. Refer to PGP process for usage.


For urgent issues we have two options:

Both methods page our on-call Security responder who will engage within SLA, and will escalate to the on-call Security Manager if SLA is passed.

For non-urgent issues or questions the Security Teams can be reached in the #security channel in GitLab Slack.

More information about the GitLab Security Teams is available on the Security Team page.

Best Practices

  1. Set up 1Password as your password manager and set a strong and unique master password.
    • Keep your Master Password a secret. No other team members should know it, including admins. If the Master Password is known or disclosed to someone else, it should be changed immediately.
    • Post a message in #PeopleOps if you forget your Master Password.
    • Consider using a generated Master Password. Most human-created passwords are easy to guess. Let 1Password create a strong Master Password. But: you will need to memorize this Master Password.
    • Do not let your password manager store the master password. It is okay to store the login.
    • For more information, review the Getting Started guide and view this video that guides you through the sign-up process.
    • For account administrators, review the admin guide.
  2. Never reuse a password you use on a company account, not for another GitLab service nor for a personal account.
  3. Use 1Password to generate strong passwords for any new accounts. In the Password Generator, increase the default password length.
  4. When signing up for a new service ask yourself which team members you need to share access with. There are three types of account access for these services, Individual, OAuth, and Single. All Individual and OAuth account services have a secure note in the Team vault. This note lists the administrators you can contact to gain access to the service for Individual services or lists the account you can use to get access for OAuth services. During onboarding you should be added to all relevant Individual services by default.
    1. Individual services (created manually per person, such as our Google accounts): keep your credentials to yourself by storing them in your 'Personal' vault in the GitLab 1Password team account.
    2. OAuth services (authentication through GitLab or Google accounts, such as for grafana).
    3. Single services (services that don't allow individual accounts or where it is too expensive): store the credentials in an appropriate company 1Password vault ('Team' or otherwise) so that your colleagues can sign in using the same credentials.
  5. If 2FA should be on for the new user account, make sure to store recovery codes in the login, and use 1Password TOTP.
  6. If you need to give more people access to credentials move them to a vault that they can access. Never duplicate or export credentials! If needed put them in the Team vault that the whole company can access or make a suggestion to create a new vault in the "1Password Shared Folders" Google Sheet. Do not share passwords on a per person basis by sharing them via 1Password, this makes it hard to reason about the sharing and doesn't change when the responsibilities change.
  7. Do not copy passwords from inside a 1Password vault to a personal password vault or other password store. 1Password should be the only password vault used for teams. Team passwords should not be duplicated or placed in personal password vaults where they can potentially be exposed to compromise.
  8. When asked security questions (what is your favorite pet, etc.) do not answer truthfully since that is easy to research. Make up an answer and write both the question and answer in 1Password. Consider using the Password Generator function in 1Password for this.
  9. Do not share credentials via email, issue comments, chat etc. This includes email addresses to login and API keys. Use 1Password vaults for this. You will be invited to applicable vaults after joining the company.
  10. If you want to see your vaults or ask to be added to a new one please leave a comment in the "1Password Shared Folders" Google Doc. You can be added to a group which has access to a vault, or you can be added directly to a vault as an individual. If there is a group that looks appropriate for you, prefer to join that. Managing a dozen groups is simpler than managing hundreds of individual access settings.
  11. Note for the 1Password admins that handle requests: when adding an individual to a vault (instead of to a group that has access to that vault), make sure that the permissions are restricted to not allow "Export Item". There is not a way of setting that as the default. It is also better to add people to a group that has the access they need, instead of individual vaults.
  12. If you're missing an appropriate vault make a comment in the relevant cell in the "1Password Shared Folders" Google Sheet.
  13. Refer to the items with NAME_OF_SITE credentials in VAULT_NAME. For example: "for access please see the AOL credentials in the Luddite vault".
  14. Do not allow your web browser (e.g. Chrome, Safari) to store passwords when prompted. This presents an unnecessary risk and is redundant as 1Password should serve as the sole password management application.
  15. Use Watchtower to find passwords that need to be changed. Watchtower tells users about password breaches and other security problems on the websites they have saved in 1Password Teams, so users can take action. This is not something account administrators can review for team members, so it is up to you to enable! Enable Watchtower by going to your 1Password app and then to Preferences > Watchtower.
  16. Use the "Security Audit" functionality of 1Password to reveal repeated passwords, weak passwords, and so forth - and then fix them.
  17. Enable two-factor authentication (2FA) with 1Password TOTP for your Google, Slack,, and accounts. Users without 2FA enabled that are stale for over 30 days will be blocked/suspended until resolved. This improves the security posture for both the user and GitLab.
  18. When traveling, consider using 1Password in "Travel Mode", see more on that below.
  19. You can also consider using a Yubikey with GitLab.
  20. Use Full-Disk Encryption on your work computer and phone. Mac users may use FileVault (for details, refer to Apple Support) and GNU/Linux users may use LUKS (for the basic idea, refer to the Arch Linux Wiki). Closing the lid of your laptop, and thus suspending it to RAM, does NOT protect you, even if your hard drive is encrypted. Power off your computer completely (don’t just suspend it) when you think it’s at risk of falling into someone else’s hands, like right before going through customs when entering a new country. This defends against memory-based attacks. Read more on the matter in this article.
  21. Set up a screen saver with password lock on your laptop. The timeout can depend on how you use your laptop.
  22. Never leave your unlocked computer unattended. Activate the screensaver, lock the desktop, or close the lid.
  23. If you backup your computer make sure the backup drive is encrypted and use a strong password.
  24. For backups on macOS (OSX) follow this tutorial: How to use Time Machine
  25. Report suspect situations to an officer of the company. Or use the panic button.
  26. If you have security suggestion, create an issue on the security issue tracker and ping the security team. New security best practices and processes should be added to the company call agenda.
  27. If you receive a security report of any kind (issue, customer ticket, etc.) never dismiss it as invalid. Please bring it to the attention of the Security Team, and follow the steps outlined on that team's handbook page.
  28. Do not forward company emails ( to a non-company email address.
  29. Do not click on links in emails you did not request yourself (requested password reset is OK, anything else is suspect). Exception: During the onboarding process you may receive account registration emails for various services GitLab uses. Before clicking these links confirm with People Operations that they initialized the process. Clicking itself is a problem even when you don't enter a password, because a visit can already be used to execute a 0-day attack. We simulate phishing attacks by having an external service send emails to our company email addresses to ensure everyone is aware of the threat.
  30. If you get strange emails personally or other things related to security feel free to ask our security people for help, they might be aiming for the company.
  31. Only sign in to various services from trusted devices. Public computers are not as trustworthy as personal ones. Team members should be sure to only sign in to their accounts from trusted computers.
  32. During offboarding, your 1Password account is deleted, which includes the Personal vault in the GitLab team account. If you want to keep your personal passwords, please copy/move them to your Primary vault which you will have if you signed up for an individual account before joining the GitLab Team account.
  33. We will configure applications of which we store the passwords in 1Password to not periodically reset passwords.
  34. Do not install software with many known security vulnerabilities (as listed in the handbook). When in doubt, do not install until after checking with the team by discussing in an issue, and then document the verdict in the handbook.

CEO & Executive Fraud

The CEO will not send you an email to wire cash, the CFO won't send you a text message to ask for gift cards, or anything else that feels like CEO fraud or CEO scam. Feel free to verify any unusual requests with a video call.

What should you do if you receive a potential phishing email or text from GitLab's CEO?

  1. If you are unsure whether the text or email is legitimate, confirm the request via Video Call or contact Security to review.
  2. If the email is determined to be fake, follow the instructions for phishing attacks below.
  3. If the text is determined to be fake: block the number, notify Security, and delete the text.

GitLab Password Policy Guidelines

Passwords are one of the primary mechanisms that protect GitLab information systems and other resources from unauthorized use. Constructing secure passwords and ensuring proper password management is essential.

GitLabbers Password Requirements

Password Management

System Password Requirements

Application Authentication Requirements

Exceptions to Password Policy

Any application that can not meet MFA and or Password requirements needs to submit an exception for the Compliance team to review. A duration of an exception is valid for 90 days followed by a proper remediation plan. After 90 days the exception will be reevaluated.

1Password Guide

1Password is a password manager. Ideally you memorize one strong password - hence the name - and let 1Password generate and manage strong, unique passwords for every site for which you have a login.


Following this guide, it will be helpful to understand a few terms we'll be using throughout.


1Password can be used in two different ways - as a standalone application (by purchasing a standalone license) or as a hosted service (by subscribing). GitLab uses 1Passwords for Teams which is a hosted service.

If you want to use 1Password for your private passwords not related to your work at GitLab, there are a few options.

1Password for Teams

1Password for Teams stores all Vaults on the 1Password servers and allows for sharing between multiple people on the same team.

Everyone at GitLab should already be signed up for our Teams account. This gives you access to the web interface, allowing you to view the Vaults we've configured and given you access to.

In addition to the shared Team vault, each member of the team has a vault called Personal which only you can see, and allows you to store personal credentials within our team's account. See the Google sheet titled "1Password Shared Folders" in Google Drive to see a listing of the available vaults and which groups or individuals have access to them. If you need access to a vault beyond the access that your onboarding process already gave you, please make a comment in the sheet and ping one of the 1Password admins in the comment. A listing of the 1Password admins can be found in a secure note in the Team vault in 1Password.

To really get the full benefit of 1Password, you'll need to hook our Teams account up to one of the native apps.

Adding the GitLab Team to a 1Password app

This guide will cover setting up the OSX app. It's their lead platform and is the most up-to-date. These instructions may or may not work for the Windows version. If you use 1Password 6 without a account, make note of this.

  1. Download and install the 1Password OSX app.
  2. Launch the app.
  3. Click "Sign in to your 1Password account" button. If there is no such button please follow the instructions for updating 1Password.

Now you'll need the Emergency Kit PDF that 1Password told you to save when you registered your Teams account. Note: Store the Emergency Kit safely. Store a copy of the Emergency Kit on a USB flash drive or print a copy and store it in a vault at home or safe deposit box — somewhere not online or accessible by anyone other than yourself.

If you saved it as a digital PDF file:

  1. Open the PDF file
  2. Click Scan QR Code
  3. Drag the scanner window over the QR code on the PDF sheet

If you printed the PDF:

  1. Click Sign In Manually
  2. For Team URL enter
  3. For Account Key enter the Account Key from your Emergency Kit
  4. For Email Address enter your email
  5. For Master Password enter the password to your Teams account (not the password you created above when you chose "I'm a new user")

After the Team is added, you should see some notifications about vaults being added to 1Password. By default you'll have Team and Personal, and may have access to others.

Adding the Gitlab Team to a 1Password account-less installation

If you already have a non-account based license for 1Password, you can still add the Gitlab Team to your current account, but there are a few peculiarties:

  1. The Master Password you create for your new Gitlab Team account is distinct from your current local vault Master Password, but you will still be able to access all vaults in the OSX app, local and Gitlab, with your existing local vault password.
  2. You will not be able to log into using your local Master Password. If you choose to set up 1Password this way, please do print out your Gitlab account recovery sheet with your new Master Password and store it somewhere secure, because you'll need it to access your team account online or recover the account, even if you use your local Master Password in day-to-day usage. Gitlab cannot recover your account if your account-specific Master Password is lost.
  3. It is possible to set up your Gitlab account with any of your email aliases, but each can only be used one time. PeopleOps and security will need to set it up as an additional account, so coordinate with them.

Updating 1Password to support the Teams feature

Read this section only if you could not follow the instructions in "Adding the GitLab Team to a 1Password app" section.

  1. At the prompt, choose "I'm a new user". Note: This is one source of confusion. "I created my Teams account, I'm not new!" Just go with it.
  2. Enter a master password, confirmation, and hint. This can (and should) be different from the password you used for our Teams account. This password gates access to your local, private Vault on your computer and/or phone.
  3. Skip over the remaining dialogs (syncing, newsletter, etc.)
  4. You should now have an empty vault called Primary.

Because the Teams feature is not available in your current version of 1Password, we need to update the app to the latest version:

  1. Go to Preferences
  2. Go to Updates
  3. Click Check Now
  4. Install the update and relaunch
  5. After relaunch, go to Preferences again
  6. Go to Accounts
  7. Click the + icon


Click the Vault Selector in the upper-left corner of the window:

Vault Selector

Team is a vault that everyone on the GitLab Teams account has access to, both read and write.

Personal is your hosted, private vault that is part of the GitLab 1Password for Teams account. Since the Personal vault is part of the GitLab Teams account, it should be thought of as company property (like the email account), however the vault can not be viewed by anyone else on the team, including admins. If you choose to store truly personal information in the Personal vault, it opens up the possibility that you would be separated from this information if you offboard. Such truly personal information is therefore better to store in your Primary vault, which is associated with you instead of with the GitLab Teams account, assuming that you added an individual account.

Browser Extension

Go to Browser extensions and install the extension for whatever browser you're using. You should not need a beta version here.

With the extension installed, you should be able to go to a site that has credentials stored in our Team vault and log in:

Mailchimp Login

If you don't see the site listed in the results window, make sure you're using the correct vault:

Vault switching

Saving Logins

When 1Password detects a login form submission, it may ask if you want to save the login with a dialog like this:

Save login

If you do want to save it, make sure the appropriate Vault is selected first.

Several accounts and unlocking the app

Please refer to 1Password FAQ.

If you are planning to use both the GitLab team account and a separate individual account you should first add your separate individual account to the app first (Preferences > Accounts). By doing this you will be able to unlock the 1Password app using the Master Password of the individual account.

If you were using 1Password before joining GitLab, and you receive a prompt titled Migrate To Account, choose I'll move later. There is no harm in doing this, and it is easy to move items between vaults.

1Password for your private passwords

You are encouraged to use 1Password for your private passwords, not related to your work at GitLab. This makes it less likely for a security breach to occur. You can purchase a standalone license or start an individual subscription. While under the GitLab team subscription, it is also possible to create and use a 'Personal' vault (same features of a standalone license, without the cost, but you will lose access if you go through offboarding).

Please bear in mind that if you decide to purchase a standalone license or create a personal local vault, your data is stored only in a local folder on your computer. You can optionally sync this folder to Dropbox or iCloud (if you are using a Mac/iOS) to make it available on your phone's 1Password app, or on another computer.

Signing up for a subscription seems to be the solution now recommended by AgileBits (the company behind 1Password).

To create a personal local vault:

  1. Go to Preferences
  2. Go to Advanced
  3. Under Local Vaults, check Allow creation of vaults outside of 1Password accounts
  4. Enter your Master Password
  5. A new local vault (Primary) is created outside the GitLab team account
  6. If you want to set up sync for your new local vault, go to Preferences > Sync

Two Factor Authentication and Time-based One Time Passwords

All GitLabbers should use two factor authentication (2FA) whenever possible. Our default recommendation is to use 1Password. 1Password provides an alternative solution that does not require using your smartphone: 1Password Time-based One Time Passwords (TOTP). 2FA codes are displayed directly in the 1Password app running on your laptop (Note: this can not be set up via 1Password browser extension or 1Password web app).

To enable TOTP for a saved account:

  1. Open 1Password app
  2. Go to the item for which you want to set up TOTP
  3. Click Edit in the bottom right corner
  4. Add a new field Add new field
  5. Click the field type dropdown (it offers a "Text field" by default) Field type dropdown
  6. Select One-Time Password One-time password field type
  7. Click QR code icon that appeared
  8. Scan QR code using the transparent window
  9. Click Save
  10. 2FA code should be displayed now

Please refer to demo video 1password TOPT setup

Please refer to the 1Password blog for more information on how TOTP works.

If scanning the QR code using the "transparent window" with the 1Password Mac app fails on a recent Mac OS, please consider using the 1Password iOS app instead. This mechanism works the same way, and supports Touch ID to login.

While the above 1Password default recommendation applies to all GitLabbers, there are alternative, although more complex solutions that can also be used. Google Authentication is a TOTP solution that can be used to store tokens, for those who want to have separate application for password storage and token storage. However, be aware that using two applications is more complex, and not necessary. If unsure which mechanism to use, we recommend using 1Password as a TOTP for 2FA.

Follow this guideline when getting a new mobile device, if you are using Google Authenticator as a TOTP mechanism.

Setting Up 1Password TOPT for Your GitLab Google Account

  1. Navigate to
  2. In the left-side menu, select "Security".
  3. Under "Signing into Google", click on the option for 2-Factor Authentication.
  4. Click "Get Started"
  5. Enter your password to log in to your account. If you are unable to do this and Google says it is because the account requires 2FA, contact the security team and ask them to make an exception for your account.
  6. Once successfully logged in, on the following page select "Choose another option" and then select "text message or voice call" from the dropdown menu.
  7. Enter your mobile phone number and select your preferred method (text or call), and then click "Next".
  8. Enter the code that you receive and click "Next".
  9. On the following page, click "Turn On". Now 2FA is enabled for your Google account.
  10. On the following page, scroll down to the section titled, "Set up alternative second step". From this list, select "Authenticator app" setup.
  11. This will present a QR code. Open the 1Password desktop or mobile app, and navigate to your GitLab email/Google login. Select edit.
  12. On the edit page, select "Add new section" and title it One-time password (or something else of your choosing), and then select "Add new field", and choose "One-Time Password" from the dropdown menu.
  13. Tap or click the small QR code that appears next to your newly created field. A QR scanner will open up. Use the scanner to read the QR code that Google is presenting (from step 11).
  14. Tap or click Done within 1Password to save the edits. Keep 1Password open.
  15. Within your Google settings, click "Next". Now enter the six-digit code that has appeared in the One-time password field that you have just sent up in 1Password. Once the code is entered, click "Verify". Google should present a "Done!" message. You have now set up TOPT for your Google account! Nice work.

Example Usage

This is an example of how Robert, one of our developers, uses 1Password:

Once you fully commit to using 1Password to manage all of your security information, it really does make life easier.

I memorize one strong password and let the app generate everything else. Every site I use has a unique password that I can't compromise because I don't even know it, and a hacked site can't compromise it because the password is never re-used on another site.

I store my shipping and credit card info in 1Password and use the browser extension to quickly fill out shipping and billing information on shopping sites.

I store my passport data, along with a digital scan, in 1Password; driver's license info and scan; insurance info; software license keys; any important information that needs to be secure but still easily accessible when I need it, from anywhere. I sync my personal vault to my personal iCloud so it's available on my phone, tablet, laptop, and desktop.

Even my 1Password for Teams account information is stored in my personal Primary vault, with the Emergency Kit PDF as a secure attachment:

Teams Login

I have no idea what the password is. I've never actually typed it. And that's the idea.

Traveling with 1Password

When traveling with a device that has access to the GitLab 1Password vaults, be sure to enable Travel Mode in 1Password. Travel Mode removes copies of any 1Password vaults that are not tagged as "safe for travel" from your mobile devices. None of the GitLab team vaults are marked as safe for travel so you will need to either create a dedicated travel vault or mark your personal vault as safe for travel.

Once you have enabled Travel Mode open 1Password on each device you will be taking with you so that it can sync with and remove any vaults that cannot be used while traveling.

For more information on Travel Mode and how it works, see the AgileBits blog.

Security Awareness Training

As part of the onboarding process at GitLab you should receive an email with links to Security Awareness Training, conducted by KnowBe4. This training covers how to recognize phishing attacks, how to safely use public wireless networks, as well as general security tips and principles.

In addition to completing this training as part of your onboarding process, this training will also need to be completely at least every 12 months.

The KnowBe4 email will arrive from with the subject: Important: Security Awareness Training (optional). A link to the training will be included in the email, similar to: hxxps://<>. If you have any questions about the validity of the KnowBe4 email, please contact Security in #security.

Phishing Tests

GitLab conducts routine phishing tests using a third-party testing platform. All team members will occasionally receive emails that are designed to look like legitimate business-related communications but will in actuality be simulated phishing attacks. Real phishing attacks are designed to steal credentials or trick the recipient into downloading or executing dangerous attachments. No actual attempts will be made by GitLab or the third-party testing site to steal credentials or execute malicious code.

The goal of these campaigns is not to catch people clicking on dangerous links or punish those who do, but rather to get people thinking about security and the techniques used by attackers via email to trick you into running malicious software or disclosing web passwords. If you fall victim to one of these simulated attacks feel free to take the training courses again or to ask the security team for more information on what could've been done to recognize the attack. What you shouldn't do is feel any shame for having clicked on the link or entered any data, nor should you feel like you need to cop to the security team and let them know you made a mistake. Making a mistake online is practically the reason the Internet was invented.

How to identify a basic phishing attack

When you receive an email with a link, hover your mouse over the link or view the source of the email to determine the link's true destination.

If you hover your mouse cursor over a link in Google Chrome it will show you the link destination in the status bar at the bottom left corner of your browser window.

Hover Example

In Safari the status bar must be enabled to view the true link destination (View -> Show Status Bar).

Some examples or methods used to trick users into entering sensitive data into phishing forms include:

Malicious Domain

Trick Username

Data Scheme

When viewing the source of an HTML email it is important to remember that the text inside the "HREF" field is the actual link destination/target and the text before the </A> tag is the text that will be displayed to the user.

<a href="">Google Login!</a>

In this case, "Google Login!" will be displayed to the user but the actual target of the link is "".

After clicking on a link always look for the green lock icon and "secure" label that signify a validated SSL service. This icon alone is not enough to verify the authenticity of a website, however the lack of the green icon does mean you should never enter sensitive data into that website.

Green Lock Example

What to do if you suspect an email is a phishing attack

Whether you believe that you have received an email from our testing platform or you suspect that the email is targeted specifically at you or GitLab, please forward the phishing email to as an attachment for it to be investigated.

To forward the email as an attachment from inside GMail:

  1. In the reply options choose "show original"
  2. Choose "download original"
  3. Save to your local drive or Google Drive
  4. Create a new email addressed to with the saved email as an attachment

GMail also offers the option to report the email directly to Google as a phishing attempt, which will result in its deletion. Reporting the email in this manner will help the security team track phishing metrics and trends over time within G Suite.

To report the email as phishing from inside GMail:

  1. Select the "More" button (three dots) on the email in question
  2. Choose "Report phishing" option from the drop down menu

If you receive an email that appears to come from a service that you utilize, but other details of the email are suspicious – a private message from a sender you don't recognize, for example – do not click on any links in the email. Instead use your own bookmark for the site or manually type the address of the website into your browser.

Unsolicited email should be treated as phishing emails. For example, if you did not register for a site claiming to send you email, do not click on links in the email or visit the site.

Using the panic email address

GitLab provides a email address for team members to use in situations that require an immediate security response. Should a team member lose a device such as a thumb drive, Yubikey, mobile phone, tablet, laptop, etc. that contains their credentials or other GitLab-sensitive data they should send an email to right away. When the production and security teams receive an email sent to this address it will be handled immediately. Using this address provides an excellent way to limit the damage caused by a loss of one of these devices.

Checklist for when panic is triggered

The following can be adapted depending on the specific situation at hand, but when in doubt: block. It is less risky to reinstate accounts and permissions than to be confronted with a malicious actor gaining access.

Copy this checklist into a confidential issue.

- [ ] Password Access and Rotation
   - [ ] Suspend 1Password account. (All responders to `panic@` should be members of the "Panic@ Responders" group in 1Password which has the rights to suspend and recover user accounts).
   - [ ] Take screenshot of what groups / vaults the individual had access to. This facilitates the next step.
   - [ ] Coordinate or actively change sensitive shared passwords. In particular sysadmin access passwords for Infrastructure (ssh, chef user/key, discuss others).
- [ ] Block Google account
- [ ] Block Slack account
- [ ] Block [ account](
- [ ] Remove account from the [gitlab-org group](
- [ ] Block access to
- [ ] Block access to Tweetdeck

Other Security Topics