Obligations to PII principals (processor)

As a PII processor, you must give your customer (the controller) practical, workable means to meet their obligations to PII principals, especially handling data subject rights like access, export, correction, and deletion. Operationalize this by offering documented request intake paths, secure fulfillment workflows, and contractual/technical commitments that make rights handling feasible at your service boundary.

Key takeaways:

• You need “means,” not promises: tools, processes, and support that let customers fulfill PII principal obligations.
• Build DSAR support into your product and operations (APIs, admin tooling, identity checks, deletion semantics, logs).
• Evidence matters: retain runbooks, request logs, processing records, and customer-facing instructions that show repeatable execution.

ISO/IEC 27701 Clause 8.3.1 targets a common failure mode in privacy programs: controllers are accountable to individuals, but processors often hold the data and the operational “keys” to fulfill requests. If your customer cannot access, export, correct, or delete PII held in your systems, they cannot meet their obligations to PII principals, and your service becomes their compliance bottleneck.

This requirement is straightforward in wording and demanding in practice. Auditors and customers will expect you to prove that your organization has engineered and staffed a reliable way to support rights requests and other PII-principal obligations across the full lifecycle: intake, identity verification support, scoped retrieval, secure disclosure, deletion (including downstream systems), and confirmation. They will also look for clarity on where your responsibility ends and where the customer must act.

This page translates the requirement into concrete, requirement-level implementation steps, with the artifacts you should retain and the questions you should be ready to answer in customer due diligence and ISO 27701 audits.

Regulatory text

Text (excerpt): “The organization acting as PII processor shall provide the customer with the appropriate means to comply with their obligations related to PII principals.” (ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management)

Operator interpretation (what you must do)

If you process PII on behalf of a customer, you must enable that customer to meet obligations owed to individuals (PII principals). “Appropriate means” should be interpreted as practical technical and organizational measures that work for your specific service model, including support for data access, export, and deletion (ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management).

Your goal is not to “take over” the customer’s controller obligations. Your goal is to ensure your systems, contracts, and operating model do not prevent compliance and that you can execute your part of the workflow predictably.

Plain-English requirement (processor obligations to PII principals)

You need to be able to tell a customer, in plain terms:

• How they can request PII actions from you (channels, forms, API endpoints, support process).
• What you can do (retrieve, export, delete, rectify, restrict) and what constraints exist (technical limits, immutable logs, legal holds the customer instructs, retention).
• How fast and how safely you will do it (process SLAs you commit to, security checks, approval gates).
• How you prove completion (confirmation, audit logs, export packages, deletion receipts where feasible).

If your product holds PII across microservices, analytics stores, backups, sub-processors, or customer-managed keys, you must still give the customer a workable path to comply. That usually requires careful definitions of “deletion,” “access,” and “export” at your boundary.

Who it applies to

In-scope entities

• Any organization acting as a PII processor for a customer, regardless of industry, if it processes PII under customer instruction (ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management).

In-scope operational contexts

Common scenarios where this requirement becomes real:

• SaaS platforms storing customer end-user data (profiles, identifiers, event logs).
• Managed services providers administering systems containing PII.
• Data processors handling support tickets that include PII.
• Sub-processor chains where you pass PII to other third parties under customer direction.

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

Use the steps below as an implementation checklist you can assign to product, security, privacy, support, and engineering.

1) Define the PII principal obligations you will support

Create a customer-facing matrix that maps request types to your capabilities:

• Access (retrieve PII)
• Export/portability (structured output)
• Rectification (update/correct)
• Deletion (and what “deletion” means in your architecture)
• Restriction/objection support (where applicable to your processing role)

Keep it specific to the PII you process and the services you provide. The requirement explicitly expects “means” that align to these needs (ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management).

2) Establish a single intake path for customer requests

Provide at least one reliable intake path (often more than one):

• Admin console workflow
• Support ticket category with required fields
• API endpoint for DSAR-style actions

Document required inputs (customer identifier, data subject identifier, scope, request type, authorization proof). Make the intake path easy to find in your privacy and support documentation.

