A data subject request desk that verifies too little hands personal data to impostors, and one that verifies too much collects passport scans it never needed and slows every lawful request. This template is a ready-to-adapt operating procedure for verifying the identity of people who make access, erasure, correction and portability requests, and of agents who act for them. It sets verification tiers tied to the sensitivity of the data, rules for agents and children, fraud indicators, how long verification data may be kept and what to record. It is written for privacy operations, DPO and customer identity teams working under the UK GDPR, the EU GDPR and the California CCPA regulations. The reasoning behind each control sits in the DSAR Guide: Handling Data Subject Requests; this page is the procedure document itself.
How to use this template
- Replace text in square brackets, such as [Organisation], [Privacy Team] and [Fraud Team], with your own names. Values shown as [X days] are placeholders for you to set; they are not legal minimums.
- "Must" marks a mandatory step; "should" marks a default that a named role may vary with a recorded reason.
- Map each tier in section 6 to your own data inventory before use. The Data Mapping and ROPA Guide helps you label systems by sensitivity.
- Keep jurisdiction-specific rules in section 4 and section 11. If you operate only in one regime, delete the other rows rather than leaving them blank.
- Have your legal team review the adapted procedure. This template summarises regulator guidance and regulations; it is not legal advice.
1. Purpose
1.1 This procedure sets out how [Organisation] confirms that a person making a data subject request, or an agent acting for them, is entitled to the response, using the least additional personal data needed.
1.2 It aims to prevent disclosure, erasure or alteration of personal data at the request of an impostor, while avoiding verification steps that are disproportionate to the request.
2. Scope
2.1 This procedure applies to every request to access, erase, correct, restrict, port or object to the processing of personal data, received through any channel: web form, privacy portal, email, post, telephone, chat, social media or in person.
2.2 It applies to customers, users, employees, former employees, job applicants and any other individual whose data [Organisation] holds, and to requests submitted by authorised agents, solicitors, parents, guardians and request-handling platforms.
2.3 Requests to opt out of sale or sharing under the CCPA must not be subject to identity verification (11 CCR 7060(b)); they are handled under [Opt-out Procedure].
3. Roles and responsibilities
| Role | Responsibility |
|---|---|
| [Privacy Team] request handler | Logs the request, selects the tier, runs the checks, records the outcome |
| [DPO or Privacy Lead] | Owns this procedure, approves tier exceptions, decides refusals for inability to verify |
| [Fraud Team] | Reviews requests that trigger fraud indicators in section 9 |
| [Customer Identity Team] | Provides step-up authentication and one-time code services used for verification |
| [HR] or [Legal] | Verifies employee requests and agent authority where documents are involved |
4. Principles
4.1 Ask only on reasonable doubt. Under GDPR Article 12(6), additional information may be requested only where there are reasonable doubts about the requester's identity. The EDPB states that the controller cannot request more personal data than is necessary to enable authentication (Guidelines 01/2022, para. 65).
4.2 Match, do not collect. Verify by matching information the requester provides against data [Organisation] already holds (11 CCR 7060(c)(1)). Avoid requesting additional information for verification (11 CCR 7060(d)).
4.3 Reuse existing authentication. Where the requester has an account, a current authenticated session is the default check. The EDPB considers the login normally sufficient and a copy of an identity document disproportionate in that case (para. 73). Under 11 CCR 7061(a), require re-authentication before deleting, correcting or disclosing data.
4.4 Scale to sensitivity. Weigh the type, sensitivity and value of the data and the harm that wrongful disclosure or deletion would cause (11 CCR 7060(c)(3); EDPB para. 70).
4.5 No fee for verification. The requester and their agent must not be charged for verification (11 CCR 7060(e)).
4.6 Identity documents are a last resort. The EDPB says an ID copy should generally not be considered an appropriate way of authentication (para. 75). Request one only where sections 6.3 or 7 require it and no lower-impact method works.
5. Intake and channel check
5.1 Log every request within [1 working day] with: request type, channel, date received, contact details given, and whether those details match a record held.
5.2 Treat a request as effective even if it arrives through a channel other than the preferred one (EDPB para. 53), and route it to the request log.
5.3 Record whether the contact detail in the request differs from the one on file. All codes and responses go to the contact detail on file, never to a new one supplied only in the request.
5.4 Start the response clock in line with the applicable rule. The ICO states that the UK timescale does not begin until the requested identity information has been received; under the CCPA, record the date the request was received. Record both dates.
6. Verification tiers
6.1 Select the tier from the most sensitive data in scope of the request, not from the request type alone.
| Tier | When it applies | Required check | Approved by |
|---|---|---|---|
| T0: none | CCPA opt-out of sale or sharing; general privacy enquiries with no data disclosed | No identity check | Handler |
| T1: standard | Account holder, or non-account data of low sensitivity such as marketing preferences or categories of data | Authenticated session with re-authentication, or match at least two data points held, plus a one-time code to the contact on file | Handler |
| T2: elevated | Specific pieces of personal data, erasure of an active account, or any data with financial value | Re-authentication with [step-up MFA], or match at least three pieces of data held plus a one-time code; for CCPA non-account holders add a signed declaration under penalty of perjury | Handler, second-person check |
| T3: high | Special category or sensitive data (health, biometrics, precise location, government identifiers, financial account data) for a requester with no account or with failed T2 checks | T2 plus a check against non-public data held, or documentary verification under 6.3 | [DPO or Privacy Lead] |
6.2 The two and three data point levels follow 11 CCR 7062(b) and (c), which describe a "reasonable degree" and a "reasonably high degree" of certainty for non-account holders. For GDPR requests, use them as a proportionate default, not a fixed rule.
6.3 Where a document is unavoidable: ask for the minimum fields (the EDPB gives name, issuing authority, and date of issue or expiry as generally sufficient, para. 76), tell the requester which fields they may redact (para. 77), view it through [secure upload], and delete it after the check under section 10.
6.4 Never use knowledge-based questions drawn from public sources, such as date of birth or address alone, as the only check for T2 or T3.
7. Agents and third parties
7.1 The agent must provide evidence of authority. The ICO states it is the third party's responsibility to provide evidence of their authority.
7.2 For CCPA requests, [Organisation] may require proof of the consumer's signed permission and may also require the consumer to verify their own identity directly or to confirm directly that they gave permission (11 CCR 7063(a)). [Organisation] must not require the consumer to resubmit the request themselves.
| Requester | Evidence of authority | Direct confirmation |
|---|---|---|
| Solicitor or legal representative | Signed authority from the individual | Confirm with the individual through the contact on file for T2 and above |
| Request-handling platform or portal | Platform's signed authority and identity of the individual | One-time code or confirmation link to the individual's contact on file |
| Holder of power of attorney or court-appointed deputy | Copy of the legal instrument | [Legal] review of the instrument |
| Parent or guardian of a child | Evidence of parental responsibility | Section 8 applies |
7.3 Deliver the response to the individual, or to the agent once authority and the individual's identity are both confirmed.
8. Children
8.1 Where the child is mature enough to understand their rights, respond to the child directly; the ICO says you should usually respond directly to the child in that case.
8.2 A parent or guardian may act where the child authorises it or where it is clearly in the child's best interests. [Legal] decides borderline cases and the reason is recorded.
9. Fraud indicators and escalation
9.1 [Organisation] must maintain measures to detect fraudulent identity-verification activity (11 CCR 7060(f)). Escalate to [Fraud Team] before any disclosure or erasure when one or more of these indicators is present:
- The contact detail, phone number or password on the account changed within [14 days] before the request.
- The request asks for delivery to a new email address, postal address or third-party storage link.
- Repeated failed verification attempts, or several requests for different individuals from one sender, IP range or device.
- Urgency or pressure tactics, or a request that pairs access with erasure ("send me everything, then delete the account").
- An agent request with authority documents that do not match the individual's records.
- Suspected compromise of the account itself; under 11 CCR 7061(b) do not comply until further verification confirms the request is genuine.
9.2 [Fraud Team] responds within [2 working days] with approve, step up to the next tier, or refuse. See the Account Takeover Prevention Guide for the wider signal set.
10. Handling verification data
10.1 Use information collected for verification only to verify the requester, for security or fraud prevention.
10.2 Delete new personal information collected for verification as soon as practical after the request is processed (11 CCR 7060(d)), and delete document images after the check. The EDPB notes that keeping an ID copy after verification is likely to infringe purpose and storage limitation (para. 79).
10.3 Store verification artefacts only in [secure DSAR system], never in email or ticket attachments, and restrict access to [Privacy Team].
10.4 Retain the verification record (section 13) without the underlying document for [the request record retention period].
11. When identity cannot be verified
11.1 Tell the requester which additional information is needed and why, within [X days] of receipt.
11.2 If verification fails for a CCPA request for specific pieces of information, deny that request (11 CCR 7062(f)). For a CCPA deletion request that cannot be verified, the request may be denied (11 CCR 7022(a)).
11.3 For GDPR requests, [DPO or Privacy Lead] decides refusal. Record that [Organisation] cannot identify the requester and the steps taken, and inform the requester of the right to complain to the supervisory authority.
12. Delivery
12.1 Deliver T1 responses through the authenticated account or to the contact on file. Deliver T2 and T3 responses only through [secure portal with MFA] or encrypted media, with links that expire after [7 days].
12.2 Before an erasure is executed, send a confirmation to the contact on file and wait [48 hours] for objection unless the requester is in an authenticated session.
13. Records
13.1 For every request record: request ID, type, channel, tier selected and reason, checks performed and result, data points matched (by category, not value), whether a document was viewed and its deletion date, fraud indicators and outcome, approver, dates received and verified, and response date.
13.2 Report monthly to [DPO or Privacy Lead] on the measures in Implementation guidance.
14. Review
14.1 [DPO or Privacy Lead] reviews this procedure every [12 months], after any confirmed impersonation attempt, and when regulator guidance or regulations change. Version: [1.0]. Approved by: [Name, role]. Date: [date].
Implementation guidance
Framework mapping
| Section | Legal or regulatory basis | NIST CSF 2.0 | NIST SP 800-53 Rev 5 |
|---|---|---|---|
| 4. Principles | GDPR Art. 12(6); 11 CCR 7060 | GV.OC-03 | PT-2 |
| 6. Verification tiers | 11 CCR 7061, 7062; EDPB Guidelines 01/2022 | PR.AA-02 | IA-12 |
| 7. Agents | 11 CCR 7063; ICO guide to subject access | PR.AA-02 | IA-12 |
| 10. Verification data | 11 CCR 7060(d); EDPB para. 79 | GV.OC-03 | SI-12 |
Rolling it out
- Inventory channels: list every route a request can arrive by, including social media and the switchboard, and point each to the log.
- Label data by tier: mark which systems hold T2 and T3 data so the handler can select a tier from the search scope.
- Wire in existing authentication: ask [Customer Identity Team] for a re-authentication and one-time code flow the privacy portal can call, so most requests never need a document. The NIST SP 800-63A-4 Identity Proofing (IAL) Guide helps when you design the T3 documentary path.
- Train the desk: run impersonation exercises against the DSAR desk the same way as against the service desk. The Help Desk Identity Verification Policy Template covers the parallel controls.
- Pilot and adjust: run the tiers on one region or brand for [one month], review refusals and escalations, then extend.
Measures
- Share of requests verified without any new personal data collected.
- Number of identity documents requested, and the share deleted within the set period.
- Median days from receipt to verification by tier.
- Fraud escalations, and confirmed impersonation attempts stopped.
- Refusals for inability to verify, with reasons.
Common gaps: verifying by asking for an ID copy by default; sending codes to the address in the request; keeping ID scans in the ticket system; agent requests accepted on a signed letter alone for sensitive data.
Related NHI Mgmt Group resources: DSAR Guide: Handling Data Subject Requests · Identity Proofing and KYC Guide · Account Recovery and Help Desk Security Guide · Data Minimisation. This template summarises UK GDPR, EU GDPR and CCPA regulation requirements on verifying requesters and is not legal advice.