Subprocessor transparency and governance

The subprocessor transparency and governance requirement means you must (1) know which subprocessors handle your cloud PII, (2) disclose them appropriately to customers, and (3) control their access through contracts, risk review, and ongoing change management aligned to ISO/IEC 27018 expectations ¹. Your goal is audit-ready proof that subprocessor use is intentional, reviewed, and bounded.

Key takeaways:

• Maintain an accurate subprocessor inventory tied to specific PII processing activities and data locations ¹.
• Implement a formal notice-and-approval/objection workflow for adding or changing subprocessors ¹.
• Flow down privacy and security obligations into subprocessor contracts and verify performance through periodic review ¹.

“Subprocessor transparency and governance requirement” work is rarely blocked by lack of intent; it’s blocked by incomplete inventories, unclear ownership, and unmanaged change. ISO/IEC 27018 is aimed at cloud service providers acting as PII processors, and it expects you to be able to identify and govern any third party that processes cloud PII on your behalf ¹. That includes infrastructure providers, support tooling, customer service platforms, analytics providers, and specialized operators (for example, a managed detection and response firm) if they can access or process PII.

Operationalizing this requirement is about building a small set of mechanisms that hold up under customer scrutiny and audit sampling: a defensible definition of “subprocessor,” a living inventory, a contracting standard that flows down privacy controls, and a change management process that prevents “shadow subprocessors” from appearing through procurement shortcuts or engineering decisions. This page gives you a requirement-level implementation blueprint: who owns what, what to implement first, what artifacts you need, and where audits typically get stuck.

Regulatory text

Framework source (summary-level only): “Baseline implementation-intent summary derived from publicly available framework overviews; licensed standard text is not reproduced in this record.”
Requirement intent: “Disclose and govern subprocessors handling cloud PII.” ¹

What the operator must do (plain-English):

1. Identify subprocessors that can process cloud PII for your service ¹.
2. Disclose subprocessor use to customers in a clear, maintained way ¹.
3. Govern subprocessor risk through contractual obligations, due diligence, and controlled onboarding and change management ¹.

This requirement is “medium” severity in practice because failures tend to show up as customer contract breaches, audit findings, or incident fallout: you cannot defend processing boundaries if you cannot show who touched data, under what terms, and under what approvals ¹.

Plain-English interpretation (what “good” looks like)

You can pass this requirement if you can answer these questions quickly, consistently, and with evidence:

• Who are your subprocessors, exactly? Names, roles, and what they do with PII ¹.
• Which customer data and processing activities do they support? A mapping from subprocessor to service component and PII categories.
• Where is processing occurring? Locations/regions if relevant to your customer commitments.
• How do you control changes? A documented workflow for adding, replacing, or materially changing subprocessors.
• What contract terms bind them? Privacy and security obligations that match your promises to customers ¹.

A common internal test: if engineering can add a new SaaS tool that receives PII without legal/compliance learning about it, you do not yet have governance.

Who it applies to

Entities: Cloud service providers acting as PII processors (including SaaS, PaaS, and IaaS providers) that rely on third parties to deliver the service ¹.

Operational contexts that trigger the requirement:

• Customer PII stored or processed in your cloud environment, with third parties involved in hosting, support, monitoring, backups, communications, analytics, or customer success workflows ¹.
• Any environment where personnel or systems from a third party can access production data containing PII.
• Mergers, new product lines, or new regions where subprocessor footprint changes frequently.

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

Step 1: Define “subprocessor” for your program

Write a short definition used across procurement, security, and engineering intake. Include:

• A subprocessor is a third party engaged by you that processes cloud PII on your behalf ¹.
• “Process” includes hosting, storing, transmitting, accessing, viewing, support handling, or derived processing where PII is present.

Decision rule (practical):

• If a third party can access production systems that contain PII, treat them as a subprocessor.
• If a third party receives data exports that include PII, treat them as a subprocessor.
• If a third party only receives irreversibly anonymized data, document why it is not a subprocessor and keep the rationale.

Step 2: Build and maintain a subprocessor inventory (single source of truth)

Create an inventory that is owned (named system owner), versioned, and reviewed ¹. Minimum fields:

• Legal entity name, DBA, and contract owner
• Service provided and system/component supported
• Data access type (storage, support access, telemetry, etc.)
• PII categories affected (free text if you don’t have a taxonomy yet)
• Processing locations/regions (as committed contractually)
• Start date, status (active/terminated), last review date
• Link to DPA/SCCs or equivalent contractual addenda
• Link to risk assessment and security review

Operational note: tie the inventory to procurement. If purchase orders can be issued without creating/updating the inventory entry, you will miss tools.

Step 3: Implement disclosure and notice mechanisms

ISO/IEC 27018’s intent is transparency plus control ¹. Your disclosure approach should match your customer contract language, but operationally you want:

• A public or customer-accessible subprocessor list (often on a trust page or within the customer portal).
• A change notice process for additions or replacements.
• A customer communication log (what changed, when, who was notified, method).

Practical minimum:

• Publish the list and keep a dated change log.
• Use a standard customer notice email template that states the new subprocessor, purpose, and effective date.
• Track objections and resolution path (security review call, alternative routing, contract termination right if applicable).

Step 4: Flow down privacy and security terms into subprocessor contracts

You need contract language that binds subprocessors to the privacy and security commitments you owe customers ¹. Your checklist should cover:

• Confidentiality obligations for personnel
• Security controls obligations (appropriate to the service)
• Restrictions on secondary use of PII
• Breach/incident notification obligations to you
• Assistance with data subject requests as applicable to your commitments
• Sub-subprocessor restrictions (require your approval or equivalent control)
• Data return/deletion at termination

Control design tip: Maintain a “subprocessor addendum” template that legal can attach to MSAs. Track exceptions explicitly with risk acceptance.

Step 5: Perform risk review before onboarding, and re-review on change

Before enabling access or sending data:

• Confirm the subprocessor is in the inventory.
• Complete a risk assessment appropriate to the access level (questionnaire, SOC report review, pen test summary, etc.).
• Verify contract terms are executed.
• Validate technical controls: least privilege, access logging, encryption, and segregation.

Then define change triggers:

• Material scope change (new data types, new region, new access method)
• New product integrating the subprocessor
• Incident at the subprocessor
• Contract renewal with changed terms

Step 6: Control subprocessor access technically (not only on paper)

Auditors and customers will look for control operation, not just policy language. Build:

• Access provisioning tied to ticketing with approvals
• Time-bounded access for support vendors
• Central logging of third-party access to production
• Segmentation (separate environments, scoped credentials)
• Offboarding checklist (disable accounts, revoke keys, confirm deletion)

Step 7: Monitor and attest internally

Run a recurring internal review that produces evidence:

• Inventory review sign-off
• Reconciliation: procurement spend vs inventory, and SSO app catalog vs inventory
• Sampling: pick a few subprocessors and confirm contract + risk review + access controls exist

Where Daydream fits naturally: teams often struggle to keep inventories, notices, and contract/risk artifacts aligned across procurement, legal, and security. Daydream can act as the system of record for subprocessor inventories, map them to processing activities, and package audit-ready evidence sets without relying on spreadsheet archaeology.

Required evidence and artifacts to retain

Maintain these in a place you can export for customer diligence and audits:

1. Subprocessor inventory (current + historical versions) ¹
2. Subprocessor disclosure list and dated change log ¹
3. Notice records (email distributions, portal announcements, support tickets)
4. Executed contracts: MSA + DPA/addenda + security terms ¹
5. Risk assessment package per subprocessor (questionnaire, SOC report review notes, exceptions)
6. Approval records for onboarding and for material changes
7. Access control evidence: provisioning tickets, role mappings, logs, offboarding confirmations
8. Periodic review minutes: inventory review, re-assessment triggers, remediation tracking

Common exam/audit questions and hangups

Expect these questions and prepare tight answers:

• “Show me your complete list of subprocessors that can process PII.” Hangup: your list excludes support tooling or incident response providers.
• “How do customers get notified of changes?” Hangup: you publish a list but have no documented notice workflow or change log.
• “Prove you flow down privacy obligations.” Hangup: contracts vary by subprocessor with undocumented exceptions.
• “How do you prevent unapproved subprocessors?” Hangup: engineering can add tools via corporate card; procurement controls are bypassed.
• “How do you offboard?” Hangup: termination does not include credential revocation proof or deletion attestation.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Treating “subprocessor list” as marketing content	Audits require traceability and governance evidence	Make the inventory the source; publish a controlled view for customers
Inventory without system mapping	You cannot prove relevance to PII processing	Add “service component” and “processing activity” fields
Contract templates exist but exceptions are unmanaged	Exceptions become systemic gaps	Track exceptions with explicit approvals and compensating controls
No change triggers	Subprocessors drift over time	Define “material change” triggers and require reassessment
“We have SOC reports” as the whole program	Reports do not show your approvals, scoping, and access controls	Combine due diligence + contract + technical enforcement + notices

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific regulator actions.

Operational risk still concentrates in predictable places:

• Contractual exposure: Many customer DPAs require subprocessor disclosure and change notice. Missing a subprocessor can become a breach of contract.
• Incident blast radius: If a subprocessor is involved in an incident and you cannot show governance, your incident response becomes slower and less defensible.
• Audit outcomes: ISO-aligned audits commonly sample third parties; incomplete inventories and missing approvals generate findings.

Practical 30/60/90-day execution plan

Days 0–30: Establish control ownership and stop the bleeding

• Assign owners: one for inventory, one for contracting standards, one for onboarding workflow.
• Draft your “subprocessor definition” and decision rule; publish internally.
• Build the initial inventory from procurement records, SSO app catalog, cloud marketplaces, and security tooling.
• Stand up an interim approval gate: no new third party gets PII access without security + legal sign-off.
• Publish a first-cut customer-facing subprocessor list if you don’t have one; include a “last updated” date and contact channel.

Days 31–60: Convert inventory into governance

• Implement a documented onboarding workflow with required steps: inventory entry, risk review, contract execution, access controls.
• Standardize subprocessor contractual addendum language; create an exception process.
• Create notice templates and a change log process; align with your customer commitments.
• Run a first internal reconciliation (procurement vs inventory) and remediate gaps.

Days 61–90: Prove operation and become audit-ready

• Perform a sample-based control test: pick several subprocessors, produce the full evidence packet.
• Add monitoring triggers: renewal dates, scope changes, new regions, incidents.
• Implement periodic review cadence (inventory review meeting + sign-off record).
• Package “customer diligence ready” artifacts: list, change log, governance overview, and a standard Q&A.

Frequently Asked Questions

What counts as a subprocessor versus a normal third party?

Treat any third party you engage that can process cloud PII on your behalf as a subprocessor ¹. If they can access production data with PII or receive exports containing PII, put them through the subprocessor governance path.

Do we need to publicly list every subprocessor?

You need to disclose subprocessors appropriately to customers and govern changes ¹. Whether “public” or “customer-portal only” depends on your contracts, but you should be able to provide a current list plus change history on request.

How do we handle a subprocessor that refuses our contract addendum?

Document the gap, run an exception process, and decide whether compensating controls are acceptable (for example, reduced data scope or no production access). If you cannot meet your customer commitments, do not onboard them for PII processing.

Are cloud infrastructure providers always subprocessors?

If the provider processes PII as part of delivering your service (hosting, storage, backups, support access), treat them as subprocessors and include them in your inventory and disclosures ¹. If you have a clear basis that they do not process your cloud PII, document that rationale.

What evidence do auditors ask for most often?

Auditors usually sample a few subprocessors and expect to see the inventory entry, executed privacy/security terms, risk review, and proof of controlled access and offboarding. Missing any one of those items often results in a control effectiveness finding.

Our subprocessor list is maintained by Legal, but Security onboards tools directly. How do we fix that?

Make the inventory the shared system of record and connect onboarding to a required workflow step that both Legal and Security must complete. If your tooling supports it, use Daydream to centralize inventory, approvals, and evidence so change management does not depend on email threads.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control lifecycle management

Footnotes

1. ISO/IEC 27018 overview