Obligation to cooperate regarding PII principals' rights

ISO/IEC 27018 Annex A.2.1 requires a public cloud PII processor to give its cloud service customers practical means (tools, features, and support) to help them fulfill PII principals’ rights requests: access, correction, erasure, and portability. You operationalize this by defining a rights-assistance service, mapping where customer PII lives, and proving you can execute customer-authorized actions reliably. ¹

Key takeaways:

• Provide customer-facing mechanisms to support access, correction, erasure, and portability of PII. ¹
• Treat this as an operational capability with defined workflows, roles, and verification, not a contract clause. ¹
• Retain evidence that requests are authenticated, executed across all systems (including backups where applicable), and auditable end-to-end. ¹

This requirement is about “cooperation,” but auditors will test capability. If you process customer PII in a public cloud context, you need to enable your customers (the controllers) to respond to individuals who ask to access, correct, erase, or port their personal data. ISO/IEC 27018 puts the burden on the public cloud PII processor to provide the means, which generally translates into product features, documented procedures, and support processes your customer can trigger and rely on. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to: (1) define what “means” you provide (self-service UI, APIs, tickets, export formats, deletion workflows), (2) ensure those means cover every place customer PII can exist across your service (primary stores, logs, analytics stores, derived datasets), and (3) build evidence that you can execute the actions under customer instruction with appropriate access control and traceability. ¹

This page translates Annex A.2.1 into requirement-level implementation guidance you can put in front of Engineering, Support, and Legal, then audit against.

Regulatory text

Requirement (verbatim): “The public cloud PII processor shall provide the cloud service customer with the means to enable them to fulfil their obligation to facilitate the exercise of PII principals' rights to access, correct, erase, or port their PII.” ¹

Operator interpretation (plain English)

You must give customers practical ways to carry out PII principals’ rights requests for PII you process on their behalf. “Means” is intentionally broad: it can be product controls, documented procedures, APIs, and a support channel. What matters is that your customer can actually complete the rights request lifecycle for data inside your service, using what you provide. ¹

What auditors look for

• Clear customer-facing method to submit/execute requests (UI, API, or support workflow). ¹
• Demonstrated ability to find and act on the relevant PII (access/export, correct, erase). ¹
• Controls that prevent unauthorized rights actions (authentication, authorization, change control, logging). ¹

Who it applies to

In-scope entities

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

In-scope operational contexts (common examples)

• Multi-tenant SaaS platforms storing end-user profiles, communications content, telemetry tied to identifiable users, or account-level identifiers that qualify as PII in the customer’s context. ¹
• Managed services where you administer or operate customer environments containing PII and you can take actions on their instruction. ¹

Out of scope (but commonly confused)

• Requests submitted directly by an individual to you when you have no way to validate they are acting through the customer/controller. The requirement is to enable the customer to fulfill rights obligations, not to bypass the customer’s verification process. ¹

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

1) Define the “rights assistance” service you provide

Document, in customer-facing terms, how a customer can request and complete each right type:

• Access: how to locate and export PII tied to an identifier. ¹
• Correction: how to update inaccurate PII and where corrections propagate. ¹
• Erasure: how deletion works, what systems it covers, and what is excluded. ¹
• Portability: what export formats exist and how the customer obtains them. ¹

Practical control: publish a short “Data Subject Rights Support” page in your customer documentation plus an internal SOP for Support/Engineering. ¹

2) Map where customer PII exists inside your service

Create and maintain a system-by-system data map for customer PII, including:

• Primary production databases
• Search indexes
• Logs/telemetry stores where identifiers appear
• Analytics/warehouse datasets
• Caches and derived datasets that replicate identifiers ¹

This map is the backbone for “means.” If you cannot point to where PII is, you cannot credibly enable access/erasure/portability. ¹

3) Implement request intake and authorization checks

You need a reliable way to confirm the request is authorized by the customer:

• Accept requests through authenticated customer admin roles (preferred), signed API calls, or a support ticket from verified customer contacts.
• Require enough identifiers to locate the data (customer tenant ID plus user ID/email/external reference, depending on your service). ¹

Common operator pattern: treat “rights actions” like privileged admin functions with heightened approval and logging. ¹

4) Build execution workflows for each right type

Implement repeatable workflows with clear handoffs:

Access / Portability

• Query across the mapped systems for the subject identifier.
• Export to a customer-consumable format and deliver via the customer’s secure channel (admin download, API response, encrypted transfer).
• Record what was exported and from which systems for auditability. ¹

Correction

• Update authoritative records.
• Reindex/propagate to dependent stores where needed.
• Record the change event and who authorized it. ¹

Erasure

• Delete or de-identify PII from production stores under customer instruction.
• Trigger downstream deletion for replicated stores (indexes, analytics copies) based on your data map.
• Record completion and any exceptions (for example, data that cannot be immediately removed due to technical constraints you disclose to the customer). ¹

5) Add operational guardrails

Minimum guardrails auditors expect to see:

• Role-based access control for who can run exports, corrections, and deletions.
• Logging of request receipt, authorization, action taken, and completion status.
• Quality checks so exports/deletions are complete across systems in the data map. ¹

6) Prove it works (tabletop + evidence)

