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

Third Party Minimum Security Standards

Third Party Minimum Security Standards

Scope

In order to maintain the confidentiality, availability and integrity of GitLab classified data, this minimum security standards guide was developed. This guide is applicable to any Third Party with an inherent risk score of Moderate or High as determined by the first phase of the Third Party Risk Management procedure.

Roles and Responsibilities

Role Responsibilities
Security Risk Team Maintain Third Party Minimum Security Standards
  Review provided evidence as part of the Third Party Risk Management activities
  Communicate observations and advise in remediation
  Conduct additional risk-based reviews, as applicable
Business Owner (requester) Participate in the initial Inherent Risk determination process
  Provide Minimum Standards guide to the Third Party
  Act as liaison with Third Party and Security Risk team, as needed, to complete assessment
  At the end of the engagement, ensure all data is destroyed or returned
  Participate in periodic access reviews, as applicable

Standards

The following standards will be reviewed during the Third Party Risk Management procedure.

Third Parties Providing Applications (Free or Paid)

This information is collected by sending an automated questionnaire from ZenGRC. This questionnaire asks the Third Party to provide:

Third Parties who can not meet these standards will be asked to provide evidence of compensating controls through a more detailed questionnaire that is also sent through ZenGRC.

Third Parties Providing Services

Professional Services Organizations, Resellers, Partners, Alliances, Mergers and Acquisitions

This information is collected by sending an automated questionnaire from ZenGRC. This questionnaire asks the Third Party to provide:

Individual Contractors

NOTE: If the Contractor is being provided with a GitLab issued endpoint, no information is required from the Contractor to complete the Security Assessment. However, if the Contractor will be using their own device, an automated questionnaire is sent from ZenGRC. This questionnaire asks the Third Party to provide:

Third Parties Providing Physical Services (Field Marketing)

Exceptions

  1. GitLab may engage with a Professional Services Organization that provides a variety of services against multiple Statements of Work. In these cases, the Third Party will undergo a Security Assessment at the time of contract signing and annually thereafter. With each individual engagement, the contractors will follow the procurement contractor process and orientation process for external consultants. Security Assessments will not be conducted for each Statement of Work.
  2. If a Third Party does not provide the requested documents and/or completed questionnaires within 10 business days, each outstanding item will be rated based on GitLab's Observation Risk Rating methodology and follow up activity will occur based on the risk.
  3. If a Third Party cannot meet one of the standards noted on this page, and cannot provide any evidence of a countermeasure, each outstanding item will be rated based on GitLab's Observation Risk Rating methodology and follow up activity will occur based on the risk. NOTE that in some cases, if the exception is a high enough risk to the organization, it will require a Risk Treatment plan through the Security Operational Risk Management program.

SLA's

Once the requested information is received from the third party, we intend to have the audit completed within 10 business days. The 10 business days start once the requested items are received. This however, does not account for instances when there are delays in the Third Party responding to our follow up request.

Guidance to sharing data externally

Before sending data outside of GitLab should review the following guidance:

Data Classification


Team members should review the Data Classification Standard. For data that is classified as Yellow or above:

  • The Third Party must first establish a non-disclosure agreement or similar confidentiality contractual clauses. See the guide and template for GitLab confidentiality agreements.
  • Use the principle of "need-to-know" and obtain approval by the appropriate data owner. Good questions to ask yourself are:
    • What specific data does the third party need?
    • What can be omitted?
    • In what manner will they use the data?
    • Will they download it and share it with a fourth party?
    • Where will the data be stored?
    • How will they destroy it when they are done?
    • How will access be logged and monitored?
    • How will access be revoked?
    • How will access be reviewed to ensure it is still appropriate?

Consent for Use


For data that is classified as Yellow or above must have documented consent prior to sharing with Third Parties. Examples include:

  • Customer Data (anything uploaded or created within GitLab by customers)
  • Customer user analytics that is not anonymized
  • Sending gifts to event attendees to a home address
  • Team member personal information gathered during surveys
  • Pictures and other identifying information of individuals

Methods of Sharing Data

For data that is classified as Yellow or above, the following guidelines should be used:

GitLab’s Tools Instructions and Controls  
  GitLab - Create a new private project dedicated to the engagement with external users.
- Do not create an issue in an existing private project as the Guest level member will not be able to see the issue if private.
- Add the external user with Reporter permissions.
- Open an issue to share the non-public data in the description of the issue and mark it confidential.
- Do not attach documents with the data as the attachment can be accessed unauthenticated with the direct link.
- Include the disclaimer below in the description along with the data.
- Remove the user from the project once done and delete the issue.
  Google Workspace - Create a dedicated folder for External Sharing and a subfolder for the external party.
- Upload the data to a document or sheet and verify the considerations in Step 2 before sending the invite to the external users.
- Include the disclaimer below in the document.
- Share the document to the intended party with the appropriate access level.
- Grant Editor access only if they need to collaborate in order to limit their ability to change permissions or invite others to the sheet.
- Viewer or Commenter access will allow the party to download, print or copy so this is the preference if they do not need to edit the document.
  Company email - Consult the Security Assurance team to validate any additional steps that are needed for the type of data shared.
- Encrypt the document or sheet and password protect. An easy way to accomplish this is by creating a file and encrypting it with the Mac built-in Disk Utility capability.
- Choose a random password generator with at least 60 characters. 1Password provides a generator tool where you can adjust the length.
- Add the disclaimer below in the document or create a separate sheet in the workbook.
- When sending the encrypted file, Gmail may prompt you to store it in G-Drive if the size is over 25MB. You should allow this even if your recipient doesn't have a Google account; the direct link shouldn’t require it.
- Send the password in a separate email to the recipient outside a different channel than the encrypted document sent. For example, if the document was sent via email the password can be shared by a text message, phone call or a different email account.
- Ask the recipient to confirm deletion of the emails once successfully opened, and the document when no longer needed.

Additional Tips


For data that is classified as Yellow or above:

  • Do not store any local copies of data. If you have to download them, ensure you delete them as soon as possible.
  • Do not use email to send data. If you receive an email containing these types of data, delete it and request it be sent using a secured method (see above).
  • Create a mutual plan with timelines to return and/or dispose of the data once the Third Party no longer needs it. It might be helpful to schedule regular check-ins and identify deliverables that demonstrate expected progress.
  • When the engagement is final, remove the user(s) from the document or sheet. Also, confirm with the external party that they have deleted any locally saved or shredded printed data.
  • Utilize the below disclaimer below:

Disclaimer

THIS DOCUMENT IS DISCLOSED ONLY TO THE RECIPIENT TO WHOM THIS DOCUMENT IS ADDRESSED AND IS PURSUANT TO A RELATIONSHIP OF CONFIDENTIALITY UNDER WHICH THE RECIPIENT HAS OBLIGATIONS OF CONFIDENTIALITY. THIS DOCUMENT MAY CONTAIN CONFIDENTIAL INFORMATION, PROPRIETARY INFORMATION AND/OR TRADE SECRETS (COLLECTIVELY “CONFIDENTIAL INFORMATION”) BELONGING TO GITLAB INC. AND/OR ITS AFFILIATES AND/OR SUBSIDIARIES. THE CONFIDENTIAL INFORMATION IS TO BE USED BY THE RECIPIENT ONLY FOR THE PURPOSE FOR WHICH THIS DOCUMENT IS SUPPLIED. THE CONTENTS OF THIS DOCUMENT ARE PROVIDED IN COMMERCIAL CONFIDENCE, SOLELY FOR THE PURPOSE, THIS DOCUMENT IS SUPPLIED TO THE RECIPIENT, BY GITLAB. ANY INFORMATION THAT GITLAB CONSIDERS TO BE A CONFIDENTIAL INFORMATION WILL NOT BE SUBJECT TO DISCLOSURE UNDER ANY PUBLIC RECORDS ACT. ANY DATA LOCALLY STORED MUST BE RETURNED AND/OR DISPOSED UPON COMPLETION OR NO LONGER NEEDED. PLEASE CONFIRM IN THIS DOCUMENT ONCE THE DISPOSAL IS DONE.

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license