For release and change managers
That is the actual complaint, and the honest response begins with what you cannot have: on a shared service nobody approves each release, because a shared service cannot run one version per customer. What is offered instead is advance notice to a person, additive changes, a stated deprecation window, and a per-release record your change process can consume.
An organisation with a mature change process has spent years earning it — a calendar, a board, a freeze period, a rollback plan, a record of who approved what. It governs everything the organisation deploys, and it governs none of what its suppliers deploy into the same operation on a Tuesday morning.
The result is a category of incident that is nobody’s fault and lands entirely on the customer. A supplier ships a reasonable improvement, it interacts with something specific about how one organisation uses the product, and the people paged are people who deployed nothing that week and will spend the first two hours proving that.
Deprecation is the slower version of the same problem. A notice appears in a release note that nobody subscribed to, a period passes, something is removed, and the integration built three years ago by somebody who has left stops working. Every step was announced and no step reached a person whose job was to act on it.
Freeze periods are where the mismatch is sharpest. An organisation with a genuine reason to change nothing — a financial close, a peak trading week, an election, an enrolment period — discovers that the freeze applies to their own deployments and not to their suppliers’, and that the exception request has nowhere to go.
And the effect on assurance is the quiet one. A system assessed in March is not the system running in September, nothing declared the divergence, and the assessment on file describes something that no longer exists. The security review was correct when it was written and it has been silently untrue since.
A shared service cannot run a different version for each customer, so nobody on it approves individual releases — and a change-control page that implies otherwise has described a veto the reader does not have and will discover they do not have during an incident.
That is stated first because it is the thing every change manager wants and the thing most supplier pages fudge. On the shared service, releases go to everybody, and the honest offer is not approval but predictability: notice before rather than after, additive change rather than reshaping, and a record your process can consume.
Notice reaches a person you nominate rather than a release feed. This is the difference between a deprecation that is announced and one that is received, and it is almost the whole of what goes wrong in this area. A supplier who publishes to a changelog has satisfied a documentation obligation and communicated with nobody.
Changes are additive by default. Fields are added rather than repurposed, code lists grow rather than change meaning, behaviour is extended rather than altered under a stable version. A change that would break an existing integration is a new version rather than a release, and the old version continues for a stated deprecation period rather than an indefinite one that ends when somebody notices the cost.
Every release carries a record your own change process can consume: what changed, which surfaces it touches, whether anything is deprecated and when it ends, and how to tell if you are affected. That last field is the one that makes it usable — a release note describing what changed is common, and a release note telling a specific customer whether it matters to them is not.
Freeze periods are honoured where they are declared in advance, and this is where the shared service reaches its real limit rather than a drafted one. A declared freeze suspends non-essential releases affecting your organisation; it does not suspend a security fix, and it does not suspend a change required to keep the service running. That boundary is drawn here rather than during your close week.
And where a change genuinely cannot wait — a security fix — the notice is after rather than before, with the reason stated. Pretending otherwise would be a commitment nobody keeps, and the first time it was broken would be the moment your trust in every other commitment on this page was correctly withdrawn.
Whether notice reaches a person — measured by a nominated contact named in the agreement rather than a changelog subscription.
Whether a change can break you silently — measured by the additive-only commitment, testable by checking whether any field has ever been repurposed.
How long you have after a deprecation — measured by the deprecation window written as a number of months rather than at our discretion.
Whether a release record enters your process — measured by the per-release record, including whether your organisation is affected.
Whether a declared freeze is honoured — measured by declaring one during a trial and confirming non-essential releases are suspended.
Whether your assessment is still accurate — measured by the running version being reportable on demand against the version you assessed.
no per-customer release approval on the shared service, because a shared service cannot run one version per customer. No commitment to notice before a security fix — those proceed and the notice follows with the reason. No suspension during a freeze of a change required to keep the service running. Where per-release approval is genuinely required, the answer is a deployment inside infrastructure you operate, where the release is an artefact your pipeline promotes. An independent SOC 2 Type II attestation is in progress and no report exists yet.
Running inside infrastructure you already operate is where the veto genuinely exists, and it exists because the release becomes an artefact your pipeline promotes on your maintenance window rather than a change we make. Your change board approves it like anything else your organisation deploys, and your freeze period covers it because it is yours.
The cost of that is described on the deployment page and should not be minimised here: your team carries the patching cadence, and a version left unpromoted for a long time is a version accruing the fixes it did not take. A veto is also a responsibility, and organisations that acquire one sometimes discover they preferred not having it.
On the shared service, the compensating property is the release record. It is written so your change process can consume it as an input — a dated entry describing what changed and whether your organisation is affected — which is not approval and is considerably better than a changelog nobody reads.
No promise that a security fix waits for notice. A supplier making that commitment would break it the first time it mattered, and the breaking of it would correctly destroy confidence in every other commitment on this page. Security fixes proceed and the notice follows with the reason.
No promise of per-customer approval on a shared service. Every change manager wants it, most supplier pages imply it without saying it, and the discovery that it does not exist happens during an incident. Where it is genuinely required, the deployment inside your own estate is the honest answer and it comes with a cost that belongs in the decision.
What is committed is narrower and keepable: notice to a person, additive change under a stable version, a deprecation window stated in months, a release record your process can consume, and freeze honouring for non-essential change. Each of those can be tested during a trial rather than trusted.
Every property here is designed rather than independently attested. A SOC 2 Type II attestation is in progress and no report exists yet; change management would fall within the scope of the one under way rather than being a separate exercise, and it is an attestation with a defined period rather than a certification.
Name the contact in the agreement. Notice that goes to a mailing list is notice nobody receives, and the audit question afterwards is whether you were told — which a subscription does not answer.
Fix the deprecation window as a number of months rather than accepting a period at the supplier’s discretion. A discretionary window shortens precisely when the supplier most wants to remove something, which is the moment your integration is least ready.
Ask exactly what a declared freeze does and does not suspend, and get it in writing before your first close period rather than during it. A supplier who cannot answer that has not thought about it, and you will be the case that makes them.
And decide honestly whether you need per-release approval. If you do, that is the estate-hosted deployment and it comes with a patching cadence your team carries. Many organisations discover during that conversation that predictability was what they actually wanted.
A trial period during which your team nominates a contact, receives release records into your change system, and declares one freeze week to observe what is and is not suspended.
Declaring a freeze during a trial is the only way to find out what a freeze commitment is worth, and it costs a week. Doing it during a real close period is how most organisations find out instead.
Have the release records land in your change system rather than in an inbox, and check whether the affected-or-not field is actually usable by whoever triages your changes. A record nobody can act on is a changelog with better formatting.
Then decide the shape. If the trial shows that predictability is enough, the shared service is the right answer; if your process genuinely requires approving each release, that is the estate-hosted deployment and its cost belongs in the decision rather than in a later surprise.
On the shared service you cannot, and it is better to hear that here than during an incident. One version serves everybody, so per-customer approval is not something the arrangement can offer and a page implying otherwise would be describing a veto you do not have. Where approval is genuinely required, the honest answer is a deployment inside infrastructure you operate, where a release becomes an artefact your pipeline promotes on your maintenance window and your change board approves it like anything else — at the cost of your team carrying the patching cadence.
That is almost the whole of what goes wrong here. A supplier publishing to a changelog has satisfied a documentation obligation and communicated with nobody, and the integration that breaks was built three years ago by somebody who has left. Notice goes to a person your organisation names in the agreement, and the deprecation window is a number of months rather than a period at our discretion — because a discretionary window shortens exactly when a supplier most wants to remove something, which is when your integration is least ready.
A freeze declared in advance suspends non-essential releases affecting your organisation. It does not suspend a security fix and it does not suspend a change required to keep the service running, and that boundary is drawn here rather than during your close week. Get it in writing before your first one and test it during a trial by declaring a freeze week deliberately — a supplier who cannot tell you what a freeze does and does not cover has not thought about it, and your close period should not be the case that makes them.
That is the quiet cost of supplier change and almost nothing reports it. The running version is reportable on demand against the version you assessed, so the divergence is a question your team can ask at any time rather than something discovered during a re-assessment. Combined with additive-only change under a stable version, it means an assessment ages predictably rather than silently — which is not the same as never ageing, and no supplier can offer that.
No, and any supplier who commits to that will break it the first time it matters. A security fix proceeds and the notice follows with the reason stated. Making the opposite promise would buy a signature and would be broken within the year, at which point you would be right to withdraw confidence from every other commitment on this page. The narrower promises here — notice to a person, additive change, a stated deprecation window, a release record, freeze honouring for non-essential change — are the ones that can actually be kept.