System

The vendor management process will be supported by our ‘Vendor Management’ Jira project, where all vendor requests will be handled through a service desk ticket. The Jira service desk form will collect information needed by all teams typically involved in vendor approvals and fire off sub-ticket review tasks linked to the review team’s Jira project boards.

Vendor Types

• Software: this can be SaaS or non-SaaS products
• Services: Consulting services; any company that is commissioned to perform knowledge enhancing project-based work for Sourcegraph. Examples of this include any work that concludes with a report issued to the company, product development work, training development, sales & marketing projects and regulatory consulting work.
• Temporary contractors : Individuals that have been contracted for a limited amount of time to enhance/assist/deliver project base work (they are a separate group since their access level to data will most likely be different to a ‘Service’ engagement)
  • For temporary contractors, we use our standard forms, which you can find in the Vendor contracts section of our Contract review and signature policy.

Request type

There are four types of request tickets that we support:

• New vendor onboarding - new contracts/services/tools
• Annual review - annual risk review that helps us keep track of vendor risk (i.e. are their certifications still in place, did any of their policies change, etc.)
• Offboarding - when we want to terminate or sunset a vendor we have previously engaged with

Data

Our process captures the baseline information needed to process vendor requests :

• Vendor Name
• Vendor Description
• Vendor Web Link
• Vendor Type
• Data Classification and Description
• Budget Requirements
• Cost Center Information
• Procurement Partner Engagement (i.e. Vendr )
• System/Relationship Owner
• Documentation (incl. DPA, MSA, etc.)

As we improve our process, additional information will be captured during the ticket creation that will facilitate due diligence reviews (for instance requestors will be asked for specific security review related information at time of vendor request creation)

Reviewer Teams

The teams involved in the due diligence process for the vendor review will be notified about new reviews through a Jira sub-ticket, which will be triggered and created according to our triage/review logic (see below). Each team is responsible for monitoring their Jira boards for new review tickets that need to be resolved in a timely manner (see SLAs below). There is no particular order in which the reviews need to be done (i.e. they can be worked on in parallel). Once a vendor has been reviewed please mark your sub-ticket as approved/rejected as appropriate (and provide as much information in the ticket comments on why this decision has been made). This will automatically reflect in the status of the parent ticket (i.e. the original vendor request ticket):

• Security: 7 business days SLA (from sub-ticket creation date)
• Legal : 7 business days SLA (from sub-ticket creation date)
• Finance : 7 business days SLA (from sub-ticket creation date)
• Tech Ops : 10 business days SLA (from ticket creation date)

Triage and Review Logic

From a vendor management perspective we base our review requirements on the sensitivity of data that is shared with the vendor. According to our Data management policy we will route each of the classifications for reviews as follows:

• Restricted: Security, Legal, Tech Ops
• Private: Security, Legal, Tech Ops
• Internal: Security, Legal, Tech Ops
• Public: Tech Ops, Legal

From a procurement standpoint, we have an additional decision factor of ‘budget’, which determines if a finance review happens as part of the vendor request.

Note: Any budget approvals and discussions sit outside the vendor management process. They are a part of the procurement process and are a prerequisite for vendor requests.

Please see below matrix for review requirements for ANY type of vendor:

As we improve the form and capture more details for the request, we will be able to build more sophisticated routing rules and pre-checks for the review teams to minimize manual input, specifically for recurring standard requests.

Security

Security approval - information needed and reviewed:

• What type of information is being shared with the vendor: customer data, sourcegraph data, both?
• Security compliance certifications like ISO27001 or SOC 2.
• Encryption standards of data at rest and in transit (transport layer security).
• Clear measures around confidentiality, integrity, availability, and resilience of processing systems and services.
• Clear process in case of a security incident and the reporting to Sourcegraph.
• Ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident.
• Periodic testing on security, assessing and evaluating the effectiveness of technical and organizational measures for ensuring the security of the processing.

Legal

Tech Ops

Tech Ops approval - information needed and reviewed:

• Okta provisioning and/or SAML available?
• If no, how is access protected

Finance

Finance approval - information needed and reviewed:

• Airbase CC and/or PO# based on paying bills policy
• Contract & commercial terms
• W-9