Disclosure of sub-contracted PII processing

“Disclosure of sub-contracted PII processing” is a simple requirement that fails in messy ways: teams treat the sub-processor list as marketing content, procurement signs agreements without privacy review, or engineering enables a new downstream service before the customer is informed. ISO/IEC 27018:2019 Annex A.8.1 is explicit about timing and content. You disclose before use, and you include the names and locations of sub-processors.

For a CCO or GRC lead, the goal is not a perfect spreadsheet. The goal is an operating model that prevents undisclosed sub-processing from happening, even when the business is moving fast. That means you need (1) a precise definition of “sub-processor” in your environment, (2) a single source of truth for who processes PII on your behalf, (3) contractual language that allows and structures disclosures, and (4) workflow controls that stop go-live until the disclosure step is complete.

This page gives requirement-level implementation guidance you can drop into your compliance program, your third-party risk process, and your product release/change management lifecycle, with evidence artifacts that auditors and enterprise customers will ask for.

Regulatory text

Requirement (verbatim): “The use of sub-contractors by the public cloud PII processor to process PII shall be disclosed to the relevant cloud service customer before their use, including the names and locations of any sub-processors.” ¹

Operator interpretation (what the standard forces you to do)

1. Identify sub-processing of PII. If a third party will process PII on your behalf as part of delivering your cloud service, they are in scope.
2. Disclose before first use. The disclosure must occur before the sub-processor is put into production for that customer’s PII.
3. Disclose minimum content. At minimum, disclose sub-processor name and location. In practice, customers also expect a short description of the processing activity to understand the exposure.
4. Target the right customer. Disclosure goes to the “relevant cloud service customer,” meaning the customer whose PII will be touched.

This is a disclosure requirement, but it creates a control requirement: you need a gating mechanism that prevents undisclosed sub-processing.

Plain-English requirement (quick translation)

If you use another company to help deliver your cloud service and that company will touch customer PII, you must tell the customer before that company starts. Your notice must name the company and where they are located. If you cannot confidently tell a customer who your sub-processors are, you cannot claim conformance to this control.

Who it applies to

Entity scope

• Public cloud PII processors (cloud service providers processing PII on behalf of customers). ¹

Operational scope (where this shows up)

• Infrastructure and hosting: IaaS/PaaS providers, managed hosting, CDN, DNS, DDoS protection where logs contain PII.
• Customer support tooling: ticketing, chat, call recording, remote support, screen sharing.
• Analytics and monitoring: APM, error reporting, session replay (often overlooked).
• Subservice organizations: outsourced operations/SOC, managed database, managed backups.
• Professional services (if they access production data containing PII).

Practical scoping rule: if the third party can access, store, transmit, or otherwise process customer PII because you engaged them to deliver your service, treat them as a sub-processor for this requirement.

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

Step 1: Define “sub-processor” for your program

Write a one-page definition aligned to ISO/IEC 27018 language:

• Sub-processor = a third party engaged by you to process PII in delivering the cloud service.
• Include examples (support platform, managed hosting).
• Exclude true independent controllers where you do not determine processing on behalf of the customer (document rationale when excluded).

Output: Sub-processor definition memo + scoping decision log.

Step 2: Build and maintain a sub-processor inventory (single source of truth)

Create an inventory with required fields:

• Legal entity name (not product brand)
• Processing location(s) relevant to the service (country/region)
• Processing purpose (what they do for you)
• Data categories (high-level: account data, support data, logs)
• Access model (continuous, on-demand, break-glass)
• Status (planned / approved / active / offboarded)
• Customer applicability (all customers vs. specific products/regions)

Control point: Tie the inventory to procurement intake and architecture review so it stays current.

Output: Sub-processor register with ownership, update cadence, and change history.

Step 3: Implement a “no-go” onboarding gate before any sub-processor touches PII

Put a mandatory control in your onboarding workflow:

• Procurement cannot sign, and engineering cannot integrate, until the sub-processor is:
  1. recorded in inventory,
  2. approved by security/privacy (TPRM + DPIA-style review where applicable), and
  3. scheduled for customer disclosure.

A practical mechanism is a checklist in your intake tool (or Daydream) that blocks approval until the disclosure workflow is attached to the record.

Output: Onboarding SOP with an approval gate and clear RACI.

Step 4: Establish the customer disclosure mechanism (what “disclose” means operationally)

ISO/IEC 27018 requires disclosure before use, but it does not prescribe the channel. Choose a method that is provable:

• Contract exhibit / sub-processor list referenced in your DPA or service terms.
• Customer portal notice with versioning and timestamps.
• Direct written notice (email to contract notices address) for material changes or customer-specific processors.

Minimum content to include:

• Sub-processor legal name
• Location(s)
• Effective date (planned first use date)
• High-level description of processing (recommended to avoid confusion and reduce customer escalations)

Output: Standard disclosure template + publication/notification procedure with evidence capture.

Step 5: Make “before use” real with release/change management

Most failures happen here: the sub-processor gets enabled in production while legal is still “working on the notice.”

Implement a release condition:

• For any change that routes, stores, or exposes PII to a new sub-processor, the change ticket must link to:
  • the inventory record, and
  • evidence of disclosure completion for impacted customers.

If you support multiple product lines, embed this in your architecture decision record (ADR) process or security design review checklist.

Output: Change management checklist item + sample completed change ticket.

Step 6: Manage ongoing changes (names, locations, new subprocessors)

Treat these as controlled events:

• New sub-processor
• Location expansion (new region/country)
• Corporate name change (M&A) that changes the legal entity processing PII
• New processing purpose (support tool begins to store production data)

For each event:

1. update inventory,
2. evaluate customer impact,
3. disclose before the changed processing starts,
4. retain evidence.

Output: Sub-processor change log + customer notice history.

Step 7: Align contract language so disclosures are enforceable and repeatable

Even though ISO/IEC 27018 is a standard (not a law), customers will contractually expect a structure:

• A clause that permits sub-processing subject to disclosure.
• A defined notice method (portal vs. email).
• A commitment that disclosure occurs before use.
• A requirement that disclosed list includes names and locations.

Output: Standard DPA/service terms language and exhibit structure (maintained by legal/compliance).

Required evidence and artifacts to retain

Auditors and enterprise customers will look for proof of both design and operation:

Core artifacts

• Sub-processor inventory/register with version history.
• Policies/SOPs:
  • third-party intake and approval SOP
  • sub-processor disclosure procedure
  • change management procedure showing “new sub-processor” trigger
• Customer-facing disclosure:
  • published sub-processor list (current and archived versions)
  • notification emails or portal notices (timestamped)
• Governance evidence:
  • approval records for onboarding (security/privacy sign-off)
  • meeting notes or tickets showing decision and timing (“before use”)

Evidence quality tips

• Keep screenshots/PDF exports of the sub-processor page per update, with date and version.
• Preserve proof of when the sub-processor first processed PII (go-live ticket) and ensure disclosure predates it.

Common exam/audit questions and hangups

• “Show me your current sub-processor list and when it was last updated.”
• “How do you ensure a new sub-processor cannot be used before customers are notified?”
• “Do you disclose locations at the country level, or only ‘EU/US’?”
• “How do you handle customer-specific sub-processors or professional services access?”
• “Prove timing: disclosure date vs. first processing date.”

Where audits get stuck: the team can produce a list, but cannot show a control that prevents undisclosed processing.

Frequent implementation mistakes (and how to avoid them)

1. Listing brands instead of legal entities. Fix: require legal name in the inventory and disclosure template.
2. Using vague locations. Fix: disclose locations with enough specificity to be meaningful (country/region) and align to how processing actually occurs.
3. Inventory drift. Fix: make procurement and architecture review the only “front doors” to new sub-processors, and enforce the gate.
4. Treating “support tools” as out of scope. Fix: assume support data includes PII unless proven otherwise; document exclusions.
5. No link to change management. Fix: add a mandatory “new/changed sub-processor” trigger in change tickets and release approvals.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat risk as customer-driven and audit-driven:

• Contract risk: failure to disclose can trigger breach of contract claims, termination rights, or blocked deals during security reviews.
• Operational risk: undisclosed sub-processing often correlates with weak third-party change control and incomplete data flow mapping.
• Reputational risk: customers interpret undisclosed sub-processors as hidden outsourcing or uncontrolled data transfer.

Practical 30/60/90-day execution plan

First 30 days (stabilize and stop the bleeding)

• Assign ownership: one accountable role for the sub-processor register and disclosure workflow.
• Draft the sub-processor definition and scope boundaries; publish internally.
• Stand up a baseline inventory from procurement records, architecture diagrams, and finance/AP spend lists.
• Implement an interim gate: “no new sub-processor without compliance sign-off” in procurement intake.

Next 60 days (make it repeatable and auditable)

• Create the customer disclosure template and publish method (contract exhibit, portal page, or direct notice).
• Backfill evidence: capture the current published list and archive it as a controlled artifact.
• Add a required field set in intake tickets (name, location, purpose, data categories, access model).
• Connect change management to the disclosure step for new/changed data flows.

Next 90 days (operational maturity)

• Move from spreadsheet dependency to workflow tooling (for example, manage sub-processor records, approvals, and notice evidence in Daydream so you can prove timing and completeness during audits).
• Run an internal control test: pick recent sub-processor changes and verify disclosure occurred before go-live.
• Train procurement, engineering, and customer-facing teams on the trigger conditions and escalation path.
• Establish an ongoing review cadence for the sub-processor list and location accuracy tied to contract and architecture changes.

Frequently Asked Questions

Does “before their use” mean before contract signature or before production go-live?

Operationally, treat it as before the sub-processor first processes customer PII. If you disclose at contract signature but add a sub-processor later, you still need disclosure before the later go-live.

What counts as a “location” that must be disclosed?

Disclose the location(s) where the sub-processor processes PII in a way a customer can evaluate, commonly at a country or region level. Whatever granularity you choose, keep it consistent with your actual data flows and contracts.

If we use a sub-processor only for aggregated telemetry, is it in scope?

If telemetry can include PII or be linked back to an identifiable person, treat it as in scope and disclose. If you determine it is not PII, document the determination and the technical basis.

How do we handle emergency onboarding (incident response, urgent scaling) where timing is tight?

Your process still needs a “before use” gate; build a pre-approved bench of incident-response and infrastructure sub-processors with disclosures ready. For truly exceptional events, document the decision, the timing, and customer communication immediately.

Do we need customer consent or just disclosure?

ISO/IEC 27018 Annex A.8.1 specifies disclosure before use and does not add a consent requirement in the provided text. Your contracts may still require consent or allow objections; align the workflow to your contract terms.

What evidence is strongest in an audit?

Timestamped customer notices (portal versions or notice emails) plus a change ticket showing the sub-processor’s first use date. Auditors want to see the disclosure clearly predates processing.

Footnotes

1. ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors