Handling requests

To meet the ISO/IEC 27701 “Handling requests” requirement, you must document and run a repeatable process for receiving, validating, routing, and responding to legitimate PII principal requests within defined timeframes. Operationally, that means a single intake path, identity verification, clear ownership, tracked deadlines, and retained evidence for every request. ¹

Key takeaways:

• Publish and operate documented procedures for PII principal requests, not just a privacy policy statement. ¹
• Define response timeframes, identity verification, and escalation rules, then prove you followed them with audit-ready records. ¹
• Build a workflow that coordinates privacy, security, and system owners, since most requests require data discovery and controlled release. ¹

“Handling requests” is one of the easiest privacy controls to describe and one of the hardest to execute consistently. ISO/IEC 27701 expects more than good intentions: you need defined, documented policies and procedures to handle legitimate requests from PII principals, and those procedures must include response timeframes. ¹

For a CCO, compliance officer, or GRC lead, the practical challenge is operational coordination. A single request can touch customer support intake, privacy triage, identity verification, data discovery across systems, security review, and sometimes third parties that process data on your behalf. If you cannot show a clean chain from receipt to closure, auditors will treat the program as ad hoc even if you “usually respond.”

This requirement page translates the clause into a working process you can implement quickly: roles and routing, minimum procedure content, what evidence to keep, and where teams get stuck in audits. The goal is simple: any legitimate request should move through your organization predictably, within your stated timeframe, with consistent outcomes and defensible records. ¹

Regulatory text

ISO/IEC 27701 requires that “The organization shall define and document policies and procedures for handling and responding to legitimate requests from PII principals, including response timeframes.” ¹

What the operator must do: create written, approved documentation that explains (1) how requests are received and authenticated, (2) how you decide whether a request is legitimate, (3) how you route and fulfill it, (4) how you track deadlines, and (5) how you respond and record closure. The standard is assessing both documentation and execution: auditors will compare your procedure to real request tickets and outputs. ¹

Plain-English interpretation (what “handling requests” means)

You need a “front door” and a “factory line” for PII principal requests.

• Front door: people know where to submit requests; staff recognize requests that arrive via email, support tickets, or mail; and you log them in one system of record.
• Factory line: you verify identity, classify the request type, assign owners, locate relevant data, apply security and privacy checks, respond within your stated timeframe, and retain proof you did each step.

“Legitimate requests” means you do not have to honor every message. You do need a documented way to validate identity, authority (for agents), and whether the request falls within your policy scope. ¹

Who it applies to (entity and operational context)

Applies to: PII Controllers. ¹

Operationally relevant for teams that:

• collect or determine how customer/employee/end-user personal data is processed
• run customer support, privacy inboxes, complaint handling, or account management channels
• manage enterprise systems that hold personal data (CRM, HRIS, analytics, marketing, support tooling, data warehouses)
• rely on third parties to store or process personal data (because fulfilling requests may require coordinating with those third parties)

If you are a controller with multiple products or business units, treat this as an enterprise process with local fulfillment playbooks. One central policy, multiple system-specific runbooks.

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

1) Define request scope and intake channels

• List the request types you will handle (for example: access, correction, deletion, restriction, portability, objection, consent withdrawal, account closure requests that imply data deletion).
• Define approved intake channels (web form, email alias, postal address, in-product path) and how “non-standard” requests get forwarded to the intake queue.
• Train frontline teams (support, sales, HR) to recognize a request and route it the same day it is received.

Deliverable: “PII Principal Request Handling Procedure” plus an internal quick-reference guide for frontline teams. ¹

2) Set response timeframes and internal SLA checkpoints

ISO/IEC 27701 requires defined response timeframes. ¹

Operationalize this by documenting:

• when the clock starts (receipt vs. validated identity)
• internal checkpoints (triage complete, identity verified, data discovery complete, response drafted, response approved)
• rules for pausing the clock if you need more information from the requester (state your rule and apply it consistently)

Keep the timeframe definition simple and auditable. Auditors will sample request records and test whether your timestamps match your own rule.

3) Implement identity verification and authority checks

Document a verification approach appropriate to the risk of disclosure:

• what identifiers you accept (account login, email verification, known transaction details, signed authorization for agents)
• how you handle mismatches (request more information, deny with rationale, escalate)
• when you require stronger verification (higher-risk data categories or inability to match the requester confidently)

Control objective: prevent unauthorized disclosure of PII while still enabling legitimate requests. ¹

4) Triage and classify the request

Create a triage checklist:

• request type
• requester type (individual, employee, authorized agent)
• systems likely involved
• whether a third party must act (processors, SaaS platforms)
• exceptions or conflicts (legal hold, security investigation, contractual limits) if relevant to your program scope

Then assign an owner and due date in the system of record.

5) Execute data discovery and fulfillment with system owners

Most failures happen here because teams “answer from memory” instead of proving the search.

Minimum operational steps:

• Use a data map or system register to identify where the person’s data resides.
• Assign tasks to system owners to extract, correct, delete, or otherwise act.
• Require system owners to return completion evidence (query output, admin screenshots, export file hash, deletion job ID, or attestation).

If third parties hold relevant data, your procedure should include how you contact them, how you track their completion, and how you reconcile partial responses.

6) Review response for privacy/security before sending

Before releasing data:

• confirm identity verification completed
• check for over-disclosure (data about other individuals, internal-only notes, security-sensitive fields)
• apply secure delivery (encrypted file transfer or in-portal download) per your security standards

7) Respond, close, and retain records

Closeout requirements:

• response sent date
• disposition (fulfilled, partially fulfilled, denied)
• reason codes for denial/partial fulfillment
• links to exported files or storage location (with retention controls)
• lessons learned if it exposed a data mapping gap

A clean closeout record is what makes this requirement “real” in an audit.

Required evidence and artifacts to retain

Keep evidence that proves both design (you documented the process) and operating effectiveness (you followed it).

Policy/procedure artifacts

• Request handling policy and procedure including response timeframes. ¹
• Identity verification standard and escalation matrix. ¹
• Intake channel documentation and staff routing guidance.

Operational records ¹

• intake record with timestamps
• verification steps performed and outcome
• request classification and assigned owner(s)
• system search tasks and completion evidence/attestations
• communications with the requester
• final response package (or a copy/summary) and secure delivery method
• closure approval and reason codes for denials/partial outcomes

Program-level records

• request log register (case list)
• metrics dashboard (volume, aging, backlog, common failure points) without publishing unsupported numbers externally
• periodic QA reviews of closed cases and corrective actions

Tools like Daydream can help by standardizing intake, routing, evidence collection, and audit exports so requests do not live in scattered inboxes and spreadsheets. Keep the process owner accountable for the workflow configuration and the evidence schema.

Common exam/audit questions and hangups

Auditors tend to test this control by sampling closed requests and walking them end-to-end.

Expect questions like:

• “Show me your documented procedure and where response timeframes are defined.” ¹
• “How do you verify identity? Show evidence for these sampled cases.” ¹
• “Where are requests logged? How do you ensure nothing gets lost from email or support channels?”
• “Who approves denials and partial fulfillments?”
• “How do you coordinate with third parties and prove they completed required actions?”
• “Show an example where you escalated a complex request and met your timeframe rule.”

Hangups that cause findings:

• timeframes exist in a policy but are not tracked in tickets
• inconsistent identity verification evidence
• ad hoc searches without repeatable data discovery steps
• missing denial rationales or approvals

Frequent implementation mistakes (and how to avoid them)

1. Multiple intake paths with no consolidation.
   Fix: require forwarding to a single queue and log every request, even if it is denied.

2. No written rule for “clock start.”
   Fix: state the clock rule in the procedure, train to it, and configure the workflow to match.

3. Identity verification is “tribal knowledge.”
   Fix: create a verification checklist and store evidence in the case record.

4. System owners respond by email without proof.
   Fix: require structured task completion with attachments or attestations; reject “done” without evidence.

5. Over-disclosure in access responses.
   Fix: add a privacy/security review step and use standard redaction guidance for mixed data.

Risk implications (why operators care)

Poor request handling creates three practical risks:

• Unauthorized disclosure risk if identity verification is weak.
• Regulatory/audit nonconformance risk if you cannot show documented procedures and adherence to timeframes. ¹
• Operational risk when requests interrupt engineering or support work because there is no standard routing and data map.

Treat this as a controlled workflow with defined ownership and evidence, not an email inbox responsibility.

Practical 30/60/90-day execution plan

First 30 days: establish the minimum auditable process

• Appoint a process owner (usually Privacy or GRC) and define RACI across Support, Security, Legal, and key system owners.
• Draft and approve the request handling procedure with response timeframes, identity verification, and escalation. ¹
• Stand up a single intake mechanism and a system-of-record ticket workflow with required fields.
• Publish internal guidance for frontline routing and run a short training.

By 60 days: make fulfillment consistent across systems

• Build a system register for where PII resides and assign system owners for request tasks.
• Create standard task templates per request type (access export, correction, deletion).
• Implement a QA review on a sample of closed requests and document corrective actions.
• If you use Daydream or similar tooling, configure evidence requirements and audit export formats now.

By 90 days: harden and scale

• Add automation where safe (auto-acknowledgements, identity verification steps, deadline alerts).
• Formalize third-party coordination steps for processors that must act to fulfill requests.
• Add management reporting for backlog and aging, then set operational triggers for escalation.
• Run an internal audit-style walkthrough: pick several requests and verify evidence completeness end-to-end.

Frequently Asked Questions

What counts as a “legitimate request” under ISO/IEC 27701?

ISO/IEC 27701 requires procedures for “legitimate requests” from PII principals, so you need documented criteria to validate identity and authority before acting. Your procedure should explain how you handle incomplete or unverifiable requests. ¹

Do we need a dedicated portal, or is an email inbox enough?

An inbox can work if you still log every request into a tracked system-of-record with ownership, timestamps, and evidence. Audits fail when the inbox is the “system” and actions are not captured consistently. ¹

How specific do response timeframes need to be?

The requirement is that response timeframes are defined and documented. Write a clear rule for when timing starts and how you track it, then enforce it through workflow deadlines and escalation. ¹

What evidence should we keep if we deny a request?

Retain the request, identity verification outcome, the documented reason for denial, and approval/escalation notes according to your procedure. Auditors will look for consistency across denied cases, not just fulfilled ones. ¹

How do we handle requests that require action by third parties?

Your procedure should include steps to notify the relevant third party, track their completion, and retain proof of what they did. Keep the controller’s case record as the single place showing end-to-end fulfillment. ¹

Who should own the process: Legal, Privacy, Security, or Support?

Assign one accountable owner for the procedure, workflow, and audit responses, then delegate fulfillment tasks to system owners and support teams through a RACI. The standard cares that the process is defined, documented, and followed, not which department name appears on the org chart. ¹

Footnotes

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