Update file third-party-risk-management.md

### Leveraging Bitsight

Usage of Bitsight provides the Security Risk team with a comprehensive and continuous view of the external security posture of GitLab's vendor ecosystem. Bitsight enables Security Risk to identify and assess potential security risks across our vendors in real-time, allowing us to prioritize our resources and focus on addressing the potentially critical vulnerabilities that could impact GitLab. GitLab leverages two services:

- **Bitsight Total Risk Monitoring**

Bitsight's Total Risk Monitoring is leveraged to obtain additional assurance over the security of a vendor's externally accessible environment by use of public scans and peer benchmarking. When assessing a vendor, their Bitsight report is downloaded and reviewed to determine whether their scoring is adequate, as evidenced by an "Advanced" security rating. Bitsight ratings of "Basic" or "Intermediate" are reviewed in further depth to understand the rationale behind the lower rating and whether the deficiencies identified may indicate a risk to GitLab. Due to the wide scope of Bitsight's scans, some deficiencies may exist within areas that do not impact GitLab's usage of a vendor's service(s), and thus do not contribute to the vendor's residual risk. If deficiencies are identified that may present a material risk to GitLab, further inquiry may be performed with the vendor to determine whether they have been resolved. Un-resolved material deficiencies should be documented within the TPRM Assessment Report and reported to the Business Owner via the [TPRM Security Notice Process](#tprm-security-notice-process) defined below.

Assessors should [submit a Company Request](https://help.bitsighttech.com/hc/en-us/articles/231344488-Company-) if a vendor is not present within BitSight at the time of review.

Usage of Bitsight provides the Security Risk team with a comprehensive and continuous view of the external security posture of GitLab's vendor ecosystem. Bitsight enables Security Risk to identify and assess potential security risks across our vendors in real-time, allowing us to prioritize our resources and focus on addressing the potentially critical vulnerabilities that could impact GitLab. GitLab leverages Bitsight for continuous monitoring of most critical systems through the process below:

- **Bitsight Daily Alerting**

Bitsight's Daily Alerting is leveraged to establish a system for continuously monitoring the security posture of GitLab's highest criticality vendors to identify and respond to potential risks and vulnerabilities promptly. The use of this service enables Security Risk to maintain a proactive approach to third party security management, operating 24/7 to help safeguard GitLab sensitive data and infrastructure effectively. Changes in GitLab's Tier 1 vendor's environments could lead to further security inquiries and investigations, a new security review, or TPRM Security Notice, depending on the severity and impact to GitLab.

Assessors should [submit a Company Request](https://help.bitsighttech.com/hc/en-us/articles/231344488-Company-) if a vendor is not present within BitSight at the time of review.

### TPRM Approval Windows

The Security Risk team has established approval windows dictating the lifecycle of our TPRM assessments and their reliance in approving requisitions, after which a new assessment must be completed prior to approval of subsequent requisitions to ensure continued adherence to GitLab's regulatory and due diligence requirements. These windows are defined in alignment with the nature of the requisition, sensitivity of data shared, and the Critical System Tier

### TPRM Security Notice Process

Deficiencies identified during a TPRM review are reported to the Business Owner via a [TPRM Security Notice](https://gitlab.com/gitlab-com/gl-security/security-assurance/security-risk-team/third-party-vendor-security-management/-/issues/new?issuable_template=Security%20Notice%20%20Template) within GitLab. This issue contains (1) background information pertinent to the vendor or requisition, (2) a description of the validations performed by the Security Risk team,  and (3) a description of Security deficiencies and resulting risk that may be present to GitLab data shared with the vendor. A "worst case" scenario is included to portray the potential real-world impact of a security incident resulting from the risk. Where possible, TPRM will also include a recommendation for either mitigating or avoiding the identified risk. For deficiencies resulting from a failure in the design or operating effectiveness of a system's Security controls, a [Technical Security Validation](/handbook/security/security-assurance/security-risk/third-party-risk-management/#technical-security-validations) may be requested prior to stakeholder delivery to provide greater context within the Security Notice. These items are documented in order to support an informed decision by the Business Owner and other relevant parties.

Deficiencies identified during TPRM and Post-Implementation Controls (PIC) reviews are reported to the Business Owner via a [TPRM Security Notice](https://gitlab.com/gitlab-com/gl-security/security-assurance/security-risk-team/third-party-vendor-security-management/-/issues/new?issuable_template=Security%20Notice%20%20Template) issue. This issue contains (1) background information pertinent to the vendor or requisition, (2) a description of the validations performed by the Security Risk team,  and (3) a description of Security deficiencies and resulting risk that may be present to GitLab data shared with the vendor. A "worst case" scenario is included to portray the potential real-world impact of a security incident resulting from the risk. Where possible, TPRM will also include a recommendation for either mitigating or avoiding the identified risk. For deficiencies resulting from a failure in the design or operating effectiveness of a system's Security controls, a [Technical Security Validation](/handbook/security/security-assurance/security-risk/third-party-risk-management/#technical-security-validations) may be requested prior to stakeholder delivery to provide greater context within the Security Notice. These items are documented in order to support an informed decision by the Business Owner and other relevant parties.

#### Requisition Denial

- **Application Integrations** — Documentation of any API connections established at go-live and confirmation that API keys are managed per GitLab policy.

- **Compliance Scope** — Acknowledgment of any compliance obligations associated with the system.

Completed PIC issues are linked to the vendor's [Tech Stack](https://helplab.gitlab.systems/esc?id=gitlab_cmdb_applications) record. Questions can be directed to @security-risk in the #security_help channel.

Completed PIC issues are linked to the vendor's [Tech Stack](https://helplab.gitlab.systems/esc?id=gitlab_cmdb_applications) record. Questions can be directed to @security-risk in the #security_help channel.

Where a control domain identifies a deficiency against GitLab's requirements and no compensating control is present, Security Risk opens a [TPRM Security Notice](https://gitlab.com/gitlab-com/gl-security/security-assurance/security-risk-team/third-party-vendor-security-management/-/issues/new?issuable_template=Security%20Notice%20%20Template) for the Business Owner's sign-off, following the [TPRM Security Notice Process](#tprm-security-notice-process).

### Other Types of Third Party Assessments