Article 12 GDPR: request deadlines, identity checks and evidence

What GDPR Article 12 requires for every data subject request

When a data subject request arrives, the clock starts on receipt, and Article 12 sets the rules that govern everything that happens until the request is closed. It is the procedural backbone for the rights in Articles 15 to 22: access, rectification, erasure, restriction, portability, objection and automated decisions. The core obligation is to act without undue delay and within one month of receipt. Article 12(3) allows two further months for complex or numerous requests, but only if the person is told of the extension and the reasons within the first month. Your request workflow therefore needs a receipt timestamp, a due date and an escalation step that fires well before that date, not a reminder sent after it has passed.

Article 12 also covers how answers are given and what they cost. Where a request arrives electronically, the reply should be electronic where possible unless the person asks otherwise. If you decline to act, you must explain why within the same month and tell the person about the right to complain to a supervisory authority and to seek a judicial remedy (Article 12(4)). Information and actions are free of charge. A reasonable fee or a refusal is available only for manifestly unfounded or excessive requests, and you carry the burden of proving that. Identity checks under Article 12(6) are permitted only where you have reasonable doubts, and they should request no more than is needed to confirm identity. Confirm with your legal team which of these decisions your ticketing and intake tools must record, and who signs off on refusals.

The risk is twofold: missed deadlines and friction that makes the right hard to exercise. In 2023 the Spanish DPA fined Securitas Direct EUR 100,000 under Article 12(2) for directing people to a chargeable telephone number to exercise their rights, and ordered the notices replaced within 12 months. The lesson for system owners is that intake channels, forms and notices must be free, reachable and consistent with what the system actually does. Review every public-facing request route, including web forms, email aliases and phone scripts, against that standard before the first request arrives.

Which systems, teams and third parties Article 12 reaches

Article 12 places the duty to act on requests on the controller, so the scope of its request process has to match everywhere personal data can enter, sit and leave the organization. The cards below cover the intake points, the systems a request can touch, the people who triage requests, and the processors that must follow instructions. Each one is a scoping decision that should be written down and tested before a request arrives.

Every intake channel

Requests arrive by email to general mailboxes, through web forms, by telephone, by post and sometimes through social media or a customer support chat. Article 12 expects the controller to handle them consistently, and the Spanish DPA's fine against Securitas Direct shows the risk of routing people to a chargeable line. Map each channel, name an owner for it, and check that every route leads to the same tracked case with a clock running from receipt.

Systems holding personal data

A request can reach the CRM, billing, support tickets, analytics, backups, archives and spreadsheets kept by individual teams. Build an inventory of which systems hold personal data and how each one is searched, exported or changed. Without that list, the one-month deadline in Article 12(3) becomes a search exercise that starts too late. Ask for the inventory as a deliverable before any workflow is designed.

Staff who triage requests

Someone must recognize a request whether it is labeled as one or buried in a complaint, record the date of receipt, and route it to the right owner. Named roles, backup cover for absence and clear escalation paths to the privacy lead reduce the chance that a request sits unread. Write the triage steps into a runbook and confirm who can approve refusals or fees under Article 12(5).

Processors and sub-processors

Where a processor hosts or operates a system, it must support the controller's response and act on documented instructions. Contracts should state how quickly a processor passes on a request, what it searches, and how it returns data securely. Sub-processors in the chain need the same flow down, so ask each processor to list its sub-processors and their response paths.

Controller owns the obligation

The controller remains responsible for the response even when a processor runs the search, exports the data or deletes records. A processor's delay does not move the one-month clock or remove the duty to explain any refusal. Document which party performs each step, agree service levels for processor support in writing, and test the handoff before a real request depends on it.

Ticketing and records of actions

A shared ticketing system gives the organization one place to log each request, its deadlines, extensions and communications. Confirm that the tool can record receipt dates, identity checks, extension notices and the reasons for any refusal. Verify this with the vendor and in a test environment rather than assuming the capability is present.

How an assessor tests the request-handling process

This table lists the test steps an independent assessor or supervisory authority typically takes against Article 12, with the evidence each step examines and the findings that usually appear. Read each row as a question the assessor will ask of your request records and written procedure. Most failures come from missing dates and undocumented decisions, not from the policy text itself.

