IT Contracts and Data Privacy: Specificity is (Still) King

By: Brian K. Fullmer 

Frequently in information technology contracts (such as Master Services Agreements, SaaS Agreements, licenses, and other vendor contracts for businesses), a short but simple statement is the sole clause establishing information security obligations:

“Vendor shall use such physical, administrative, and technical controls and procedures as are necessary to safeguard the confidentiality, integrity and availability of data.”

While this language can be serviceable and useful in connection with obtaining services from an IT vendor, as it creates some degree of obligation to maintain the security of data, in many situations, this language serves to create more ambiguity and risk than it resolves – not to mention raising more questions than it answers. Whose responsibility is it to determine what is “necessary,” and under what standard is a particular practice or procedure deemed necessary or unnecessary?

These questions raise the specter of intractable disputes before a data breach but become even more critical after a malicious third party infiltrates a network and exfiltrates critical, confidential, or other data. For many small and medium businesses, the cost savings from avoiding negotiation and creating specificity in network security and data privacy obligations become meager in comparison to the litigation and dispute resolution expense of ascertaining precisely who was liable to whom and for what failures. As with all contracts, an ounce of precision and prevention in contract drafting can prevent a pound, if not a ton, of headaches for a business seeking to negotiate and enter into information technology services agreements.

During negotiations with IT vendors, the focus often rightfully shifts to “high value” clauses: ownership of the intellectual property derived from the relationship, including customer/client data and statistics, and service level performance standards (with related indemnification and/or termination provisions). While these clauses revolve around key items and thus should remain a focus, ownership of risk (including prevention measures) often falls into the oft-described category of “things that aren’t important until they become important.” Data privacy and security thus, unfortunately, becomes relegated to a “low-cost, low-reward” proposition in negotiation – despite the looming third factor of risk reduction.

While robust IT resources (personnel, technology, policies, and procedures) provide a viable first line of defense against data exfiltration and breach, businesses can more robustly mitigate risk through a combination of operational measures and the following guiding principles in contract drafting and negotiation:

• Specificity is (Still) King. As a general principle, when it comes to data privacy, the more granular a contract can get, the clearer the obligations are, and the easier it becomes for a party suffering a breach to identify the source and seek appropriate legal recourse.
• Due Diligence: Ask for It. Often in contract negotiation with IT vendors, the diligence process is shortened compared to a merger or acquisition. While this is an effective cost-saving measure, a few simple questions and steps can provide a variety of insights as to risk “pain points”:
  • Does the vendor have specific policies and procedures in place for key cybersecurity practices (such as intrusion detection and monitoring or vulnerability management)? If so, even a cursory or brief review of these policies can point to strengths and weaknesses in data privacy standards.
  • Has the prospective vendor had a breach or otherwise been involved in a breach? If so, asking for basic details (if the vendor can provide them) can provide key insight.
  • What resources does the prospective vendor have in terms of staff or hardware? While it would be inappropriate to ask for an internal network diagram, vendors often are happy to provide staff numbers and limited hardware lists.
• Hold the Prospective Vendor to Standards. If possible, making reference to established cybersecurity standards in a covenant provides broad, low-cost language that ultimately becomes granular via the reference. This is particularly important if PCI-DSS standards apply. While vendors may balk at this, a robust example is to have a vendor covenant to maintaining applicable NIST standards. At minimum, if diligence has revealed that the vendor has an internal policy, reference to that policy creates a tangible standard to point to. In the event a dispute arises in the future, it becomes that much easier to point to a standard (and thus, the failure to meet that standard) in resolution proceedings.
• Operational Terminology Should be Included. While it may seem unimportant to include IT operational language or terms in a contract, solidifying these in writing at the beginning of the relationship further establishes standards and good evidence for recourse in the event of a dispute. While relying on the “IT folks” to sort it out via a handshake agreement may work flawlessly 90% of the time, the remaining 10% of the time can become so costly that it far outweighs any cost savings in not memorializing operational details. Some key examples of operational topics to memorialize in well-drafted agreements are as follows:
  • Identifying the points of ingress/egress in a network (including IP addresses and ports) to be used by the prospective vendor, and obligating a vendor to use only those points of ingress/egress.
  • Establishing a minimum schedule for a prospective vendor’s vulnerability management procedures with respect to shared access and software, particularly with respect to “0-day” or other critical vulnerabilities.
  • Establishing notification and response procedures in the event an intrusion is detected.
  • Establishing a minimum standard for auditing and testing security (whether penetration testing, simulation, or otherwise).

Negotiating and entering into agreements with IT vendors is not an “all-or-nothing” venture, and as with all contract terms, businesses are well-advised to adequately weigh the risk and reward of specificity with all terms of an agreement, including data privacy. Businesses must function, after all; the only way to effectively reduce data risk to zero is to simply not produce, handle, or store data at all. Yet by appropriately selecting some of the strategies set forth above (and others), even a small or medium-size business can take large steps to provide an additional legal layer of protection for data in vendor agreements.

If you would like to learn more or are thinking about entering into an IT agreement and would like suggestions as to how to reduce risk, please contact Brian Fullmer at Sacks Tierney either via phone at (480) 425-2651 or via e-mail at brian.fullmer@sackstierney.com