The Vendor That Changed Its Subcontractor
Your company uses a cloud analytics vendor to process customer behavioral data for a personalization feature. The contract includes a standard data processing addendum requiring notice before engaging a subprocessor and giving you a right to object. In March, the vendor's status page announces a 'platform migration' to a new hosting provider in a different country. You learn of it from a colleague who saw the status page, not from the vendor. The migration moves data from a region your transfer assessment covered to one it did not. The vendor's security team sends a SOC 2 report showing a clean audit period that ended three months before the migration. Your personalization feature drives roughly 8% of conversion revenue. The vendor's account manager says the migration was 'infrastructure only, no data movement' - but your own logs show API calls now resolving to the new region.
1. Is this a breach notification event, a vendor-management failure, or both? Walk through the analysis.
Read the worked answer
It is both, but they require different responses and should not be conflated.
Vendor-management failure - clearly yes:
- The DPA required notice before engaging a subprocessor. You received none; you learned via a status page.
- Your right to object was functionally nullified because the change was already live.
- The SOC 2 report covers a period ending before the migration, so it provides no assurance about the new environment. Accepting it as current would be a control failure on your side.
Breach notification - depends on jurisdiction and data type:
- The trigger is typically unauthorized access/disclosure or a change in the risk to the data, not the migration itself. A region change can constitute a transfer without a valid transfer mechanism, which is a compliance event distinct from a security incident.
- Your logs contradicting the vendor's 'no data movement' claim is the material fact: either the vendor is misinformed about its own architecture or it misrepresented. That elevates the issue from paperwork to trust.
Do not notify regulators or customers yet on the theory that 'a migration happened.' Establish first whether data actually left the covered region and whether the new location has an adequate transfer basis. Then decide notification on facts, not on the vendor's characterization.
2. The account manager is your main relationship and is pressing you not to escalate. What do you do, and how do you handle the revenue exposure?
Read the worked answer
Escalate - but escalate on facts and through the contract, not emotionally.
Immediate actions:
- Send a written notice of DPA breach to the vendor's privacy/legal contact (not the account manager), requesting: confirmation of data location, the subprocessor list, the transfer mechanism relied on, and a remediation plan with dates.
- Preserve your own logs as evidence; do not rely on vendor-provided records.
- Suspend or restrict the personalization data flow if you cannot confirm the transfer basis - a feature can be degraded while facts are established.
Handling the revenue exposure honestly:
- 8% of conversion revenue is a real cost, but it is not a reason to accept an unassessed cross-border transfer. Frame the trade-off to business leadership in risk terms: the exposure from an unlawful transfer typically exceeds the revenue at stake, and the decision belongs to leadership with the risk stated plainly.
- Offer a middle path: restrict the data flow to the minimum needed to keep the feature partially live while the vendor remediates. This preserves some revenue without continuing the unassessed transfer.
Do not let the account manager's reassurance substitute for vendor legal confirmation. Relationship pressure is a known failure mode in vendor risk; the contract exists precisely for the moment the relationship is uncomfortable.
3. What changes to your vendor risk process would prevent this from recurring?
Read the worked answer
The failure was not that the vendor migrated; it was that your monitoring depended on the vendor's goodwill.
Process changes:
- Independent change detection: monitor vendor status pages, subprocessor lists, and certificate/region changes automatically rather than waiting for notice. Add a contractual obligation to notify within a defined window (e.g., 10 business days) with a remedy for failure.
- Objection rights with teeth: require notice before the change takes effect and specify what happens if notice is missed - suspension right, termination for cause, or service credits.
- Audit freshness rule: define an acceptable recency window for SOC 2 or equivalent reports relative to material changes. A report that predates a migration does not cover it; require a bridge letter or updated report.
- Subprocessor register: maintain your own list, reconciled quarterly against the vendor's published list.
- Transfer-basis check as a gate: any region change triggers a transfer assessment before data flows, not after.
Ownership: assign each vendor a named internal owner accountable for these checks, and report vendor compliance status to the same audit committee cadence as the rest of the program. Otherwise this becomes one more unowned control.