Test step	Evidence the assessor examines	Common finding
Review the written request procedure	Procedure covering intake channels, owners, deadlines, identity checks, fees and refusal wording	Procedure exists but does not match how staff actually handle requests
Sample closed requests	A sample drawn from the request register across all channels, including email and postal requests	Requests received outside the main channel are missing from the register
Check dates from receipt to response	Recorded receipt date, response date and elapsed days for each sampled request	No receipt date recorded, so the one-month period cannot be shown
Verify extension notices	Copy of the extension notice with its date and stated reasons, sent within the first month	Extensions applied without a notice, or notices sent after the first month
Check identity verification decisions	Recorded reason for each identity request, the information asked for and the outcome	Identity checks requested without a documented reason or applied inconsistently
Confirm free-of-charge practice	Records showing no charge was made, or documented reasoning for any fee or refusal as manifestly unfounded or excessive	Fees or payment routes applied without a documented basis
Inspect refusal letters	Refusal letters giving the reasons, the complaint right to a supervisory authority and the judicial remedy option	Refusals sent without the complaint and judicial-remedy information
Inspect electronic replies	Evidence that electronic requests were answered electronically unless the person asked otherwise	Electronic requests answered by post or with no recorded preference

How to build a compliant request workflow, step by step

This sequence turns the Article 12 rules into a working intake, logging, verification and reply process that a team can run and an assessor can trace from first contact to closed request.

Define intake channels and one logging point
List every channel a person might use to make a request, including email, web forms, post, phone and in-person requests, and decide which ones the organization will accept and where each one lands. Route all of them into one request register or helpdesk queue so no request sits in a mailbox nobody monitors. The step is done when every channel is documented, each one feeds the same queue, and staff who receive requests in other places know how to forward them the same day. Article 12(2) expects the controller to facilitate the exercise of rights, so a channel that is hard to find or leads to a chargeable line is a defect the workflow must prevent.
Record receipt timestamps and deadline tracking
Stamp every request with the date and time it was received, the channel, the requester category and the response due date calculated from the one-month rule in Article 12(3). Store the clock start in the system of record, not in someone's notes, so the deadline can be audited later. Set alerts well before the due date for staff and an escalation path to the privacy lead. The output is a request register where each row shows receipt date, due date, status and owner. Ask the vendor or your own administrators to confirm how the tool calculates due dates and whether the timestamps are immutable.
Write identity verification rules proportionate to risk
Define how the team confirms who is asking, based on the sensitivity of the data and the likelihood of impersonation. Article 12(6) allows additional information only where the controller has reasonable doubts, so the rules should say when no check is needed, when a low-friction check such as confirming an existing account is enough, and when stronger evidence is justified. Document what information may be requested, how it is handled, and how it is deleted after use. The output is a short verification standard approved by the privacy owner, with examples for common request types. Avoid asking for more identity data than the request requires.
Set extension and refusal criteria with written reasons
Write the conditions under which the team may extend the deadline for complex or numerous requests, and the conditions under which it may charge a reasonable fee or refuse a manifestly unfounded or excessive request. Article 12(3) requires the requester to be told about an extension and its reasons within the first month, and Article 12(4) requires reasons and information about complaint and judicial remedies when no action is taken. The controller bears the burden of showing that a refusal or fee is justified under Article 12(5), so each decision needs a recorded rationale. The output is a decision template and a sign-off step for any refusal.
Set electronic reply and delivery standards
Where a request arrives electronically, decide how responses will be sent electronically by default, unless the requester asks for another method, as Article 12(3) provides. Define approved delivery methods for personal data, such as an authenticated download portal or encrypted transfer, and prohibit sending sensitive copies as unprotected attachments. Confirm that replies include the information the requester needs to understand the outcome and to complain if they wish. The output is a reply library of approved templates and a delivery standard that the security team has reviewed. Ask your platform owner which delivery features are native and which need custom work.
Assign owners and build the runbook
Turn the steps above into a runbook that names who receives, verifies, searches, decides and replies to each request type, with handoffs between the privacy, IT and legal roles. Include the search routine for finding data across systems, the quality check before release, and the closure criteria. Keep the runbook under version control so changes to deadlines, templates or verification rules are traceable. The output is an approved runbook and a named owner for each role, reviewed at least as often as your privacy notices.
Test end to end with sample requests
Before relying on the workflow, submit sample requests through every channel, including an incomplete one, a request needing verification, an extension case and a refusal case. Follow each through the register, check that timestamps and due dates are correct, that reminders fire, that replies use approved templates and that evidence is retained. Record the results and fix gaps before go-live. The output is a signed test record showing each path worked, which an assessor or regulator can review. Label these samples as test data and make sure they are removed from production systems afterward.