Run internal test cases per right type using non-production or dedicated test tenants. Keep the run logs, screenshots, and ticket trails. Auditors accept “proof of capability” when it is repeatable and tied to controlled procedures. ¹

If you manage many third parties in your stack (subprocessors, SaaS tools, managed data platforms), track which of them can block your ability to search/export/delete. Daydream can help you keep that subprocessors inventory, the associated controls, and the request-to-evidence trail in one place so audits do not turn into a document scavenger hunt.

Required evidence and artifacts to retain

Keep artifacts that show both design and execution:

• Customer-facing documentation describing rights support mechanisms (access, correction, erasure, portability). ¹
• Internal SOP/work instructions for Support and Engineering. ¹
• Data map showing systems containing customer PII and owners for each system. ¹
• Access control evidence (role definitions, admin permission model, approval workflow). ¹
• Request logs/tickets and action logs demonstrating completed rights actions (with sensitive data redacted). ¹
• Test records showing repeatable exports/corrections/deletions in controlled conditions. ¹

Common exam/audit questions and hangups

Expect questions like:

• “Show me how a customer requests an export for a specific user and how you deliver it.” ¹
• “What systems are included in your erasure workflow? How do you know you did not miss a copy?” ¹
• “Who can run deletions in production and what approvals are required?” ¹
• “If portability is requested, what format do you provide and what is the customer instruction path?” ¹

Hangups that stall audits:

• No authoritative data map, only tribal knowledge.
• Rights requests handled ad hoc by senior engineers without a controlled workflow.
• Unclear boundary between customer responsibility (identity verification) and processor responsibility (execution in the cloud service). ¹

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating “means” as a contract promise only.
   Fix: Build an actual mechanism (admin console action, API endpoint, or verified support workflow) and test it. ¹

2. Mistake: Erasure that only deletes from the primary database.
   Fix: Tie deletion to the PII data map and include replicated stores (indexes, analytics datasets, logs where feasible under your design). Document exceptions clearly for customers. ¹

3. Mistake: No authorization model for rights actions.
   Fix: Require authenticated customer admin roles or verified contacts; log who requested and approved the action. ¹

4. Mistake: Portability outputs that are unusable.
   Fix: Provide exports that preserve context (field names, timestamps, object relationships) and a short schema guide in your documentation. ¹

Enforcement context and risk implications

ISO/IEC 27018 is a standard, not a regulator. Your risk is commercial and audit-driven: inability to support customer rights requests can fail customer security reviews, delay procurement, trigger contract disputes, and create downstream exposure when your customers are audited and need evidence of processor cooperation. The control also intersects with incident response because rights workflows often require privileged data access and should be governed accordingly. ¹

A practical 30/60/90-day execution plan

No numeric timelines are required to comply; use phases that match your release cadence and risk.

Immediate phase (stabilize expectations)

• Publish customer-facing instructions for requesting access/correction/erasure/portability within your service scope. ¹
• Create an internal intake workflow with authorization checks and a single owning team (often Support + Security/GRC). ¹
• Start an initial PII system map for the highest-risk data stores. ¹

Near-term phase (make it repeatable)

• Implement or refine export and deletion mechanisms that cover the mapped systems.
• Add logging/audit trails and limit who can perform rights actions.
• Run test cases and store evidence packets for each right type. ¹

Ongoing phase (make it resilient)

• Keep the PII data map current as new features ship and new data stores appear.
• Add regression tests or runbooks so rights actions do not break with platform changes.
• Track subprocessors and ensure contracts/operational reality allow you to complete customer-authorized rights actions across the stack. ¹

Frequently Asked Questions

Do we have to accept rights requests directly from individuals?

ISO/IEC 27018 Annex A.2.1 focuses on giving your cloud service customer the means to fulfill PII principals’ rights. Design your workflow so the customer authorizes actions, and route direct individual requests back to the customer unless you have a verified customer instruction path. ¹

What counts as “means” in practice: product features or support tickets?

Either can qualify if the customer can reliably complete access, correction, erasure, and portability for PII you process. Auditors usually prefer repeatable mechanisms with documented steps and logs, whether that is self-service tooling or a controlled support workflow. ¹

How far does “erase” need to go (logs, analytics, backups)?

The requirement is to enable the customer to exercise erasure for PII you process, so you need a defensible scope tied to where PII exists in your service. Maintain a data map, define what your deletion workflow covers, and disclose any technical constraints or exclusions in customer-facing documentation. ¹

We are multi-tenant. How do we avoid exporting the wrong customer’s data?

Build exports around tenant-scoped identifiers and enforce authorization through customer admin roles or verified contacts. Add checks in the workflow to confirm tenant boundaries before you generate an export and record the authorization trail. ¹

Do we need a formal “data portability format”?

ISO/IEC 27018 requires you to provide means for portability, so define a customer-consumable export format and document it. Include enough structure so the customer can interpret fields and relationships without involving engineering each time. ¹

What evidence is most persuasive in an ISO/IEC 27018 audit?

Auditors want to see a repeatable process and proof it works: customer-facing instructions, internal runbooks, access controls, and logs showing completed access/export, correction, and deletion actions under customer authorization. Keep a few redacted request-to-completion evidence packets ready. ¹

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