Cyber Risk in the Vendor Ecosystem

The past several years have demonstrated a transition from enterprise-wide cyber-risk management to ecosystem-wide cyber-risk management. In enterprise-wide cyber-risk management, each individual company protects the security of its own information assets and systems. The ecosystem approach recognizes that other parties outside of the company may increase or reduce the company’s cyber-risk exposure and attempts to manage this external risk. This article provides an overview of the vendor ecosystem, addresses cyber risk assessment, and concludes with a discussion of cyber risk mitigation by contract.

I. Overview of the Vendor Ecosystem

In evaluating the cyber risks posed by a vendor relationship, the customer (Customer) should consider the entire ecosystem of the vendor (Vendor). The Customer-Vendor relationship is not binary. Rather, the Vendor is a Customer of other vendors and a contractor to its various subcontractors; it may have other relationships that could impact the Vendor’s services to the Customer or the Customer’s cyber-risk exposure.

Figure A shows the Vendor’s subcontractors and service providers on the Extended Ecosystem to the left of the Vendor. To the right of the Vendor are Customer-related parties that may interface with the Vendor or its subcontractors or service providers. These include the Customer’s subcontractor, customers, and customers’ customers, as shown.

The Vendor operates downstream from its various licensors and service providers and is dependent upon these third parties to provide services to the Customer. Consider a Vendor providing licensed software (Licensed Software) in a software-as-a-service (SaaS) environment. The Vendor grants a limited license to the Customer in the Licensed Software but retains possession of the Licensed Software and operates and maintains the Licensed Software on the Customer’s behalf. The Vendor may own the Licensed Software but has likely licensed third-party components of the Licensed Software from other owners or licensors, and has licensed other software from third parties that acts in combination with the Licensed Software to provide the SaaS service to the Customer. For these types of risks, the Vendor may be limited in its ability to select or influence its upstream service providers and in its ability to promise or pass on to the Customer certain assurances and commitments, rights and remedies, and service levels from its upstream providers.

The Vendor subcontracts various aspects of its operations to service providers. For example, in the SaaS context, the Licensed Software may be owned by the Vendor, but maintained and operated at a third-party data-processing center. This means that although the Customer contracts with the Vendor for the SaaS service, it may directly interface with the Vendor’s subcontractor that operates the data-processing center, or the data-processing center may otherwise have access to the Customer’s information or systems. In this context, the quality of the services and the extent of the cyber risk may be dependent upon the performance of the Vendor’s subcontractors. For the types of risk posed by the Vendor’s primary subcontractors, the Vendor may have greater bargaining power than in the upstream scenario and may be able to “flow down” certain requirements and performance standards to the subcontractors. The Vendor would be expected to have the ability to monitor and mitigate risks posed by subcontractors. Figure B shows how Vendor-related parties may be involved in providing services to the Customer.

The Customer may have obligations to its Customers or its customers’ customers that may impact the Vendor services and attendant cyber risk. Using the SaaS example, the Vendor’s subcontractor data-processing center may have access to consumer data owned by the Customer’s customers. For example, consider a Customer that offers payroll services to its customers, which involves consumer data of its Customer’s employees. The Customer outsources the ACH processing of the payroll to the Vendor, and the Vendor subcontracts with a data-processing center to prepare the ACH files to make payroll payments from the accounts of the Customer’s employer customers to the accounts of their consumer employees. The Customer’s customers’ responsibilities to preserve the security of employee information will be delegated by the Customer to the Vendor, which will in turn delegate that to its subcontractor that operates the data-processing center. The cyber risks to the consumer employee information may be exacerbated at each point of access to the employee information.

The Customer’s subcontractors and upstream service providers may also interface with the Vendor or provide information to the Vendor or impose requirements on the Customer that would apply to the Vendor. The Customer must consider the cyber risk arising out of contacts between these third parties and the Vendor.

Figure A: Vendor Ecosystem

Figure B: Vendor-Related Parties

Cyber-Risk Assessment in the Vendor Ecosystem

The initial cyber-risk assessment conducted by the Customer with respect to a proposed vendor arrangement may be complicated by the web of upstream service providers and subcontractors that touch the Vendor’s or Customer’s information or systems. When the Customer’s information is classified as proprietary or confidential, the Customer should first identify all information access vectors and risk exposures posed by the vendor relationship. The next step is to identify all third parties involved in those access vectors and determine whether the third parties are upstream service providers or subcontractors of the Vendor, or customers or subcontractors of Customer, or some other third party. Other third parties may include regulators, law enforcement, or other nonparties that may have access to confidential information or that may mitigate risk to the security of such information.

The information-security risk assessment regarding the third parties that operate within the Vendor ecosystem will vary depending on whether the third party is an upstream service provider or subcontractor, and to the extent that the third party has the ability to access, modify, disclose, or exfiltrate the proprietary and confidential information of or interface with Customer or Vendor systems. These types of third parties are described in the “Extended Ecosystem” inside ring in Figure A.

Consider the SaaS context described above. If an upstream third-party component of the Licensed Software infringes an intellectual property right of another, then the Customer’s liability exposure for infringement may be heightened; if the third-party licensor does not touch the Customer’s information, however, the information-security risk may be negligible. If a subcontractor of the Vendor is understaffed, and there are delays in service but no impact on Customer information, the transactional or reputational risks to the Customer may be heightened, but not necessarily the information-security risks.

Some risks may implicate a variety of service providers. For example, again in the SaaS context, if there is a widespread power outage, the access vector (interface with the data-processing center) may not be available, but there may be no ensuing risks to the Customer information if all access is suspended. If a data-processing center loses power, however, and does not have adequate back-up capabilities and resiliency, the Customer’s information that is maintained by the data-processing center may be at risk. In order to manage this risk, the Customer would likely decide to address the Vendor’s responsibilities in the event of a power outage. Power outages are foreseeable risks that may not be managed by the Customer directly with the Vendor’s subcontractor’s power company.

Steps in this assessment include:

• identifying the types of third parties that may access the Customer’s proprietary and confidential information (whether from the Customer directly or from another third party)
• classifying the third party as an upstream service provider or a subcontractor of the Vendor
• identifying the specific types of risks posed by the Vendor and each third party
• assigning a risk level posed by the Vendor or each third party for the types of risks identified
• determining whether third-party risk requires mitigation by the Customer and/or the Vendor

Certain third parties may require direct assessment by the Customer if an entire Vendor function (or comparable access to information or systems) is delegated to the third party. For example, in the SaaS context, the Customer may engage in due diligence of the data-processing center directly and require the Vendor by contract to monitor and manage risks posed by the center.

The outer ring of Figure A identifies possible external risk factors that may serve to mitigate the cyber risks posed by the Vendor ecosystem. These include:

• cyber insurance coverages held by the Customer or by the Vendor that would apply to certain types of risks identified during the assessment process
• payment system rules or regulatory oversight applicable to the Vendor regarding certain cyber risks
• external audits (like SSAE 16 or SOC-2 audits or National Automated Clearing House Association (NACHA) audits) or certifications (like PCI compliance or ISO 27001) made of the Vendor (or the Vendor-related parties) addressing the types and levels of cyber risk

Consider again the payroll processor example above. The Customer is the payroll processor providing services to its customers by facilitating wage payments to its customers’ employees. The Customer outsources the ACH debit-origination process to the Vendor; the Vendor will be bound by the NACHA operating rules and must format payments as required by the rules. This external requirement serves to mitigate certain security risks attendant in the payment process.

Similarly, if the Vendor subcontracts with a data-processing center and the center is SOC-2 audited annually, the risk posed by the security protocols and standards observed by the center should be mitigated, or at least monitored, by the SOC-2 assessment process.

The types and levels of cyber risk to the Customer posed by the extended Vendor ecosystem in the inside ring of Figure A should be mapped to any external cyber-risk mitigants, like those set forth on the outer ring of Figure A. In that way, the Customer can quantify its level of cyber risk posed by the Vendor relationship and its ecosystem, and identify any gaps that may require additional mitigation.

Mitigation of Cyber Risk in the Vendor Ecosystem

Generally, the Customer-Vendor contract should identify which contracting party is responsible for managing the specific types of cyber risk posed by the relationship. The contract between the Vendor and the Customer should address each party’s obligations regarding the cyber risks that it poses and third parties that pose information-security risk to the other party (i.e., key third parties). The types of Vendor-related parties that should be considered are shown in Figure B and are addressed in greater detail above. The Customer’s ability to mitigate information-security risk posed by key third parties will vary depending on whether the key third party is an upstream service provider or a subcontractor of the Vendor. The ability to manage these cyber risks by contract will be further dependent on the following:

• the terms of the Vendor’s contracts with the key third parties
• the Vendor’s bargaining leverage with the key third parties
• the Vendor’s ability to monitor the key third parties

In many instances, the Vendor’s contracts with key third parties may be confidential. Moreover, the Customer will not likely be a third-party beneficiary of such contracts. Therefore, it is important that these risks be addressed directly in the Vendor-Customer contract or otherwise mitigated by the Customer or the Vendor (whether through due diligence, independent monitoring, reliance on other third-party monitoring, or other practical way to address key third-party risk).