How the one-month clock, extensions and refusals work in practice

The one-month clock starts on receipt of the request, not on the day an analyst first opens the ticket or the day identity is confirmed. Article 12(3) requires the controller to act on requests under Articles 15 to 22 without undue delay and within one month of receipt. Request-handling workflows should therefore record the receipt timestamp at the point the request reaches any channel the organization monitors, including a generic mailbox, a web form or a contact centre. Identity checks under Article 12(6) may pause the clock only in the sense that the controller can ask for more information where it has reasonable doubts. Confirm with counsel how your supervisory authority treats requests that arrive through channels nobody watches, because the clock may already be running before anyone has logged the request.

An extension of two further months is available only for complex or numerous requests, and only if the data subject is told of the extension and its reasons within the first month. Article 12(3) sets both conditions. A notice sent in week five does not qualify, and a notice that gives no reason does not qualify either. The first-month notice should state the request reference, the date of receipt, the extended deadline, and the specific reason, such as the volume of records held across several systems or the need to review third-party data. Ticketing and case-management records should hold the notice as evidence. Whether a particular request is complex is a judgment that counsel or your supervisory authority can help you confirm, so document the reasoning when you make it rather than after a complaint arrives.

Where the controller does not act on a request, Article 12(4) requires it to explain why within one month and to inform the person of the right to complain to a supervisory authority and to seek a judicial remedy. For requests that are manifestly unfounded or excessive, Article 12(5) allows a reasonable fee or a refusal, and the controller bears the burden of demonstrating that character. Keep a written justification for each refusal or fee, with the facts that support it, because an assessor or regulator will ask for it. Free handling is the default, so any fee policy should be approved in advance and checked against the Spanish DPA decision on chargeable contact routes, reported by the EDPB in September 2026, before it is applied to any request.

Evidence that satisfies Article 12 and how to keep it current

Article 12 is tested through the paper and system trail a controller can show for each request. The cards below cover the artifacts an assessor or supervisory authority will ask for, and the periodic sampling and reviews that keep them accurate between audits.

Written request handling procedure

A dated procedure that sets out how requests are received, logged, verified, answered and closed, with named owners for each step. It should state the one-month response period, the conditions for a two-month extension, and the wording used when a request is refused. Check that the procedure matches what staff actually do, since a regulator will compare the document against case files.

Request register with timestamps

A register that records each request's date of receipt, channel, request type, identity check status, due date, extension notice date, and closure date. The receipt timestamp anchors every deadline, so it should be captured automatically where possible. Sample entries against ticket histories to confirm the dates reflect when the request actually arrived.

Identity verification records

Records showing when identity was doubted, what additional information was requested, and whether the requester's identity was confirmed before data was disclosed. Keep these proportionate and minimal, since collecting extra identity data creates its own obligations. Confirm that the clock treatment in the register is consistent with the period during which verification was pending.

Extension and refusal notices

Copies of every notice sent within the first month that extends a request, with the reasons, and every notice explaining why no action will be taken. Refusal notices must also name the right to complain to a supervisory authority and to seek a judicial remedy. Check that each notice was sent within the deadline, not just that it exists.

Response templates and channel inventory

Approved templates for acknowledgments, extensions, refusals, fee notices and final responses, plus a list of every channel through which requests can be made, such as web forms, email, post, telephone and in-app. Under Article 12, electronic requests should normally receive electronic replies. Reconcile the inventory against the systems you actually run, because an unmonitored mailbox or portal is a common gap.

Staff training records and procedure reviews

Attendance records, materials and dates for training of everyone who can receive or answer a request, including service desk and frontline teams. Pair these with dated reviews of the procedure, the templates and the register, and note what changed after each review. Between audits, sample a set of closed requests each period, check deadlines and notices, and record the findings and corrective actions.

What meeting Article 12 costs in money and effort

