Record Retention Policy
This Records Retention Policy promotes and assists with the implementation of procedures, best practices, and tools to promote consistent life cycle management of GitLab records. Because records contain important information, it is essential to take a systematic approach to the management of records.
1. Records Management
Records management addresses the life cycle of records, i.e., the period of time the records are in the possession of GitLab.
The life cycle usually consists of three stages: 1) Creation or receipt; 2) Maintenance or use; and 3) Destruction or retention. This policy is used in conjunction with the Records Retention and Disposal Standard. Records retention does not mean permanent retention. There are certain situations where documents must be preserved permanently, but most records need only be retained for a specified period of time. When the retention period for a particular record expires, we should destroy or delete the record. However, if we destroy or delete a record before its retention period expires, GitLab may be subject to penalties and sanctions. Unnecessary retention of records creates significant burdens for GitLab. For example, unnecessary records take up valuable storage space and make retrieval of needed records more difficult and costly. Consequently, GitLab recommends destruction of records after the retention period expires, except in those instances where GitLab directs otherwise (such as when a Litigation Hold is issued by the Legal Department). In other words, GitLab requires adherence to the records retention requirements and recommends the destruction of records according to the Retention Schedule.
2. The Difference between a “Record” and “Non-Record”
GitLab Records Retention Policy is based on a fundamental distinction between a “record” and a “non-record.” GitLab Records Retention Schedule applies only to “records.” Therefore, it is important to understand the difference between a “record” and a “non-record.”
2.1 What is a “record”?
A “record” is a Document created or received by a GitLab entity or individual in the transaction of business that contains significant business value. It is maintained to memorialize GitLab’s policies, procedures, functions, decisions, operations, processes or other business activities. The business value of a record is derived from the legal, regulatory, fiscal, operational, or informational significance of the content. “Records” must be retained throughout their life cycle in accordance with GitLab Records Retention Schedule. “Document” as used above is a piece of written, printed or electronic matter that provides information or evidence or otherwise serves as an official record and can include software application files, paper, slide presentations, spreadsheets, CAD drawings, electronic images, pictures, emails, faxes, and the like.
2.2 What is a “non-record”?
Simply stated, a “non-record” is everything that does not qualify as a “record.” Non-records are materials that GitLab does not own, materials without substantive business value, or materials that have only temporary use as reference or reminders. They are not subject to GitLab Records Retention Schedule and should be discarded when no longer needed. Examples of non-records include: Correspondence that is only needed for a short period of time and does not have substantive business value; Calendars; Informational items such as publications and extra copies of documents kept only for convenience or reference; personal or casual correspondence, Reminders and ticklers that are needed only for a short period of time and do not have substantive business value. This would include things like reminders, “post-it” notes or superseded drafts.
2.3 The difference between an original record and a copy
The original record represents GitLab’s official version of any information asset. Original records may be created by a GitLab team member, received by GitLab from an outside source, or may be forms processed by a GitLab department. A copy of a record is typically a duplicate that was created for dissemination or handy reference. There is no obligation to retain copies. Copies may be disposed of when they are no longer needed.
3. Responsibility for Developing and Managing Records
GitLab team members are responsible for making and keeping records of their work. In that regard, they have three basic obligations: Create records needed to do the business of GitLab, record decisions on actions taken, and document activities for which they are responsible.
Maintain records in a legible and readily identifiable format.
Take care of records so that information can be found when needed. This means setting up adequate directories and files, and filing materials regularly and carefully in a manner that allows them to be safely stored and efficiently retrieved when necessary.
Carry out the destruction or retention of records under their control; This includes transferring records to storage or destruction of records in accordance with GitLab Records Retention Schedule and verifying records are destroyed in a manner conducive to prevent the release of sensitive information into the public domain (i.e. erasing, shredding, etc.). The individual or department that maintains the official version of a record is responsible for managing the record. This is known as the Record Owner. The Record Owner is responsible for the use, retention, and destruction of that record, unless and until a record is officially transferred to a designated archive or storage center.
4. Management of Electronic Records
The Record Owner ensures that electronically-generated records are identified, and the systems used to store the records comply with this Records Retention Policy and Records Retention Schedule. Records may be managed in either a paper format or an electronic format. Electronic recordkeeping systems must be designed to ensure the security and integrity of the records, preservation of records for the time when they are needed, and migration of data to other GitLab systems or subsequent systems. Consequently, GitLab records should not be maintained solely on the personal hard drive, flash drive, or directories of a GitLab team member assigned only for that person’s use. GitLab team members should create an electronic filing system located in the appropriate server for their department or function, with specific folders for each team member and for each matter, and transfer their GitLab records to those folders, or at least copy them to those folders, as soon as possible after those records are created.
4.1 Emails and Slack
Much of the business conducted today is done by email and Slack. GitLab has separate guidelines with regard the use of GitLab managed messages and attachments, which covers such things as communication etiquette, prohibited use and content of communications, password and encryption key security and integrity, GitLab’s right to access information, confidential GitLab information, privileged communications and personal use of email. Email and Slack communications are subject to the same records retention procedures that apply to other documents and must be retained in accordance with GitLab Records Retention Schedule. The following guidelines apply to emails and Slack:
The status of any particular communication (i.e., whether it is a record and its retention period) is determined by its content, not the method of delivery.
The responsibility of maintaining and retaining an internally created and distributed document most often falls on the author, not the recipient.
GitLab team members who receive emails from outside GitLab are responsible for proper management of those communications. In an effort to be environmentally conscious, the printing of emails for record retention purposes is discouraged.
GitLab strongly discourages the storage of voluminous non-record email messages because of the limited value of such messages, and the cost and confusion associated with unmanaged retention and proliferation of email. Unmanaged retention of messages fills up storage space on the network servers, extends the amount of time to backup data, requires additional resources to maintain, slows performance, and can potentially lead to an inaccurate history of GitLab because it is haphazard and incomplete. As a general rule, team members are encouraged to promptly delete any non-record email messages they send or receive that no longer require action and are no longer necessary to GitLab’s business. If a non-record email no longer has business value, it should be deleted.
4.2 Other Confidential Documents
GitLab employees are discouraged from printing or creating hard copies of confidential or proprietary documents or records. Hard copies of documents containing personal data, as defined in the Data Classification Index (internal only), is restricted, unless the creation of a hard copy record containing personal data is required for legal reasons, such as mailing information related to employment or benefits. If creating hard copies is unavoidable, employees must properly dispose of hard copy records in their home offices by shredding them and/or otherwise rendering the documents unusable or unreadable. Hard copies must never be printed to be kept for any long-term time period. If they are printed and kept for a short-term time period, they must be stored in a locked cabinet, drawer or other secure location until they are no longer needed, and can then be properly discarded, as described above.
5. Retention Period
The retention periods for specific types of records are set forth in GitLab Records Retention Schedule. The Records Retention Schedule will ensure that records are safely preserved until the retention period has expired. GitLab recommends that the records be destroyed in the normal course of business in accordance with the Records Retention Policy and Records Retention Schedule. In some instances, GitLab may choose to permanently preserve information for business or historical reasons. Such records are specifically designated in the Records Retention Schedule.
6. GitLab Records Retention Schedule
GitLab Records Retention and Disposal Standard establishes the retention periods for various types of records. It applies to all records, regardless of format. Retention of records according to the Records Retention and Disposal standard must be observed to ensure consistent application of reasonable due diligence in recordkeeping practices.
GitLab’s Records Retention Policy promotes the destruction of records and other documents at the earliest possible time, in accordance with the following principles:
All records should be promptly destroyed pursuant to GitLab Records Retention Schedule. As discussed above, “non-record” materials are not subject to the Records Retention Schedule and should be discarded when no longer needed.
The retention periods in the Records Retention and Disposal Standard applies to the “original” version, or official record, of each information asset. Copies of records should be destroyed when they are no longer needed.
All record control processes will contain documented procedures clearly defining methods for identifying, storing, protecting and retrieving Records.
Identification methods should include a recommended destruction date and a mechanism for efficient retrieval of the information.
Storage will be in such a form as to preserve the integrity of the data and prevent eroding, tampering or altering the data.
Protection of the stored information will be in such a form as to ensure the integrity of the storage mechanism.
Retention will be, at a minimum, for the time period set forth in the Records Retention and Disposal Standard.
Records will be properly disposed of once the respective retention period has lapsed.
Disposal of the information will be in such a form as to protect the sensitive nature of the information therein and prevent release into the public domain.
Litigation Holds or other non-destruct directives issued by GitLab’s Legal Department override any destruction authority granted by the Records Retention Schedule. In addition, destruction of non-record materials identified in the Litigation Hold is suspended.
When the decision is made to destroy GitLab information, it must be destroyed/erased in a secure and confidential manner that is appropriate to the sensitivity of the informational content. Team members will consult the Data Classification and Handling Procedures for details on retention, destruction and storage of all Records.
7. Litigation Holds
GitLab is occasionally the subject of threatened or pending litigation or administrative proceedings. Such proceedings will suspend the normal operation of GitLab Records Retention Policy. Where appropriate, GitLab will issue a “Litigation Hold” to certain team members, departments or the entire GitLab organization. The Litigation Hold will provide a description of records and other documents that must be preserved. The failure to preserve records, documents and other evidence could subject GitLab to fines or sanctions. It is, therefore, very important to manage documents and other evidence in strict accordance with the Litigation Hold.
8. Special Situations
8.1 Mergers and acquisitions
Documents that may come into the possession of GitLab through the acquisition of another business entity, or through mergers or other agreements, are subject to GitLab Records Retention Policy. Such documents will be promptly screened and managed in accordance with the Policy directives.
8.2 Consolidations
In the event of consolidations, such as a facility closure, GitLab will continue to manage records associated with such facilities in accordance with GitLab Records Retention Policy. The following guidelines apply: All records should be transferred to the new Record Owner, or as directed by GitLab. Legal Department must be informed of the identity of the new Record Owner and provided a description of the records transferred. If a successor Record Owner is not identified, GitLab records will be transferred to the department or office most closely associated with the record’s business function. For instance, personnel files without new Record Owners must be forwarded to the People Operations Team. All other records must continue to be managed in accordance with GitLab Records Retention Policy. To ensure this, the Legal Department must be involved in all decisions concerning the destruction or transfer of such records.
8.3 Team Member Moves (Office Moves, Reassignments and Termination of Employment)
Team members are responsible for following GitLab’s Record Retention Policy for ensuring that records are properly maintained. When team member’s duties are being reassigned or the relationship with the team member is terminated, each team member should conduct an inventory of records and other materials in their possession and follow the steps listed below: If the team member has any records that belong in department files, follow the procedures for ensuring that those records are properly stored in the appropriate location. Dispose of non-record materials as soon as the team member no longer needs them. Remove or destroy any personal materials. Team members are reminded that materials relating to their jobs cannot be removed without GitLab’s permission. Identify active records that are needed for current business and arrange for their transfer to the new Record Owner or as directed. The manager of the former team member whose employment was terminated is responsible for compliance with the steps described above.
8.4 Contractual obligations
In some instances, GitLab may be required to maintain certain types of records or other types of information for designated periods of time pursuant to its contractual obligations with third parties. To the extent agreed to by GitLab, those contractual obligations must be honored. If there is a conflict between the Record Retention Schedule and a contract, the longer of the two terms shall prevail unless otherwise prevented by law.
9. Communications
GitLab Legal is responsible for implementing and managing the Records Retention Policy.
Team Member Personnel File Retention Policy
This Policy sets out the approach GitLab takes to the maintenance, retention and destruction of team members’ personnel files.
A personnel file is an official record containing employment-related personal information, held in the Company’s human resources information systems and, where applicable, with third party vendors that provide employment verification and payroll support, and maintained according to the requirements of local law. GitLab maintains personnel files for all team members currently and for the specified time periods set out by law for team members formerly employed by GitLab entities. If you are employed by a PEO, your personnel file will be maintained by your particular hiring organization.
A non-exhaustive list of the records which a team member’s personnel file might include is set out below:
A personnel file generally includes:
- hiring documentation and employment and performance records (offer letter, right to work and identification documents, records relating to performance, promotion and transfer, compensation, performance appraisals, awards or citations for excellent performance, warnings and any formal discipline,notes on attendance, and any contract or written agreement between you and GitLab);
- logs (including Growth & Development logs, Learning & Development logs, and signed acknowledgments);
- necessary medical or health and safety records*, details of leaves* and any payroll, pension or tax records (payslips, deductions, social security contributions, garnishments/attachments) (*where required, these records are maintained separately from other personnel records); and,
- separation of employment documents (including resignation letters, termination, separation or severance agreements, correspondence and reference statements).
GitLab maintains, retains, and destroys personnel records in accordance with its Record Retention Policy and Records Retention and Disposal Standard. The retention period for personnel file records may vary and the criteria used to determine the required retention period will be based on an assessment of requirements under local laws, the purpose for which the record was created and stored and the basis on which the information is being processed.
GitLab’s Records Retention Policy promotes the destruction of records and other documents at the earliest possible time and records will be properly disposed of once the respective retention period has lapsed. Disposal of the information will be in such a form as to protect the sensitive nature of the information therein and prevent release into the public domain.
GitLab is occasionally the subject of threatened or pending litigation or administrative proceedings. Such proceedings may suspend the normal operation of the GitLab Records Retention Policy. Where appropriate, GitLab will issue a Litigation Hold to certain team members, departments or the entire GitLab organization. The Litigation Hold will provide a description of records and other documents that must be preserved. The failure to preserve records, documents and other evidence could subject GitLab to fines or sanctions. It is therefore very important to manage documents and other evidence in strict accordance with the Litigation Hold. Note, that Litigation Holds or other non-destruct directives issued by GitLab’s Legal Department will override any destruction authority. If you have any questions about a Litigation Hold, please reach out to the legal team at legal@gitlab.com.
Team members can consult the Data Classification and Handling Procedures for details on retention, destruction and storage of all records.
Current and former team members may request a copy of their personnel file by submitting a request through this form. Additionally, team members can access and edit certain records at any time via Workday.
46417d02)
