Key Takeaways
- Key definitions like Customer Data and Security Incident determine when every downstream obligation kicks in and are critical to get right.
- The cost of a data breach is increasing across the years, making a well-drafted DSA even more critical for customers sharing their valuable data with vendors.
- Liability clauses are incomplete if they are drafted as a cohesive system that can work together after an incident occurs to ensure sufficient protection and recovery for the customer.
If you have spent any time negotiating technology vendor agreements, you have probably encountered a Data Security Addendum (“DSA” or otherwise commonly referred to as a Security Exhibit or Security Terms) in some form. Maybe the vendor sent you their standard template. Maybe you inherited one from a predecessor. Maybe you have been operating without one and quietly hoping nothing goes wrong.
As a seasoned in-house attorney supporting buy-side agreements for a Fortune 500 financial services company, I review a high volume of contracts on a regular basis and I’m finding that the majority of deals I work on involve security terms. Here is what I have learned after years of negotiating these documents: most DSAs are structurally incomplete. They may look comprehensive and seem to use all the right terminology. But when you map their provisions against the actual anatomy of a real breach, you start to find the gaps, and those gaps are exactly where vendors shelter when things go sideways.
So let’s talk about what a DSA actually needs to do, what every required provision is responsible for, how they connect to each other, and what you should be looking for and fixing when one lands on your desk.
What is a DSA?
A Data Security Addendum is a contract that governs how a vendor must protect your data, what they are required to do when something goes wrong, and what you can recover when they fail. It operates alongside your Master Service Agreement and Data Processing Agreement, but it serves a distinct function. Where your MSA governs the commercial relationship and your DPA governs regulatory compliance of personal data, your DSA governs the security obligations themselves.
The Foundation: Core Definitions
There is a constant, natural tension between customers and vendors when it comes to data security. Customers want the broadest, strongest, most stringent requirements from vendors because every gap in scope is a gap in protection, and the costs of a breach fall hardest on the party whose data was compromised. Vendors want the narrowest, lightest, most flexible requirements because broader obligations expand their costs and notification exposure.
Customer Data Definition
Before a single security obligation can be evaluated, you need to know what data it attaches to. The Customer Data definition is the ground floor of the entire DSA. It determines the scope of every security obligation, every Security Incident trigger, and every financial remedy in the document. If your DSA is a building, the Customer Data definition is what it is built on. Get it wrong, and the rest of the structure is compromised regardless of how well it is drafted.
The most common drafting mistake is defining Customer Data as “information provided by Customer to Vendor in connection with the Services.” Every word in that phrase is a limitation. Let’s break it down. “Provided by Customer” excludes data the vendor generates or derives. “In connection with the Services” invites a narrow reading that excludes background processing, metadata generation, and incidental data collection.
A properly drafted Customer Data definition captures:
- everything the vendor receives from you,
- everything they generate or collect on your behalf, and
- everything they derive from any of the above, including model outputs, behavioral profiles, and AI-generated analytics.
Security Incident Definition
The Security Incident definition determines when a vendor’s notification obligations, remediation obligations, and indemnification provisions are triggered. Getting this definition right is one of the most consequential drafting decisions in the entire agreement.
Vendors of course prefer to narrowly define Security Data. They may propose language tied to “confirmed, unauthorized access” to specific categories of data. Every qualifier such as “confirmed,” “unauthorized,” or “resulting in,” is a narrowing, delay mechanism. It allows the vendor to investigate, assess, and characterize the situation before their obligations attach. In a real breach, that delay costs you dearly.
From the customer perspective, you’ll want to broadly define Security Incident as much as possible. Broadly drafted definitions include “any actual or reasonably suspected” compromise, unauthorized access, acquisition, disclosure, loss, or destruction of Customer Data, regardless of whether the vendor has confirmed it or assessed its severity. Suspected and potential breaches matter to a customer whose client, user, or employee data may be at risk. That’s why customers prefer the notification clock to start running at reasonable suspicion, not at confirmed determination.
The Core: Security Obligations
Everything in a DSA is built on the vendor’s affirmative obligation to implement and maintain appropriate security measures. This is where most DSAs begin and where many of them stop being specific enough to be useful.
Vague language like “industry-standard security measures” or “reasonable technical and organizational measures” sounds protective but gives you almost nothing to enforce. What is industry standard? According to whom? Measured when? A sophisticated vendor will usually be able to argue their practices met whatever standard is implied.
Your DSA needs to be specific and clear. Enumerate the security controls you require, such as encryption standards for Customer Data at rest and in transit, access control protocols, multi-factor authentication requirements, vulnerability management and patching timelines, penetration testing frequency, employee security training, and subprocessor oversight. The more specific you are, the harder it is for a vendor to claim compliance while doing the minimum.
The Response: Notification and Remediation
Once a Security Incident is triggered, two parallel obligations attach: notification and remediation. These are related but distinct, and your DSA needs to address both clearly.
Notification Obligations
Notification obligations cover when the vendor must tell you about a Security Incident, what information they must provide, and how that information must be delivered. Forty-eight to seventy-two hours is the current market standard for initial notification, with a more detailed follow-up report within a defined period. Your notification provision should specify what the initial notice must contain: at minimum, the nature of the Security Incident, the Customer Data affected, the number of individuals involved, and the steps the vendor is taking in response.
Remediation Obligations
Remediation obligations cover who pays for the costs of responding to a Security Incident. This is where many DSAs are most incomplete and where your financial exposure is greatest.
Remediation costs include forensic investigation, breach notification to affected individuals and regulators, credit monitoring services, regulatory fines, legal fees, class action exposure, and crisis communications.
According to the 2025 IBM Cost of a Data Breach Report, the average U.S. breach now costs $10.22 million, an all-time high.[1] Your remediation cost provision needs to define these categories explicitly and make clear that the vendor is responsible for them when the Security Incident originated in their environment.
The Recovery: Indemnification, Limitation of Liability, Insurance
Indemnification and limitation of liability are the provisions that determine whether your DSA actually makes you whole after a Security Incident or leaves you absorbing costs that should sit with the vendor.
Indemnification
Your indemnification provision should cover the full scope of losses you can incur: remediation costs, regulatory fines assessed against you as a result of the vendor’s Security Incident, third-party claims and class action settlements, outside counsel fees, and reputational damage costs. The trigger language matters enormously here. Push for a “arising out of or relating to” nexus rather than “directly and proximately caused by.” The former covers the full chain of consequences; the latter invites arguments about intervening causes.
Limitation of Liability
The limitation of liability section is where DSA negotiations most frequently stall because it forces both parties to confront the real financial stakes in concrete terms.
Most commercial agreements cap vendor liability at fees paid in the prior twelve months.[2] For a vendor that’s processing millions of your customer records and charging $200,000 annually, that cap has no relationship to your actual exposure.
A meaningful DSA includes a super cap, or a separate, higher limit that applies specifically to Security Incidents. Super caps are usually expressed as a fixed dollar amount rather than a fee multiple because the security risk is rarely tied to the dollar spend. Gross negligence and willful misconduct should be carved out entirely because those categories of conduct reflect a deliberate or reckless disregard for security obligations that no liability cap should reward. Allowing a vendor to cap liability for conduct that is grossly negligent or intentional would undermine the entire risk allocation framework of the DSA.
Insurance
Indemnification and super caps only matter if the vendor can actually pay. Cyber insurance is the provision that ensures financial remedies are backed by real capacity rather than vendor balance sheet promises.
Require the vendor to maintain cyber liability insurance coverage at a defined minimum limit, typically $5 million to $10 million for enterprise relationships, and to name you as an additional insured or provide a certificate of coverage on request. The policy should cover the specific categories of loss your DSA addresses: Security Incident response costs, third-party liability, regulatory fines, and business interruption. A vendor who refuses to maintain cyber insurance is either uninsurable, which tells you something, or is signaling that they do not intend for your indemnification rights to be financially meaningful.
The Extended Obligation: Subprocessor Controls
Vendors don’t usually operate alone. They use subprocessors, third-party tools, cloud infrastructure providers, and service partners to deliver their platform. Every one of those relationships is a potential vector for a Security Incident involving your Customer Data.
Best practices and leading market standards require that your DSA address subprocessors directly. Require the vendor to maintain a list of approved subprocessors, notify you before adding any new subprocessor who will have access to Customer Data, and flow down security obligations to every subprocessor that mirrors the obligations the vendor has accepted to you. If the vendor’s subprocessor suffers a Security Incident affecting your Customer Data, the vendor should remain fully liable as if the Security Incident had occurred in their own environment.
The Verification Mechanism: Audit Rights
Security representations in a DSA are only as good as your ability to verify them. Audit rights are the provision that converts a vendor’s security promises from self-reported claims into independently verifiable commitments.
A meaningful audit rights provision gives you the right to request a current SOC 2 Type II report or equivalent certification, to submit a security questionnaire for the vendor to complete, and, for high-risk engagements, to conduct or commission a security assessment of the vendor’s controls and practices. It should specify the frequency, the vendor’s cooperation obligations, and what happens if the audit reveals material gaps.
Most vendors will resist full on-site audits but will accept annual SOC 2 obligations and security questionnaire responses. Accepting those as the floor is often reasonable. What is not acceptable is a DSA with no verification mechanism at all, which is what most standard vendor templates contain. If you cannot verify the security controls you are relying on, you are not managing risk, you are hoping.
The Lifecycle Obligation: Data Retention and Return
Every DSA should address what happens to your Customer Data when the engagement ends. Without a data retention and return provision, you have no visibility into whether the vendor retains your data indefinitely, how it is protected after the engagement concludes, or whether it is actually deleted rather than merely archived.
Return of Data
Upon termination or expiration of the agreement, or upon your written request at any time during the term, the vendor should be required to return all Customer Data to you in a usable, structured format within a defined period, typically thirty to sixty days. Return obligations should extend to all copies of Customer Data regardless of where they are stored, including in backups, archives, and subprocessor environments.
Data Retention
The data retention provision should specify the maximum retention period following termination, require return or secure destruction of all Customer Data and any copies within a defined period, and require the vendor to provide written certification of deletion. It should also address data held by subprocessors, which vendors routinely forget to include. A vendor who insists on retaining your Customer Data indefinitely for undefined business purposes is telling you something important about how they intend to use it.
The Use Restriction: Permitted Use of Customer Data
Security obligations protect Customer Data from unauthorized third-party access. Permitted use restrictions protect Customer Data from authorized but impermissible use by the vendor itself.
Vendors increasingly derive value from the data they process. Model training, benchmarking, commercial analytics, product improvement, and market intelligence are all potential uses of Customer Data that a vendor may pursue without disclosure if your DSA does not prohibit them. Your DSA should expressly restrict the vendor’s use of Customer Data, and any derivative thereof regardless of form, to the sole purpose of providing the contracted services. Any other use should require the customer’s prior written consent.
This is not a hypothetical risk. The 2025 IBM Cost of a Data Breach Report found that shadow AI, where employees or vendor systems feed Customer Data into AI tools outside the vendor’s approved security controls, was a factor in 20% of breaches.[3] A permitted use restriction creates a contractual backstop against exactly that kind of unauthorized processing.
The Architecture: How the Provisions Connect
These provisions do not operate independently. They form an architecture, and weaknesses in one area cascade through the others. Like this:
A narrow Customer Data definition means the Security Incident trigger may not apply to the data that was actually breached. A narrow Security Incident definition means the notification clock never starts. A broad notification obligation means nothing if your remediation cost provision does not cover what you actually spend. A robust indemnification clause is toothless against a liability cap that is capped at fifty thousand dollars, and none of it matters if the vendor lacks the insurance to back it up. Subprocessor obligations without audit rights are unverifiable. Permitted use restrictions without data retention obligations leave the vendor free to continue using Customer Data after the engagement ends.
So my pro tip to you is: read every DSA as a system. The question at each provision is not whether the language sounds reasonable but whether it does what it needs to do when a real Security Incident unfolds in real time.
If your DSA is a building, the Customer Data definition is the ground floor, the Security Incident definition is the alarm system, and audit rights are the smoke detector. Most vendor templates give you walls with no foundation, an alarm that only sounds after the fire has spread, and no way to test whether any of it works.
Contract Review Tips
The next time a vendor’s DSA lands on your desk, read it in this order:
- Start with the Customer Data definition and ask whether it covers every category of data the vendor will touch.
- Map the Security Incident definition and ask whether it triggers at reasonable suspicion or only at confirmed breach.
- Trace the notification timeline and remediation cost provisions and ask whether they address what you would actually need in a real incident.
- Review the indemnification and liability structure and ask whether the super cap has any relationship to your actual exposure.
- Then check for the provisions that most vendor templates omit entirely: subprocessor controls, audit rights, data retention obligations, permitted use restrictions, and cyber insurance requirements.
- Cross check the DSA against the master agreement it attaches to for alignment with defined terms, inconsistencies across clauses, and appropriate cross-referencing to related sections.
- Partner with your security experts to review the gaps, discuss the context, and determine which ones to redline and push for in the negotiation process.
A well-negotiated DSA is not just a legal document. It is a risk allocation framework that closes the gap between what the law requires and what your specific risk exposure demands. Build it completely. Because, as we know, the data is in the details.
[1] IBM Security, “Cost of a Data Breach Report 2025,” IBM Corporation, 2025. The report analyzes breaches experienced by 604 organizations across 17 industries and 16 countries and regions between March 2024 and February 2025.
[2] The twelve-month fee cap is widely documented as the prevailing market standard in technology vendor agreements. See, e.g., World Commerce & Contracting, “Commitment Matters: Understanding Limitation of Liability Clauses,” 2022; and Taft Stettinius & Hollister LLP, “Negotiating Technology Contracts: Key Provisions and Pitfalls,” noting that standard liability caps in SaaS and enterprise software agreements are most commonly set at fees paid in the prior twelve months.
[3] IBM Security, “Cost of a Data Breach Report 2025,” IBM Corporation, 2025. The report found that shadow AI was a contributing factor in 20% of breaches studied, and that customer Personal Data was the most commonly compromised data type in those incidents at 65%, notably higher than the global average of 53% across all breach types.
The post Anatomy of a Data Security Addendum appeared first on Contract Nerds.