The customer's legal team sends their security addendum. It runs to several pages, it was written for every vendor they buy from, and some of it describes an operation you do not run. Signing it as written creates obligations your controls cannot meet. Rejecting it wholesale stalls the deal.
Most security addendums are negotiable, and the negotiation goes faster when security and legal work through it together, clause by clause, with a clear view of what your controls actually do. This article covers the clauses that come up most, what is usually being asked, and a workable alternative for each. Contract interpretation turns on the exact wording and governing law, so confirm any redline with counsel before you send it.
Before you redline: three questions
Answer these before you mark up a single clause.
Does it conflict with your existing terms? Compare it with your data processing agreement and your standard security exhibit. Note any conflict and check which document the contract says takes precedence.
Can your controls meet each clause today? Security should read every clause and mark it as met, met with a change, or not met. Legal cannot make that call alone.
Is the customer regulated in a way that fixes some terms? An EU financial entity under DORA, or a healthcare customer under HIPAA, may be required to include certain terms. For those, negotiate how the obligation is met, not whether it exists. DORA contract requirements for ICT services covers what those buyers must secure.
Your earlier inventory of commitments helps here. Security commitments in customer contracts covers how to record what you have already agreed elsewhere, so this addendum does not contradict it.
Incident notification
The usual ask: notice of any actual or suspected security incident within a short fixed window, sometimes a few hours.
The problem: "any," "suspected," and a short clock together mean notifying the customer of events that turn out to be nothing, often before you know anything useful.
A workable alternative: define a security incident as a confirmed breach of security affecting the customer's data. Start the clock when you become aware of that incident, not when the first alert fires. Allow an initial notice with the facts known at the time, followed by updates.
Understand the customer's reason. Under GDPR Article 33, a controller generally has 72 hours from becoming aware of a personal data breach to notify its supervisory authority, and a processor must notify the controller without undue delay. Your customer needs time to meet their own deadline. A window that respects that, with a clear trigger, is usually acceptable to both sides.
Audit rights
The usual ask: the right to audit you, on site, at any time, as often as the customer wishes.
A workable alternative: an annual right, with reasonable notice, during business hours, satisfied first by your current audit report and a completed questionnaire. Further audits only after a security incident affecting the customer or at a regulator's request. The customer bears its own costs, and auditors are bound by confidentiality and cannot access other customers' data.
Regulated buyers may need broader rights than this. When they do, negotiate the method, such as remote evidence review or a pooled audit with other customers, rather than the right itself.
Prescribed controls
The usual ask: specific technical requirements, such as a named encryption algorithm, a particular scanning frequency, or compliance with the customer's own security policy "as updated from time to time."
The problem: prescriptive controls age badly, and an obligation to follow another company's policy as it changes is an obligation you cannot see in advance.
A workable alternative: outcome-based wording, such as encrypting customer data at rest and in transit using current industry-accepted algorithms, tied to your documented security program. Add a clause that lets you change controls provided the overall level of protection is not materially reduced. If the customer insists on their policy, agree to a specific dated version, with changes requiring your agreement.
Customer penetration testing
The usual ask: the right to penetration test your service.
A workable alternative: in a multi-tenant service, offer your own test summary, as described in sharing penetration test results with buyers, a scoping call with your tester, or testing in a dedicated environment. If you allow customer testing, require advance notice, an agreed scope and window, and that findings are shared with you.
Subprocessors
The usual ask: prior written consent before you engage any new subprocessor.
A workable alternative: notice of new subprocessors in advance, with a right to object on reasonable grounds and, if the objection cannot be resolved, a right to terminate the affected service. This matches the general written authorization model GDPR Article 28 allows, and it is workable for a service with many customers. Per-customer consent can stop you changing a vendor at all.
Data location
The usual ask: all customer data stored and processed only in a named country or region.
The check: storage location is only part of it. Ask engineering whether backups, logs, support tooling, and staff access from other countries are covered. If they are not, narrow the clause to primary storage and disclose the rest, or say what you can actually offer.
Personnel requirements
The usual ask: background checks for all personnel, training, and signed confidentiality agreements.
A workable alternative: limit background checks to personnel with access to customer data, carried out where permitted by local law and to the extent it allows. What employers can check varies widely by country and, in the US, by state and city.
Deletion and return
The usual ask: delete all customer data within a short period after termination, including from backups, and certify it.
A workable alternative: deletion from production systems within a set period, and from backups as they expire on their normal rotation. Offer a written confirmation rather than a certificate if you cannot verify backup deletion item by item.
Fixing the customer's findings
The usual ask: remediate any vulnerability the customer identifies within a fixed number of days, regardless of severity.
A workable alternative: remediation according to severity, using the timelines in your vulnerability management policy, with compensating controls documented where a fix takes longer.
Liability, indemnities, and insurance
Security addendums often carry higher liability caps for data breaches, uncapped indemnities, or minimum insurance coverage. These are commercial and legal decisions. Security's role is to explain the realistic exposure: what data the service holds, how much, and which controls limit the impact of a breach. Finance should check any insurance minimum against the actual policy before anyone agrees to it.
Order of precedence
A customer's addendum often sits alongside your own data processing agreement and security exhibit, and the documents rarely agree on every point. Check what the contract says about which document wins in a conflict. If it says nothing, ask for a clause that settles it. Without one, two inconsistent notification windows or deletion periods can both appear binding, and you will learn which one applies at the worst possible time.
After signature
Record every term that deviates from your standard position, with an owner and the control that fulfills it. A shorter notification window means a named customer on your incident notification list. A data location promise means a check in change management. An addendum that is signed and filed, but not reflected in operations, is a breach waiting for its occasion.
How TrustLynce helps
TrustLynce customer commitments tracks what each contract promises against the controls that fulfill it, so negotiated terms stay visible after signature.