Does the assessment still reflect the service?

A vendor assessment reflects conditions at a particular time. This article looks at the changes that should trigger a reassessment, whether assurance reports cover the service in use, and the control responsibilities an organization keeps when it relies on an external provider.

A snapshot, not a guarantee

Every third-party risk program produces assessments: questionnaires, due diligence files, assurance reports, risk ratings. Each one answers a question about a specific service, delivered in a specific way, at a specific time. The trouble starts when that answer is treated as permanent.

Services change. A vendor adds a new data center, moves support offshore, acquires a competitor, or enables an AI feature by default. Your own use changes too: a pilot becomes a core process, a single team becomes the whole enterprise, or the vendor starts receiving data it was never assessed for. The assessment on file still says “low risk.” The service in use may no longer match it.

So the question I ask when I review a third-party program is not “Was this vendor assessed?” It is: “Does the assessment still reflect the service?”

Figure 1. The assessment describes one moment. Each trigger widens the gap between what was assessed and what is in use.

Triggers that should reopen the file

Periodic reassessment, such as an annual review for critical vendors, is necessary but not enough. Some changes are significant enough that waiting for the next cycle leaves the organization relying on an outdated conclusion. Strong programs define these triggers in policy and assign someone to watch for them.

Trigger	Why it matters	Reasonable response
New service, product, or module	The original assessment covered a different scope	Assess the new scope before go-live
Expanded use or more sensitive data	The inherent risk rating may no longer be accurate	Re-rate the relationship; confirm controls fit the new data
Change in ownership, merger, or acquisition	Control environment, staff, and priorities can change quickly	Request updated assurance; review contract assignment terms
Security incident or data breach	Direct evidence that controls may have failed	Obtain the root-cause analysis; reassess affected controls
New subcontractor or fourth party	Your data may now sit with a party you never assessed	Confirm notification rights; review the new party’s assurance
Exceptions in the latest assurance report	Controls the assessment relied on may not be operating	Evaluate impact; agree remediation with the vendor
New AI capability enabled	New data uses, new model risk, possibly new terms of service	Treat as a scope change; involve AI governance
Financial distress or service failures	Resilience and continuity risk rises	Review exit plan and contingency arrangements

The U.S. banking agencies’ Interagency Guidance on Third-Party Relationships: Risk Management (2023) frames this as a lifecycle: planning, due diligence and selection, contract negotiation, ongoing monitoring, and termination. Triggers are what connect ongoing monitoring back to due diligence when something material changes.

Does the assurance report cover the service you use?

Many organizations lean heavily on SOC reports, and they should; independent assurance is valuable. But a SOC report is only useful evidence if it covers the service, the period, and the controls you are relying on. When I review how a team used a SOC report, these are the questions I expect them to have answered.

Question	Where to look	Red flag
Is this the right type of report?	Report title and opinion	A SOC 1 used for security assurance, or a Type I (design only) used as evidence that controls operated over time
Does the system description match the service you use?	Section 3, system description	The product, module, or region you use is not in scope
Does the period cover your reliance?	Opinion and period dates	Report period ended many months ago, with no bridge letter
Which subservice organizations are carved out?	System description and opinion	Critical hosting or processing is carved out and not separately assessed
What are the complementary user entity controls (CUECs)?	Usually near the end of the system description	No one in your organization has mapped or owns them
Were there exceptions, and do they matter to you?	Section 4, tests and results	Exceptions in access or change controls with no follow-up
Is the opinion qualified?	Auditor’s opinion	A qualified opinion accepted without analysis

A bridge letter (sometimes called a gap letter) from the vendor can cover the months between the report period and today, but it is a management statement, not independent assurance. Treat it as such.

The responsibilities you keep

Outsourcing a service does not outsource accountability for it. Regulators have been clear on this point, and it holds true in practice: when something goes wrong, customers and examiners look to the organization, not its vendor.

Even with a well-controlled vendor, your organization keeps important controls. The SOC report usually lists many of them as CUECs. In cloud services, they appear in the provider’s shared responsibility model.

Responsibility	Typically the vendor’s	Typically yours
Physical security and infrastructure	Data centers, hardware, hosting	Choosing a provider and region that meet your requirements
Application changes	Releasing tested changes to the platform	Testing how changes affect your configuration and processes
User access	Securing the platform’s own administrative access	Approving, reviewing, and removing your users’ access
Configuration	Providing secure options	Choosing and maintaining the settings you use
Data	Protecting data within the platform	Deciding what data you send, classifying it, and keeping it accurate
Monitoring	Monitoring the platform for threats	Monitoring your own use, alerts, and the vendor’s performance
Incidents	Detecting and notifying you of incidents	Responding, notifying customers or regulators as required
Exit	Returning or deleting data at termination	Maintaining an exit plan and a way to continue the service

The pattern is consistent. Access, configuration, data, and response stay with you. If the CUECs in a vendor’s report are not mapped to named control owners in your organization, the assurance has a gap, no matter how clean the vendor’s opinion is.

AI-enabled vendors deserve particular attention

AI features are now arriving inside software organizations already use, often switched on by default. That makes them one of the most common reassessment triggers. When a vendor adds AI, I ask:

• Is our data used to train or improve the vendor’s models, and can we opt out?
• Which model or provider sits behind the feature, and is that a new fourth party?
• Have the terms of service or data processing terms changed?
• Does the feature make or influence decisions about customers or employees?
• Is there an accountable owner in our organization for the AI use, not just the contract?

These questions belong in the vendor review, and the answers belong in the AI use-case inventory as well.

A reassessment checklist

Use this list for any critical or high-risk relationship, at the scheduled review and whenever a trigger occurs.

1. Scope: Do we still use the service the way it was assessed? Has the data we share changed?
2. Rating: Is the inherent risk rating still accurate?
3. Assurance: Is the latest SOC or other assurance report current, of the right type, and in scope for our service?
4. Exceptions: Have we evaluated every exception and agreed follow-up where it matters?
5. Fourth parties: Do we know the critical subcontractors and how they are assured?
6. CUECs: Is every complementary user entity control mapped to an owner and evidenced?
7. Incidents and performance: Have there been incidents, outages, or service-level failures since the last review?
8. AI: Has the vendor introduced AI capabilities that change how our data is used?
9. Contract: Do the contract terms still support our audit, notification, and exit needs?
10. Exit: Is the exit plan realistic and current?

The conclusion has to stay true

A vendor assessment is a conclusion: this relationship is acceptable, at this level of risk, with these controls. The work of third-party risk management is keeping that conclusion true, or changing it when it no longer is. When the service changes, the assessment should change with it.

---

This article reflects my professional perspective and is general information, not legal or regulatory advice. Apply it in light of your organization’s obligations and risk appetite.