Going Beyond Confidential Information: The "Information Security" Provision
About this time last year, my IT Security Department approached me and asked that I develop a contract provision specific to "information security" that could be included in all of my contract templates. I'm very protective of my department's contract templates, and am very adverse to adding any new language unless it's absolutely necessary. I've written the contract templates broadly enough to cover almost all of my customers' requirements, and I usually only need to point out how a particular contract provision will protect the customer for them to walk off feeling comfortable with the contract as-is. Besides, if I included a specific contract provision for every issue that a customer has raised with me over the years, my contract templates wouldn't be templates--they'd be books. Good luck then on getting vendors to use my paper.
So, when IT Security approached me, I took the same tact and explained that there were at least three provisions in the existing contract template that protected my company. The first, and most obvious, is the confidentiality provision. The second, and less obvious, is the following provision:
I asked whether or not the IT Security policy was included as a part of our company's policies and procedures (it is) and whether vendors are made aware of the IT Security policy (yes, they are). I then responded that our company was covered as a result of the above provision, that it was intentionally written broadly, and that I felt comfortable that no new language needed to be added to the contract templates.
The last provision that I pointed out was actually an entirely separate agreement--the HIPAA Business Associate Agreement--which addresses protected health information (PHI) and a vendor's obligations relating to such information.
My IT Security folks pressed me to consider information that was sometimes "more" than confidential but less than PHI. Specifically, what they called "protected" data, such as names, addresses, phone numbers, and credit card information. They agreed that this protected data was covered under my definition of "Confidential Information" and the provision above but that the obligation of confidentiality didn't get to "how" the protected data would be protected by vendors. Upon hearing that, I carefully explained that we want to avoid telling vendors "how" to do things, only telling them "what" as much as possible, and that dictating "how" a vendor provides services sometimes creates liability and culpability on our (the customer's) behalf. What my IT Security folks wanted was a contract provision that obligated a vendor to have certain information security standards. I agreed to do a little more research and that I would get back to them with a final response.
Shortly after beginning my research, I began to agree with my IT Security staff. Especially when it comes to "protected" data that is being transmitted electronically, I was convinced that our vendors needed some sort of minimum standard by which to demonstrate reasonable efforts to protect our data. Many of the articles I was reading were saying the same thing...
The next part of my research was developing an appropriate contract provision. When it comes to contract language, and especially with the availability of information on the Internet, I usually like to see what other people have drafted. In fact, I was hoping that I could just cobble someone else's language. What I found was that almost no one was contractually addressing information security like the articles and experts that I read had been recommending. Of the dozens of contracts I sifted through trying to find example language, only a few contracts contained any language around information security: Bank of America, General Motors, Reuters, Sprint, Time Warner and Vonage. Of those, and no offense to the folks that drafted those contracts, the information security language was weak. Consequently, I ended up drafting some language that was vetted by a number of different folks (fellow lawyers and other purchasing professionals).
The provisions that follow are what everyone, including my IT Security, ended up liking. These provisions have also been modified based on vendor responses to earlier versions of the language. What follows seems to stick, after a little explanation, with vendors about 75% of the time with no or little change. Of course, the provisions don't always make sense or work (such as with independent consultants), so they require some modification every now and then. To keep yourself from having to go through the same process, feel free to use the following--free of charge. Isn't the Internet great?
So, when IT Security approached me, I took the same tact and explained that there were at least three provisions in the existing contract template that protected my company. The first, and most obvious, is the confidentiality provision. The second, and less obvious, is the following provision:
1. Compliance With Laws; Customer Policies and Procedures. Both parties agree to comply with all applicable federal, state, and local laws, executive orders and regulations issued, where applicable. Vendor shall comply with Customer policies and procedures where the same are posted, conveyed, or otherwise made available to Vendor. Without limiting Vendor’s other obligations of indemnification herein, Vendor shall defend, indemnify, and hold Customer Indemnitees harmless from and against any and all Claims, including reasonable expenses suffered by, accrued against, or charged to or recoverable from any Customer Indemnitee, on account of the failure of Vendor to perform its obligations imposed herein.
I asked whether or not the IT Security policy was included as a part of our company's policies and procedures (it is) and whether vendors are made aware of the IT Security policy (yes, they are). I then responded that our company was covered as a result of the above provision, that it was intentionally written broadly, and that I felt comfortable that no new language needed to be added to the contract templates.
The last provision that I pointed out was actually an entirely separate agreement--the HIPAA Business Associate Agreement--which addresses protected health information (PHI) and a vendor's obligations relating to such information.
My IT Security folks pressed me to consider information that was sometimes "more" than confidential but less than PHI. Specifically, what they called "protected" data, such as names, addresses, phone numbers, and credit card information. They agreed that this protected data was covered under my definition of "Confidential Information" and the provision above but that the obligation of confidentiality didn't get to "how" the protected data would be protected by vendors. Upon hearing that, I carefully explained that we want to avoid telling vendors "how" to do things, only telling them "what" as much as possible, and that dictating "how" a vendor provides services sometimes creates liability and culpability on our (the customer's) behalf. What my IT Security folks wanted was a contract provision that obligated a vendor to have certain information security standards. I agreed to do a little more research and that I would get back to them with a final response.
Shortly after beginning my research, I began to agree with my IT Security staff. Especially when it comes to "protected" data that is being transmitted electronically, I was convinced that our vendors needed some sort of minimum standard by which to demonstrate reasonable efforts to protect our data. Many of the articles I was reading were saying the same thing...
The next part of my research was developing an appropriate contract provision. When it comes to contract language, and especially with the availability of information on the Internet, I usually like to see what other people have drafted. In fact, I was hoping that I could just cobble someone else's language. What I found was that almost no one was contractually addressing information security like the articles and experts that I read had been recommending. Of the dozens of contracts I sifted through trying to find example language, only a few contracts contained any language around information security: Bank of America, General Motors, Reuters, Sprint, Time Warner and Vonage. Of those, and no offense to the folks that drafted those contracts, the information security language was weak. Consequently, I ended up drafting some language that was vetted by a number of different folks (fellow lawyers and other purchasing professionals).
The provisions that follow are what everyone, including my IT Security, ended up liking. These provisions have also been modified based on vendor responses to earlier versions of the language. What follows seems to stick, after a little explanation, with vendors about 75% of the time with no or little change. Of course, the provisions don't always make sense or work (such as with independent consultants), so they require some modification every now and then. To keep yourself from having to go through the same process, feel free to use the following--free of charge. Isn't the Internet great?
1. Information Security. Vendor acknowledges that Customer has implemented an information security program (the Customer Information Security Program, as the same may be amended) to protect Customer’s information assets, such information assets as further defined and classified in the Customer Information Security Program (collectively, the “Protected Data”).Where Vendor has access to the Protected Data, Vendor acknowledges and agrees to the following.
1.1 Undertaking by Vendor. Without limiting Vendor’s obligation of confidentiality as further described herein, Vendor shall be responsible for establishing and maintaining an information security program that is designed to: (i) ensure the security and confidentiality of the Protected Data; (ii) protect against any anticipated threats or hazards to the security or integrity of the Protected Data; (iii) protect against unauthorized access to or use of the Protected Data; (iv) ensure the proper disposal of Protected Data; and, (v) ensure that all subcontractors of Vendor, if any, comply with all of the foregoing. In no case shall the safeguards of Vendor’s information security program be less stringent than the information security safeguards used by the Customer Information Security Program as provided by Customer to Vendor for this purpose. The Customer Information Security Program is Confidential Information of Customer.
1.2 Right of Audit by Customer. Customer shall have the right to review Vendor’s information security program prior to the commencement of Services and from time to time during the term of this Agreement. During the performance of the Services, from time to time and without notice, Customer, at its own expense, shall be entitled to perform, or to have performed, an on-site audit of Vendor’s information security program. In lieu of an on-site audit, upon request by Customer, Vendor agrees to complete, within forty-five (45 days) of receipt, an audit questionnaire provided by Customer or Customer’s designee regarding Vendor’s information security program.
1.3 Audit by Vendor. No less than annually, Vendor shall conduct an independent third-party audit of its information security program and provide such audit findings to Customer.
1.4 Audit Findings. Vendor shall implement any required safeguards as identified by Customer or information security program audits.
1.5 Indemnification by Vendor. Without limiting Vendor’s other obligations of indemnification herein, Vendor shall defend, indemnify, and hold Customer Indemnitees harmless from and against any and all Claims, including reasonable expenses suffered by, accrued against, or charged to or recoverable from any Customer Indemnitee, on account of the failure of Vendor to perform its obligations imposed herein.
1.2 Right of Audit by Customer. Customer shall have the right to review Vendor’s information security program prior to the commencement of Services and from time to time during the term of this Agreement. During the performance of the Services, from time to time and without notice, Customer, at its own expense, shall be entitled to perform, or to have performed, an on-site audit of Vendor’s information security program. In lieu of an on-site audit, upon request by Customer, Vendor agrees to complete, within forty-five (45 days) of receipt, an audit questionnaire provided by Customer or Customer’s designee regarding Vendor’s information security program.
1.3 Audit by Vendor. No less than annually, Vendor shall conduct an independent third-party audit of its information security program and provide such audit findings to Customer.
1.4 Audit Findings. Vendor shall implement any required safeguards as identified by Customer or information security program audits.
1.5 Indemnification by Vendor. Without limiting Vendor’s other obligations of indemnification herein, Vendor shall defend, indemnify, and hold Customer Indemnitees harmless from and against any and all Claims, including reasonable expenses suffered by, accrued against, or charged to or recoverable from any Customer Indemnitee, on account of the failure of Vendor to perform its obligations imposed herein.
Awesome material, Stephen. What a great concept that I've wrestled with, as well.
How do you handle sprinkling audit provisions in a variety of places, especially when they may conflict with each other? Isn't it better to leave audit language in one area and point to it from this language?
Reply to this
Tony,
Excellent questions and thanks for taking the time to comment! As you point out, I've had to carefully consider the conflicts of "similar" terms. The format of my contract templates is primarily based on a tool, HotDocs by LexisNexis, that I use to automate the contract templates. The HotDocs tool, which is a superb tool in my opinion, has certain limitations that require me to use some creative license. For example, I don't have a survival clause in my contract templates, because, when I'm dynamically generating a contract template, the form isn't intelligent enough to track how certain clauses are enumerated (the placement of clauses and enumeration varies by type of contract template). Therefore, I'm forced to include something like "The provisions of this Section XX shall survive the termination of this Agreement" with every clause that I need to have survive. The case with my information security provision is similar. All of my contract templates have an audit provision, but not all of my contract templates have an information security provision. Therefore, I have to "split" common language from contract template-specific language. If it weren't for having to modularize contract language in this manner or not having an automated tool, I likely would have had all of the audit language in one spot.
The benefit of a tool like HotDocs is that I have a database of contract terms that allows me to easily propagate new and changed terms across all contract templates. Another benefit is that I can tailor a contract template without having to find or draft language. For example, I may have a contract template form that asks the user whether the vendor is a "top tier" vendor. If so, the contract template form will select a mutual indemnification clause whereas, if the vendor had been a lower tier vendor, the contract template form will otherwise select a unilateral indemnification clause (the vendor indemnifies me as the customer).
Another reason is tactic-related... In many of my contract templates, I have language sprinkled throughout the contract that is similar in intent but not in "looks." Basically, redundant language that isn't necessary, but if one part is redlined out by a vendor and the other part isn't, the intent is still there. One example I describe in great detail in my contract negotiation handbook is the "Expressly Implied Warranties" tactic.
Sorry for the long-winded response!
Best regards,
Stephen
Reply to this
Our VP Strategic Sourcing feels that our NDA covers this even though Information Security is not specifically mentioned. Do you think that is adequate or should we add language to the contract similar to what is mention in the article?
Thanks
Jerry Ligrani
IT Sourcing Manager
Corporate Express.
Reply to this
Jerry,
That's exactly what my opinion was--at first. The flaw in NDA language is that it doesn't go to "how" to protect the confidential information. Normally, I'm adverse to telling a vendor how to do something, but in this case I ended up being convinced otherwise. NDA language, back in the day, was certainly adequate. Mostly, it was intended to cover printed material. As the mobility of electronic media has grown (think thumb or jump drives) and the transfer of data using electronic means increases (think EDI), merely calling the data on that media or that is being being transferred "Confidential Information" (and then hoping for the best in terms of the vendor protecting that information) is no longer--in my mind--sufficient.
Try out this scenario, let's say your company transmits payroll data via EDI to a payroll processing vendor. Your agreement with that vendor has a typical confidentiality provision, and it's clear that the payroll data is "Confidential Information." One day, the newspaper reports that your vendor has been hacked. It turns out all of your payroll data was exposed (social security numbers included). You and your boss get called into the office of the President of US Operations. The newspaper has apparently called your company to get a statement, outraged employees have been calling the CFO all morning, and the President's e-mail inbox has been flooded. The President wants to know what the contract says and what kind of contractual recourse you have.
Given this scenario, in which of the following cases are you more likely to hang on to your job?
A. You shrug and tell him you have a standard confidentiality provision in the contract.
B. You tell him that you have one of those new-fangled information security provisions in the contract, that the vendor had to have an IT security policy and standard which provided no less security than your own, that an IT audit provided to your IT department by the vendor (as required by the contract) no less than a year ago didn't reveal any flaws in their security, and that the vendor has clearly indemnified you against loss or exposure of that data.
Reply to this