The security schedule your customer sent back

The enterprise buyer returns your contract with its own security and data processing annex, and somebody accepts it to keep the deal moving. What those four clauses actually commit you to.

Problems, in order · Part of Outsourced General Counsel

Your commercial terms went out. What came back was your own contract with a long annex bolted to the end of it, called something like "Information Security and Data Processing Requirements", and a procurement contact asking you to confirm acceptance by Friday so the deal lands in the quarter.

Somebody confirms. The deal closes. Nobody reads the annex, because the annex is not where the price is.

The annex is where the cost is.

What is a customer security schedule?

The security questionnaire you filled in during procurement described what you already do. The schedule says what you will do, for the life of the contract, whether or not you still do it that way in two years. The two documents look similar and do completely different jobs, and the second one is the one with teeth.

There is a reason these schedules arrive at all. Where the customer is handing you personal data to process on their behalf, they are required to put certain terms in writing. The obligation sits on them, which is why the paper comes from their side and why it is rarely negotiable in outline.

So some of the schedule is the customer meeting an obligation they cannot avoid. That part is fine, and arguing with it wastes the goodwill you will need for the rest. The rest is commercial drafting that arrived under the same cover, and it is not the same thing at all.

Which clauses actually decide what this costs you?

Uptime, measured their way

Your website says 99.9%. The schedule may also say 99.9%, and mean something entirely different by it.

The number is the easy part. The definitions underneath it are where the exposure sits: whether planned maintenance is excluded, whether the measurement window is monthly or annual, whether degraded performance counts as downtime, whether an outage in one customer-facing module counts the same as a full platform failure, and who measures. A monthly window with no maintenance carve-out is a materially harder promise than an annual one with a four-hour window each Sunday, and both can be written as 99.9%.

Then there is what happens when you miss. Service credits are usually capped and usually modest. What matters more is whether repeated misses give the customer a termination right, and whether that right comes with a refund of fees paid in advance.

The breach notification clock

The schedule will give you a period to notify the customer of a security incident. Twenty-four hours is common. Some ask for twelve.

That clock starts on becoming aware, and it usually runs in calendar hours rather than working ones. If your own incident process is built around confirming what happened before telling anyone, it is not compatible with a twelve-hour contractual clock, and the gap between the two is not discovered on a quiet Tuesday. It is discovered at two in the morning on a Saturday when the on-call engineer does not know that a contract requires a customer to be told before the investigation has found anything.

The drafting point is the trigger. "Becoming aware of a security incident" is much wider than "confirming a personal data breach", and the wider version means notifying the customer about events that turn out to be nothing, which has its own commercial cost.

Audit rights

Most schedules give the customer a right to audit. Read three things: who may exercise it, how often, and who pays.

A right for the customer to audit once a year on reasonable notice is normal. A right for the customer and any of its regulators and any third party it appoints to audit at any time, at your cost, with access to your premises and personnel, is a different obligation. So is an audit right that survives termination for several years.

The practical answer is usually not to refuse the right. It is to cap the frequency, require notice, confine it to the systems used to provide the service, and accept a recognised third-party report in satisfaction of it where you have one.

Sub-processor consent

This is the clause that quietly restricts how you run the business. If the schedule requires the customer's prior written consent before you engage a new sub-processor, then changing your hosting provider, your email service or your support tooling becomes a contractual negotiation with every customer who has that clause.

The regime the law contemplates has two versions: specific authorisation, or general authorisation with notice and a right to object. The Information Commissioner's Office sets out what the contract has to say about sub-processors and the controller's authorisation. General authorisation with a notice period is the version a supplier can actually operate. Specific consent, given to twenty customers, is a veto held by twenty people over your own infrastructure decisions.

Why does agreeing four different versions hurt more than agreeing one bad one?

This is the part that does not show up at signature and shows up hard at the first incident.

Say four enterprise customers each returned their own schedule, and each was accepted to keep the deal moving. One requires notification in twelve hours, one in twenty-four, one in seventy-two, and one on becoming aware of any incident affecting any system. Your incident runbook cannot be written four ways. In practice you either operate to the strictest clause across all four, which is the promise you never intended to make generally, or you operate to your own standard and are in breach of at least one contract every time something happens.

The same applies to audit windows, to sub-processor notice periods, and to the definition of downtime. Four bespoke schedules is not four contracts. It is one operating standard that nobody chose, made of the worst clause from each.

The fix is unglamorous: know what you have agreed, in one place. That is what contract lifecycle management is for, and it is the reason a register of who has which version beats a folder of signed PDFs. Once you can see the estate, the next enterprise schedule gets negotiated against a known position rather than against whatever the last one said.

What a sensible position looks like

You are not going to redraft an enterprise customer's schedule, and trying to is how a deal slips a quarter. What works is a short list of changes you always ask for, justified in operational terms rather than legal ones.

Notification measured from confirmation of a reportable breach rather than awareness of any incident. A notice period that matches a process you actually run. Audit rights capped at once a year, on notice, satisfied by an existing third-party report where one exists. General sub-processor authorisation with thirty days' notice and a right to object. Uptime defined with a maintenance window and measured monthly on the service as a whole.

Five points, asked for consistently, accepted most of the time. That is a very different negotiation from reading forty pages cold, three days before quarter end.

Dinmore Bell runs this as a standing position rather than a series of emergencies: the schedule you will accept, the five changes you always ask for, and a register of what every customer actually holds. Where that work belongs inside a wider function, it sits alongside the rest of what an outsourced General Counsel covers for a business selling into enterprise buyers.

Where a specialist is needed

Where a schedule sits on top of a regulated relationship, the schedule is not the whole picture. Financial services outsourcing rules, NHS and public sector frameworks, and sector-specific resilience requirements each impose terms of their own, and the customer's procurement team may not be the part of their organisation that knows this.

Where an incident has already happened and a regulator is involved, the question stops being contractual and becomes a reporting and enforcement question on a statutory clock. Where the data moves outside the UK, the transfer mechanism is a separate piece of work from the schedule itself. In each case the right move is specialist input early, and Dinmore Bell brings it in and runs it rather than handing the problem back.