The Controlled Documents Annual Review Work Instruction focuses on the annual review of Controlled Documents to ensure they are meeting procedural expectations. The Controlled Document Procedure is in place to ensure that there is consistency in developing and maintaining controlled documents at GitLab according to legal and regulatory requirements.
Goal: 100% of controlled documents reviewed and approved annually.
| Document Name | Description | URL | Code Owners |
|---|---|---|---|
| Acceptable Use Policy | Specifies requirements related to the use of GitLab computing resources and data assets by GitLab team members so as to protect our customers, team members, contractors, company, and other partners from harm caused by both deliberate and inadvertent misuse. | https://about.gitlab.com/handbook/people-group/acceptable-use-policy/ | Security, Legal and PeopleOps |
| Access Management Policy | Specifies Centralized access management ensuring that the authorized GitLab team-members have access to the correct data and systems at the correct level. | https://about.gitlab.com/handbook/security/access-management-policy.html | Security Assurance Management |
| Access Review Procedure | Defines the importance of the User access review process as an important control activity required for internal and external IT audits, helping to minimize threats, and provide assurance of who has access to what. | https://about.gitlab.com/handbook/security/security-assurance/security-compliance/access-reviews.html | Security Compliance Team |
| Application Vulnerability Management Procedure | Designed to provide insight into our environments, promote healthy patch management among other preventative best-practices, and remediate risk; all with the end goal to better secure our environments and our product. | https://about.gitlab.com/handbook/security/security-engineering/application-security/vulnerability-management.html | Security Management |
| Audit Logging Policy | Ensures the proper operation and security of critical information system activity. | https://about.gitlab.com/handbook/security/audit-logging-policy.html | Security Assurance Management |
| Backup Procedure | Documents that our production databases are taken every 24 hours with continuous incremental data (at 60 sec intervals). | https://about.gitlab.com/handbook/engineering/infrastructure/production/#backups | Infrastructure Management Team |
| Backup Recovery Testing Procedure | Documentation implementing a backup testing pipeline to detect whether or not the backup is actually restorable and in good shape. | https://gitlab.com/gitlab-com/gl-infra/gitlab-restore/postgres-gprd/blob/master/README.md | Infrastructure Management Team |
| Business Continuity Plan | Documentation of our overall organizational program for achieving continuity of operations for business functions. Continuity planning addresses both information system restoration and implementation of alternative business processes when systems are compromised. | https://about.gitlab.com/handbook/business-technology/gitlab-business-continuity-plan/ | Information Technology Team |
| Business Impact Analysis (BIA) | Documents how we identify and prioritize system components by correlating them to mission critical processes that support the functioning of GitLab. | https://about.gitlab.com/handbook/security/security-assurance/security-risk/storm-program/business-impact-analysis.html | Security Risk Team |
| Change Management Procedure | Specifies requirements to manage changes in the operational environment with the aim of doing so (in order of highest to lowest priority) safely, effectively and efficiently. | https://about.gitlab.com/handbook/engineering/infrastructure/change-management/ | Infrastructure Management Team |
| Controlled Document Procedure | Deploying control activities through policies and standards that establish what is expected and procedures that put policies and standards into action ensuring there is consistency in developing and maintaining controlled documents at GitLab utilizing a hierarchal approach for managing legal and regulatory requirements. | https://about.gitlab.com/handbook/security/controlled-document-procedure.html | Security Assurance Management |
| Cryptography Standard | Defines approved cryptographic algorithms, settings, and cryptographic modules for the purposes of encrypting data at rest or in transit within the various systems and subsystems used by the GitLab product. | https://about.gitlab.com/handbook/security/cryptographic-standard.html | Security Management |
| Data Classification Standard | Defines data categories and provides a matrix of security and privacy controls for the purposes of determining the level of protection to be applied to GitLab data throughout its lifecycle. | https://about.gitlab.com/handbook/security/data-classification-standard.html | Security Assurance Management |
| Data Protection Impact Assessment (DPIA) Policy | Ensures that our use of personal data is fully understood, that risks to the rights and freedoms of individuals resulting from the processing of personal data are carefully examined and that all appropriate measures are put in place to protect these rights throughout the lifecycle of the processing. DPIAs, in conjunction with the associated forms and guidance, should be used to ensure that our obligations and policies in this area are met. | https://about.gitlab.com/handbook/legal/privacy/dpia-policy/ | Security Management |
| Data Management Standard | Documents how the data team delivers results that matter securing our data. | https://about.gitlab.com/handbook/business-technology/data-team/data-management/ | Data Team Management |
| Data Platform Guidelines | Identifies our guidelines for the data flow diagram, system tiers and access. | https://about.gitlab.com/handbook/business-technology/data-team/platform/ | Data Team Management |
| Database Disaster Recovery Procedure | Documents our disaster recovery for databases. | https://about.gitlab.com/handbook/engineering/infrastructure/database/disaster_recovery.html | Infrastructure Management Team |
| Disaster Recovery Procedure | Documents our disaster recovery. | https://gitlab.com/gitlab-com/gl-infra/readiness/-/blob/master/library/disaster-recovery/index.md | Infrastructure Management Team |
| Encryption Policy | Documents the encryption process in which data is securely encoded at rest and in transit to remain hidden from or inaccessible to unauthorized users to better protect private, proprietary and sensitive data and enhance the security of communication between client applications and servers. | https://about.gitlab.com/handbook/security/threat-management/vulnerability-management/encryption-policy.html | Security Threat Management |
| EndPoint Management Procedure | GitLab utilizes centralized laptop management for company-issued laptops. | https://about.gitlab.com/handbook/business-technology/team-member-enablement/onboarding-access-requests/endpoint-management/ | Business Technology Management |
| GCF Security Control Procedure | GCF Security Controls identified that need to be implemented by the security compliance team and dedicated team for compliance or regulatory reasons, these controls follow an established process in order to make that implementation successful. | https://about.gitlab.com/handbook/security/security-assurance/security-compliance/security-control-lifecycle.html | Security Compliance Management |
| GitLab Password Standards | 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. | https://about.gitlab.com/handbook/security/password-procedure.html | Security Assurance Management |
| GitLab Terms of Service | Documents the terms of service when using GitLab | https://about.gitlab.com/terms/ | GitLab Legal |
| Information Security Management System (ISMS) | Documents the boundaries and objectives of GitLab's ISMS | https://about.gitlab.com/handbook/security/ISMS.html | Security Assurance Management |
| Infrastructure Vulnerability Management Procedure | This procedure provides insight into the GitLab production environment, promotes healthy patch management among other preventative best-practices, and remediates risk; all with the end goal to better secure our environments and our product | https://about.gitlab.com/handbook/security/threat-management/vulnerability-management/Infrastructure-vulnerability-procedure.html | Security Threat Management |
| IT Help Team Standards | Documents IT Support responsibilities for onboarding and managing company assets. | https://about.gitlab.com/handbook/business-technology/team-member-enablement/self-help-troubleshooting/ | Business Technology Management |
| IT Ops Policy and Standards | Documents IT Operations responsibilities for onboarding and managing company assets. | https://about.gitlab.com/handbook/business-technology/employee-enablement/it-ops-team/ | Business Technology Management |
| Network Security Management Procedure | Documents network security and privacy requirements for the safety of GitLab's network infrastructure | https://about.gitlab.com/handbook/engineering/infrastructure/network-security/ | Infrastructure Management |
| Off-boarding Procedure | Documents off-boarding step by step process that covers all the steps necessary to successfully part ways with an employee following their resignation or termination. When done well, a clear offboarding process ensures a smooth transition for both the company and the departing employee. | https://about.gitlab.com/handbook/offboarding/offboarding_standards/ | People Management |
| Penetration Testing Policy | Document determines whether or not defensive measures employed on the system are strong enough to prevent security breaches. Penetration test reports also suggest the countermeasures that can be taken to reduce the risk of the system being attacked. | https://about.gitlab.com/handbook/security/penetration-testing-policy.html | Security Assurance Management |
| People Policies | These policies document the benefits, procedures, and requirements of the company. | https://about.gitlab.com/handbook/people-policies/ | People Management |
| Production Architecture | The GitLab.com core infrastructure is primarily hosted in Google Cloud Platform's (GCP) us-east1 region (see Regions and Zones)—and we use GCP iconography in our diagrams to represent GCP resources. We do have dependencies on other cloud providers for separate functions. Some of the dependencies are legacy fragments from our migration from Azure, and others are deliberate to separate concerns in the event of cloud provider service disruption. This document does not cover servers that are not integral to the public facing operations of GitLab.com. | https://about.gitlab.com/handbook/engineering/infrastructure/production/architecture/ | Infrastructure Management Team |
| Records Retention & Disposal Procedure | Documents the specific retention and secure disposal requirements for critical GitLab records. | https://about.gitlab.com/handbook/security/records-retention-deletion.html | Security Risk Management |
| Security Operational Risk Management Procedure | The Information Security Risk Management Program performs risk analysis of information resources that store, process or transmit an organization's data. The purpose of the Security Operational Risk Management (“StORM”) program at GitLab is to identify, track, and treat security operational risks in support of GitLab's organization-wide objectives. The Security Risk team utilizes the procedures below to ensure that security risks that may impact GitLab's ability to achieve its customer commitments and operational objectives are effectively identified and treated. | https://about.gitlab.com/handbook/security/security-assurance/security-risk/storm-program/ | Security Risk Management |
| Security Change Management Procedure | Outlines the procedural change management steps as they relate to the Security Department. | https://about.gitlab.com/handbook/security/security-change-management-procedure | Security Assurance Management |
| Security Compliance Observation Creation Procedure | Defines the risks identified at the information system or business process levels and details the creation process for observations. | https://about.gitlab.com/handbook/security/security-assurance/observation-management-procedure.html | Security Compliance Management |
| Security Compliance Observation Remediation Procedure | Defines the risks identified at the information system or business process levels and details the remediation process for observations. | https://about.gitlab.com/handbook/security/security-assurance/observation-remediation-procedure.html | Security Compliance Management |
| Security Incident Communications Plan Procedure | Documents the communication response plan to map out the who, what, when, and how of GitLab in notifying and engaging with internal stakeholders and external customers on security incidents. This plan of action covers the strategy and approach for security events which have a ‘high’ or greater impact as outlined in GitLab’s risk scoring matrix. | https://about.gitlab.com/handbook/security/security-operations/sirt/security-incident-communication-plan.html | Security Management |
| Security Incident Response Guide | Documents the responsibilities of all GitLab team members when responding to or reporting security incidents. | https://about.gitlab.com/handbook/security/security-operations/sirt/sec-incident-response.html | Security Management |
| Security Operations On-Call Guide (Major Incidents) | Documents how the Security Operations Team (SecOps) is collectively on-call 24/7/365, split into 12-hour shifts Monday to Friday and 48-hour coverage Saturday and Sunday. | https://about.gitlab.com/handbook/security/secops-oncall.html#major-incident-response-workflow | Security Assurance Management |
| Security Trainings Procedure | Describes the security awareness training program that provides ongoing training to GitLab team members that enhances knowledge and identification of cybersecurity threats, vulnerabilities, and attacks. | https://about.gitlab.com/handbook/security/security-assurance/governance/sec-training.html | Security Assurance Management |
| Third Party Risk Management Program | Documents the process in order to minimize the risk associated with third party applications and services. The Security Risk Team performs security reviews on new and renewing third party vendors that are requested through the procurement process. | https://about.gitlab.com/handbook/security/security-assurance/security-risk/third-party-risk-management.html | Security Risk Management |
| Token Management Standard | Outlines "GitLab's" approved standards for token usage, settings, and distribution for the purposes of providing authentication and authorization within the various systems and subsystems used to support "GitLab's" product. | https://about.gitlab.com/handbook/security/token-management-standard.html | Security Assurance Management |
| Vulnerability Management Standard | Documents the continual process of identifying, prioritizing, mitigating and remediating vulnerabilities. This standard will focus on impact to in-scope GitLab systems in order to reduce the risk relating to security vulnerabilities that could impact the achievement of GitLab goals. | https://about.gitlab.com/handbook/security/threat-management/vulnerability-management/ | Security Threat Management |
| Role | Responsibility |
|---|---|
| Security Governance Team | Responsible for maintaining the work instructions and facilitating annual controlled documents review |
| Security Compliance Team | Responsible for testing Security Policies and supporting standards and procedures as part of ongoing continuous control monitoring |
| Security Assurance Management (Code Owners) | Responsible for approving changes to these work instructions |
| Code Owners | Responsible for defining, implementing and maintaining controlled documents for their programs |
| Everyone | Everyone is welcomed and encouraged to create or suggest changes to controlled documents at any time. |
Controlled documents are required to be reviewed and approved on a minimum of an annual basis and may be updated ad hoc as required by business operations.
The Security Governance team will initiate and track the annual review via a GitLab Epic. Issues will be opened for each department and assigned to the relevant Code Owners with a list of in scope documents and instructions. Merge Requests will be opened in cases where changes are required and tracked via the same issue.
When a new controlled document is identified, an MR should be opened and assigned to Security Governance to add the document to the List of Controlled Documents.
The Controlled Documents Template should be applied at this time if not already done.
Exceptions to this program will be tracked as per the Information Security Policy Exception Management Process.
