Every customer contract you sign contains security commitments. Some are in a security exhibit everyone reads. Others sit in the data processing agreement, the service level terms, an order form, or a document the contract incorporates by reference. Together they describe what you have promised to do, and very few companies can list them.
That gap matters when something changes. You replace a subprocessor, move a data region, or revise your incident process, and nobody checks whether a customer was promised the old arrangement. This article covers where commitments live, the kinds you will find, why your SOC 2 report depends on them, and how to keep a register that stays accurate.
Where security commitments live
Look in more places than the security exhibit.
The master agreement. Usually a general obligation to maintain appropriate security, plus confidentiality, liability, and termination terms that affect security indirectly.
The data processing agreement. Under GDPR Article 28, it must cover security measures, subprocessors, assistance with data subject requests, deletion or return of data, and audits. What belongs in a GDPR data processing agreement goes through each term.
The security exhibit or addendum. The specific controls: encryption, access, testing, notification windows.
The service level agreement. Availability, support response times, sometimes backup and recovery objectives.
A business associate agreement, where HIPAA applies. It carries its own safeguard and breach reporting obligations.
Order forms. Customer-specific terms often appear here, outside the documents legal reviews most carefully.
Incorporated documents. A link to your security page, a policy, or the customer's questionnaire and your answers to it.
Incorporated documents deserve particular care. If a contract incorporates the current version of a page on your website, editing that page may change your obligations. If it incorporates a fixed version, you may be bound to a description you have since outgrown.
The kinds of commitment you will find
Most commitments fall into a handful of types. Each depends on a control you operate.
| Type | Typical wording | Depends on |
|---|---|---|
| Program | Maintain a written information security program | Policy set and governance |
| Assurance | Maintain a SOC 2 report and provide it annually | Audit schedule |
| Specific control | Encrypt customer data at rest and in transit | Technical configuration |
| Notification | Notify customer of a security incident within a set time | Incident response process |
| Subprocessors | Give notice of new subprocessors and allow objection | Vendor management process |
| Customer rights | Complete an annual questionnaire, allow audits | Review and audit handling |
| Data lifecycle | Delete or return data within a set time after termination | Deletion process and records |
| Personnel | Background checks, confidentiality agreements, training | People processes |
The table is a way to sort commitments, not a list of what to accept. Negotiating specific clauses is a separate exercise, covered in a later article on security addendums.
Why your SOC 2 report depends on them
Commitments are not only a legal concern. In a SOC 2 examination, the description criteria ask your system description to cover your principal service commitments and system requirements. The trust services criteria are then evaluated in terms of whether your controls give reasonable assurance that those commitments and requirements are achieved.
In practice, the commitments in your standard contract terms shape what the audit tests. If your standard terms promise incident notification within a set time, your incident response controls should be able to meet it, and your auditor may ask how you know they do. Writing the SOC 2 system description covers how to describe those commitments in the report.
Building a commitments register
A register is a list of every commitment, linked to the control that fulfills it. Each entry needs:
- Not done:
Customer, contract, and clause reference
- Not done:
The commitment in its exact wording, not a paraphrase
- Not done:
Type, from the categories above
- Not done:
Whether it matches your standard terms or deviates from them
- Not done:
The control or controls that fulfill it
- Not done:
An owner
- Not done:
Any deadline or trigger, such as a notice window or annual delivery date
- Not done:
Evidence that it has been met, where it recurs
Build it in two passes. First, record your standard terms once, linked to controls. Then go through signed contracts and record only the deviations. For most companies the deviations are a manageable list, and they are the entries that need the closest attention.
Going forward, make the register part of contract signature. Legal flags any security term that differs from standard. Security confirms whether existing controls can meet it before signature, not after.
Standard and non-standard terms
Every deviation from your standard terms creates an operational branch. A customer with a shorter incident notification window means your incident process needs a customer-specific notification list and a clock that starts at the right moment. A customer with a data location requirement means your infrastructure changes need a check against that customer's terms.
The aim is not zero deviations. Large customers will negotiate, and some requests are reasonable. The aim is that every deviation is recorded, owned, and reflected in the process that has to perform it. Your incident response plan should know which customers have non-standard notification terms. Writing an incident response plan covers where that list belongs.
An illustration
Say a 60-person SaaS company signs an enterprise customer whose addendum requires incident notice within 48 hours, against a standard term of 72. Six months later, the company's incident response lead revises the notification procedure and sets a single 72-hour target for all customers, because that is what the standard terms say. Nothing in the procedure mentions the exception.
Nobody did anything careless. The commitment lived in a contract the incident team never saw. A register entry linking that clause to the notification control, with the incident lead as owner, would have surfaced it the moment the procedure changed.
Reading the vague commitments
Some commitments are deliberately broad: "industry standard security," "commercially reasonable measures," "appropriate technical and organizational measures." Their meaning depends on the contract, the governing law, and the circumstances, and it is not settled by a security team's reading. Confirm with counsel how a broad standard is likely to be interpreted before you rely on it.
From a controls point of view, broad commitments are easier to defend when your contract ties them to something documented, such as your security policy or a named framework. A commitment to maintain a program aligned with ISO 27001, or to maintain a current SOC 2 report, gives both sides a reference point.
Keeping commitments and controls in step
Commitments break most often when a control changes and nobody checks the contracts. Build the check into the places where change happens:
Change management. Any change to data location, encryption, logging retention, or subprocessors includes a register lookup.
Vendor changes. Adding or replacing a subprocessor triggers the notice process for every customer entitled to notice.
Policy revisions. A policy change that weakens a commitment, such as a longer remediation window, is checked against customer terms first.
Annual review. Once a year, the owner of each commitment type confirms the controls still meet every commitment of that type.
How TrustLynce helps
TrustLynce customer commitments tracks the commitments in your contracts against the controls that fulfill them, so a control change can be checked against what customers were promised.