Third-party risk management was built around procurement events. A vendor is onboarded. The security team reviews their SOC 2 report, assesses data handling, confirms sub-processors, and signs the data processing agreement. A calendar entry is set for the annual renewal review. The assessment is filed. The vendor is approved. This process made sense when the product you approved in January was still the product you were running in December.
That assumption does not hold anymore. Your vendors ship continuously. AI features are rolling out inside tools that your procurement process assessed for different capabilities. The Salesforce your security team reviewed in January now has Agentforce capabilities active in June. The Microsoft 365 tenant that passed your vendor assessment when Copilot was a separate purchase now has it included in your existing licence tier. The productivity tool approved by your IT team twelve months ago has a document-summarisation model that was not in the product when the assessment was done. Each of these is a new capability, a new data-processing behaviour, and a new risk — and none of them triggered a procurement event that would have surfaced them for review.
The quiet rollout is not an accident. It is a go-to-market pattern. Vendors enable AI features by default, or make them opt-out rather than opt-in, or bundle them into existing tier upgrades. The changes land in your environment without a contract amendment, without a new DPA, and without the notification that would prompt your security team to re-assess. Your risk posture changes. Your vendor register does not.
01 / Why onboarding-only diligence is structurally behind
Onboarding reviews assess the product as it exists at a point in time. They cannot assess what the vendor will ship next quarter. For most of the history of enterprise software, that limitation was acceptable — core platforms changed slowly, and significant capability changes came through major releases that were visible enough to prompt re-assessment. The release cadence of SaaS platforms with embedded AI has broken that assumption.
A SOC 2 report reviewed at onboarding tells you about the controls the vendor had audited at the time of the report. It does not tell you what the product does with your data today. Vendors issue updated SOC 2 reports on their own cycles — typically annually — and the gap between the report and the current product can span multiple significant AI feature launches. A company that relies on annual SOC 2 reviews to track its third-party risk is reviewing evidence of what vendors were doing up to a year ago, while the current product may be doing something materially different with covered data.
The mismatch compounds as vendor relationships age. A vendor relationship in its third or fourth year may have been rigorously assessed at onboarding, adequately reviewed at annual renewal, and quietly transformed by AI features added in the intervening months. The security team's picture of that vendor relationship reflects the version of the product they reviewed, not the version that is currently processing company data. The gap is not a failure of the security team. It is a failure of the review cadence to keep pace with the product development cadence.
02 / What continuous vendor oversight looks like
Continuous vendor oversight does not mean re-running the full onboarding assessment every quarter. It means building a programme that runs between procurement events and catches what changes in between.
The foundation is a vendor inventory that is tied to data classifications. Every vendor relationship should have a record of what data categories that vendor can access — customer records, employee data, financial information, health data, intellectual property. That classification is not static. As vendors add capabilities, the scope of what they can access, process, or generate outputs from may change. The inventory needs to reflect not just who has access to what, but what they are currently doing with it — and that requires monitoring what the vendor's product actually does, not just what it did at onboarding.
Review schedules need to run on their own trigger conditions, not only on calendar cycles. An annual review is appropriate for low-risk vendors processing non-sensitive data. Vendors with access to regulated data categories — personal data under GDPR, protected health information under HIPAA, financial records under relevant frameworks — warrant more frequent review. Vendors in active AI development warrant a watch process that operates between formal reviews, specifically looking for new feature announcements, AI capability updates, and changes to data processing terms.
The tool approved in January is a different tool by June. Vendor risk management that runs only at onboarding and annual renewal is reviewing a product that no longer exists.
AI-feature watch is a new discipline within vendor oversight. It requires tracking vendor product announcements, release notes, and terms-of-service updates with the same attention that was historically given to security bulletins. A vendor that adds a large language model to its document storage product has changed the risk profile of that relationship, even if the change is framed as a feature rather than a security event. The watch process catches those changes and routes them to the appropriate review queue before they become unmanaged risk.
03 / Contractual posture in the AI era
Many vendor contracts signed before 2022 contain no specific terms about AI. The data processing agreements address sub-processors, data retention, and breach notification. They do not address whether the vendor may train models on your data, whether AI-generated outputs are covered by confidentiality obligations, or how the vendor notifies you when AI features are added that change the scope of data processing.
Updating contractual posture is a matter for legal counsel with expertise in data agreements. What can be said generally is that the standard vendor agreement renewal cycle provides a natural moment to introduce terms that address AI feature changes. AI addenda — specific schedule attachments addressing AI data use, model training restrictions, and AI feature notification obligations — are increasingly common in enterprise agreements. Notification clauses that require vendors to disclose AI capability additions before they are enabled in customer environments are a reasonable ask and one that the more security-conscious enterprise vendors will accept.
The negotiation posture depends on leverage, sector, and regulatory context. A company operating under HIPAA has a specific need to understand how covered data flows through any AI features a business associate may introduce. A company operating under GDPR must understand whether new AI processing constitutes a new purpose that requires updated lawful basis documentation. These are obligations the company carries regardless of whether the vendor flagged the change. Contractual terms that shift the notification burden to the vendor support the company's ability to meet its own obligations.
This is general description, not legal advice. The specific terms appropriate for a given vendor relationship depend on facts that only counsel familiar with the relationship and the applicable law can assess. The operational point is that the renewal cycle is the moment to address what the original agreement did not contemplate — and AI processing is, for most agreements signed before 2023, something the original agreement did not contemplate.
04 / Your vendor oversight is also your sales asset
Enterprise customers are asking the same questions about your third-party risk programme that you should be asking about your vendors. Security questionnaires from prospective customers routinely ask how you assess the security posture of your own vendors, how frequently you review third-party relationships, and how you manage the risk of AI features in tools that process their data. The company that cannot answer those questions clearly is not just exposed to risk — it is exposed to deal risk.
A structured, evidenced vendor oversight programme produces answers that hold up in a customer security review. The vendor inventory, with data classifications attached, shows the prospective customer that you know what third parties have access to. Review schedules that actually run — with completion records that can be shown — demonstrate that the oversight is operational rather than aspirational. AI-feature watch records demonstrate awareness of the specific risk that AI-era vendor relationships introduce.
The dynamic is self-reinforcing. Your customers are asking you these questions, which means your customers' customers are asking them these questions. The mid-market company that operates a credible third-party risk programme is not just managing its own exposure. It is demonstrating to the enterprise customers whose business it wants that it can be trusted to handle their data responsibly — and that it has thought through what happens when the tools it uses are updated in ways that change that responsibility.
05 / Making the programme operational
A vendor oversight programme that exists as a policy document and a spreadsheet is not a programme. It is an intention. Making it operational requires connecting the inventory, the review schedule, and the evidence to a process that actually runs — and produces a record that can be shown to auditors, customers, and boards.
The inventory needs to be maintained, not built once. Vendors are added and removed. Data classifications change when vendor capabilities or data-sharing arrangements change. The inventory is only useful as a governance tool if it reflects the current state of the vendor relationships, not the state they were in when someone last updated the spreadsheet.
Review schedules need to produce evidence that the reviews happened. A schedule that says reviews happen annually is not evidence that any review occurred. The record of each review — who conducted it, what was assessed, what the finding was, whether any issues were escalated — is what makes the schedule real. That record is also what the auditor examines and what the enterprise customer's security team asks to see. The difference between having a vendor oversight programme and being able to prove you have one is the difference between a policy and a record.
Governing systems you already run means the vendor relationships those systems represent are already part of the risk picture. Okta, Salesforce, Microsoft 365, Google Workspace, AWS — each of these is both a system you operate for business purposes and a vendor relationship you are responsible for overseeing. When the oversight programme is connected to continuous evidence from those systems, it reflects the current state of those relationships in real time. The AI features active in Salesforce today are visible in the oversight record today. The gap between what your vendors are doing and what your programme knows they are doing closes. That is the programme that is worth building.
See it on your company.
This is the desk work of the office we embed. A structured governance review shows you, on your own documents and systems, exactly where your proof is strong, fragile, and missing — in plain language, no data required.