This table breaks down the cost components of running Article 12 request handling, showing who is paid for each, whether it is one-time or recurring, and what drives it up. Use it to build a quote request, since no fee figures are supplied for this work and each line depends on your own request volume, channels and systems.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it
Intake and triage staff time	Internal privacy or service staff, or an outsourced desk	Recurring	Request volume, number of intake channels, and how often requests need a second review
Helpdesk or ticketing licenses	Software vendor, or no license fee with self-hosted open-source tools	Recurring if commercial, one-time setup otherwise	Number of agents, retention of tickets, and whether deadline tracking needs add-ons
Deadline tracking build	Internal engineers or an implementation partner	One-time, with ongoing maintenance	Number of request types, reminder rules, and integration with existing ticket queues
Identity verification design	Engineers, security staff and legal reviewers	One-time, with periodic review	Sensitivity of the data held, available verification signals, and the risk of impersonation
Procedure drafting and legal review	Internal privacy counsel or external lawyers	One-time, then periodic updates	Number of jurisdictions, refusal and fee rules, and how often notices change
Staff training	Internal time, or an external trainer	Initial and recurring for new staff	Staff turnover, number of teams that touch requests, and tooling changes
External review or assessor sampling	Independent auditors or assessors, paid by the organization	Recurring per assessment cycle	Scope of the assessment, sample sizes agreed, and the quality of the request records

Which open-source tools support Article 12 request handling

Article 12 deadlines only work if every request is logged when it arrives, assigned, and timed against the one-month clock. Ticketing systems hold that record. Two open-source options cover different intake patterns. GLPI (GPL-3.0-or-later) provides its Assistance module, which lets users create, follow and process tickets, problems and changes following ITIL practices.

Assistance tickets: GLPI's Assistance module supports tickets, problems and changes, which helps separate rights requests from general IT work.
Planning and statistics: Built-in plannings and statistics help a team see open requests against their due dates.
Kanban view: A board view helps staff move requests through identity checks, search and response stages.
Zammad (AGPL-3.0-only): Zammad brings email, chat, telephone and social media messages into one ticket system, so requests sent through several channels land in one queue.
Channel consistency: Confirm which intake channels your organization must monitor, and check that each one creates a ticket with a received timestamp.

Before choosing either tool, confirm the exact request types, reporting fields and timers your workflow needs by testing them in a staging instance.

Where organizations usually fall short on Article 12

Most Article 12 failures are procedural rather than technical: the clock starts late, the request channel is hard to find, or the reply omits something the law requires. Each gap below is easy to miss in a request workflow and easy to test once you know what to look for.

Clocks that start at the wrong date

The one-month period runs from receipt of the request, not from the date someone in the business read it or the date identity was confirmed. Requests that arrive through a mailbox nobody monitors, a web form that does not timestamp, or a forwarded email often start late in practice. Check that every intake channel records a receipt timestamp, and that the deadline is calculated from that value and shown on the ticket.

Requests arriving through unlogged channels

Requests often reach staff by phone, chat, social media or a colleague's inbox, and never become a case. A request that is not recorded cannot be tracked against the deadline or shown to a supervisory authority later. Confirm which channels customers can use, route each one into a single ticket queue, and test whether a request sent to a support address creates a case automatically.

Chargeable or hard-to-find routes

Article 12 requires that information and actions be free of charge, and the Spanish DPA fined Securitas Direct EUR 100,000 under Article 12(2) for directing people to a chargeable telephone line to exercise their rights. Review privacy notices, account pages and automated replies to confirm that the route is free, visible and not dependent on a premium number. Ask whether a customer can submit a request without creating an account or paying a fee.

Inconsistent identity checks

When controllers have reasonable doubts about who is asking, they may request the information needed to confirm identity, but the checks must be proportionate and applied the same way. Problems appear when one agent asks for a passport, another accepts an email reply, and a third processes a request with no check at all. Write a verification standard per request type, record which check was used on the ticket, and ensure the clock is not suspended without a documented reason.

Missing extension notices

A two-month extension is available only for complex or numerous requests, and only if the requester is told within the first month, with reasons. Teams often realize late that a request is complex and then extend silently or not at all. Add a mandatory extension step to the ticket workflow that fires before day 30, requires a stated reason, and sends the notice through the same channel the request came in on.

Refusals without required content

When a controller does not act on a request, it must explain why within one month, and tell the person they may complain to a supervisory authority and seek a judicial remedy. A refusal letter that omits either element is a compliance gap even if the refusal itself is justified. Keep a refusal template with fixed required paragraphs, require a reviewer to sign off, and record the rationale against the request so the decision can be reproduced later.

Questions buyers ask about Article 12 effort, cost and outsourcing

Does a certificate prove Article 12 compliance?

No. The GDPR requires no audit, attestation or certificate, and certification under Article 42 is voluntary. Even where a certificate exists, it does not reduce the controller's responsibility for compliance. Article 12 compliance is shown by your own working process: deadlines tracked from the day of receipt, extension notices sent within the first month, identity checks applied proportionately, and refusals explained with the complaint and judicial remedy information. Supervisory authorities judge that practice directly, and the evidence is your request logs, templates and decision records.

