An AI vendor can send you a recent SOC 2 Type 2 report while running a model that changed after the examination period. The report still matters. The buying decision now depends on two questions: what did the examination cover, and what evidence explains the changes since then?
Read the period and scope together
A SOC 2 report describes a system and the controls examined against applicable Trust Services Criteria. It provides reasonable assurance within that scope. It is not a certification that every feature is secure or a guarantee about future performance. AICPA’s SOC reporting overview.
The period end date tells you where the Type 2 examination stops. The issue date tells you when the report was delivered. Neither creates a universal twelve-month expiration rule. A buyer should define how recent the evidence must be for the service and the decision, then examine relevant changes after the period.
For an AI service, those changes may include a new model provider, a different retention setting or broader tool access. A model update does not automatically invalidate the report. What matters is whether the assessed change-management process covered it and whether the change affects the use you are approving.
What Type 1 and Type 2 can tell you
Both report types require careful reading of the system description and the auditor’s opinion. The difference concerns the period and the work performed.
A Type 1 report addresses the system description and suitability of control design as of a specified date. It does not provide an opinion on operating effectiveness over a later period.
A Type 2 report also addresses operating effectiveness over a specified period and includes the auditor’s tests and results. Read exceptions and qualifications rather than treating the report’s existence as a clean result. Testing may use samples; a report does not prove that every control worked in every instance. Schellman’s explanation of SOC examinations.
Suppose the examination period ended in March and the vendor added a model provider in June. Ask how it assessed that provider, approved the data flow and tested the release. Existing controls may cover the change, but the March report cannot supply June’s execution evidence. That distinction makes the follow-up request more precise.
A bridge letter is a management statement
Between reports, a bridge letter can help explain whether management knows of material changes. Its value depends on what it says and how it relates to the service you use.
A bridge letter is issued by the service organization’s management. It does not extend the auditor’s opinion into a period the auditor did not examine. If the letter reports no material changes while a release note describes a new model integration, ask how management evaluated that change and request supporting evidence. Acceptance periods are a buyer-policy question; there is no universal three-month rule for every buyer. Linford’s guidance on bridge letters.
Ask for evidence about the change
Start with the assessed system boundary, relevant criteria and subservice organizations. Check the complementary user-entity controls: some protections depend on settings or processes your own organization must maintain. A favorable report cannot compensate for an obligation the customer has not implemented.
Then connect the report to the current service. Useful evidence might include the approval for a model-provider change, a retention configuration, a current subprocessor list or a permission test. Ask for the evidence that addresses your specific uncertainty, rather than requesting a large collection of unrelated screenshots.
A feature that can take actions deserves particular attention to tool permissions and approval enforcement. Test whether an unapproved action is refused and whether the event can be traced. These are also useful questions when reviewing an AI vendor’s questionnaire.
Agree on what requires another review
Not every release needs a full reassessment. Define the changes that could alter your exposure and the evidence needed to evaluate them. Give each unresolved issue an owner and a date.
Read the examination
Check the dates. Record the period start, period end and report issue date separately. Assess freshness against the importance of the service and your own policy.
Check the system boundary. Relate the described services, data flows and controls to the AI feature you use. Absence of a model name alone does not prove AI was excluded.
Read the opinion and test results. Examine qualifications, exceptions and management responses. Decide whether they affect the controls your use depends on.
Trace shared responsibilities. Identify carved-out subservice organizations and complementary user-entity controls. Verify the settings and processes your organization must supply.
Review subsequent changes
Review material changes. Ask about new model providers, data uses, retention terms and permissions since the report period. Request the approval and test evidence for relevant changes.
Evaluate the bridge letter. Treat it as management’s representation. Resolve apparent conflicts with release notes or other evidence before relying on it.
Agree on notifications. Put relevant change and incident-notice requirements in the contract, with scope and timing the parties can actually meet.
Set review triggers. A new data destination, expanded action authority or failed control test may warrant a targeted review. Record when evidence must be refreshed and who decides whether the remaining uncertainty is acceptable.
Keep the report connected to the service you use
A SOC 2 Type 2 report is evidence about a defined system over a defined period. Use it to understand the controls and their tested operation, then investigate changes that matter to your use. The follow-up should explain whether those controls continue to address the exposure you are accepting.
Explore Zania’s third-party risk management →
Sources:
Share
