What does control A.1.3.10 require?
The organisation shall define and document policies and procedures for handling and responding to legitimate requests from PII principals.
This control sits within the Obligations to PII principals objective (A.1.3). It is the operational control that underpins all the individual rights controls: consent withdrawal, objection, access, correction and erasure, providing copies and third-party notification. Without a well-defined request handling framework, individual rights become theoretical rather than practical.
What does the implementation guidance say?
Annex B (section B.1.3.10) provides guidance on building a comprehensive request handling framework:
- Timeframes for response — Define clear deadlines for acknowledging and completing requests, aligned with applicable legal requirements (e.g. one month under GDPR, with possible two-month extension for complex requests)
- Verification procedures — Establish proportionate procedures for verifying the identity of the requester before processing the request
- Escalation paths — Define who handles routine requests, when and how requests are escalated (e.g. complex requests, requests involving sensitive data, requests where exemptions may apply)
- Logging of requests and outcomes — Maintain a comprehensive log of all requests received, including dates, types, decisions, completion dates and any exemptions applied
- Self-service options — Consider providing self-service mechanisms (online portals, preference centres) that allow PII principals to exercise certain rights without needing to submit a formal request
- Staff training — Train all relevant staff on the request handling procedures, including how to recognise a valid request, how to verify identity, and how to use the request management system
- See also A.1.3.3: Determining Information for PII Principals for related requirements
- See also A.1.3.4: Providing Information to PII Principals for related requirements
The guidance emphasises that request handling should not be an ad hoc process. A documented, repeatable procedure ensures consistency, reduces the risk of missed deadlines and provides the evidence trail that auditors expect.
How does this map to GDPR?
Control A.1.3.10 maps to GDPR Article 12(3-6) and Article 15(1)(a-h):
- Article 12(3) — The controller shall provide information on action taken on a request without undue delay and in any event within one month of receipt. The period may be extended by two further months where necessary, with the controller informing the data subject within one month
- Article 12(4) — If the controller does not take action on the request, it shall inform the data subject without delay and at the latest within one month, of the reasons and the right to lodge a complaint
- Article 12(5) — Information and actions taken shall be provided free of charge. Where requests are manifestly unfounded or excessive, the controller may charge a reasonable fee or refuse to act
- Article 12(6) — Where the controller has reasonable doubts about the identity of the requester, it may request additional information
- Article 15(1)(a-h) — The specific information that must be provided in response to an access request
GDPR Article 12 is the procedural framework that governs how all data subject rights are exercised. Getting this right is essential for compliant operations.
How does this relate to ISO 29100 privacy principles?
This control supports two ISO 29100 privacy principles:
- Individual participation and access — Effective request handling is the mechanism through which individuals exercise their participation rights
- Accountability — Documented procedures, logging and training demonstrate that the organisation takes its obligations seriously and can evidence compliance
Get started easily with a personal product demo
One of our onboarding specialists will walk you through our platform to help you get started with confidence.
What evidence do auditors expect?
When assessing compliance with A.1.3.10, auditors will typically look for:
- Request handling policy — A comprehensive, documented policy covering all request types, timeframes, roles, escalation criteria and exemptions
- Standard operating procedures — Step-by-step procedures for each request type (access, rectification, erasure, portability, objection, consent withdrawal)
- Request register — A maintained log of all requests with dates, types, assigned handler, status, completion date and outcome
- Performance metrics — Data showing average response times, completion rates within deadline, and any breaches of timeframes with root cause analysis
- Identity verification procedures — Documented and proportionate verification steps for each channel through which requests are received
- Training records — Evidence that staff handling requests have been trained and that training is refreshed regularly
- Response templates — Standardised templates for acknowledgement, fulfilment, partial fulfilment and refusal, ensuring consistent and legally sound communication
What are the related controls?
| Control | Relationship |
|---|---|
| A.1.3.2 Obligations to PII principals | Identifies the rights; A.1.3.10 provides the operational framework for fulfilling them |
| A.1.3.7 Access, correction or erasure | The most common request types that the handling framework must support |
| A.1.3.9 Providing copy of PII processed | Copy and portability requests are handled within this framework |
| A.1.3.5 Modify or withdraw consent | Consent withdrawal requests are handled within this framework |
| A.1.3.6 Object to PII processing | Objection requests are handled within this framework |
| A.1.3.8 Obligations to inform third parties | Third-party notification is a downstream step in the request handling workflow |
What changed from ISO 27701:2019?
For a step-by-step approach, see the Transition from 2019 to 2025.
In the 2019 edition, this requirement was part of Clause 7.3.9 (Handling requests). The 2025 edition gives this its own control number (A.1.3.10) with dedicated guidance in B.1.3.10. The core requirements are substantively the same, but the 2025 edition places greater emphasis on self-service options and staff training as components of an effective handling framework. The structured format also makes it easier to audit this control independently. See the Annex F correspondence table for the full mapping.
Free yourself from a mountain of spreadsheets
Embed, expand and scale your compliance, without the mess. IO gives you the resilience and confidence to grow securely.
Why choose ISMS.online for data subject request handling?
ISMS.online provides a complete request management system built for privacy compliance:
- Centralised request portal — A single intake point for all PII principal requests, with automatic categorisation by request type and assignment to the right team member
- Deadline management — Automated deadline calculation based on the applicable jurisdiction, with escalation alerts as deadlines approach and overdue notifications if they pass
- Identity verification workflow — Built-in verification steps that can be configured by request type and risk level, ensuring proportionate checks without creating friction
- End-to-end audit trail — Every action taken on a request is logged with timestamps, from initial receipt through to final response, creating the evidence base auditors require
- Performance dashboard — Real-time metrics on request volumes, response times, completion rates and trends, helping you identify operational bottlenecks and demonstrate continuous improvement
- Self-service integration — Provide PII principals with self-service options for common requests (consent management, preference updates), reducing the volume of formal requests your team must handle
FAQs
What makes a request “manifestly unfounded or excessive”?
Under GDPR, a request may be manifestly unfounded if the individual clearly has no intention of exercising their rights (for example, making the request purely to cause disruption). A request may be excessive if it is repetitive, for example requesting access to the same data multiple times within a short period without any change in circumstances. The burden of proof is on the controller to demonstrate the request is unfounded or excessive. This threshold is deliberately high, and most genuine requests should be fulfilled.
How should you handle verbal or informal requests?
A valid data subject request does not need to be made in writing or use specific language. Staff should be trained to recognise when a verbal enquiry or email constitutes a valid request. Best practice is to log the request immediately in your tracking system and follow the same procedure as for formal requests. If identity verification is needed, explain this to the individual and guide them through the process. The deadline begins from the date the request is received, not from when identity is verified.
What should you do when a request involves multiple rights?
A single communication from a PII principal may contain multiple requests (for example, access to their data and erasure of certain records). Each element should be logged and tracked separately, as different timeframes, exemptions or procedures may apply. However, the response can be consolidated into a single communication to the individual. Where one element depends on another (for example, providing access before erasure so the individual can verify the data), manage the sequence accordingly.
