Vendor-caused incidents continued to surge in 2021. Nearly 20 percent of the total incidents we handled last year were caused by vendors, with more than half requiring notification. As in prior years, vendor incidents involved phishing schemes and inadvertent disclosures but primarily resulted from ransomware attacks on the vendors’ systems. These ransomware attacks often involved the theft of customer data from a vendor’s environment or even spread of the ransomware from the vendor to the customer’s environment by utilizing the vendor’s own credentials.

Working with clients on both the vendor and customer sides of these incidents, we have seen the widespread and lasting effects such incidents have on all parties involved. Many vendors play a critical role in their customers’ operations and pride themselves on their focus and dedication to security. But the troves of sensitive data they maintain and access to multiple customer environments make them high-value targets for threat actors. Threat actors can not only rely on their usual tactics for extorting payments but leverage the added pressure of customers that need their data or the vendor’s services to maintain normal business operations. Even in cases where the incident may not be evident to a vendor’s customers, we have seen threat actors contact customers directly in an attempt to strong-arm the vendor into paying the ransom. The magnitude of vendor incidents often garners increased public attention, which can further complicate a vendor’s decision to pay.  

On the customer side, vendor-caused incidents present unique challenges to incident responders, who are at the mercy of their vendor’s decisions, backup procedures, and willingness to share information. Often these vendors are the only game in town, leaving customers with few alternatives. As sensitive data continues to flow to third-parties, vendor risk management remains as important as ever. Below are some lessons learned and tips for strengthening defenses around vendor-caused incidents.

• Discovery and Notification Timelines Vary Greatly – The time it takes vendors to notify their customers of an incident can vary greatly depending on the type and extent of the incident, the scope of the vendor’s services, and the parties’ legal or regulatory obligations. In ransomware situations, vendors may rush to get a communication out to customers that is incomplete or inaccurate, requiring customers to repeat or expand their notification analysis as the investigation develops. Planning, preparing for, and practicing a response to ransomware incidents can help bring organization and swiftness to a chaotic situation. The importance of creating a ransomware playbook and performing tabletop exercises cannot be overstated, and companies should be sure to include a vendor-cause incident scenario in their planning. Even after initial incident response and containment, it may take several weeks or months for a vendor to determine the extent of data impacted and the customer to which it belongs. Vendors should ensure they perform frequent inventories to identify where sensitive customer data is stored, and customers should know the nature and extent of data being shared with third-parties. These complexities often lead to a longer notice timeline to individuals.
• Information Sharing Also Varies – Because the incident occurred at the vendor, the vendor controls the investigation, as well as what information is shared with customers and when. For vendors, it can be difficult to balance the need to provide accurate and complete information to customers with the desire for transparency. Even after completion of the investigation, vendors may be unable or unwilling to share full details, even where there are contractual requirements to do so. In some matters we have handled, vendors provide only conclusory findings and refuse to share the details that led to those findings, or even the name of the forensic vendor.  This is often frustrating to customers struggling to complete their analysis and comply with regulatory requirements. Vendors should consider having a version of their forensic report that can be shared with customers to help those customers determine their notification obligations.
• Vendor Vetting (and Re-Vetting) Remains Key – Before engaging a new vendor that will receive access to their environment or data, customers must exercise due diligence to make sure the vendor has adequate security safeguards in place and practices good data hygiene. Not only can proper vetting help reduce the likelihood of a data security incident occurring, it can also protect a company from regulatory and litigation exposure alleging negligent vendor selection or oversight. In some sectors, such as accounting, legal services, and government, vendors may receive personal information without customers realizing the risk and ensuring the vendor has appropriate safeguards in place. Healthcare entities in particular are required to obtain satisfactory assurances that their vendors that create, receive or maintain protected health information on their behalf (“business associates”) appropriately safeguard the information. Evaluating a vendor’s compliance with security requirements is achieved through vendor risk assessments, which are expected to be periodically repeated, particularly in response to environmental or operational changes and when an incident occurs.
• Understand and Limit Data Sharing – On both the customer and vendor sides, minimizing the personal and/or sensitive information shared with or accessed by a vendor can mitigate risk and exposure. In many of the vendor incidents we have handled, the vendor, customer, or both were unaware of the nature and scope of the data being shared between customer and vendor. This can lead to a lot of initial uncertainty regarding the incident’s impact and potential notification obligations. To avoid this, it is important for customers to only share information that is necessary for the vendor’s services. Customers also need to understand what data is being collected, by whom, and for what purposes; how that data is being stored and for how long; and which vendors have access to that data. Vendors should likewise understand the data they receive or have access to and the associated obligations, and take steps to ensure they do not receive sensitive data that is not required to perform their services. As mentioned above, conducting frequent inventories of customer data and where it is stored can also help vendors quickly identify impacted customers when a data security incident occurs. 
• Make Notice Provisions Make Sense – In many cases, customers try to add certainty or urgency to vendor breach notification through contract. These provisions may include things such as “immediately,” “within 24 hours,” “within 72 hours,” etc., and are trigged by “discovery” of an incident. However, as incident responders know, upon discovery of an incident, there is little meaningful information available, and downstream contracts are often not top of mind and may not even be accessible due to the incident. Instead of using boilerplate breach notification clauses, the parties should consider the type of information being shared, the scope of the services, and what the parties’ legal and regulatory obligations may be. This is especially important for highly regulated organizations, such as healthcare providers and financial institutions, as vendor incident notifications could “start the clock” on their own breach notification deadlines, which is problematic where the scope of the incident and the data involved are not yet known. Ideally, the parties will arrive at a clause that balances the customer’s desire for transparency and prompt action with the realities of incident response. Vendors should also be sure they are aware of these timing requirements and build them into their incident response procedures.
• Know Your Remedies – In addition to negotiating breach notification clauses in vendor agreements, the parties should understand contractual terms and conditions surrounding notification obligations and remedies. In 2021, we saw more and more vendors refusing to perform notifications for their own breaches because the contract did not explicitly require them to do so. Customers should include contract language that specifically sets forth the vendor’s obligations to notify individuals and/or regulators and the customer’s request and approval. Vendor agreements also vary greatly on the compensation offered in the event of a vendor-caused incident. When an incident impacts thousands of customers, the language in the vendor contract is critical to determining customers’ rights. For vendors, maintaining good business relationships with customers is often a top priority, which may require going above and beyond their contractual obligations.
• Customers Face Regulatory Scrutiny and Class Actions Too – Even when an incident occurs at a vendor, we have seen customers face regulatory inquiries or class actions. While regulators will often focus primarily on the vendor that experienced the incident, they can and will also investigate a vendor’s customers, most often with regard to the notification to individuals, the sufficiency of control the customer had over the vendor’s security measures, and whether the parties entered into the appropriate agreements regarding their respective responsibilities. In 2021, we also saw an increase in the number of class actions filed against companies for a vendor-caused incident. In many cases, plaintiffs do not recognize the vendor or even know their information had been shared with the vendor, making the company they have a direct relationship with the easier target.

[View source.]