Customer obligations

ISO/IEC 27701 Clause 8.2.5 requires you, as a PII processor, to help your customer (the controller) meet their obligations to respond to PII principal rights requests. Operationally, you need a defined, testable workflow and contractual commitments so customers can reliably request access, correction, erasure, and portability actions you perform on their behalf. ¹

Key takeaways:

• Build a customer-facing rights-request support process with clear intake, verification, execution, and confirmation steps.
• Make assistance enforceable via contract terms, SLAs, and a named contact path (ticketing or portal), not informal email threads.
• Keep evidence: request logs, identity/authority checks, action logs, and customer-facing completion notices.

“Customer obligations” in ISO/IEC 27701 is a processor-side requirement. Your customer owns the legal duty to respond to PII principal rights requests, but you control systems, logs, and data operations the customer needs to fulfill that duty. Clause 8.2.5 makes that dependency explicit: you must assist the customer in responding to requests from PII principals to exercise their rights. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing this requirement is to treat it like a service you deliver consistently: define what request types you support, how customers submit them, how you validate authority, how you execute actions across environments (production, backups, logs, analytics), and how you prove you did it. Auditors tend to focus on whether the process is repeatable, whether responsibilities are clearly split between customer and processor, and whether the evidence trail matches the commitments you made.

This page gives requirement-level implementation guidance you can put into contracts, procedures, and operational runbooks, plus the artifacts to retain for ISO audits and customer due diligence.

Regulatory text

ISO/IEC 27701 Clause 8.2.5 requirement: “The organization shall assist the customer in fulfilling the customer's obligations to respond to requests from PII principals to exercise their rights.” ¹

Plain-English interpretation

If you process PII for customers, you must make it realistically possible for them to answer individual rights requests. Assistance is not a vague promise. It means you have a working way to (a) receive a customer instruction tied to a PII principal request, (b) take the requested action on the data you process, and (c) provide the customer confirmation and supporting details so they can close the request. The typical scope includes access, correction/rectification, erasure/deletion, and portability. ¹

Who it applies to

Entity types

• PII processors: organizations processing PII on behalf of customers (controllers). ¹

Operational context (where this shows up in real life)

You are in scope if any of the following are true:

• You host, store, transmit, transform, analyze, or otherwise handle customer PII in an application or managed service.
• Your customer cannot fully fulfill a rights request without your cooperation (for example, you control deletion tooling, exports, event logs, or identity mappings).
• You use subprocessors that also touch the customer’s PII, which means your assistance must extend through your supply chain (practically, you coordinate and confirm).

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

Below is an operator-grade workflow you can implement in a quarter and then harden.

1) Define “assistance” as a supported service catalog

Create a customer-facing list of request types you support and what you will do for each. Keep it crisp:

• Access: provide PII extracts, categories, and relevant metadata you hold for the customer’s account and the specific PII principal.
• Correction/rectification: update fields, replace records, or apply customer-provided corrected values.
• Erasure/deletion: delete, de-identify, or logically purge records within your systems as applicable.
• Portability: export in a structured format you can generate reliably.

Make the catalog explicit about boundaries: what identifiers are required, what data stores are included, what is excluded (for example, aggregated analytics), and how you handle logs/backups (for example, “removed from active systems; backups expire per retention schedule,” if that is your actual practice). This scope clarity is what prevents ad hoc “yes” commitments from Sales that you cannot evidence later.

2) Put intake on rails (don’t accept free-form email as the primary path)

Stand up a single intake path customers can use repeatedly:

• A ticket form in your support system, or
• A portal workflow, or
• A structured email alias with required fields and automatic ticket creation.

Minimum fields to require:

• Customer account name and authorized requester (role, email domain)
• Request type (access/correct/erase/portability)
• PII principal identifiers you can match (internal user ID, email, phone, device ID, or other)
• Relevant date range (if applicable)
• Any customer-provided authorization confirmation (for example, “PII principal verified by controller”)

