This website uses cookies

Read our Privacy policy and Terms of use for more information.

What should lawyers and professionals know about cybersecurity clauses in their contracts? It’s not as simple as a risk framework or how to handle a breach.

We covered this topic in a recent webinar on this topic, including what to learn from your own security team, how breaches actually happen, what SOC 2, ISO 27001, and NIST do and do not cover, why data classification ends up driving everything else in the contract, how to handle incident notification clocks and the known-versus-should-have-known line, and how to make audit rights useful rather than theoretical.

Joining me for this webinar were two in-house lawyers with cybersecurity expertise:

  • Aparna Williams, Chief Legal Officer at Sophos, who spent over 25 years in the cybersecurity industry after starting her career as a contracts negotiator,

  • Bill Price, a three-time tech chief legal officer, now working as a fractional general counsel with a cyber recovery background.

Their combined view from the legal seat at security companies made the conversation unusually practical.

Here are 10 practical strategies they shared during our discussion:

  1. Spend time with your security team before you draft. You need to see how the company has actually built its protections. Look at the information security plan and the network architecture. Talk to the security team and CISO. You do not need to master the technology. Problems happen when we draft without understanding the architecture of our cybersecurity program and systems.

  2. Focus on the gap analysis between your security policy and the vendor's. We all know the vendor won’t, and likely can’t, adopt your security policy. It would make it impossible for the vendor to scale. But that doesn’t mean you give up. Your job negotiating cybersecurity provisions is to identify which of your requirements are non-negotiable, which can be met through certifications, and which need to be added to the contract as specific obligations. You start that process by figuring out what’s different and then collaborating with the in-house security team on what to do about it.

  3. Phishing and inadequate patching are common causes of breaches, so make sure you contract for both. Bill Price shared that the large majority of breaches he has seen were from those sources. Phishing is a human risk that we address with mainly through internal training and culture. It’s different than inadequate patching, which is squarely a vendor risk. The contract should require the vendor to maintain a current certification and tie that to a contractual representation and warranty, so a failure and damages arising from it is treated as a breach-of-contract claim.

  4. Make the vendor responsible for its sub-processors. Every vendor has sub-processors. It’s critical that our data contracts put the vendor on the hook for the sub-processor's compliance. The best practice is to be specific. Name the obligation specifically. Do not bury it in a generic flow-down clause.

  5. Frameworks are outcomes, not technical requirements. SOC 2, ISO 27001, and NIST certifications tell you the vendor has built a management system or audit program around a set of outcomes. They do not tell you the vendor has the specific technical controls to protect your data. Our contracts need to address that gap. Treat the certification as a baseline. Use the security questionnaire to determine their implementation systems and processes. Then use the contract to address what the essential concepts your company or client needs.

  6. Use tiered data classification to tighten your contract’s provisions. Confidential information definitions may not distinguish between different types information the same way. When we include tiered classifications, both parties have to discuss and reach agreement on what gets the most protection, what gets less, and what controls apply at each level. This approach also helps clarify what the vendor can access and what they have to do with the data once they are done with it.

  7. Critical infrastructure and AI agents change the threat model. The expansion of AI agents means greater risks when protecting operational continuity and autonomous processes. There are meaningful safety and and continuity risks when energy systems, healthcare equipment, and AI agents act on the company's behalf. These risks are more than just data-protection issues. Make sure you incorporate the rigorous standards required when lives or operations are on the line.

  8. Start the notification clock at discovery, not at the first weird ping. Tie your notification obligations to “discovery” and tie discover to the way the vendor’s monitoring actually works. You don’t necessarily want a 24-hour notification obligation that starts from the moment something looks unusual. That’s likely to lead to data noise and dilute the more serious issues in the reports. Also, require notification on belief rather than only on confirmation, so the customer is in the room when the call gets made about whether to escalate. Bill shared that his preferred language is "discovers or reasonably suspects," with 48 hours from discovery as roughly the outer limit.

  9. Pre-engage privileged forensics vendors before you need them. Identify the forensics firms before anything happens. When the world is on fire, you have no leverage on pricing and no time to onboard new vendors. Also, make sure you have your outside counsel retain them so the forensics work product is privileged. While not necessarily a contractual provision, make sure it is in place. It’s one of the highest-value moves a legal team can make to prepare for cybersecurity incidents.

  10. Ensure the audit rights language is specific to the deal. Customers should tie audits to events that matter. The point is to make the audit produce information that feeds into a decision. For example, tie them to your own certification cycle so you have the information you need. Tie them to your vendor’s certification events so you get the renewed reports. Avoid provisions that create a theoretical inspection right for customers. We also need to require penetration testing findings where the vendor runs them anyway.

Other resources:

Subscribe to Stay in the Loop

Our weekly newsletter covers the upcoming How to Contract webinars and recaps like this one. Subscribe now to keep these fundamentals on hand the next time you sit down with a security exhibit.