When an SDK vendor changes owner, licence or terms, run an off cycle review. Check data flows and destinations, the vendor's privacy statements, your store declarations, the support and security contact, and your exit options. Treat it like a new vendor request until those answers are in hand.
Why this trigger matters
An approval rests on who the vendor is and what they do with data. A new owner may change hosting, sub processors, defaults or roadmap. None of that has to appear in a version number. Apple's guidance says developers are responsible for the practices of third-party partners whose code is in their app and must keep their privacy answers accurate if practices change. A vendor change is one way practices change without you touching code.
How you find out
You often will not be told. Sources worth watching:
- The vendor's changelog, blog and status page.
- Release notes and licence files in new versions. Diff the licence file on each upgrade.
- Updated privacy policies or terms notices sent to account contacts.
- Package registry ownership and maintainer changes.
- News about the vendor, read with care and confirmed with the vendor.
Make the account contact a shared mailbox, not one person, so notices are not lost when staff leave.
The review list
| Area | Question |
|---|---|
| Data flows | Do hosts, regions or sub processors differ from last review? Run a traffic test |
| Privacy | Did the data description or privacy manifest change? Do our declarations still match? |
| Terms | What changed? Hand contract questions to your legal advisers |
| Security | Is the disclosure contact still valid and is there a published policy? |
| Support | Who answers now, and is the release cadence the same? |
| Exit | Could we leave in a reasonable time, using the removal playbook? |
This post is an engineering and governance view. It is not legal advice about contract terms or notice obligations.
Decide and record
Outcomes are the usual four: continue, continue with conditions, replace, or remove. Conditions might include pinning the current version while questions are answered, turning off optional collection, or moving to a wrapper so replacement is cheaper.
Do not upgrade to the first version released under the new owner until the review is done. Staying on the approved pinned version for a short time costs little and buys time. Pinning guidance for iOS and Android is in earlier posts.
Keep the paper trail
Add the date, the trigger, the findings and the decision to the register. Next time a similar change occurs you will have a template, and an auditor or customer asking how you manage vendors gets a real answer.
Safeguard's compliance and evidence automation can help keep such records organised, and dependency scanning shows what changed in a build.
Quick check
Should we upgrade immediately to the new owner's release?
No. Stay on the approved pinned version until the review is done.
How do we learn about a vendor sale?
Watch changelogs, licence diffs, registry maintainer changes and account notices, and use a shared contact mailbox.
Sources
Last reviewed: 19 October 2026.
