Vendor Management

Background

Narrative makes every effort to assure all IT vendors and subprocessors who have the ability to impact the confidentiality, integrity, and availability of Narrative’s technology and sensitive information are compliant and do not compromise the integrity, security, and privacy of Narrative or its customer data. The following applies to applicable such IT vendors and partners:

• IT vendors and subprocessors are prohibited from accessing Narrative’s information security assets until a contract containing security controls is agreed to and executed by the appropriate parties.
• IT vendors and subprocessors must comply with the security policies defined and derived from Narrative’s Information Security Program.
• IT vendors and subprocessors must ensure that relevant sensitive information is protected, safeguarded, and disposed of securely. Narrative strictly adheres to all applicable legal, regulatory and contractual requirements regarding the collection, processing, and transmission of sensitive data such as Personally-Identifiable Information (PII).
• Narrative may choose to audit IT vendors and subprocessors to ensure compliance with applicable security policies, as well as legal, regulatory and contractual obligations.

New Vendor Procurement

The process of evaluating a new vendor and getting them approved for internal use or to integrate them into the product.

Participants:

• Requester: the individual requesting the procurement of a new vendor.
• Security Engineer: a member of the Security Engineering team

Out of scope for this document are:

• Criteria for evaluating a vendor with respect to its suitability for its intended use in the organization.
• Obtaining approval from finance and/or operations for procurement of vendor.

Prototyping

Responsible parties:

• Requester

During the prototyping phase of evaluating potential vendors we adopt a flexible policy that, in general, allows for the use of low risk vendors without a lot of ceremony. However, there are cases where a vendor must be vetted and aproved by the Security Team prior to use.

A security review is required prior to prototyping if any of the following conditions hold:

• The vendor will process to any confidential or restricted data as part of the prototype, especially any data that is subject to regulatory scrutiny like PII. See the Data Classification Policy for help determining what is confidential or restricted.
  • NB: this includes if prototyping will require that the vendor integrate with an existing system that may contain confidential or restricted data. E.g., if we're sharing some non-sensitive, internal-use document for processing with a vendor that's fine, but if they need broad access to files we store in Google Drive then a review is required.
• The vendor requires access to any part of Narrative's infrastructure. E.g., if we're sending server performance metrics to a vendor via an API integration where we're always in control of what data is sent then that's fine, but if a vendor requires that we set up an AWS IAM role that allows them broad access to our accounts then a review is required.

Protection of Narrative's intellectual property is also a concern: if a vendor's solution involves the exchange or handling of proprietary data like code artifacts, then prototype using low value or open source repositories.

If you're not sure whether a security review is required, please reach out to the security team using on Slack in the #security channel.

Vendor Procurement Request

Responsible parties:

• Requester

Prior to the use of a vendor in production we require that they be reviewed by a member of the Security Engineering team to determine the level of risk Narrative is assuming by working with the vendor and how to mitigate that risk.

Create a Vendor Assessment Request Shortcut Ticket and fill out the required vendor details. From there, a member of the Security Team will perform an assessment and lay out next steps.

Risk Assessment

Responsible parties:

• Security Engineer

The first step is evaluating a vendor is establishing a "risk level". Our risk classification levels are:

• High: the vendor stores or has access to sensitive data or a failure of this vendor would have critical impact on Narrative.
• Moderate: the vendor does not store or have access to sensitive data and a failure of this vendor would not have critical impact on Narrative.
• Low: the vendor doesn't store or have access to any data and a failure of this vendor would have very little to no impact on Narrative.

In assigning a classification level, proceed through the following steps:

• Review vendor information:
  • What products or services are we using and what is the nature of our engagement with them?
  • Specifically: what data are they storing or processing? How will Narrative employees access their systems?
• Identify the classification level of the data involved: will the vendor store or process customer-provided data, personally identifiable information (PII), intellectual property, or any regulated information?
• Determine whether the vendor's access controls meet our standards:
  • Can we authenticate using SSO?
  • If not, does the vendor have a secure password policy and enable us to enforce MFA?
• What would happen in the following scenarios? Consider the impact on Narrative, customers, and regulatory compliance.
  • The vendor was breached and all the data they were storing became public?
  • The vendor suffered and outage and would be unavailable for 24 hours or more?
  • Our access to the vendor's systems or services is compromised? What are the potential risks of unauthorized access, data manipulation, or other malicious activities? Weigh this outcome by how likely this is to happen.

Example classifications:

• Narrative uses Amazon Web Services (AWS) to power almost every piece of functionality on the platform, including storing and processing all customer-owned data. Failure or compromise of AWS would result in severe disruption to Narrative's business operations. This is a clearly a high-risk vendor.
• We use OpenAI's models to build automation into our platform, e.g., it powers our AI Data Assistant, Rosetta. However, no confidential or restricted data is sent to OpenAI and their failure would result in the impairment of some of our services, but not materially affect our ability to continue to do business. This is a moderate-risk vendor.
• Maxmind APIs are used to get enriched information about IP addresses for a small set of customer use cases. They neither process nor store any interesting data and their failure would result in, at most, a moderate loss of revenue. They are a low-risk vendor.

Update the Vendor Procurement request ticket with your assessment of the risk level.

