Capability
Track every client's data subject requests against the Article 12(3) clock
A request that quietly passes a month is a breach; the same request, extended and communicated with reasons, is compliant. RINS.AI runs that clock for every client from one console — and is honest about what it does not reach.
Frameworks covered
What Article 12(3) requires
A controller must respond to a data subject request 'without undue delay and in any event within one month of receipt' (Art. 12(3)). That month can be extended by two further months where necessary — but only if the controller informs the data subject of the extension, and of the reasons for it, within the first month. The extension is neither automatic nor silent: an unacknowledged extension is not an extension.
This is the distinction the deadline turns on. A request that reaches a month with no response and no communicated extension is a breach. The same request, extended and communicated with reasons inside the first month, is compliant. The difference is not the elapsed time — it is whether the subject was told, in time, and why.
- One month from receipt (Art. 12(3))
- Extendable by two months — only with reasons, communicated within the first month
- A silent extension is a breach, not an extension
The clock is computed, not stored
The deadline is computed from the request's received-at timestamp every time it is read, not written once into a status field. A stored deadline can go stale — edited, missed by a background job, or frozen when a status changes. A computed clock cannot: it always reflects the real time remaining from the moment of receipt.
A request moves through six states across its life. Crucially, an identity-pending request keeps the clock running: verifying a requester's identity under Article 12(6) is a precondition for acting, not a pause. Treating verification as an extension is one of the most common ways a request is allowed to breach while it looks 'on hold'.
- Deadline derived from received_at on every read — it cannot go stale
- Six request states across the lifecycle
- identity_pending keeps the clock running — Art. 12(6) verification is not an extension
Refusals and records a supervisory authority will ask about
A request can be refused, but not with free text. RINS.AI requires a structured legal ground — manifestly unfounded or excessive (Art. 12(5)(b)), an erasure exemption (Art. 17(3)), a restriction of rights (Art. 23), data not held, or identity not established. That structured ground is exactly the field a supervisory authority asks about when it reviews a refusal; 'we decided not to' is not an answer.
Records are append-only. A completion, refusal, or extension is never overwritten — a correction is appended, with the actor who made it and the timestamp, so the original decision and its amendment both survive. The trail shows what was decided, by whom, and when it changed.
- Structured refusal grounds: Art. 12(5)(b), Art. 17(3), Art. 23, data not held, identity not established
- Append-only amendments — original retained, correction attributed and timestamped
- Portfolio view — which client has a request about to breach
What it does not do — the boundary that matters
This is the part a responsible buyer checks first. RINS.AI searches the records the platform holds — a client's ROPA entries, scan results, and stored evidence. It does not reach into a client's CRM, email, or HR system, and the response states plainly which systems were not searched. That disclosure is part of the output, not a footnote.
And it produces a controller worklist — it does not fulfil the request. The controller decides what to disclose, redact, or refuse. A DSR tool that appears to fulfil a request automatically is more dangerous than none: it invites a disclosure no one reviewed. RINS.AI runs the clock, structures the decision, and records it; a human completes it.
- Searches only platform-held records: ROPA, scans, evidence
- Does NOT reach a client's CRM, email, or HR — and the response says which systems were not searched
- Produces a controller worklist; it does not fulfil the request
Regulation sources
- GDPR Art. 12 — Transparency & modalities (incl. the 12(3) one-month deadline) ↗
- GDPR Art. 15 — Right of access (what must be provided) ↗
- GDPR Art. 17 — Right to erasure (incl. 17(3) exemptions) ↗
- GDPR Art. 23 — Restrictions ↗
Links go to the official consolidated text on EUR-Lex.
FAQs
Does verifying identity pause the deadline?
No. Article 12(6) identity verification is a precondition for acting, not an extension of the Article 12(3) clock. In RINS.AI an identity-pending request keeps counting down, so verification delay never quietly consumes the month.
Does it answer the request for us?
No — and deliberately. It assembles a worklist from the records the platform holds and tells you which systems it could not search. The controller reviews, redacts, and completes the response. Automatic fulfilment is a liability, not a feature.
Builds compliance tooling for MSPs and privacy consultancies, working daily with GDPR, DORA, NIS2 and the Gulf PDPL regimes.
Last updated Sep 16, 2026