Restriction on secondary use of customer PII

The restriction on secondary use of customer PII requirement means you may only process a customer’s PII for the specific purposes you agreed to in contract (and any documented instructions), and you must prevent internal teams or third parties from repurposing that PII for analytics, product improvement, marketing, or any other non-approved use. Operationalize it by locking “purpose” into your data inventory, access controls, and monitoring, then proving compliance with auditable evidence.

Key takeaways:

• Tie every PII dataset to an approved purpose and prohibit all other uses by default.
• Enforce purpose limitation with technical controls (access, segmentation, logging) plus contract and process controls (DPAs, change control).
• Keep examiner-ready artifacts: purpose maps, approvals, access reviews, and monitoring results.

For cloud services and other environments where you process customer PII, “secondary use” risk shows up in ordinary work: engineers pulling production data into test tools, product teams training models on customer content, support exporting logs for troubleshooting, or a subcontractor retaining data “for service improvement.” Each of those can breach the processing scope you promised to the customer, even if the data never leaves your systems.

ISO/IEC 27018 is built for public cloud PII processors and focuses heavily on customer control, transparency, and purpose limitation. The restriction on secondary use of customer PII requirement is straightforward in concept but easy to fail in practice because most organizations manage access by role, not by purpose, and most data platforms are designed for reuse.

This page translates the requirement into an operator checklist: define allowed purposes, bind them to datasets, make non-approved reuse technically difficult, and maintain evidence that your controls actually run. The goal is audit-ready execution: you should be able to show, quickly, where customer PII lives, why you have it, who can touch it, and how you prevent repurposing outside agreed scope.

Requirement: Restriction on secondary use of customer PII (ISO 27018)

Plain-English interpretation: If you are processing customer PII, you can’t repurpose it for any other reason than the processing purposes you agreed with the customer (and any documented customer instructions). If a new purpose arises, you need customer authorization and you must update the relevant contractual and operational documentation before processing.

This is the “purpose limitation” control, implemented as a hard operational rule: no new purpose without approval.

Regulatory text

Provided excerpt (framework summary): “Baseline implementation-intent summary derived from publicly available framework overviews; licensed standard text is not reproduced in this record.” The requirement intent for ISO27018-07 is: “Prevent use of customer PII for purposes outside agreed processing scope.” ¹

What the operator must do:

1. Define and document the “agreed processing scope” per customer (or per service line where terms are standardized).
2. Ensure the actual processing of PII stays inside that scope across the full lifecycle: collection, access, analysis, sharing, storage, and deletion.
3. Put controls in place that block or detect secondary use (technical + procedural).
4. Retain evidence that you enforce the restriction, not just state it. ¹

Who it applies to (entity and operational context)

This requirement primarily applies to organizations acting as cloud PII processors, meaning you process PII on behalf of a customer (the customer is typically the controller) under contract and instructions. ¹

Operationally, it applies anywhere customer PII can be touched or transformed, including:

• Production application databases and object stores
• Logs, telemetry, and traces that contain identifiers
• Customer support tooling (ticket attachments, call recordings, screenshots)
• Data warehouses, BI tools, and customer success analytics
• ML/AI training, prompt logs, and evaluation datasets
• Subprocessors and managed service providers that can access customer environments

If you are both a controller for your own user accounts and a processor for enterprise customers, scope the control to the processor side first (customer-provided or customer-derived PII processed on their behalf), then harmonize across your broader privacy program.

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

Use this as an execution runbook for the restriction on secondary use of customer PII requirement.

Step 1: Define “allowed purposes” in a purpose register

Create a short, controlled list of permitted purposes that match your customer agreements. Typical buckets (adapt to your contracts):

• Provide the contracted service (core processing)
• Security (fraud detection, abuse prevention, incident response)
• Support and troubleshooting (case-bound)
• Legal or compliance obligations (where applicable and contractually addressed)

Rule: If it’s not in the purpose register, it’s prohibited for customer PII until explicitly approved.

Artifact: Purpose Register (owner, definition, examples, prohibited examples, approval authority).

Step 2: Map customer PII to purpose, system, and customer contract terms

Build or update your data inventory so each dataset containing customer PII includes:

• Data category and fields (identifiers, contact data, content, logs)
• System of record + downstream copies
• Customer or service line it relates to
• Approved purpose(s) from the register
• Retention and deletion triggers
• Allowed disclosures (including subprocessors)

