Atbildēt uz GDPR datu subjekta pieprasījumu 30 dienu laikā

Kad izmantot

Any person — customer, ex-employee, job applicant, website visitor — asks what data the company holds on them, or asks to correct, delete, restrict, export it, or objects to processing. Not for a suspected personal-data breach — use tech.security-audit. Not for maintaining the register of processing activities itself — use company.gdpr-register. A request may arrive addressed to anyone in the company; once recognized, this playbook takes over.

Pirms sāc

• The date the request was received is known (any channel counts; a phone call is logged the same day).
• The company knows its role: controller for its own customer/employee data, processor for client data —
• The requester's identity can be checked if there is reasonable doubt (Art. 12(6)) — but no new data may be

Ko izpilde pieprasa2

Ceļš8 soļi

1. S1

   Log the request the day it is seenaģents

   Record: requester, date received, channel, which right is invoked (access, rectification, erasure, restriction, portability, objection), verbatim text. Compute the deadline: one month from receipt; if the month has no equivalent day, the last day of that month.

   Izdarīts, kad the request log entry exists with the received date and the deadline date. ⛔ "Received" is when it reached any company mailbox, not when support opened it.

2. S2

   Find every place the data livesaģents

   Search mail (bc mail search), documents, CRM, invoicing, spreadsheets, website forms, backups, and list systems held by processors (payroll, hosting, mail provider).

   Izdarīts, kad a written inventory names each system, what it holds, and who controls it — including "checked, nothing found" per system.

3. S3

   Verify identity if there is doubtaģents

   If the requester is not already known to the channel they wrote from, ask for confirmation through a channel already on file.

   Izdarīts, kad identity is confirmed, or the doubt is written down and the answer notes it.

4. S4

   Prepare the answer packaģents

   For access: a copy or structured export of the personal data, plus purposes, categories, recipients, retention period and the source if not collected from the person. Draft the response letter; if the company intends to refuse or to extend by up to two months, draft the reasons and the complaint information.

   Izdarīts, kad the draft letter and the data export exist and are dated.

5. S5

   Decideīpašnieksvajag apstiprinājumu · īpašnieks

   Apstiprinājums · S5 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

   Review the pack: grant in full, grant in part, refuse (name the specific ground), or extend with the reason sent within the first month. Check erasure against retention duties — invoice and payroll data the company must keep by law is restricted, not deleted.

   Izdarīts, kad the owner has named the decision in writing.

6. S6

   Send the answeraģentsvajag apstiprinājumu · īpašnieks

   Apstiprinājums · S6 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

   Send the approved letter with the export (a password-protected archive or a secure link, never a plain attachment of a full export to an unverified address).

   Izdarīts, kad the sent message is in the mail record with its date, within the deadline.

7. S7

   Execute the decision. `[irreversible for erasure]`aģents

   Rectify, erase, restrict or export as approved — in every system from S2, including the mail provider's deletion, and note where data survives in immutable backups and when those age out.

   Izdarīts, kad each system from S2 shows the change or a written note why it cannot (legal retention, backup lifecycle).

8. S8

   Record and closeaģents

   Write the outcome in the GDPR register's request log: what was asked, decided, sent, changed, and the dates. Set a task to confirm erasure/restriction propagated (a check two weeks out).

   Izdarīts, kad the log entry is complete and the follow-up task exists.

Pārbaudes — kā zinām, ka izdevās

• Read the sent letter back against the request: every right invoked is answered, yes or no, with reasons.
• The sent date is on or before the deadline (or the extension notice went out within the first month).
• A spot-check in one system from S2 shows the data actually changed or is gone — "we sent the order" is not a check.
• The request log entry would let a stranger reconstruct the whole run.

Ja noiet greizi

Ko atstāj katrs solis

1. S1the request log entry exists with the received date and the deadline date. ⛔ "Received" is when it reached any company mailbox, not when support opened it.
2. S2a written inventory names each system, what it holds, and who controls it — including "checked, nothing found" per system.
3. S3identity is confirmed, or the doubt is written down and the answer notes it.
4. S4the draft letter and the data export exist and are dated.
5. S5the owner has named the decision in writing.
6. S6the sent message is in the mail record with its date, within the deadline.
7. S7each system from S2 shows the change or a written note why it cannot (legal retention, backup lifecycle).
8. S8the log entry is complete and the follow-up task exists.

Ko saglabāt

The request verbatim with received date · the S2 inventory · identity check (or the reason none was needed) · the approved decision (who, when) · the sent letter and export checksum · per-system confirmation of the S7 change · the final log entry. Keep for the retention period the GDPR register defines.

Kā šī procedūra uzlabojas

After every 5 requests ask: how many days from receipt to answer, and which step consumed the wait? Did S2 find a system holding the data that nobody knew about? Was any decision reversed after the answer went out? A new version changes the step that caused the wait or the miss, and says so in its change note.