Disclosure of sub-contractors used to process PII

ISO/IEC 27701 Clause 8.5.5 requires you, as a PII processor, to tell your customer which sub-contractors (sub-processors) will process their PII before you engage them, and to obtain the customer’s approval. Operationalize this by maintaining an accurate sub-processor inventory, embedding approval gates into procurement, and flowing equivalent privacy obligations into every sub-processor contract. ¹

Key takeaways:

• You need a pre-engagement disclosure plus a documented customer approval step for any sub-processor that will touch customer PII.
• Contract language must require sub-processors to meet equivalent PII protection obligations.
• Auditors will test your inventory accuracy and whether approvals actually happened before access was granted.

“Disclosure of sub-contractors used to process PII” is a control that fails in boring, operational ways: a team onboards a cloud tool, a support outsourcer, or an analytics provider, and PII starts flowing before Legal, Procurement, and the customer ever see the name of the sub-processor. ISO/IEC 27701 Clause 8.5.5 closes that gap by forcing two outcomes: (1) customers are informed about the sub-processors you intend to use for their PII, and (2) customers approve that use before the sub-processor is engaged. ¹

For a Compliance Officer, CCO, or GRC lead, this requirement is less about policy language and more about building a repeatable approval gate that engineering, procurement, and customer contracting cannot bypass. The fastest path is to standardize definitions (what counts as a sub-processor), connect your data mapping to your third-party intake process, and make customer approval a contractual and workflow prerequisite to granting access to production data.

Regulatory text

ISO/IEC 27701:2019 Clause 8.5.5 / Annex B.8.5.5 states: “The organization shall disclose to the customer any use of sub-contractors to process PII before their engagement and shall obtain customer approval for the use of sub-contractors.” ¹

What the operator must do:

1. Disclose the identity and intended use of any sub-contractor that will process customer PII.
2. Do it before engagement (before the sub-processor is onboarded, connected, or granted access to customer PII).
3. Obtain customer approval and retain proof of approval.
4. Ensure equivalent PII protection obligations are imposed on the sub-processor through contract terms, so your commitments to the customer remain enforceable downstream. ¹

Plain-English interpretation (what it means day to day)

If a third party will touch a customer’s PII because you hired them (cloud hosting, ticketing, managed services, call center, analytics, fraud tools), your customer gets a say. You must tell them who the sub-processor is and what role they play, and you must get documented approval before you let that sub-processor process the customer’s PII. ¹

This is easiest to think of as a change-control requirement for your sub-processor list: adding or replacing a sub-processor is not only procurement; it is a customer-notice and customer-consent workflow with auditable timestamps.

Who it applies to

In-scope entities

• PII processors providing services to customers where PII processing is part of delivery (for example, SaaS, managed services, outsourced operations). ¹

In-scope operational contexts

This requirement triggers when:

• A sub-contractor will process PII on your behalf for a customer (direct access or indirect processing through systems).
• You are adding a new sub-processor, changing an existing one, or expanding scope such that a third party newly begins processing customer PII.
• A “non-obvious” service begins to process PII (e.g., error logging, customer support tooling, email/SMS delivery, data enrichment). The compliance risk is highest where teams do not consider the provider a “sub-processor” during onboarding.

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

1) Define “sub-processor” and “PII processing” in operational terms

Write a short definition that procurement and engineering can apply during intake:

• Sub-processor = any third party engaged by you that will process customer PII to deliver the service.
• Processing includes hosting, storing, transmitting, viewing, manipulating, or deleting PII.

Make this definition the decision rule inside your intake workflow so teams do not self-interpret.

2) Build and maintain a sub-processor inventory tied to PII data flows

Maintain a register with, at minimum:

• Sub-processor legal name and corporate entity
• Service description and purpose
• Whether they can access production PII (yes/no; how)
• Data categories involved (customer contact data, identifiers, etc.)
• Processing locations (if known from contracting)
• Start date, end date, owner, and last review date
• Customer coverage notes (which products/tenants use them)

This inventory must reflect reality. Auditors commonly test this by sampling systems and tracing data flows back to the list.

3) Add a “customer approval required” gate before engagement

Implement a gate that blocks any of the following until approval is recorded:

• Contract execution with the sub-processor (where feasible)
• Technical integration with production systems
• Creation of sub-processor credentials or SSO
• Network allowlisting, API keys, or data exports

Approval can be handled through your customer contract terms (pre-approval mechanism) or explicit written approval per customer. The operational requirement is that you can show approval happened before engagement. ¹

4) Standardize the disclosure package you provide to customers

Create a customer-ready disclosure format (often a “Sub-processor List” plus a change notice) that includes:

• Sub-processor name
• Role/purpose
• What PII processing they perform
• How to approve or object (based on your contract model)

Keep it consistent, and treat changes as controlled communications.

5) Contractually flow down equivalent PII protections

Your sub-processor agreement should include obligations that match what you promised customers about privacy and security. ISO/IEC 27701’s intent here is equivalency: the sub-processor should not be a weak link that undermines your customer commitments. ¹

Minimum practical flow-downs to implement:

• Confidentiality and limits on processing to documented instructions
• Security requirements appropriate to the service risk
• Restrictions on onward sub-processing (or approval requirements)
• Incident notification obligations and cooperation duties
• Return/deletion expectations at termination

6) Operationalize change management for sub-processors

Treat sub-processor changes as a formal change:

• Intake request with business justification
• Privacy review (PII involved, purpose, minimization)
• Security review (due diligence evidence)
• Customer disclosure and approval
• Implementation approval (technical go-live)
• Post-go-live verification (data flows match approved scope)

If you use Daydream to manage third-party risk and due diligence, connect the intake record, risk assessment, sub-processor register entry, and customer approval evidence in one place so you can answer auditor samples without manual stitching.

Required evidence and artifacts to retain

Auditors and customers will ask for proof that disclosure and approval happened before engagement. Keep:

• Sub-processor inventory (current version plus change history)
• Customer-facing sub-processor list (published copy) and change notices
• Approval evidence per customer or per contract mechanism (signed MSA/DPA terms, written approvals, ticket/workflow approvals with timestamps)
• Sub-processor contracts with privacy/security flow-down clauses
• Onboarding workflow records showing the approval gate (procurement tickets, access requests, change records)
• Data flow documentation tying sub-processors to systems and PII categories
• Exception records where a sub-processor was engaged without prior approval, plus remediation and customer communication (if this ever happens)

Common exam/audit questions and hangups

Expect questions like:

• “Show me your current list of sub-processors that process customer PII.”
• “Pick a sub-processor added recently. Prove the customer was informed and approved before go-live.”
• “How do you ensure engineering cannot add a tool that processes PII without triggering disclosure and approval?”
• “Where do you impose equivalent privacy obligations on sub-processors, and how do you verify the contract contains them?” ¹

Hangups that slow audits:

• Inventory exists, but no evidence of approval timing
• Approval exists, but it is unclear which sub-processor(s) it covers
• Sub-processor legal entity mismatch (brand name listed, different contracting party signed)
• Sub-processor list is static; reality changed

Frequent implementation mistakes (and how to avoid them)

1. Relying on a “we’ll publish a list” approach without approval mechanics.
   Fix: Make the contract model explicit about how approval is granted and how objections are handled, then retain evidence that the mechanism applied for each customer.

2. Treating only hosting providers as sub-processors.
   Fix: Include support tooling, messaging providers, analytics, managed detection, and any outsourced operations that can access PII.

3. Letting approvals happen after technical integration.
   Fix: Put the gate at access issuance. If no access, no processing.

4. Not flowing down equivalent obligations.
   Fix: Maintain a sub-processor contract addendum template and require Legal to confirm inclusion during onboarding. ¹

5. No ownership for the inventory.
   Fix: Assign a named control owner and a single system of record (GRC tool, controlled spreadsheet, or contract lifecycle system) with change tracking.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, the risk is contractual and trust-driven: a customer can claim breach of contract or terminate if you engage sub-processors without the agreed approval process, and incidents at undisclosed sub-processors create heightened scrutiny because you cannot show you followed your own processor obligations. ¹

Practical execution plan (30/60/90)

First 30 days (stabilize and stop new noncompliance)

• Appoint control owner and define “sub-processor” decision rule for intake.
• Create a baseline sub-processor inventory from procurement, security tooling, and engineering system maps.
• Implement an interim approval gate: no new third party that touches PII goes live without Privacy/Legal sign-off and documented customer approval path.

By 60 days (make it repeatable)

• Publish a customer-facing sub-processor list format and standard notice template.
• Update onboarding workflow to require: inventory entry, disclosure package, approval evidence, and contract flow-down confirmation.
• Remediate gaps for existing sub-processors: reconcile list to real data flows, correct entity names, and document customer approval coverage.

By 90 days (make it auditable)

• Add change tracking and periodic review ownership for the sub-processor inventory.
• Run an internal audit-style test: sample sub-processors and prove disclosure + approval occurred before engagement.
• Centralize artifacts in one record per sub-processor (Daydream can hold the due diligence, contract clauses, and customer approval evidence so audits become a retrieval exercise, not an investigation).

Frequently Asked Questions

What counts as a “sub-contractor” under this requirement?

Any third party you engage that will process customer PII to deliver your service is a sub-contractor/sub-processor for this purpose. If the third party can host, access, transmit, or otherwise handle customer PII on your behalf, treat them as in-scope. ¹

Do we need customer approval for every single third party we use?

You need approval for sub-contractors that process the customer’s PII. Office productivity tools with no customer PII, or providers fully outside the service delivery path, may be out of scope, but document the decision rule and rationale.

Can “approval” be handled in the contract instead of asking each customer every time?

Yes, if your customer contract defines a clear approval mechanism for sub-processors and you can show it applied before engagement. Your evidence still needs to connect the mechanism to the specific sub-processor and timing. ¹

What evidence is strongest for audits: an email, a contract clause, or a portal notice?

The strongest evidence is whatever is contractually binding for the customer plus timestamped records. Many teams rely on executed contract terms and a controlled sub-processor list with change logs; if you use emails or tickets, ensure they are searchable and retained.

How do we handle emergency onboarding (e.g., incident response firm) where prior approval is hard?

Pre-negotiate contractual terms that cover emergency sub-processors, and build a documented exception process with immediate customer notification and retroactive approval where your contract allows it. Keep the exception rare and well-evidenced because it will draw auditor attention. ¹

We have multiple products and business units. Do we need separate sub-processor lists?

You need disclosures that are accurate for the customer’s service. That can be one master inventory with product/tenant applicability fields, plus customer-facing views filtered to what the customer’s data actually touches.

Footnotes

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