3) Implement request authentication and authorization checks

As a processor, you generally act on customer instructions, so your core control is validating:

• The requester is an authorized representative of the customer.
• The request is within the customer’s tenant/scope.
• The request parameters are sufficient to locate records without over-collection.

Add internal checks to prevent cross-tenant access and accidental disclosure. If your service supports direct data subject requests, route them to the customer unless your contract says otherwise.

4) Build repeatable fulfillment workflows (technical + human)

For each request type, maintain a runbook that covers:

• Systems of record to query
• Data mapping logic (identifiers, joins, canonical IDs)
• Export format and secure delivery method
• Deletion mechanics (hard delete, soft delete, tombstoning)
• Propagation to sub-processors (if you engage them for the service)

This is where most teams fail: they have a policy, but no deterministic workflow that engineering and support can run without improvisation.

5) Define deletion semantics and limitations upfront

Customers will ask: “Is it deleted everywhere?” You need an honest, documented answer:

• What gets deleted immediately (primary stores)
• What is de-identified vs deleted (analytics)
• How you handle backups and logs
• How long residual copies may persist based on your architecture and retention controls

Even without publishing time-bound claims, be explicit about which data stores are covered and what evidence you provide after execution.

6) Provide customer instructions and enablement materials

“Appropriate means” includes organizational support, not only tooling:

• Customer-facing DSAR guide (how-to steps)
• Data schema or export field dictionary
• Contact points for escalations
• Any prerequisites (customer must supply user ID, must verify identity, must confirm scope)

Make these materials part of onboarding for customers likely to receive frequent requests.

7) Track every request end-to-end and retain proof

You need operational traceability:

• Intake timestamp, request type, scope
• Approvals and authorization checks performed
• Actions taken (queries run, deletion jobs triggered)
• Outcome and customer confirmation
• Exceptions (unable to locate data, ambiguous identifiers, conflicting instructions)

8) Test and rehearse

Run internal tabletop tests using realistic cases:

• Access request for a user with multiple identifiers
• Deletion request with downstream sub-processor propagation
• Export request with large datasets and secure transfer constraints

Testing is how you find hidden PII stores and broken joins before a customer’s audit finds them.

9) Contractual alignment (make “means” enforceable)

Ensure your data processing terms describe:

• Supported request types and cooperation obligations
• The customer instruction process
• Sub-processor cooperation model
• Evidence you provide after completion

ISO 27701 is not a contract standard, but auditors and customers will expect your commitments to match your operational reality (ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management).

Required evidence and artifacts to retain

Auditors and customer assessors typically want evidence that the “means” exist, are used, and are controlled.

Retain:

• Customer-facing DSAR/rights support guide (versioned)
• Internal runbooks per request type (access/export/deletion/rectification)
• System data map: where customer PII is stored and how it is indexed
• Request logs (ticketing system records, API logs, case management records)
• Approval and access control evidence for staff performing fulfillment
• Sub-processor instruction procedure (how you pass deletion/access instructions downstream)
• Sample redacted request packets (inputs, outputs, confirmation)
• Exception handling records (cannot fulfill, partial fulfillment, ambiguity resolution)

If you use a platform like Daydream to manage third-party due diligence and evidence collection, store these artifacts as standardized evidence packages so customer requests and audits do not trigger a scramble across support, engineering, and legal.

Common exam/audit questions and hangups

Expect these questions in ISO 27701 audits and customer security reviews:

• “Show me how a customer requests deletion and how you execute it end-to-end.”
• “What data sources are in scope for access/export? How do you ensure completeness?”
• “How do you prevent a customer admin from requesting data outside their tenant?”
• “What happens in backups, logs, and analytics stores after deletion?”
• “Which sub-processors receive PII, and how do you flow down requests?”
• “Provide evidence from a recent request, with sensitive details redacted.”

Hangups that trigger findings:

• No written definition of deletion semantics.
• Manual fulfillment with no quality checks or peer review.
• No way to demonstrate sub-processor cooperation.
• Export format is ad hoc, inconsistent, or insecurely transmitted.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating DSAR support as a support-only process.
   Fix: Make it a cross-functional workflow with engineering-owned data mapping and automation where possible.

2. Mistake: Building an export that leaks internal or cross-tenant data.
   Fix: Use tenant-scoped queries, test with adversarial identifiers, and require review for edge cases.

3. Mistake: “Delete” means UI removal only.
   Fix: Document and implement deletion across primary stores and downstream processors. If some stores cannot be fully purged (for example, immutable logs), document the limitation and provide an alternative such as de-identification where consistent with your design and customer instructions.

4. Mistake: No customer documentation, only internal procedures.
   Fix: Publish a concise customer guide. Customers need a clear path to invoke your support.

5. Mistake: No retained proof of completion.
   Fix: Standardize closure notes and keep machine logs tied to the case ID.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat enforcement risk here as customer-driven and audit-driven. In practice, failures show up as:

• Lost deals due to privacy/security questionnaires
• Contract breaches of assistance/cooperation clauses
• Audit findings under ISO 27701 programs when “means” are undocumented or untested

The business risk is concentrated in high-volume request environments (consumer apps, HR systems, identity platforms) and in architectures with many data stores and sub-processors.

Practical execution plan (30/60/90)

Use this as an operator plan to get from “we think we can” to “we can prove it,” without making time-bound claims to customers.

First 30 days (stabilize and document)

• Assign an owner for “PII principal obligations support” under your privacy program.
• Inventory request types you will support (access/export/deletion at minimum, per your service scope).
• Draft customer-facing instructions for how to submit requests.
• Write internal runbooks for each request type, even if the steps are manual today.
• Identify all PII data stores and sub-processors involved in fulfillment.

By 60 days (make it repeatable and controlled)

• Implement authorization checks and standardized request intake fields.
• Add case tracking with consistent closure evidence (logs, exports, deletion job IDs).
• Define deletion semantics and communicate them in customer materials.
• Train support and engineering on the runbooks and escalation paths.
• Run internal tests using realistic scenarios and capture results as evidence.

By 90 days (scale and harden)

• Automate frequent actions (self-serve export, admin-driven deletion, API-based retrieval) where risk and volume justify it.
• Add QA steps for edge cases (large exports, ambiguous identifiers, multi-system propagation).
• Operationalize sub-processor request flow-down and proof collection.
• Package your evidence for customer due diligence (Daydream-style evidence binder: guides, runbooks, logs, sub-processor process).

Frequently Asked Questions

Do we have to accept requests directly from data subjects (PII principals) as a processor?

ISO 27701 Clause 8.3.1 focuses on giving your customer the means to meet their obligations to PII principals, not on you running a direct consumer intake channel. If you do receive direct requests, define a documented path to route them to the customer unless your contract requires you to handle them.

What does “appropriate means” look like for a SaaS product?

Provide a documented intake route plus product/admin features or support workflows that allow access, export, and deletion of PII in-scope for your service. The “means” should be usable without bespoke engineering per request (ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management).

How do we handle deletion when backups exist?

Document what deletion does in primary systems and how backups are handled in your architecture and retention model. Provide customers a clear explanation of residual storage and what controls prevent restored backups from reintroducing deleted PII into active systems.

What evidence should we give customers after we complete a request?

Give a confirmation record tied to a case ID, plus export files for access/portability requests and a completion statement for deletion/rectification. Internally, retain logs and job identifiers that prove what was executed.

We use sub-processors. Do we need to pass rights requests to them?

If sub-processors store or process the customer’s PII needed to fulfill the request, your “means” must include an operational way to flow instructions down and track completion. Keep a procedure and execution records that show this is repeatable.

Our customer wants an API for DSAR actions. Is a manual process acceptable?

ISO 27701 does not mandate an API, but it does require “appropriate means” that work for your customers and your service model (ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management). If volume or enterprise expectations make manual handling unreliable, prioritize an API or admin tooling and document interim controls.