You are aiming for a purpose-to-data map that lets you answer: “Where is PII used for support?” and “Which datasets may never be used for analytics?”

Artifact: Data Inventory entries with “Purpose” and “Source of authorization” fields (contract clause, DPA, customer instruction).

Step 3: Turn “purpose” into access boundaries

Policies don’t stop secondary use; access pathways do. Implement at least these controls:

• Environment separation: Keep production PII out of dev/test by default; require documented exception approval for any real-data testing.
• Role + purpose-based access: For sensitive datasets, restrict access to teams whose function matches the allowed purpose (support, security).
• Time-bound support access: Grant elevated access through a ticketed workflow with automatic expiration.
• Export controls: Restrict bulk export and external sharing; require approvals and logging for extracts containing customer PII.
• Subprocessor constraints: Ensure subprocessors can only process for the same allowed purposes; block onward use in contractual terms and technical integration patterns.

Artifacts: Access control standards, IAM group-to-purpose mapping, and ticket templates for just-in-time access.

Step 4: Put “secondary use” checks into change management

Most secondary use enters through “reasonable-sounding” new initiatives: product analytics, quality improvement, AI training, new detection pipelines.

Implement a PII Purpose Change Gate in your SDLC or governance flow:

• Any new use case that touches customer PII must state the purpose, dataset, and customer authorization basis.
• Privacy/compliance review must explicitly answer: “Is this within the agreed processing scope?”
• If not within scope, route to: customer approval + contract/DPA update + customer-facing notice if required by your agreements.

Artifacts: DPIA/PIA template section for “Purpose and scope,” change tickets with approvals, and release checklists.

Step 5: Detect and investigate secondary use signals

You need operational detection, not just preventative controls. Focus monitoring where violations occur:

• Data warehouse ingestion from production PII sources
• Large extracts or unusual query patterns
• New service accounts accessing PII stores
• PII showing up in non-approved platforms (feature stores, experimentation tools)

Define an investigation playbook:

• Triage: which dataset, which purpose tag, who accessed, what was done
• Containment: revoke access, stop pipelines
• Customer impact analysis: whether processing exceeded scope
• Corrective actions: update controls, retrain, discipline as needed

Artifacts: Monitoring rules (or queries), investigation tickets, post-incident reviews tied to purpose limitation.

Step 6: Contract and customer-instruction alignment

Secondary use restrictions fail if the contract is vague. Align customer terms to your purpose register:

• DPAs and subprocessing terms should define permitted processing purposes.
• If you offer “service improvement,” define it narrowly or exclude customer PII unless explicitly agreed.
• Document customer instructions that expand scope and store them with the data inventory record.

Artifacts: Standard DPA language library, subprocessor DPAs, customer instruction repository.

Required evidence and artifacts to retain (audit-ready)

Maintain a tight evidence set that maps directly to how you prevent secondary use:

Evidence	What it proves	Owner
Purpose Register	Defined allowed purposes; default deny for new purposes	Privacy/GRC
Data inventory with purpose tags	Every PII dataset has an approved purpose and authorization source	Data governance
Access control matrix (system → groups → purpose)	Only appropriate teams can access PII for allowed purposes	Security/IAM
JIT access tickets + approvals	Support/security access is controlled and time-bounded	Support/SecOps
Change management records for new PII use cases	Secondary use is reviewed and blocked without approval	Eng/GRC
Logs/alerts and investigation tickets	You detect and respond to out-of-scope processing	SecOps
Subprocessor agreements and access restrictions	Third parties are bound to the same scope	Procurement/Legal

Tip for speed: store these artifacts in a single “Purpose Limitation / Secondary Use” evidence folder with a quarterly export.

Common exam/audit questions and hangups

Expect these questions from auditors, customers, and ISO assessors:

1. “Show me where customer PII is used for analytics or model training.” Hangup: teams treat “internal analytics” as harmless. Your answer must tie back to allowed purposes and customer agreement scope.
2. “How do you prevent engineers from copying production data into test?” Hangup: ad hoc exceptions without approvals and expiry.
3. “Which subprocessors can access customer PII, and for what purposes?” Hangup: subprocessor lists exist, but purpose constraints are not explicit.
4. “How do you handle a new feature that needs customer PII?” Hangup: product launches ahead of privacy review.
5. “Prove it works.” Hangup: a policy without evidence of access reviews, monitoring, and investigations.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Purpose defined only in a policy. Fix: embed purpose into the data inventory and access groups; auditors want operational linkage.
• Mistake: Broad “service improvement” language becomes a blank check. Fix: define the purpose narrowly and document which datasets are excluded unless a customer opts in.
• Mistake: One-time access reviews. Fix: run recurring reviews for PII systems and keep the completed review outputs.
• Mistake: Assuming de-identification without validation. Fix: treat data as customer PII unless you can show it no longer qualifies under your internal standard and contractual commitments.
• Mistake: Subprocessors addressed only by procurement. Fix: make purpose limitation a standard subprocessor control requirement and confirm it in onboarding and periodic reviews.

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 actions. Practically, secondary use creates three high-probability risk paths:

• Contractual breach risk: processing beyond agreed scope can trigger customer claims, termination rights, or audit findings.
• Regulatory spillover: ISO 27018 purpose limitation aligns with privacy principles found in many privacy regimes; a scope breach can compound notification and reporting obligations depending on facts and jurisdiction.
• Security exposure: secondary use often increases data movement and copies, which expands breach surface area.

Practical 30/60/90-day execution plan

This plan assumes you have a working security program and need to operationalize the restriction on secondary use of customer PII requirement quickly.

Days 0–30: Establish scope and control points

• Stand up the Purpose Register and get Legal/Privacy approval.
• Identify your top PII systems (production DBs, logs, support tooling, warehouse).
• Add “purpose” and “authorization source” fields to the data inventory for those systems.
• Implement a hard rule: production data exports require a ticket, approval, and logging.

Days 31–60: Enforce access boundaries and governance gates

• Map IAM groups to allowed purposes for each top PII system.
• Implement just-in-time access for support/security where feasible.
• Add a PII Purpose Change Gate to your SDLC (PIA/DPIA or equivalent) and require it for new pipelines/features touching customer PII.
• Update subprocessor onboarding to require purpose limitation commitments and evidence.

Days 61–90: Monitoring, evidence, and audit readiness

• Deploy monitoring queries/alerts for bulk exports and new ingestion into analytics/AI platforms.
• Run a first access review on the top PII systems and remediate exceptions.
• Conduct a tabletop: “Product team requests customer PII for model training.” Verify the gate blocks it without approval.
• Package evidence in a single repository and write an auditor-facing narrative: purpose register → inventory → access controls → monitoring → response.

Daydream fit (practical, not theoretical): many teams struggle to keep purpose tags, customer instructions, subprocessors, and evidence in sync. Daydream can act as the system of record for control implementation status, evidence collection, and audit-ready narratives across third-party and data processing obligations, so secondary use restrictions don’t live in scattered docs.

Frequently Asked Questions

Does “secondary use” include internal product analytics?

Yes if the analytics purpose is not within the agreed processing scope for the customer PII at issue. Treat product analytics as prohibited by default unless your contract/DPA and customer instructions explicitly allow it and your inventory and access controls reflect that.

Can we use customer PII to train AI models for “service improvement”?

Only if that use is inside the agreed processing scope and you can point to the customer authorization basis. If your agreements do not clearly allow it, route through the purpose change gate and obtain explicit approval before processing.

What about troubleshooting logs that contain identifiers?

Logs are often the highest-risk “accidental” dataset for secondary use because they flow into analytics platforms. Tag log pipelines with allowed purposes, restrict who can query raw logs, and monitor for new downstream destinations.

If data is pseudonymized, is secondary use allowed?

Pseudonymization usually does not remove the obligation if the data still relates to an individual and can be linked back under your controls. Treat it as customer PII unless your internal standard and customer commitments say otherwise.

How do we enforce this with subprocessors?

Bind them contractually to the same permitted purposes, limit the data you share, and restrict their access path (scoped credentials, network restrictions, and logging). Keep onboarding and periodic review evidence that they follow those constraints.

What’s the minimum evidence auditors expect?

Auditors typically want a purpose definition, a map of PII datasets to purposes, proof that access aligns to those purposes, and proof you detect and investigate exceptions. A written policy alone usually fails.

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