The goal of the contract should be to mitigate cyber risks that are not otherwise mitigated or to incorporate external mitigants as part of the Contract. Examples of external mitigants are shown on the outer ring of Figure A and were discussed above.

Key cyber risks identified by the Customer during the risk-assessment process should be addressed in the Vendor-Customer contract. The following types of contract terms should be considered: the imposition of specific requirements, mechanisms for the Customer to monitor whether such requirements are met, and remediation in the event of any failures by the Vendor.

The Vendor-Customer contract may require the Vendor to ensure that the Vendor and key third parties comply with general contractual standards. For example, nondisclosure agreements typically require the recipient of protected information to limit any permitted disclosures to third parties who have agreed with the recipient to adhere to confidentiality requirements at least as stringent as those set forth in the bilateral nondisclosure agreement. This approach effectively requires the recipient to contract with any permitted third parties to protect the information and may require reliance on the Vendor’s assurances that such contracts are in place.

Another approach involves imposing specific security requirements on the Vendor and requiring the Vendor to specifically “flow down” certain requirements to key third parties. This method may require the Vendor to amend its contracts to ensure that they align with the specific contractual requirements. This approach is likely more feasible with primary subcontractors. Flow-down terms could be incorporated as an exhibit or appendix to the Vendor-Customer contract.

Alternatively, the parties could agree by contract that the Vendor will require key third parties to adhere to certain laws or third-party information standards or processes, such as the NIST framework, FFIEC CAT, or ISO standards or EU Commission directives (or GDPR next year), all risk mitigants of the type identified on the outer ring of Figure A. In this approach, the contract would require the Vendor to ensure that key third parties comply with these requirements, and that any failures by key third parties trigger notice and specific remediation and liability requirements.

Yet another alternative is that the parties could rely on external certifications for or audits of the Vendor or key third parties, such as PCI compliance, SOC or ISO audits, or examinations by governmental agencies. As above, the contract would require the Vendor to comply and ensure that key third parties comply with these requirements, and that any deficiencies are reported to the Customer. The Vendor should also be required by contract to provide evidence of compliance, such as summaries or copies of such independent reports.

A key part of any contract term addressing cyber risk is the inclusion of complete, concrete requirements that may be objectively measured. “Reasonable security,” “industry standards,” and “due care” are evolving standards in this context and may be lacking depending on the level of cyber risk posed by the relationship.

Any single contract may involve a hybrid of these approaches based on the larger ecosystem. For example, in the SaaS context in which the Vendor outsources data-processing center operations, the contract could require that:

• the subcontractor that operates the data-processing center has agreed to preserve the confidentiality of Customer information in a manner at least as stringent as the nondisclosure terms in the contract between the Vendor and the Customer;
• the subcontractor be located in the United States (or the contract could identify the subcontractor by name and location and could provide for Customer approval or notice to the Customer in the event of any change in subcontractor or data-processing center location);
• the subcontractor comply with all applicable law regarding the handling of Customer information (whether that be the law applicable to the information, the Customer, the Vendor, or the subcontractor);
• specific information-security procedures that are included in the Vendor-Customer contract be flowed down to the subcontractor; and
• the subcontractor be required to conduct annual SOC-2 compliance assessments, with concomitant reporting and remediation requirements.

In all events, the contract would include specific monitoring and reporting requirements and remedies, and the Vendor would remain primarily liable for the acts or omissions of the data-processing center.

Conclusion

The Vendor-Customer ecosystem can be quite complex. Each party will have their own subcontractors and upstream service providers. Questions to consider include the following:

• How far into the Vendor’s ecosystem must the Customer look (Figure B)?
• How much of the Vendor’s ecosystem must the Customer try to shore up?
• How much negotiating power does the Customer have over the Vendor, particularly with regard to requiring changes to the other party’s third-party contracts?
• How much bargaining leverage does the Vendor have over its key third parties?

Consider requiring the contract RFP to list all Vendor key third parties (by type if not by name) and the functions of each. The parties should consider how these risks and factors may be addressed during the RFP and contract process. For example, if there are specific flow-down terms or third-party audits that the Customer would like the Vendor and its key third parties to undertake, it may be easier to raise these specific requirements during the RFP process. At a minimum, the RFP process should require the Vendor to identify all of its upstream service providers, subcontractors, and other third parties that may have access to the Customer’s confidential and proprietary information or systems accessing or maintaining such information during the term of the contract.

The specific approach or combination of approaches that the Customer should take and the answers to the questions above will be determined by the level of risk posed by the proposed relationship and the availability of extra-contractual methods to monitor and mitigate such risk. This process requires the identification of valuable proprietary and confidential information that may be impacted, the access vectors and proposed uses of such information, and the permitted uses and disclosures by the Vendor regarding such information.