Security addenda: what enterprise buyers ask for and what to agree to

What arrives with the contract

Three documents tend to travel together. A security addendum or schedule: contractual commitments about the controls you maintain. A security questionnaire: a spreadsheet of a few dozen to several hundred questions about your practices. And, increasingly, a request for your third-party assurance report — SOC 2 Type II, ISO 27001 certificate, penetration test summary.

They interact. The questionnaire answers often become representations under the contract. The addendum commits you to maintain what the report describes. Answering one carelessly can create liability under another.

Standard asks you should expect to give

• Maintain a written information security programme appropriate to the data processed.
• Encryption in transit and at rest, using current industry standards.
• Access control based on least privilege, with multi-factor authentication for administrative access.
• Vulnerability management and regular penetration testing.
• Incident response process and breach notification within a defined window.
• Business continuity and backup arrangements.
• Personnel screening and security training.
• Annual third-party assessment, with the report made available on request under NDA.

If you cannot give these, the problem is not the contract.

Asks that deserve pushback

• Compliance with the customer’s internal policies, incorporated by reference and changeable at will. You cannot commit to a document you have not seen and cannot control. Replace with a commitment to your own documented programme and a named standard.
• Specific technical controls described in the buyer’s template that do not fit your architecture. A requirement for “dedicated hardware” or “customer-specific encryption keys” may be impossible in a multi-tenant product. Say so, and offer what you actually do.
• Unlimited on-site audit rights. Satisfy with the third-party report; reserve on-site audit for cause.
• Notification of every security incident rather than every incident affecting the customer’s data. Scope it.
• Guarantee of no breach. Nobody can promise this. Replace with a commitment to maintain the controls; the consequences of a breach belong in the liability clause.
• Certifications you do not hold by a date you cannot meet. Do not sign a promise to be ISO-certified in ninety days if the audit is not scheduled.

Answering the questionnaire

Treat every answer as a statement you would be comfortable defending after a breach. The options are yes, no, and partial-with-explanation — and “partial with explanation” is the honest answer far more often than sales would like. A “no” with a compensating control described is almost always acceptable to a serious buyer. A “yes” that turns out to be false is a misrepresentation, and the contract’s liability cap may not protect you from it.

Build a master questionnaire once, with reviewed answers, and pull from it. Answering each buyer’s questionnaire from scratch produces inconsistency, and inconsistency between what you told two customers is exactly what gets found in discovery.

Keep the two conversations separate

What you do (the security commitments) and what you pay if it fails (liability, indemnity, breach costs) are different negotiations, often with different people on the buyer’s side. Security teams want controls; legal teams want recourse. Conceding an uncapped data breach indemnity because the security schedule was hard-fought is a common and expensive mistake. Hold the liability discussion until the security terms are settled, and settle it as part of the overall cap.