AI vendor subprocessors aged care providers rely on rarely stay fixed for the life of a contract. A vendor may add a new hosting partner, a new analytics service or a new support desk months after the original due-diligence review, quietly changing who can touch resident data. A policy that only checks subprocessors at onboarding misses this drift. This is a governance and due-diligence guide, not legal advice, and providers should confirm contractual obligations with their own legal counsel.
A subprocessor is any third party a vendor engages to help deliver its service, such as cloud hosting, data storage, translation or customer support tools. When an aged care provider approves an AI vendor, it is also implicitly accepting the vendor's current subprocessor list. The risk is that this list can change after signature, and without a monitoring policy, the provider may not know until an audit, an incident or a vendor notice draws attention to it.
Why Subprocessor Oversight Cannot Stop at Onboarding
Onboarding due diligence answers one question well: was this vendor and its subprocessor chain acceptable at the time of signing. It does not answer whether the arrangement remains acceptable a year later. Vendors change infrastructure providers, expand into new markets, or outsource support functions for cost reasons. None of these changes are necessarily wrong, but each one can shift where resident information is processed and by whom.
A provider that treats subprocessor review as a one-off step effectively stops managing this risk the day the contract is signed. A standing oversight policy keeps the review live for the life of the relationship, matching the ongoing nature of the risk itself.
Build a Subprocessor Register Linked to Each AI Vendor
Start with a simple register: vendor name, service provided, current subprocessor list, data categories involved, country of processing where relevant, contract review date and the internal owner responsible for tracking changes. This does not need to be complex software. A well-maintained spreadsheet or a structured record in a governance platform is enough if it is actually kept current.
Governa's questions to ask before signing with an AI vendor article is a useful reference for the initial due-diligence questions that should feed the register, including questions about subprocessors, data location and security certifications. Answers gathered at onboarding become the baseline the register is checked against later.
Set a Notification and Review Trigger, Not Just a Calendar Date
An annual review date is useful, but it is not enough on its own, because a subprocessor change can happen at any point in the year. Contracts should require the vendor to notify the provider of a material subprocessor change within a defined period, and the provider's policy should name who receives that notice and what happens next.
When a notice arrives, the reviewer should check the new subprocessor against the same criteria used at onboarding: data handling practices, location, security posture and any relevant certifications. Governa's cybersecurity and data governance policy template sets out data classification, third-party vendor assessment and incident reporting expectations that can guide this recurring check.
Assess the Risk of Each Change Proportionately
Not every subprocessor change carries the same weight. A change to a customer support ticketing tool with no resident data access is a lower-risk event than a change to the cloud hosting provider storing care records. Build a simple risk tier into the review process: low, medium and high, based on the data categories the subprocessor can access and the sensitivity of that data.
High-risk changes should trigger a documented review with sign-off from the accountable governance role before continued use. Lower-risk changes can be logged and reviewed at the next scheduled cycle. This proportionate approach keeps the oversight process sustainable rather than turning every notice into a lengthy investigation.
Use Vendor-Neutral Thinking to Reduce Lock-In Risk
Providers who rely heavily on one vendor's proprietary integration can find it harder to respond when a subprocessor concern arises, because switching costs are high. A vendor-neutral integration approach keeps a provider's existing systems, such as care, roster and medication platforms, connected through infrastructure the provider controls rather than a single vendor's closed ecosystem. Governa's article on the vendor-neutral approach to integrating care, roster and medication systems explains this model, and Governa Connect is built on the same vendor-neutral principle, designed to support scalable API integrations rather than locking a provider into one supplier's subprocessor chain.
Record Every Review So It Survives Staff Turnover
Subprocessor oversight fails quietly when the person who understood the vendor relationship leaves and no record exists of what was checked and why. Every review, whether triggered by a notice or a scheduled date, should leave a short record: date, subprocessor changes considered, risk tier applied, decision and next review date. This turns institutional knowledge into an auditable trail rather than something held in one person's inbox.
A structured readiness process can help a provider work out where its subprocessor oversight gaps are before they become a problem. Governa's Aged Care AI Readiness Assessment includes legal and compliance considerations, including vendor risk, as one of its readiness pillars, which can be a useful benchmarking exercise alongside a dedicated subprocessor register.
Connect Subprocessor Incidents to the Provider's Incident Process
If a subprocessor change or failure leads to a data handling concern, it should flow into the provider's existing incident management process rather than being handled as a separate, informal conversation with the vendor. Governa's incident management and reporting policy template sets out reporting responsibilities, investigation steps and record-keeping requirements that apply equally to a vendor-related incident as to an internal one.
Mapping vendor obligations against the Strengthened Aged Care Quality Standards can also help a provider show assessors how third-party oversight fits into its broader governance system. Governa's policy and evidence mapping tool supports this by linking policies and evidence to specific standards and outcomes.
A Practical Oversight Sequence to Put in Place
- Build a subprocessor register for every AI vendor, starting with the current contract and onboarding documentation.
- Confirm each contract requires notice of material subprocessor changes within a defined period.
- Apply a simple risk tier to every change and set proportionate review requirements for each tier.
- Route any subprocessor-related concern into the provider's standard incident management process.
- Review the full register at least annually, in addition to responding to individual vendor notices as they arrive.
Keeping Oversight Sustainable Over Time
The goal of ongoing subprocessor oversight is not to create a permanent, heavy compliance burden. It is to make sure a provider notices a material change before it becomes a problem, and can show a reviewer or auditor exactly when a change was assessed and by whom. A short, consistently applied register and review cycle achieves this more reliably than a single detailed onboarding review that is never revisited. For further reading on the privacy considerations that intersect with vendor oversight, see the OAIC guidance on commercially available AI products, which discusses due diligence and ongoing oversight expectations for organisations using AI products that involve personal information.
Related Resources
- subcontractor management policy template
- cybersecurity and data governance policy
- Governa security
- AI and automated decision-making policy template
- policy and evidence mapping
- OAIC guidance on commercially available AI products
Common Questions About Managing AI Vendor Subprocessors
1. How does an ongoing subprocessor register benefit a provider compared to a one-off check?
It catches changes as they happen instead of relying on memory or a single point-in-time review, giving the provider a current, defensible picture of who can access resident data through each AI vendor.
2. What should trigger an immediate subprocessor review outside the annual cycle?
A vendor notice of a material subprocessor change, particularly one involving a new location or a higher data-sensitivity category, should trigger an immediate proportionate review rather than waiting for the scheduled date.
3. Who should own the subprocessor register day to day?
A named governance, procurement or IT role should hold ownership, with a documented backup contact so oversight continues if that person is unavailable or leaves the organisation.
4. Does a vendor-neutral integration approach remove the need for subprocessor oversight?
No. It can reduce lock-in and make switching easier if a concern arises, but the provider still needs an active register and review process for every vendor and subprocessor it uses.
5. How does subprocessor oversight connect to incident management?
Any concern arising from a subprocessor change should be logged and assessed through the provider's existing incident management and reporting policy, keeping vendor-related issues inside the same accountable process as internal incidents.
