Public cloud PII processor's commercial use

To meet the public cloud PII processor’s commercial use requirement, you must prohibit your cloud provider (as a PII processor) from using contract-processed PII for marketing or advertising unless you give express, optional consent that is not required to receive the service. Operationalize this by hardwiring the prohibition into contracts, configuring product settings to prevent ad/marketing use, and retaining proof of consent and controls.

Key takeaways:

• Contract language must explicitly ban marketing/advertising use of customer PII unless express consent is granted.
• Consent must be opt-in and cannot be tied to service availability or pricing in a way that makes it a condition.
• You need evidence: signed terms, configuration screenshots, DPIA/assessment notes, and a consent log (even if “no consent given”).

This requirement is narrow, but examiners and customers treat it as high-signal because it tests whether you control secondary use of PII by a powerful third party. The specific risk is “silent repurposing”: your cloud provider takes PII you upload or generate under the service contract and uses it to market to you, your users, or lookalike audiences, or to target advertising. ISO/IEC 27018 draws a bright line: no marketing/advertising use without express consent, and the provider cannot make that consent a condition of receiving the service.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to (1) identify which public cloud services are acting as PII processors for your organization, (2) confirm the provider’s default position is “no ad/marketing use,” (3) lock it into the agreement and account settings, and (4) build a lightweight consent governance model so business teams can’t accidentally click “yes” during procurement, onboarding, or feature enablement.

This page gives requirement-level implementation guidance you can deploy in third-party due diligence, contracting, and cloud governance without turning it into a multi-quarter program.

Regulatory text

Requirement (operator meaning): A public cloud PII processor must not use PII processed under a contract for marketing and advertising unless the cloud customer gives express consent, and that consent cannot be required to receive the service. ¹

What you must do to meet it:

• Treat “marketing and advertising use of PII” as prohibited by default for any public cloud third party acting as your PII processor.
• If the provider offers any setting, feature, or term that permits marketing/advertising use, require explicit opt-in approval and document it.
• Ensure the service is still available if you decline consent; no “consent gate” during onboarding, renewals, or feature activation. ¹

Plain-English interpretation (what this really means)

If your public cloud provider is processing personal data for you, they cannot take that same data and use it to market or advertise unless you clearly and explicitly agree. “Express consent” means a deliberate opt-in, not buried terms, implied consent, or a default-on checkbox. Also, you cannot be forced to grant consent just to get the cloud service you’re buying. ¹

A practical way to interpret it in operations: your default stance should be “no secondary commercial use,” and the only acceptable exception is a documented, business-approved opt-in with clear scope and reversibility.

Who it applies to

In-scope entities

• Public cloud service providers acting as PII processors (the third party processes PII on your behalf under a contract). ¹

In-scope operational context (what to look for)

This requirement becomes relevant when:

• You store, transmit, analyze, or back up customer/employee/user PII in a public cloud service.
• The provider’s terms, product settings, or optional programs mention any of the following with respect to customer content or data:
  • “marketing,” “advertising,” “promotions,” “product marketing,” “personalized offers”
  • “data sharing,” “data enrichment,” “business insights,” “recommendations” tied to ads or marketing
• The provider offers “free” tiers, credits, or bundled features that include “data use for advertising” as a tradeoff. Even if it feels optional, you must ensure it is truly optional and not required to receive the contracted service. ¹

Typical owners inside your organization

• Procurement / sourcing (contract terms)
• Legal / privacy (DPA review, consent standard)
• Security / cloud platform team (account settings, controls)
• GRC / third-party risk (due diligence, evidence, audits)

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

Step 1: Build the “PII processor in public cloud” inventory

1. List public cloud providers and major services in use (IaaS, PaaS, SaaS hosted in a public cloud).
2. For each service, identify whether PII is processed under the contract (yes/no/unknown).
3. Flag “unknown” as a blocker for renewal or expansion until clarified.

Operator shortcut: Start with your data map and cloud billing export, then crosswalk to systems that store identity, HR, support tickets, analytics, or logs likely containing PII.

Step 2: Review contract terms for marketing/advertising use

For each in-scope provider:

1. Locate the sections on “Customer Data,” “Content,” “Data Processing,” and “Service Improvements/Marketing.”
2. Confirm the contract (or DPA) states the provider will process PII only to provide the services, and does not use it for marketing/advertising unless you expressly consent. ¹
3. If the terms allow marketing/advertising use, negotiate:
   • Default prohibition (no marketing/advertising use of contract-processed PII)
   • Express consent mechanism (opt-in, documented, scoped)
   • Non-conditionality (service must be provided even if you refuse consent) ¹

Contract clause intent (write to your counsel’s style):

• “Provider will not use Customer PII processed under this Agreement for marketing or advertising unless Customer provides express consent in writing (including via authorized admin console setting). Consent is optional and not required to receive the Services.”

Step 3: Lock down product and account settings (don’t rely on paper)

1. In the admin console, locate privacy/data use controls that relate to:
   • ad personalization
   • marketing communications based on customer content
   • “data sharing” for ads/marketing
2. Set them to off by default.
3. Restrict who can change them:
   • require admin role
   • change control ticket
   • privacy/legal approval for any opt-in

Common reality: Some platforms bury these controls across multiple consoles (billing, identity, product-level). Treat “distributed controls” as a known risk and document where each setting lives.

Step 4: Implement an “express consent” governance flow (even if you never consent)

Create a simple decision workflow:

1. Business owner submits a request describing the feature and why it needs PII for marketing/advertising.
2. Privacy reviews whether the request is allowed under your internal privacy commitments.
3. Security validates that scope is limited to what is necessary.
4. Legal confirms contract language supports an opt-in that is not a condition of service.
5. Approved? Record express consent, the scope, and the ability to withdraw.

If you never plan to allow marketing/advertising use, your governance outcome can be “standing policy: no consent granted.” That still needs evidence.

Step 5: Monitor drift (renewals, new features, “free” add-ons)

Add checks to:

• renewal playbooks (re-confirm terms and settings)
• cloud landing zone standards (default account baselines)
• procurement intake (block “advertising data use” programs unless approved)

Where teams get burned: A product update introduces a new “data use” toggle defaulted on, or a business team accepts updated terms during a click-through renewal.

Required evidence and artifacts to retain

Keep evidence in a single audit-ready folder per third party (contract + configuration + governance). Minimum set:

• Executed MSA/DPA and any amendments addressing data use restrictions ¹
• Contract redlines or negotiation notes showing how marketing/advertising use was removed or constrained
• Screenshots or exports of relevant admin-console settings showing “off” (date-stamped)
• Change management records for any setting changes (tickets/approvals)
• A consent log:
  • “No consent granted” entries are acceptable if accurate
  • If consent granted, record approver, date, scope, method of consent, and withdrawal procedure
• Third-party risk assessment notes mapping this requirement to contract controls and technical settings

Daydream fit (earned mention): If you use Daydream for third-party risk management, store the clause requirement, evidence checklist, and consent log as standardized artifacts per cloud provider so renewals don’t restart the analysis from zero.

Common exam/audit questions and hangups

Expect auditors, customers, and internal audit to ask:

• “Show me the contract language that prohibits marketing/advertising use of PII.” ¹
• “Where is express consent documented? Who can approve it?”
• “Prove consent is not a condition of service. What happens if you decline?”
• “Which settings control data use for advertising/marketing? Who can change them?”
• “Do you have evidence that these settings remain off over time?”

Hangups that slow approvals:

• Confusion between “service improvement” analytics and “marketing/advertising.” If the provider can use PII to promote products or target ads, treat it as in-scope marketing/advertising even if labeled differently.
• Click-through terms updates without review.
• Multiple sub-processors and product lines with inconsistent terms.

Frequent implementation mistakes (and how to avoid them)

1. Relying on a general privacy policy instead of the contract.
   Fix: Ensure the enforceable agreement (MSA/DPA/order form) contains the restriction. Keep the executed copy.

2. Treating “opt-out” as express consent.
   Fix: Require a positive, documented opt-in. “Default on unless you uncheck” fails the intent of express consent. ¹

3. Letting product admins enable settings without compliance review.
   Fix: Tie admin role changes and setting flips to a ticket requiring privacy/legal approval.

4. Ignoring “free tier” or credits that trade data rights for discounts.
   Fix: Add procurement guardrails: any term that conditions service value on marketing/advertising consent must be escalated. ¹

5. No evidence of “no consent.”
   Fix: Maintain an explicit log entry stating that consent has not been granted and listing the systems/settings enforcing that position.

Enforcement context and risk implications

No public enforcement cases are provided in the source materials for this requirement, so treat enforcement risk here as contractual, customer-driven, and audit-driven. Practical impacts you will see:

• Failed enterprise security reviews if you cannot show the prohibition and evidence.
• Breach of customer commitments if your privacy notices promise limited processing but the cloud provider uses PII for advertising.
• Increased incident scope if a provider’s marketing/ads systems become implicated in a security event, because secondary use expands the data footprint.

Practical execution plan (30/60/90)

First 30 days (triage and baseline)

• Identify all public cloud providers processing PII for you.
• Pull current MSAs/DPAs and confirm whether marketing/advertising use is prohibited absent express consent. ¹
• Locate and document relevant admin settings; set to “off” where applicable.
• Create a simple consent log template and record “no consent granted” for each provider unless a documented exception exists.

Days 31–60 (close gaps)

• Negotiate amendments where contract language is ambiguous or permissive.
• Implement approval workflow for any future opt-in (privacy + legal + security).
• Restrict admin permissions and add change-control requirements for the settings.

Days 61–90 (make it durable)

• Add checks to renewal playbooks and procurement intake.
• Build a recurring review step tied to major product changes and contract updates.
• Centralize evidence in your third-party risk system (or a controlled repository) so customer audits can be answered quickly.

Frequently Asked Questions

Does this requirement ban all provider analytics or service improvement?

No. It targets marketing and advertising use of PII processed under the contract without express consent. If analytics are used to deliver or secure the service, document that purpose and confirm it is not used for marketing/advertising. ¹

What counts as “express consent” in practice?

Treat it as an opt-in approval that is deliberate, documented, and authorized by your organization. A pre-checked box or implied consent through continued use is not a safe operational interpretation for “express consent.” ¹

Can a cloud provider require consent for advertising use as part of a discounted plan?

This requirement says consent must not be a condition of receiving the service. If the discount effectively requires consent to obtain the service you need, escalate to legal/privacy and treat it as noncompliant with the requirement intent. ¹

If we never grant consent, do we still need a consent process?

Yes, because teams can accidentally enable optional programs or accept updated terms. A lightweight process plus a “no consent granted” register prevents silent opt-ins and gives you audit evidence.

What evidence is strongest for audits: contract terms or screenshots?

Auditors typically want both. The contract shows enforceable restrictions, and the screenshots or configuration exports show the settings match the contract in the live environment. ¹

How should we handle a provider that refuses to change their standard terms?

Document the gap, assess the business impact, and consider compensating actions (for example, choosing a different service tier, isolating workloads, or selecting an alternate provider). If the provider’s position permits marketing/advertising use without express consent, treat it as a material third-party risk against this requirement. ¹

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