Contract Review

Responsible parties:

• Security Engineer

Formal contracts or documentation that address relevant security and privacy requirements should be in place for all IT vendors or subprocessors that process, store, or transmit confidential data or provide critical services.

Contracts must be reviewed in accordance with the following criteria, where applicable:

• Vendor accepts complete or shared responsibility for the security of the institution’s confidential data that it possesses, stores, processes, or transmits.
• Vendor ensures that security controls are regularly reviewed and validated by an independent party, and that relevant certification reports are accessible to Narrative.
• Vendor identifies the recourse available to Narrative should the vendor fail to meet defined security requirements.
• Vendor establishes responsibilities for responding to direct and indirect security incidents.
• Vendor specifies the security requirements for the return or destruction of data upon contract termination.
• Vendor implements geographic limits on where data can be stored or transmitted

For most vendors, this simply involves reviewing the Privacy Policy and Terms of Use.

Any findings should be noted on the Vendor Procurement ticket.

Compliance Report Review

Responsible parties:

• Security Engineer

If the vendor has been classified as high-risk, then some additional diligence is required on the part of the Security Team: we have to review a compliance report to ensure that the vendor's security controls are well-designed and satisfy our security requirements.

• The first step is to request a compliance report. In almost all cases a SOC 2 Type II report is sufficient, but it's somewhat context-dependent. E.g., if reviewing a new payment processor, we want evidence of PCI Compliance.
  • If an (Mutual) Non-Disclosure Agreement is required to access the relevant report, then it can be signed by any authorized agent at Narrative. In order of preference, you can ask the vendor to send the MNDA to the person acting in any of the following roles for signature: Head of Engineering, Security Officer, Founder (Nick Jordan)
• If an appropriate compliance report (SOC2 Type II, ISO 27001) is not available, then we'll have to have the vendor complete a questionnaire, e.g. a relevant subset of the Consensus Assessments Initiative Questionnaire.
• The report or questionnaire must be reviewed and recorded on the Drata vendor management page.

System Access Setup

Responsible parties:

• Security Engineer

Assuming the vendor has been approved for use, we next need to ensure that appropriate personnel are given access to the vendor in accordance with our System Access Control Policy. In practice this means:

• Only people who require access are granted credentials to the vendor systems, and persmissions must be minimally scoped to only include what the accessor requires to perform their job duties.
• All access controls must be granted following our usual account provisioning procedures.
• Access to the vendor cannot grant someone access to confidential or restricted information that they otherwise should not have access.

As a general rule, a member of the Security Team should be responsible for provisioning accounts with vendors, this helps us ensure that best practices are followed in the creation of accounts and delegation of permissions. If an account is already provisioned, then the Security Engineer should be granted administrative access.

The Security Engineer then set up access for Narrative employees to the vendor and sets roles/permissions as appropriate.

The Security Engineer is responsible for:

• Ensuring that MFA is enforced in the vendor's product if possible. If not, the Security Engineer must ensure all accessors have MFA enabled.
• Ensuring that appropriate members of the Security Team have access to the vendor's product. The justification for Security Team members having access is that in case of offboarding, termination, or account compromise, we require that someone who is on call is available and able to take action.

Update Vendor Inventory

Responsible parties:

• Security Engineer

Our policies require that we maintain an up-to-date inventory of the vendors we work with.

The following spreadsheet serves as our canonical list of vendors, which needs to be updated with appropriate information: Vendor Management List

Any compliance reports or contracts must be stored in the Security/Vendors folder in Google Drive.

Update System Access Documentation

Responsible parties:

• Security Engineer

Assuming the vendor has been approved for use, we need to update our onboarding and offboarding documentation to ensure that we both review who has access to the vendor and revoke access as necessary.

Notify Customers

Responsible parties:

• Security Engineer

If the vendor is a sub-processor of customer personal data, we notify customers that a new vendor has been added.

We may also choose to notify customers if the vendor affects "matters concerning internal controls", i.e. changes that affect the security or confidentiality of their data on the platform.

Take for example this message from Drata:

With trust at the center of everything we do, we're enhancing and evolving the Drata platform every day to ensure we maintain a secure environment, so that you can do the same for your customers. In order to continue to improve our platform, we will be launching new functionality by partnering with Cenus.

As this new vendor (sub-processor) may process your organization’s “personal data” as defined under the European Union’s General Data Protection Regulation (GDPR) in connection with the services and products that Drata provides, this communication shall serve as notification that they will be added as new Drata sub-processor.

Name Cenus Data Location United States Description of Processing Reverse ETL

This sub-processor has been evaluated in accordance with Drata's third-party risk management process. If you have any questions, please reach out to privacy@drata.com.

Thank you for being a Drata customer!

Coordinate with the Product and Partner Success teams to draft and send a message to customers.

Annual Vendor Reviews

Participants:

• Security Engineer

Once per year we review do a review of all our vendors to assure that they are still being used, that their risk classification level is appropriate, and to review updated security compliance documentation to ensure both that the vendor has appropriate controls in place and our compensating user entity controls are adequate and being followed.

todo(mbabic)

• further define process in a way that leaves appropriate evidence
• technically we are only required to review high risk vendors in Drata