The Impact of Data Security Incident Trends on Commercial Transactions: Part III – Vendor Agreement Resolutions for 2022 | Data Counsel
The Impact of Data Security Incident Trends on Commercial Transactions: Part III – Vendor Agreement Resolutions for 2022
Photo of Craig CarpenterPhoto of Erika Vela
By Craig Carpenter and Erika Vela on January 5, 2022
POSTED IN UNCATEGORIZED
As the BakerHostetler Digital Risk Advisory and Cybersecurity team wraps up the 2022 edition of annual Data Security Incident Response (DSIR) Report, we take one last look at the findings in the 2021 edition of the report to prepare our New Year’s resolutions of a data privacy and security attorney for vendor contracts.
In our first post, we reviewed the impact of these data security trends on M&A. In our second post, we reviewed the impact of these data security trends on commercial transactions. Now we will wrap up this series with an in-depth look at the impact on vendor agreements.
Data Privacy and Security in Vendor Agreements
We have previously covered the trend of increasing vendor incidents on this blog. As BakerHostetler partner Sara Goldstein mentioned in her post from earlier this year, “2020 saw a sharp spike in the number of incidents involving vendors, which amounted to over 25 percent of the total incidents handled in 2020, and the trend is continuing well into 2021.” Sara’s post includes an excellent list of key lessons to be learned from vendor incidents, including vendor vetting, data minimization, and increased focus on contractual terms and conditions. But let’s now look specifically at those all-important terms and conditions and make some contracting resolutions for 2022.
Resolution 1: Less Is More
Sometimes, the easiest way to avoid a vendor breach and the headaches that come with it is simply not to give the vendor any personal or sensitive information. This basic yet often overlooked principle can be a useful risk mitigation strategy for vendors and customers alike. Obviously, this is not always possible, as some vendors are engaged for the purpose of processing personal information; but even in such cases, it may be useful to look for ways to otherwise curtail exposure by data minimization.
On the customer side, this requires some collaboration between the legal team (internal and external) and applicable business unit to understand what data is going to be shared and why. The benefits of this exercise are twofold: First, you may end up reducing exposure from such an engagement by identifying ways to limit the data shared or accessed. Second, if it is determined that personal and/or sensitive information must be shared with or accessed by the vendor, you have nevertheless taken the first steps in completing a data protection impact assessment, which, depending on the nature of the engagement, could be required or just good practice.
On the vendor side, data minimization may also help you mitigate risk and breach exposure. If you are hosting a platform where your customers can upload content and data on their own, can you be sure that they are not uploading health information, personal information or other information that could increase your liability in the event of a breach? In certain engagements, it may be beneficial to set out in the contract what the customer can upload and what is prohibited.
Similarly, the vendor and customer should discuss opportunities to segregate and partition the customer data from that of other customers, to the extent practicable. One reason vendor breaches are so devastating (and lucrative for threat actors) is that with one breach, there is potential to attack hundreds of companies. As the customer, you obviously don’t want to be caught up in a breach where you were merely collateral damage, but as the vendor, this may be the difference between having to notify one customer of an incident and having to notify all of your customers of an incident. Customer segmentation and security measures to deter lateral threat actor movement can be addressed in the parties’ security documentation. Data localization is increasingly becoming a necessary part of this conversation as well, as cross-border data flow meets new challenges.
For these reasons, data minimization and segregation shouldn’t be seen as a contract provision that should be “won” by either side; rather, the customer and vendor should look to manage expectations and make sure the agreement accurately reflects the particular engagement.
Resolution 2: Make Breach Notification Make Sense
In many cases, the parties’ breach notification responsibilities are set out by rule (see, e.g., FDIC, OCC and Fed); however, often the parties look to add some certainty (urgency) to this process by contract. These provisions may say things like “immediately,” “promptly,” “within 24 hours,” “within 72 hours” and the like. Most are initiated by “discovery” of an incident. But as anyone who has been through a breach response knows, there is a good chance that upon “discovery of an incident,” there is not a lot of other useful information available and downstream contracts may not be immediately top of mind.
Similarly, how is a “security breach” defined in your agreement? The customer may want broad coverage, but as the vendor, you may feel that a potential insider security incident involving internal HR files may not present any real threat to your customer information, and so you may not want an obligation to “immediately” notify all of your customers of such an incident. (And on the customer side, is this kind of incident relevant? Maybe, but maybe not.)
Instead of agreeing to boilerplate breach notification clauses, the parties should consider the type of information being shared, the scope of the services, and what the parties’ legal or regulatory obligations may be. The parties should arrive at a clause that respects the customer’s desire for transparency and prompt action, while also considering the realities of breach response.
Resolution 3: Transparency in Limitations of Liability and Indemnity
It is no secret that data breaches can be destructive and expensive. The 2021 DSIR Report makes this immediately clear by highlighting some of the large ransom and investigation costs from the previous year.
This has led to increased focus and negotiation on the limitations of liability and indemnification obligations in vendor agreements, which has created a few trends for customers and vendors to be aware of:
Separate indemnity/reimbursement for data breach matters: It is growing increasingly common for customers of SaaS and IT vendors to seek reimbursement for and indemnification of expenses and liabilities arising out of a vendor data breach. Whether these should be covered and to what amount are important negotiation points. Should the indemnity cover all investigation and remediation efforts? Should it cover the cost of forensics? Should it cover breach notification letters? These are all important questions to consider (and often dependent on the two additional points discussed below).
Liability super cap for data breach issues: In SaaS and IT services agreements, the general contractual liability cap is often some multiplier of the amounts paid under the agreement or the amounts paid in 12 months; however, in the context of ransomware or other significant personal information breaches, these caps can fall well short of costs and expenses. Sometimes, the parties account for this by incorporating a “super cap” that applies to data privacy and security matters (including the expenses discussed above); however, this still requires thought and negotiation to determine an acceptable amount and coverage. The parties may want to review insurance policies or studies on data breach costs (like the DSIR Report) to get helpful data points when negotiating these limits.
Whose fault is it, anyway?: One of the most challenging aspects of negotiating data breach liability caps and indemnities is determining when the data breach liability shifts. Sometimes it is difficult to pin fault for a data breach on any party (other than the threat actor) – even with “reasonable security,” breaches can and do occur. The parties will have to negotiate when things like expense reimbursement or claim indemnity for data breaches kick in. Should reimbursement be tied to a breach of data security obligations in the agreement? Should it be tied to a third-party finding of fault?
Further complicating this analysis is that sometimes these provisions are in the master agreement with the other limitations of liability and indemnities, but sometimes they pop up in the middle of addendums.
Resolution 4: DPAs, DSAs, SCCs, Oh My!
Data addendums have become the new “battle of the forms” in technology vendor contracting. While it is obviously important that vendors and customers are addressing data privacy and security in SaaS and IT agreements (and it might be a red flag if they are not), and addressing these requirements separate from the master agreement can help expediate review, relegating these clauses to template forms that are attached or linked to a master agreement risks parties not affording them due care.
If your agreement is going to be on the other party’s paper, it is important to look through the agreement for any attached (or linked) privacy/security terms early on, to make sure this important step doesn’t stall negotiation when you are at the finish line. If this is the case, these clauses should be pulled out for legal (and technical, if necessary) review. If the agreement does not have data privacy or security terms, perhaps this is an opportunity to use your own version of model data privacy and security terms. Even if the agreement is on your paper, it is important to understand how your own data privacy and security terms will apply to this particular engagement and whether any specific technical requirements are necessary or even possible for your business.
Next, the parties should discuss what is in scope for the privacy and security addendums. Do you want the DPA merely to comply with CCPA and/or GDPR requirements? Great; then you need to make sure the DPA doesn’t have additional liability-shifting provisions that are not required by these laws. Do you want it to be a more comprehensive data privacy and/or data security addendum? Great, but you already negotiated liability caps and indemnification in the master agreement, so you need to determine whether there are any (intentionally or unintentionally) conflicting terms in the comprehensive privacy/security addendum. It is also common to see Standard Contractual Clauses attached to DPAs, but have you evaluated whether they are actually necessary to this engagement? And if so, are they the correct version? Regardless of where the parties end up on negotiating these terms, it is important to treat these addendums as integral contract terms that are reviewed just as carefully as the master agreement.
With these resolutions in mind, hopefully you will have a prosperous and headache-free SaaS and IT contracting 2022 – happy New Year from the BakerHostetler Digital Assets and Data Management Practice Group.
Photo of Craig CarpenterPhoto of Erika Vela
By Craig Carpenter and Erika Vela on January 5, 2022
POSTED IN UNCATEGORIZED
As the BakerHostetler Digital Risk Advisory and Cybersecurity team wraps up the 2022 edition of annual Data Security Incident Response (DSIR) Report, we take one last look at the findings in the 2021 edition of the report to prepare our New Year’s resolutions of a data privacy and security attorney for vendor contracts.
In our first post, we reviewed the impact of these data security trends on M&A. In our second post, we reviewed the impact of these data security trends on commercial transactions. Now we will wrap up this series with an in-depth look at the impact on vendor agreements.
Data Privacy and Security in Vendor Agreements
We have previously covered the trend of increasing vendor incidents on this blog. As BakerHostetler partner Sara Goldstein mentioned in her post from earlier this year, “2020 saw a sharp spike in the number of incidents involving vendors, which amounted to over 25 percent of the total incidents handled in 2020, and the trend is continuing well into 2021.” Sara’s post includes an excellent list of key lessons to be learned from vendor incidents, including vendor vetting, data minimization, and increased focus on contractual terms and conditions. But let’s now look specifically at those all-important terms and conditions and make some contracting resolutions for 2022.
Resolution 1: Less Is More
Sometimes, the easiest way to avoid a vendor breach and the headaches that come with it is simply not to give the vendor any personal or sensitive information. This basic yet often overlooked principle can be a useful risk mitigation strategy for vendors and customers alike. Obviously, this is not always possible, as some vendors are engaged for the purpose of processing personal information; but even in such cases, it may be useful to look for ways to otherwise curtail exposure by data minimization.
On the customer side, this requires some collaboration between the legal team (internal and external) and applicable business unit to understand what data is going to be shared and why. The benefits of this exercise are twofold: First, you may end up reducing exposure from such an engagement by identifying ways to limit the data shared or accessed. Second, if it is determined that personal and/or sensitive information must be shared with or accessed by the vendor, you have nevertheless taken the first steps in completing a data protection impact assessment, which, depending on the nature of the engagement, could be required or just good practice.
On the vendor side, data minimization may also help you mitigate risk and breach exposure. If you are hosting a platform where your customers can upload content and data on their own, can you be sure that they are not uploading health information, personal information or other information that could increase your liability in the event of a breach? In certain engagements, it may be beneficial to set out in the contract what the customer can upload and what is prohibited.
Similarly, the vendor and customer should discuss opportunities to segregate and partition the customer data from that of other customers, to the extent practicable. One reason vendor breaches are so devastating (and lucrative for threat actors) is that with one breach, there is potential to attack hundreds of companies. As the customer, you obviously don’t want to be caught up in a breach where you were merely collateral damage, but as the vendor, this may be the difference between having to notify one customer of an incident and having to notify all of your customers of an incident. Customer segmentation and security measures to deter lateral threat actor movement can be addressed in the parties’ security documentation. Data localization is increasingly becoming a necessary part of this conversation as well, as cross-border data flow meets new challenges.
For these reasons, data minimization and segregation shouldn’t be seen as a contract provision that should be “won” by either side; rather, the customer and vendor should look to manage expectations and make sure the agreement accurately reflects the particular engagement.
Resolution 2: Make Breach Notification Make Sense
In many cases, the parties’ breach notification responsibilities are set out by rule (see, e.g., FDIC, OCC and Fed); however, often the parties look to add some certainty (urgency) to this process by contract. These provisions may say things like “immediately,” “promptly,” “within 24 hours,” “within 72 hours” and the like. Most are initiated by “discovery” of an incident. But as anyone who has been through a breach response knows, there is a good chance that upon “discovery of an incident,” there is not a lot of other useful information available and downstream contracts may not be immediately top of mind.
Similarly, how is a “security breach” defined in your agreement? The customer may want broad coverage, but as the vendor, you may feel that a potential insider security incident involving internal HR files may not present any real threat to your customer information, and so you may not want an obligation to “immediately” notify all of your customers of such an incident. (And on the customer side, is this kind of incident relevant? Maybe, but maybe not.)
Instead of agreeing to boilerplate breach notification clauses, the parties should consider the type of information being shared, the scope of the services, and what the parties’ legal or regulatory obligations may be. The parties should arrive at a clause that respects the customer’s desire for transparency and prompt action, while also considering the realities of breach response.
Resolution 3: Transparency in Limitations of Liability and Indemnity
It is no secret that data breaches can be destructive and expensive. The 2021 DSIR Report makes this immediately clear by highlighting some of the large ransom and investigation costs from the previous year.
This has led to increased focus and negotiation on the limitations of liability and indemnification obligations in vendor agreements, which has created a few trends for customers and vendors to be aware of:
Separate indemnity/reimbursement for data breach matters: It is growing increasingly common for customers of SaaS and IT vendors to seek reimbursement for and indemnification of expenses and liabilities arising out of a vendor data breach. Whether these should be covered and to what amount are important negotiation points. Should the indemnity cover all investigation and remediation efforts? Should it cover the cost of forensics? Should it cover breach notification letters? These are all important questions to consider (and often dependent on the two additional points discussed below).
Liability super cap for data breach issues: In SaaS and IT services agreements, the general contractual liability cap is often some multiplier of the amounts paid under the agreement or the amounts paid in 12 months; however, in the context of ransomware or other significant personal information breaches, these caps can fall well short of costs and expenses. Sometimes, the parties account for this by incorporating a “super cap” that applies to data privacy and security matters (including the expenses discussed above); however, this still requires thought and negotiation to determine an acceptable amount and coverage. The parties may want to review insurance policies or studies on data breach costs (like the DSIR Report) to get helpful data points when negotiating these limits.
Whose fault is it, anyway?: One of the most challenging aspects of negotiating data breach liability caps and indemnities is determining when the data breach liability shifts. Sometimes it is difficult to pin fault for a data breach on any party (other than the threat actor) – even with “reasonable security,” breaches can and do occur. The parties will have to negotiate when things like expense reimbursement or claim indemnity for data breaches kick in. Should reimbursement be tied to a breach of data security obligations in the agreement? Should it be tied to a third-party finding of fault?
Further complicating this analysis is that sometimes these provisions are in the master agreement with the other limitations of liability and indemnities, but sometimes they pop up in the middle of addendums.
Resolution 4: DPAs, DSAs, SCCs, Oh My!
Data addendums have become the new “battle of the forms” in technology vendor contracting. While it is obviously important that vendors and customers are addressing data privacy and security in SaaS and IT agreements (and it might be a red flag if they are not), and addressing these requirements separate from the master agreement can help expediate review, relegating these clauses to template forms that are attached or linked to a master agreement risks parties not affording them due care.
If your agreement is going to be on the other party’s paper, it is important to look through the agreement for any attached (or linked) privacy/security terms early on, to make sure this important step doesn’t stall negotiation when you are at the finish line. If this is the case, these clauses should be pulled out for legal (and technical, if necessary) review. If the agreement does not have data privacy or security terms, perhaps this is an opportunity to use your own version of model data privacy and security terms. Even if the agreement is on your paper, it is important to understand how your own data privacy and security terms will apply to this particular engagement and whether any specific technical requirements are necessary or even possible for your business.
Next, the parties should discuss what is in scope for the privacy and security addendums. Do you want the DPA merely to comply with CCPA and/or GDPR requirements? Great; then you need to make sure the DPA doesn’t have additional liability-shifting provisions that are not required by these laws. Do you want it to be a more comprehensive data privacy and/or data security addendum? Great, but you already negotiated liability caps and indemnification in the master agreement, so you need to determine whether there are any (intentionally or unintentionally) conflicting terms in the comprehensive privacy/security addendum. It is also common to see Standard Contractual Clauses attached to DPAs, but have you evaluated whether they are actually necessary to this engagement? And if so, are they the correct version? Regardless of where the parties end up on negotiating these terms, it is important to treat these addendums as integral contract terms that are reviewed just as carefully as the master agreement.
With these resolutions in mind, hopefully you will have a prosperous and headache-free SaaS and IT contracting 2022 – happy New Year from the BakerHostetler Digital Assets and Data Management Practice Group.