What drives the effort to build a deadline-driven request process?

The effort depends mostly on how many systems hold personal data and how many channels requests arrive through. Each channel needs intake, a timestamp at receipt and a clock that runs to one month. Each system that holds data needs a way to locate and act on a request, so the work scales with your data map. Other drivers include how many staff roles must approve responses, whether you need templates for extensions and refusals, and how much request history must be reported. Ask any partner to break the scope into intake, workflow, identity checks, templates and reporting so each part can be priced and timed separately.

What does it cost to run Article 12 request handling?

Costs fall into one-time work and recurring work. One-time work includes mapping systems, configuring a ticketing workflow, writing templates and testing the process end to end. Recurring work includes staff time for each request, software licenses or hosting, periodic review of templates against guidance and updates to the process when systems change. Article 83 sets the maximum fines for infringements of data subject rights provisions at EUR 20 million or 4% of worldwide annual turnover, whichever is higher, which explains why the process is worth funding. For a quote, ask for the scope in writing, the fixed deliverables, the hosting assumptions and which parts recur after handover.

Can our in-house team build this without outside help?

Often yes, if the team already runs a service desk, knows where personal data lives and can document decisions. The work is mostly configuration, process design and records, not specialized tooling. The harder parts are usually finding personal data across systems, handling backups and logs, and writing refusal and extension wording that holds up. Teams without privacy or legal input, or with many systems and few people, tend to struggle with those steps. A useful test is whether someone can, today, show the date every open request was received and who approved each response.

What does our team need to provide to get the process working?

The organization owns the controls, so decisions and inputs must come from your side. You need to name a request owner, provide a list of systems and data stores that hold personal data, confirm which request channels are live and agree the identity verification standard. Legal or privacy staff must approve extension and refusal wording and the complaint information. Engineering must confirm which systems can export or erase data for a single person. An implementation partner can prepare the workflow, configuration and evidence, but cannot make those decisions for you.

When is outside help worth it for Article 12 work?

Outside help is usually worth considering when request volume is high, several business units or countries are involved, or the data map is incomplete. It also helps when you need a self-hosted ticketing setup that integrates with identity, logging and document systems inside your own infrastructure. Ask a prospective partner for a written, fixed scope that states which systems are covered, which deliverables you receive and what you must supply. Ask whether they will also test the workflow with sample requests. Legal advice on specific refusals stays with your privacy counsel, and any formal review is performed by an independent auditor or authority, not the implementer.

Which open-source tools can handle request tickets and records?

Helpdesk and ticketing platforms such as GLPI and Zammad can hold request tickets, track status and bring email and other channels into one queue. GLPI's Assistance module supports ticket follow-up with planning and statistics, and Zammad consolidates customer communication from several channels into one ticket system. Wikis such as XWiki keep version history of response templates and procedures, showing what changed and who changed it. BookStack's role-based permissions can restrict who edits approved templates. Confirm with each vendor that the features you need, such as deadline timers and export logs, exist in your chosen version before you commit.

How DeployOpen scopes and prepares Article 12 request handling

DeployOpen approaches Article 12 as a set of working procedures: deadlines, identity checks, electronic replies and written refusals that your request-handling systems must follow. We scope the work in writing, build the workflows inside your own infrastructure, and hand over documentation your team and your independent assessor can review. DeployOpen prepares the systems and evidence; only your controller decisions and the outcome of any independent review settle compliance.

How we scope

We agree a written scope before work starts, covering which request channels, systems and teams are in it.
The scope lists which Article 12 duties the workflow must support, including deadlines, extensions and refusal notices.
Scope also records who in your organization owns the decisions on identity checks, fees and refusals.

How we build

We configure ticketing and helpdesk tools in your environment so every request gets a dated, traceable record.
We set up role-based permissions so only authorized staff can view, change or close a request.
We test the workflow with sample requests, including extension, electronic reply and identity-check paths, and record the results.

How we hand over

We document the request procedure, roles, deadline logic and templates in a versioned knowledge base your team controls.
We deliver the test records and configuration notes so an assessor or your DPO can trace how the process operates.
We train the staff who will run the process and confirm that the handover checklist is complete.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
Retainers can cover changes to templates, permissions and workflows when your request volume or rules change.
Any support scope, response commitments and fees are set out in writing, with no pricing published here.