What a Provider Migration Means for an Existing SOC 2 Vendor Assessment

The outgoing provider passed vendor review, so the incoming one should be a formality. It is not, and the reason is structural: what your security team approved was a specific system, described in a specific report, over a specific window. None of those three things carry over.

Approval attaches to a system, not a category

A vendor risk assessment is a decision about one supplier processing one category of your data in one architecture. “LLM inference” is not the unit of approval; “this vendor, receiving these fields, retaining them for this long, in these regions” is. Change the vendor and every input to that decision is unevaluated again, including several that feel identical between providers and are not: the retention default, whether prompts and completions are eligible for training, which subprocessors sit behind the endpoint, and which regions the request can be served from.

There is a second reason that catches teams out. Most vendor registers record an approval against a purpose, and the purpose usually changes at the same time as the provider — you are moving because you want a capability the old vendor did not have. A migration that also adds file uploads, a hosted tool that fetches URLs, or a fine-tune trained on customer transcripts is not the same data flow, and would have needed re-review even if the vendor had stayed the same.

What the report actually covers

A SOC 2 report is an attestation performed under the AICPA’s Trust Services Criteria. Reading one is mostly a matter of reading its boundaries, and the boundaries are where reviews stall. Five of them matter more than the control list itself.

• Type I versus Type II. A Type I report opines on whether controls were suitably designed at a point in time. A Type II opines on whether they operated effectively across a period. Only the second tells you anything about how the vendor behaves on an ordinary Tuesday.
• The observation period, and the gap since. A Type II covers a window that has already closed. If the window ended eight months ago, nothing has been attested about the eight months you are actually buying. The instrument that covers the gap is a bridge letter (also called a gap letter) from the vendor asserting no material change since the period end — it is management’s assertion, not the auditor’s opinion, and should be read that way.
• Which criteria are in scope. Security is common to every report; availability, confidentiality, processing integrity and privacy are each included only if the vendor chose to include them. A report that covers Security alone says nothing about uptime commitments or about how the vendor handles personal data.
• Which system is in scope. The system description names products and environments. A report scoped to a vendor’s platform may or may not include a newer inference endpoint, a batch API or a fine-tuning service, and those are frequently the parts you are migrating to.
• How subservice organisations are treated. Under the carve-out method the vendor’s own hosting providers are excluded from the opinion and you are expected to obtain assurance over them separately; under the inclusive method they are covered. An inference vendor running on someone else’s accelerators is exactly the case this distinction was written for.

The section most readers skip is the one they most need: complementary user entity controls. These are the controls the auditor assumed you operate. If the report assumes customers scope API credentials per environment and revoke on offboarding, and you do not, the vendor’s clean opinion has a hole in it that is yours to fill.

What to request, and in what order

The review is slow because artefacts arrive one at a time, each answering a question raised by the last. Ask for the whole set in the first message. A reasonable opening request is the current Type II report under NDA; a bridge letter covering period end to today; the subprocessor list with regions; the data processing agreement and any zero-retention or no-training-on-customer-data option and how it is enabled; the most recent penetration test summary; and the vendor’s own incident notification commitment.

Then ask three questions that reports rarely answer directly. Does the report cover the specific endpoint and the specific region you will use. Is the retention behaviour you need a default, a contract term, or a per-request flag your code has to set. And what is the notice period and the export path if you leave — the thing that determines whether the next migration is a quarter or a fortnight. What the clause types do and what to look for in your own agreement matters far more than any summary of a given vendor’s standard terms, which are negotiated and revised continuously.

The controls that move on your side

A migration also invalidates evidence you produce. Your access reviews name key holders at the old provider. Your data flow diagram and records of processing name the old subprocessor and the old region. Your logging control asserts that prompts are redacted before they leave, and the redaction library is configured per client. Your business continuity story may have relied on a documented failover to the provider you are now leaving.

Treat those as work items rather than paperwork found late. The one that reliably surprises people is retention: if the outgoing provider held request logs for a period and you cited that in an incident response procedure, the incoming provider’s different window changes what you can reconstruct after an incident, and that is a control change, not a vendor detail. The same applies to a fine-tuned artefact you are moving — see how access to a tuned model is scoped on each side, because the register entry that says “three named engineers can invoke the model” has to still be true afterwards.

Making the review short instead of fast

You cannot make a security team skip a review, and you should not try. You can remove the two things that make reviews take months. The first is serial artefact requests, solved by asking for everything at once. The second is an undefined data flow: reviews expand to fill the ambiguity about what is being sent. Write the flow down before the first meeting — fields, whether they contain personal data, region, retention, whether outputs are stored, whether anything is used for tuning — and the review becomes a comparison against the previous entry rather than a discovery exercise.

One practical sequencing note. If you intend to dual-run both providers during cutover, say so at the start. Dual-running means production data goes to the new vendor before the migration is finished, so the assessment gates the pilot rather than the switch, and teams that discover this late lose the whole overlap window they had planned for comparison.