Change of sub-contractor to process PII

“Change of sub-contractor to process PII” is an operational requirement hiding inside what many teams treat as a contract clause. ISO/IEC 27701:2019 Clause 8.5.8 makes it explicit: if you are processing personal data on behalf of a customer, you cannot quietly swap in a new sub-processor. You must notify the customer of intended additions or replacements and give them an opportunity to object. ¹

For a CCO, Compliance Officer, or GRC lead, the hard part is not understanding the words. The hard part is making sure procurement, product, engineering, and legal can’t accidentally bypass the notice-and-objection step during a fast-moving vendor change, cloud migration, or incident-driven substitution. This page translates the requirement into a repeatable workflow, identifies the evidence you will need during audits, and highlights common failure modes (for example: “we updated our website sub-processor list” without proving customer-specific notice and objection handling).

If you use a third-party risk platform like Daydream, this is a strong candidate for automation because the same artifacts repeat: sub-processor inventory, change tickets, templated notices, response tracking, and contract addenda.

Regulatory text

Requirement (quoted): “The organization shall inform the customer of any intended changes concerning the addition or replacement of sub-contractors to process PII, giving the customer the opportunity to object to such changes.” ¹

Operator interpretation (plain English)

If you are a PII processor, you must:

1. Notify customers in advance when you plan to add a new sub-processor or replace an existing one that will process customer PII; and
2. Provide a workable objection mechanism so the customer can say “no” (or “not for my data”) and you have a defined way to respond.

This is not satisfied by having a general procurement process, or by burying an update in a generic privacy policy. The requirement is customer-facing and change-specific: “intended changes,” “inform the customer,” and “opportunity to object.” ¹

Who it applies to

In-scope entities

• PII processors providing services to customers where the processor engages sub-contractors (sub-processors) to process PII on the customer’s behalf. ¹

In-scope operational contexts (common triggers)

• Adding a new cloud service provider, analytics provider, support tooling, communications platform, payment processor, background screening provider, or outsourced operations team that touches customer PII.
• Replacing one sub-processor with another, including “temporary” substitutions during incidents, capacity constraints, M&A, or pricing changes.
• Expanding an existing sub-processor’s role so it now processes PII it did not previously process (treat this as an “addition” for this control).

Out of scope (typically)

• Changes to sub-contractors that do not process PII (for example, office supplies). Still document your rationale so the scope decision is defensible.

What you actually need to do (step-by-step)

Step 1: Define what counts as a “sub-contractor to process PII”

Write a short, enforceable definition used by Legal, Procurement, Engineering, and Security:

• “Any third party engaged by us that will access, store, transmit, or otherwise process customer PII as part of delivering the service.”

Add decision rules:

• “If the third party can access production data, logs containing identifiers, support tickets with PII, or backups, treat as processing PII.”
• “If the third party only receives irreversibly anonymized data, document the basis and exclude.”

Step 2: Maintain a sub-processor register that is customer-impact aware

Minimum fields auditors expect to see tied to this requirement:

• Sub-processor legal name and service description
• Processing purpose
• PII categories involved (high level)
• Data locations/regions (high level, if known)
• Access method (API, direct console access, managed service)
• Whether it is new or replacement for an existing sub-processor
• Customer scope affected (all customers, specific products, specific tenants)

This register becomes your control plane. If it is stale, the rest fails.

Step 3: Implement a gated “sub-processor change” workflow

Create a workflow that cannot be bypassed:

1. Change intake: requester submits a sub-processor change request (new or replacement) with business justification.
2. Privacy/security review: confirm PII involved, map to customer services, and confirm the change is “intended” (planned) rather than speculative.
3. Customer notification package: generate the notice content (see Step 4).
4. Send notice + start objection window: log the send date/time and recipients.
5. Objection handling: track objections, route to Legal/Privacy/Security, and decide on mitigation or alternatives.
6. Decision + implementation: approve go-live only after objection handling criteria are met.
7. Post-change record update: update register, contracts, and customer-facing sub-processor listings (if you maintain them).

Practical gate: if Engineering can switch vendors with only a purchase order and a DNS change, you have a control gap. Connect the workflow to procurement and release management so “go-live” requires a compliance checkpoint.

Step 4: Standardize the customer notice (what “inform” means in practice)

Your notice should be specific enough for a customer to evaluate risk and make an objection meaningful. Include:

• Identity of the new or replacement sub-processor
• What service they provide and why you’re adding/replacing
• What PII types are implicated at a high level
• Expected change date
• How the customer can object (channel and required info)
• What happens if they object (your process and response expectations)

Keep it consistent. Customers distrust notices that omit the “why” or the scope.

Step 5: Make the objection mechanism real (and document your playbook)

Define what an objection can lead to. Common outcomes:

• Offer a reasonable alternative (different sub-processor, feature disablement, data routing change).
• Offer a configuration option (opt out of a feature that requires the sub-processor).
• Offer a contractual path (termination rights or amendment) if you cannot support the objection.

The ISO text does not tell you which remedies to offer, but it does require an opportunity to object. If your process accepts objections and then ignores them, an auditor will treat the control as non-operational. ¹

Step 6: Align contracts to the operational process

Check that your customer agreements and DPAs:

• Permit you to appoint sub-processors, but condition it on notice and objection rights consistent with your workflow.
• Describe the notice method (email, portal, ticketing system) and the objection route.

Do the same downstream:

• Sub-processor agreements must allow you to meet customer commitments, including flow-down privacy/security requirements and timely cooperation.

Step 7: Operationalize with tooling (where Daydream fits naturally)

If you run this in email threads, you will lose evidence. A third-party risk system like Daydream can centralize:

• The sub-processor register (system of record)
• Change requests and approvals
• Notification templates and send logs
• Objection intake, assignments, and resolution notes
• Audit-ready exports per customer or per change event

The goal is not “more process.” The goal is a short path from “we plan to add a sub-processor” to “customers were informed, objections were handled, and we can prove it.”

Required evidence and artifacts to retain

Keep artifacts per change event and as standing records.

Standing records (always current)

• Sub-processor register (with last reviewed date/version history)
• Policy/procedure for sub-processor onboarding and change management
• Customer notification and objection SOP (roles, escalation, decision authority)
• Templates: notice email/portal message, objection intake form, response letters

Per change event

• Change request ticket with classification (addition vs replacement) and PII scope
• Risk/security/privacy review notes and approvals
• Copy of customer notice content
• Proof of delivery (email logs, portal notification logs, customer distribution list)
• Objections received (if any) and case notes
• Final disposition and rationale (approved, delayed, alternative offered)
• Contract/DPA updates if required

Common exam/audit questions and hangups

Auditors and customer assessors tend to probe:

• “Show me the last sub-processor change and prove customers were informed before the change.”
• “How do you define ‘sub-contractor to process PII’ and who decides?”
• “How do customers object, and what happens operationally after an objection?”
• “Do you notify all customers or only those impacted? How do you determine scope?”
• “How do you prevent teams from adding a tool that processes PII without triggering notice?”

Hangup to anticipate: teams often have a public “sub-processor list” page but cannot show customer-specific notice and objection workflow evidence for a specific change.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: treating a website update as “notice.”
   Fix: log direct customer notifications (email/portal) per change event with send evidence.

2. Mistake: no defined objection outcomes.
   Fix: document a decision tree (alternative, opt-out, contractual path) and assign decision authority.

3. Mistake: register exists but is not connected to procurement/release.
   Fix: require a sub-processor register entry ID in purchase approvals and change tickets.

4. Mistake: “replacement” is treated as lower risk and bypasses notice.
   Fix: replacements are explicitly in scope. Handle both the same way. ¹

5. Mistake: support vendors or contractors are missed.
   Fix: include support tooling, outsourced support, and consultants with production access in the definition and intake triggers.

Enforcement context and risk implications

No public enforcement cases were provided for this ISO clause, but the risk is still concrete:

• Contractual breach risk: many customer DPAs mirror this requirement. Failure can trigger audit findings, termination rights, or blocked deals.
• Operational privacy risk: sub-processor swaps often change access paths, data regions, or security controls. Without review and notice, you increase the chance of unauthorized processing and customer disputes.
• Assurance risk: ISO/IEC 27701 audits focus on demonstrable operation. A “policy-only” control frequently fails because the evidence trail is thin.

Practical execution plan (30/60/90-day)

First 30 days (stabilize and stop surprises)

• Assign control ownership (Privacy/GRC) and define the in-scope definition of “sub-contractor to process PII.”
• Build or clean up the sub-processor register with service owner input.
• Add a mandatory intake question in procurement: “Will this third party process customer PII?” Route “yes” to the change workflow.
• Draft the notice template and objection intake form; get Legal sign-off.

By 60 days (make it operational across teams)

• Implement the gated workflow in your ticketing system or Daydream: intake → review → notify → objection handling → approve.
• Train procurement, engineering, and product on triggers (new tool, new integration, support outsourcing, data pipeline changes).
• Run a tabletop: simulate adding a new sub-processor and walk through notice, an objection, and an alternative.

By 90 days (prove it works and make audits easy)

• Perform an internal audit on the last change event: verify evidence completeness from intake through decision.
• Add monitoring: quarterly reconciliation between accounts payable/procurement records and the sub-processor register to catch shadow additions.
• Publish a customer-facing process description (short) that matches what you actually do, and ensure customer success knows how to route objections.

Frequently Asked Questions

Do we need to notify customers for every new third party we onboard?

Notify customers only for additions or replacements of sub-contractors that will process customer PII. Define “process PII” clearly and document why a third party is out of scope if you do not notify.

What counts as an “opportunity to object”?

Customers need a clear channel to object and a real chance for you to respond before the change takes effect. Your procedure should define who reviews objections and what remedies you can offer. ¹

Can we send notice through a portal instead of email?

Yes, if your contracts allow it and you can prove delivery and timing (for example, portal notification logs tied to the customer account). Auditors will ask for evidence that the customer was informed, not just that you posted an update.

What if the change is urgent, like replacing a provider during an outage?

The requirement speaks to “intended changes,” so urgent substitutions still need governance. If you must act fast, document the emergency decision, notify customers as soon as practicable, and capture how you handled objections once service stabilized. ¹

Do customers get to veto the change completely?

ISO/IEC 27701 requires an opportunity to object, but it does not prescribe the remedy. Your DPA and commercial commitments usually determine whether you must offer alternatives, opt-outs, or termination options.

How do we show an auditor that this control is working?

Provide a recent change event packet: the register entry, change request, approval trail, customer notice, proof of send, objection records, and final decision. The strongest evidence ties timestamps to the sequence: review → notify → objection handling → implement.

Footnotes

1. ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management