July 31, 2017//Ellen NeveuxLast Updated: November 18, 2020
Anyone who has negotiated a software license agreement in the last few years has likely encountered a difficult discussion about liability and indemnity in the event of a breach. Although there is no single scenario that determines who is liable for these costs, in the case of Target, they paid an $18.5 million multistate settlement, the largest ever for a data breach, to resolve state investigations of the 2013 cyber-attack that affected more than 41 million customer payment card accounts. This action set new industry standards for companies that process payment cards and maintain confidential information about their customers.
Pushing risk to the vendor
In the past, vendors may have capped their liability at the total or a percentage of fees paid under an agreement. But today, savvy enterprises are using separate information security agreements and industry-specific strategies like business associate (BA) agreements in healthcare. These agreements push as much liability risk to the vendor as possible.
A BA agreement is a contract used by healthcare organizations that requires vendors to comply with HIPAA security and privacy rules. BA agreements are only necessary for vendors that handle protected health information (PHI), but healthcare companies are increasingly requesting them from other vendors as well. Unnecessary BAs are a real problem for vendors that are not handling PHI; they have to choose between losing a customer or shouldering a liability burden that isn’t relevant to the delivery of their services.
Information security agreements are used by all sorts of organizations to require vendors to meet specific security requirements. These agreements tend to look a lot like regulatory requirement checklists and, like those checklists, the language may be broad. This breadth is intended to allow vendors leeway to implement security in ways that make sense for their own environments, but fuzzy language can also leave a lot of room for finger-pointing if a breach occurs.
For instance, this example of an information security agreement requires vendors that handle PHI on a frequent basis to use a site-to-site VPN or other direct network connection. What exactly comprises a “frequent basis” is undefined and, while VPNs are specifically mentioned, VPNs are far from perfect for third-party remote access. Logins get shared, passwords get stored in the open at support centers and it’s impossible for an enterprise to track the current status of any vendor employee. The “other direct network connections” could take many forms that may or may not provide the authentication, access control and audit that ensures security and vendor accountability.
Both sides have a lot to lose
As a customer, you need to be aware of your software vendor’s security policies and procedures and do your best to hold them accountable. As a technology vendor, be aware that your negligence can be very, very expensive. If you are still using outdated tools to support your customers or sharing logins and passwords, it’s time to take a close look at your company’s liability exposure.
In summary, customers and their technology vendors should invest time discussing proper implementation and management of a third-party remote access system. Both sides have too much to lose to rely on poorly designed or outdated methods.