The framework agreement sits with sales. The service description at the front, an information security annex at the back, signature due by the end of the month because the deal should still land in this quarter. In many SMEs, nobody who will later have to keep the security clauses in customer contracts ever reads them. This is rarely a legal problem, it is an operational one: commitments appear that the business only learns about when a customer calls them in.
From that point the notification deadline is a deadline and the certification is a date, and none of it is up for negotiation any more.
Security clauses in customer contracts create obligations that surface in operations months later: notification deadlines, audit rights, certificates with a cut-off date, approval duties for subcontractors. Before signature they are negotiating points. After it they are costs. The most expensive security measure in an SME is often a sentence nobody from security has seen.
A contract clause is a security measure without a budget
When an SME spends money on security, it goes through procurement: quote, comparison, approval, budget line. A security clause in a customer contract works differently. It enters the company through sales, it has no price and no budget line, and it still creates work for the entire term of the contract. An audit right costs preparation and support from people who also run normal IT. Behind a certification obligation sits a build programme plus audit fees, and behind a notification duty sits somebody who is allowed to decide outside office hours.
The uncomfortable part is that these obligations are often sensible. A customer who sets requirements is doing something right. They are simply decided at the one place in the company where nobody can judge the operational consequences.
After signing, many companies buy a tool that is meant to cover the commitment. Most of the time that is the wrong direction. The clause does not call for software, it calls for ownership: somebody who decides, reports and signs when it matters. More protection, fewer tools, lower cost applies here too, but only if you know what you are committing to beforehand.
Which security clauses in customer contracts cost the most?
The most expensive clauses are the ones that demand an ongoing service rather than a state. A sentence about encryption is usually met quickly. A 24-hour notification deadline, an annual on-site audit right and a certificate with a cut-off date tie up time and money every year, from people you do not have twice.
| Clause | What it triggers in operations |
|---|---|
| Reporting an incident within 24 or 48 hours | Detection, assessment and a decision path around the clock. The deadline runs on a Saturday too. |
| Customer audit right on site | Preparation, hosting, evidence, follow-up work. Two to three working days per audit, in our experience more the first time. |
| Certificate by a given date | An ISMS build plus external audit fees plus surveillance audits in the following years. |
| Approval before using subcontractors | Every change of a cloud service or provider needs the customer to sign off. |
| Deletion and return of all data at the end of the contract | You have to know where this customer's data sits. Including backups and archives. |
| Technical minimum requirements with deadlines | Patch deadlines and hardening rules that can go beyond how you run things today. |
The last row draws the least attention when you read it and holds up worst in daily operations. A clause demanding patches for critical vulnerabilities within seven days is quickly agreed. It does mean that a production system reboots on a Wednesday, even in peak season. That trade-off belongs in the management team, not in the contract archive.
What a 24-hour notification deadline demands in operations
The best known security clause in a customer contract is the notification deadline. It looks harmless, because a notification is quick to write. These deadlines are short because they come from regulation that applies to the customers themselves and gets passed down the supply chain. In Switzerland a statutory 24-hour deadline applies only to operators of critical infrastructure, who have had to report cyberattacks to the BACS, the Swiss federal office for cybersecurity, within 24 hours of discovery since 1 April 2025 (source: reporting obligation information from the Swiss federal office for cybersecurity). In data protection no number of hours appears in the law. Under Art. 24 of the revised Swiss Data Protection Act (nDSG), the controller reports a data security breach with a high risk to the EDÖB, the Swiss data protection commissioner, "as quickly as possible" (source: Data Protection Act on Fedlex).
Your contract is allowed to be stricter than both, and it often is. That is legitimate, it only moves the real difficulty. The 24 hours are not the problem. The problem is the path to the notification. Who notices on a Friday evening that something has happened, who is allowed to decide that it is reportable, and who is allowed to tell a major customer that their data may be affected. If those three questions are settled in advance, the deadline is workable. If they are not, more monitoring will not help either, because the time is lost in coordination rather than in technology.
The same pattern shows up with EU customers when requirements from the NIS2 directive are passed on through the contract. How that lands in Swiss SMEs is covered in NIS2 and Swiss SMEs.
Who reviews the security clauses before signature?
One person with a mandate, not a committee. In an SME this works when sales has exactly one address to send a contract with a security annex to, and when that address answers within two working days. Sales bypasses anything slower, because the deal is pressing. Ownership without a response time is not ownership, it is a bottleneck.
Reviewing a security clause is not a legal opinion. It produces three possible answers, and its value lies in happening before signature at all:
- We can keep this today. The commitment matches what is already running.
- We can keep it, but it costs. Achievable, yet it demands effort, budget or an additional role. The commitment is bearable as soon as the cost and the owner are named.
- We cannot keep it. Either renegotiate or accept it deliberately as a risk, documented and carried by the management team. Not quietly hoped away.
The third case is the most important one, and it is a business decision rather than an IT decision. A contract can be worth taking on a commitment that is not covered today. The management team then knows it has just bought a project and not only a customer.
An example of how this looks in practice
Take a machine builder in the canton of Aargau with 130 employees, signing a framework agreement with a large industrial customer. The security annex demands three things: ISO 27001 within twelve months, incident notification within 24 hours, and a customer audit right once a year.
The contract is attractive, the annex looks like a formality. Two months later IT notices what the company has committed to. The certification is not a document but a build programme with a scope decision, policies, a risk register and an external audit. The notification deadline assumes somebody is reachable and able to decide at the weekend. The audit right means a customer gets to ask questions nobody has asked before.
Cleaning that up afterwards costs more than the review beforehand would have. Three realistic routes remain: set up and budget the certificate as a programme, move the cut-off date with the customer to a workable one, or reduce the commitment to an ISMS built to ISO 27001 and tie certification to the point at which the customer needs it. All three are viable. They are simply open on worse terms after signature, because the other side no longer gains anything from easing your load.
What you can commit to without regretting it
The security clauses in customer contracts that hold up are the ones attached to something you do anyway. A notification deadline is sustainable when an on-call rota and a decision path exist, because you need both for your own incidents. An audit right is manageable when the evidence sits where customer questionnaires need it. A certificate makes sense when it convinces several customers and not just one.
It gets expensive as soon as a clause demands a separate world: a process only for this customer, an evidence pack only for this contract, a technical requirement that does not fit the rest of your operations. Two contracts like that, and you are running three security standards in parallel. That is the same sizing problem as with tools, only bought through contracts. Companies that consolidate the requirements of several customers onto one set of evidence answer the next questionnaire faster and more honestly. How that works without guessing is covered in Customer security questionnaires. What we take on in a mandate, including audit support, is set out under packages and fixed prices.
When is renegotiating worth it?
Renegotiating is almost always worth it when the clause comes from a template rather than from an obligation of the customer. One question tells you which it is: where does this requirement come from. If it comes from a standard annex used by procurement, the chances are good that a cut-off date or a deadline can move. If it comes from regulation or from an audit the customer is subject to, they will not delete it, because they have to pass it on.
That difference decides what you can ask for. In the first case it is about dates and scope. In the second it is only about how you meet the requirement, and there the customer is often cooperative, because they want the contract too. The argument that you are too small for it rarely works. A concrete counter-proposal with a date often does.
Frequently asked questions
Can we have a certification obligation removed from the contract?
Sometimes, though usually only in a weaker form. The common route is to tie the obligation to the evidence instead of the certificate: an ISMS built to ISO 27001 with an audit report or a self-declaration, with the option of certifying later. What matters is that you name a date you can hold, rather than quietly accepting the one proposed.
What happens if we break a security clause?
Rarely a lawsuit straight away. More often an escalation in day to day business: procurement asks for a remediation plan, the next audit turns uncomfortable, the contract renewal slips. It gets expensive when the breach becomes visible together with an incident. You then negotiate liability and trust at the same time, in a week when you have neither.
Does every contract need a security review?
No, and that ambition is what makes the review fail. A threshold sales can apply itself works better: contracts with a security annex, with access to customer data, or with a connection into customer systems. The rest carries on as before. A review that only covers those few contracts and works reliably there is worth more than a policy for everything that nobody follows.
Most of these commitments would have held if somebody had read them before signature. What is missing is rarely a control, it is ownership that sits early enough in the process. What security commitments are in the last contract you signed? The answer says more about your security organisation than any tool list.