3) Verify customer authority and prevent cross-tenant disclosure

Your biggest operational risk is sending one customer another customer’s data, or acting on an instruction from an unauthorized person at the customer.

Controls to implement:

• Maintain an authorized requester list per customer (named admins, escalation contacts).
• Require requests to originate from a known channel (ticket portal + SSO is strongest; otherwise enforce domain allowlisting and secondary verification for changes).
• Add a “four-eyes” check for exports or bulk disclosures when the request is unusual (large scope, new requester, urgent pressure).

4) Map your data so you can actually find it

Most failures happen because teams do not know where the PII is. Build a simple, living “PII location map” for each product/service:

• Primary databases and tables (by logical name)
• Object storage (files, attachments)
• Search indexes
• Caches
• Data warehouse / analytics pipelines
• Application logs and audit logs
• Backups and snapshots
• Subprocessors (who has what)

This map becomes your execution checklist and your evidence backbone.

5) Execute using repeatable runbooks per request type

Create runbooks that an on-call engineer or support specialist can follow without improvising.

Access runbook essentials

• Query by stable identifier(s)
• Export in a controlled format
• Quality check: ensure fields match the requested principal only
• Deliver via secure channel (portal download or encrypted transfer)
• Record what was disclosed and when

Correction runbook essentials

• Validate customer instruction includes corrected values
• Update source-of-truth first, then propagate to derived stores
• Confirm completion and document any fields you cannot change (with reason)

Erasure runbook essentials

• Identify all in-scope stores from the PII location map
• Perform deletion/de-identification steps per store
• Handle derived data: reindex, recompute, or mark as deleted where needed
• Record exceptions (legal hold, retention constraints, technical limits) and provide them to the customer for their response narrative

Portability runbook essentials

• Produce export in a consistent schema
• Include timestamps, field definitions, and context needed for reuse
• Confirm integrity (file hash) if your process supports it

6) Confirm completion back to the customer with the right detail

Close the loop with:

• What action was taken
• What systems were touched (high level)
• What data was produced (for access/portability)
• Any limitations or partial completions and why
• The timestamp and the operator ticket reference

7) Make it contractual and measurable

ISO auditors and customer security teams will ask where this is documented. Ensure your agreements (or addendum) state that you will assist with PII principal rights requests and define:

• Supported request types
• Customer’s responsibilities (verification of the PII principal, lawful basis to instruct)
• Your responsibilities (execution and confirmation)
• Security requirements for transmission
• Subprocessor coordination expectations

8) Test the workflow and treat failures as incidents

Run internal “tabletop” tests and at least one end-to-end dry run per request type. Track defects like any other control gap. If you cannot execute reliably, you are not providing assistance in practice.

Where Daydream fits naturally: if you manage many third parties and complex processor/customer roles, Daydream can centralize customer-request intake evidence, contract obligations, and the artifact trail for audits so you can show assistance was performed consistently without hunting through tickets, chats, and scattered logs.

Required evidence and artifacts to retain

Keep evidence that proves both process and execution:

Governance artifacts

• Rights-request assistance procedure (processor-side)
• Service catalog of supported request types and scope boundaries
• Roles and responsibilities (RACI) for support, security, engineering, and privacy
• Customer contractual language or addendum clauses covering assistance

Operational artifacts ¹

• Intake record (ticket/portal entry) with required fields
• Proof of requester authorization (admin list match, SSO record, secondary verification note)
• Execution logs (queries run, job IDs, deletion confirmations, export generation logs)
• Customer completion notice (what was done, when, limitations)
• Subprocessor coordination records if applicable (tickets/emails/confirmations)
• Exception approvals (legal hold, technical infeasibility) with rationale

Control monitoring artifacts

• Periodic review of authorized requester lists
• Training records for teams handling requests
• Test results from tabletop or dry runs and remediation tickets

Common exam/audit questions and hangups

Expect these lines of inquiry:

• “Show me the documented process for assisting customers with rights requests.” (They want a procedure and ownership.)
• “Provide two examples of completed requests and the evidence trail.” (They want intake → verification → action → confirmation.)
• “How do you prevent unauthorized requests from a customer’s junior employee?” (They want authority checks.)
• “Where is the data located, and how do you ensure deletion covers derived stores?” (They want the data map and runbooks.)
• “How do subprocessors factor into your assistance commitment?” (They want coordination proof.)

Hangups that stall audits:

• You can do deletion in production but have no story for backups/logs.
• Requests are handled in Slack/email with no consistent record.
• Different teams interpret “erasure” differently across products.

Frequent implementation mistakes and how to avoid them

1. No single intake path. Fix: one primary channel with mandatory fields and auto-ticketing.
2. Relying on the customer to “tell you what to delete” without identifier standards. Fix: publish accepted identifiers and matching rules.
3. Overpromising erasure across everything. Fix: document technical limits and align contract language to reality.
4. Exporting data without a cross-tenant safety check. Fix: require authorization verification and add a second review for unusual exports.
5. Ignoring derived data and analytics. Fix: include derived stores in the PII location map and runbooks, or explicitly exclude with clear rationale.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list case examples. Practically, the risk is customer harm and contractual breach when you cannot support rights requests promptly or accurately, plus security exposure if your access/export process discloses the wrong data.

A practical 30/60/90-day execution plan

First 30 days (foundation)

• Assign an owner for customer rights-request assistance (privacy ops, support ops, or GRC with engineering counterpart).
• Draft the service catalog: request types supported, required identifiers, scope boundaries.
• Stand up a single intake path (ticket form/portal) and publish it to customers.
• Create the first version of the PII location map for your top product/service.

By 60 days (make it repeatable)

• Write runbooks for access, correction, erasure, and portability.
• Implement authority verification: authorized requester list per customer and a standard verification checklist.
• Add secure delivery methods for exports (portal download or controlled transfer).
• Update contract templates or customer addendum language to reflect the assistance you can evidence.

By 90 days (make it auditable)

• Run end-to-end tests for each request type and document outcomes.
• Build an evidence packet template (what to attach to each ticket to pass an audit).
• Train support and engineering on the workflow and escalation paths.
• Add basic metrics dashboards (volume, aging, exception reasons) for internal control monitoring.

Frequently Asked Questions

Do we have to accept rights requests directly from PII principals?

Clause 8.2.5 is about assisting your customer in responding to PII principal requests, not running your own direct-to-individual intake. Your safest operating model is to accept instructions from the customer and require the customer to verify the individual. ¹

What rights are in scope for “customer obligations”?

ISO/IEC 27701 expects processors to assist with requests from PII principals to exercise their rights; common examples include access, correction, erasure, and portability. Your service catalog should state which of these you support per product and any technical limits. ¹

How do we handle deletions when we have immutable logs or long-lived backups?

Document exactly what you delete from active systems and what you cannot delete immediately, then communicate those constraints to the customer in the completion note. Align your contractual language and customer guidance to that reality so audits don’t find a promise you can’t prove.

Can we charge customers for assisting with rights requests?

ISO/IEC 27701 Clause 8.2.5 states you must assist; it does not specify commercial terms. If you charge for extraordinary effort, define what counts as extraordinary in the agreement and still keep a standard path for routine requests. ¹

What evidence do auditors usually want to see for this requirement?

They typically ask for a documented procedure plus sample completed requests showing intake, authority checks, execution records, and customer confirmation. If your proof is scattered across email and engineering notes, consolidate it into the ticket as attachments or linked logs.

We use subprocessors. Do we need to involve them in the workflow?

If subprocessors process the relevant PII, your assistance to the customer often depends on coordinating with them and retaining their confirmations. Treat subprocessor coordination as part of your runbook and evidence packet so you can show the customer’s request was fully executed.

Footnotes

1. ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management