Privacy and protection of personally identifiable information

ISO/IEC 27018:2019 Clause 18.1.4 requires a public cloud PII processor to (1) protect personally identifiable information (PII) in line with applicable privacy laws, regulations, and contracts, and (2) never use customer PII for the provider’s own purposes. To operationalize it, hard-code “no provider purpose” into contracts, product design, access controls, and monitoring.

Key takeaways:

• You must prevent “own purpose” use of customer PII, including marketing, advertising, or analytics unrelated to delivering the contracted service.
• Compliance is not a policy-only exercise; you need technical and operational controls that block, detect, and prove non-use.
• Auditors will look for enforceable contract language, data-use governance, and evidence that production access and secondary processing are controlled.

This requirement is one of the fastest ways for a cloud provider to fail a privacy assessment: you can have strong security controls and still violate ISO/IEC 27018 if teams reuse customer PII for internal goals that are not part of providing the service. Clause 18.1.4 is plain: comply with applicable privacy obligations, and do not use PII for your own purposes.

For a Compliance Officer, CCO, or GRC lead, the operational challenge is scope control. “Own purposes” shows up in subtle places: product telemetry that captures identifiers, support tooling that exports customer records into ticketing systems, engineering sandboxes seeded with production data, or marketing teams asking for “just a list of admins” to announce a new feature. The control objective is to make the prohibited behavior hard to do by default, easy to detect when it happens, and contractually and procedurally unambiguous.

This page gives you requirement-level implementation guidance: who it applies to, what to build, what to retain as evidence, what auditors ask, and how to execute quickly without turning it into a multi-quarter rewrite.

Regulatory text

Clause requirement (operator meaning): Privacy and protection of personally identifiable information must be ensured as required by relevant legislation, regulations, and (if applicable) contractual clauses, and a public cloud PII processor must not use PII for its own purposes. ¹

What the operator must do:

• Identify which privacy obligations apply to your processing (laws/regulations plus customer contractual requirements) and implement controls to meet them.
• Define and enforce a “no provider purpose” rule: customer PII can only be processed to deliver the contracted cloud service (plus any customer-authorized processing), not for the provider’s independent benefit. ¹

Plain-English interpretation (what this means in practice)

You are allowed to process customer PII only to run the service the customer bought (and any explicitly agreed supporting activities such as support, security operations, billing, or legal compliance). You are not allowed to repurpose that PII to benefit your business outside that service relationship.

Practical examples of “own purposes” you should treat as prohibited unless the customer has explicitly agreed:

• Marketing outreach based on data from the customer tenant (names, emails, roles, usage tied to an identity).
• Advertising or cross-selling lists derived from tenant user records.
• Training generalized internal models on customer PII without explicit customer agreement.
• Building benchmark reports that expose or rely on identifiable customer user data.

Examples that are typically within “provide the service” (still must be controlled and documented):

• Billing and account administration.
• Security monitoring and fraud/abuse prevention inside the service.
• Support case resolution (with least-privilege access and logging).

Who it applies to

Entity types: Public cloud service providers acting as PII processors for customer data. ¹

Operational contexts where this control matters most:

• Multi-tenant SaaS/PaaS/IaaS environments where identities, logs, and support data commonly contain PII.
• Shared services teams (support, SRE, SOC, finance, product analytics) that touch production or derived datasets.
• Third parties you rely on for sub-processing (ticketing, CRM, analytics, logging), because their “secondary use” becomes your problem as the processor chain owner.

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

Use this as an execution checklist. The goal is to convert a principle (“don’t use PII for own purposes”) into enforceable design constraints.

1) Define “permitted purpose” and “provider own purpose”

• Write a Data Use Policy section that distinguishes:
  • Permitted processing purposes (service delivery, support, security, billing, compliance).
  • Prohibited processing purposes (marketing/advertising, unrelated product research, monetization, generalized profiling).
• Add examples tied to your actual workflows (support exports, telemetry, sandbox data, incident response).

Operator tip: Avoid vague verbs like “improve services” without boundaries. That phrase is often used to justify broad analytics.

2) Put the rule in customer contracts and internal terms

• Ensure your customer agreement/DPA (where applicable) explicitly states:
  • You act as a processor for customer PII in the public cloud context.
  • You process PII only on customer instructions or as required to provide the service.
  • You do not use customer PII for your own purposes. ¹
• Mirror the same rule in internal acceptable-use and confidentiality obligations for workforce members and contractors.

3) Build a “secondary use” intake and approval gate

Create a lightweight review path for any new or changed processing that touches customer PII:

• Request intake: what data, from where, identifiers involved, purpose, retention, access path, sub-processors.
• Approval criteria: permitted purpose, minimization, pseudonymization/anonymization plan, logging, and customer authorization if needed.
• Output: an approved design record plus an implementation ticket.

If you use Daydream for third-party risk and compliance workflows, this is a good place to run intake, attach design evidence, and maintain an auditable decision trail across Legal, Security, and Product without chasing email threads.

4) Enforce via technical controls (not just policy)

Implement controls that make prohibited “own purpose” use difficult:

• Data classification and tagging for customer PII fields and datasets.
• Access controls: least privilege, role-based access, and separation between production PII and analytics/marketing systems.
• Approved data paths: restrict exports from production to only sanctioned destinations (for example, security logging systems or support tooling with defined retention).
• Environment controls: block use of production PII in dev/test unless a documented exception exists with compensating controls.
• Audit logging for PII access, exports, and privileged support sessions.

5) Control sub-processors and tooling that can become “own purpose” channels

• Inventory third parties that receive customer PII (ticketing, CRM, observability, analytics).
• Ensure contracts and configurations prohibit their secondary use of your customers’ PII.
• Validate that integrations do not send unnecessary identifiers (minimize data fields).

6) Train teams on the real failure modes

Target training to roles that most often create violations:

• Support engineers: what they can access, when, and how to document customer-authorized access.
• Product/analytics: what constitutes prohibited repurposing, how to use aggregation or de-identification.
• Marketing/sales ops: hard rule against using tenant-derived PII lists.

7) Monitor, test, and prove it

• Monitor for suspicious data movement (exports, bulk downloads, unusual queries).
• Run periodic access reviews for roles that can reach customer PII.
• Test by sampling recent support cases and data exports to confirm purpose and authorization were documented.

Required evidence and artifacts to retain

Auditors will expect proof that the rule is real, enforced, and repeatable.

Minimum evidence set:

• Data Use / Privacy Policy (internal) stating permitted vs prohibited purposes.
• Customer contract language (MSA/DPA clauses) stating non-use for provider purposes. ¹
• Data inventory / data map covering where customer PII resides, flows, and is exported.
• Sub-processor inventory plus contract terms addressing secondary use and confidentiality.
• Access control evidence: role definitions, approvals, access review records.
• Audit logs showing access to PII and exports, with retention aligned to your assurance needs.
• Change records for new processing activities (intake forms, risk reviews, approvals).
• Training records for staff with PII access.

Common exam/audit questions and hangups

Auditors and customer assessors tend to press on a few predictable points:

1. “Define ‘own purposes.’ Where is it documented?”
   If you cannot point to a clear definition with examples, they will assume broad internal reuse is possible.

2. “Show me how marketing/analytics are blocked from receiving customer PII.”
   They will want architecture diagrams, data egress controls, and system integrations that prove separation.

3. “How do you ensure sub-processors don’t reuse the PII?”
   Expect requests for sub-processor terms and due diligence artifacts.

4. “Can engineers pull production data into dev/test?”
   This is a common hangup. If the answer is “sometimes,” expect follow-ups on approvals, masking, and logging.

5. “How do you demonstrate compliance with ‘relevant legislation and regulations’?”
   Have a short obligations register that maps applicable privacy requirements to your control set, even if it is high level.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating “improve our services” as a blanket permitted purpose.
  Fix: Define improvement activities that are allowed (for example, aggregated, de-identified metrics) and require explicit review for anything involving identifiable PII.

• Mistake: Allowing support tools to become uncontrolled data lakes.
  Fix: Configure ticketing and attachment handling, restrict exports, and set retention rules.

• Mistake: No control over data exports.
  Fix: Implement approved destinations and alerting on bulk extraction.

• Mistake: Sub-processor sprawl without purpose limits.
  Fix: Maintain a living sub-processor list and gate new tools through privacy/security review before any PII is connected.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, the risk profile is still clear: “own purpose” use can create contract breach exposure, customer trust loss, and failed assurance reviews because the control is explicit in the standard. ¹

Practical 30/60/90-day execution plan

Use phased delivery to get to audit-ready quickly without waiting on perfect tooling.

First 30 days (Immediate stabilization)

• Publish a clear “no provider purpose” policy statement and permitted-purpose definitions.
• Locate all systems where customer PII flows into non-production environments, analytics, CRM, or ticketing.
• Insert contract/DPA language updates into your standard templates for new deals.

Next 60 days (Control implementation)

• Stand up the secondary-use intake/approval gate for new processing.
• Implement or tighten access controls and logging for privileged/support access.
• Reduce PII fields sent to third parties; update configurations and document data minimization.

Next 90 days (Assurance-ready)

• Run access reviews for PII-touching roles and remediate overbroad permissions.
• Perform a sample-based audit of support cases and exports for purpose/authorization evidence.
• Produce an “ISO 27018 18.1.4 evidence pack” folder that includes the artifacts listed above, with current dates and named owners.

Frequently Asked Questions

Does “not use PII for its own purposes” prohibit all analytics?

No. It prohibits repurposing customer PII for provider-benefit activities outside delivering the service. Analytics may be acceptable if it is necessary for service delivery, security, billing, or is customer-authorized and documented. ¹

Can we use customer PII to train internal AI models?

Treat that as “own purpose” unless the customer explicitly agrees and the purpose is contractually documented. If you proceed, route it through a formal intake and ensure minimization, access controls, and logging.

If a customer sends PII in a support ticket, can support staff view it?

Yes, if viewing is necessary to resolve the support issue and you control access, log activity, and restrict reuse. Keep the evidence trail showing the business purpose and access governance.

What evidence will auditors ask for first?

They usually start with contract/DPA language, your internal policy defining permitted vs prohibited purposes, and proof that technical controls prevent data from flowing into marketing/advertising systems. ¹

How do we handle third parties that receive customer PII (sub-processors)?

Maintain an inventory, ensure contracts prohibit secondary use, and minimize the data shared by configuration. Document the review and approval for each new third party connection.

Our product team wants to email tenant admins about new features. Is that “own purpose”?

It can be, if the contact list is derived from customer-tenant PII for marketing. Route this through Legal/Privacy review, confirm the contractual basis and customer expectations, and consider using customer-managed communication channels or opt-in mechanisms.

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