Uzturēt aktuālu apstrādes darbību reģistru (VDAR 30. pants)

Kad izmantot

Every quarter, and immediately after any change that adds, stops or materially alters a processing activity (new CRM, new payroll provider, new camera system, a product starts collecting end-customer data). Not for answering an individual's access or deletion request — that is support.data-subject-request. Not for the technical side (access rights, backups, device security) — that is tech.security-audit. Not for the annual company filings — that is money.annual-report-lv and company.registry-watch.

Pirms sāc

• The previous register version is in the documents module, or the owner has confirmed this run creates it.
• A named person is the data-protection contact; if a DPO is designated, their details are known
• The quarter's change list exists: ask each module owner what tools, suppliers and data flows changed.

Ko izpilde pieprasa1

Ceļš8 soļi

1. S1

   Collect the quarter's changesaģents

   Ask each module owner (in one message, one deadline): new tools, new suppliers touching personal data, stopped activities, changes in what data is collected or why.

   Izdarīts, kad every module owner has answered or the deadline has passed and the silence is recorded.

2. S2

   Inventory what actually runsaģents

   List from the tools themselves, not from memory: which SaaS services hold personal data (mail, CRM, accounting, support, HR, analytics), which suppliers receive it, which backups hold it.

   Izdarīts, kad there is one list of systems that nobody disputes, dated today.

3. S3

   Diff the register against realityaģents

   Compare the current register rows to the S2 list. Mark each row: unchanged · changed (what) · missing (system with no row) · dead (row with no live system).

   Izdarīts, kad every row has a mark and every unmatched system has a proposed new row.

4. S4

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

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

   Present the diff: proposed new rows, changed rows, rows to retire. For each new activity the owner confirms purpose, legal basis, data categories, retention, and the named internal owner.

   Izdarīts, kad the owner has approved or corrected each proposed change, with the date recorded.

   ⛔ An activity without a named owner and a retention period does not go into the register — it goes back.

5. S5

   Update the registeraģents

   Apply the approved changes: one row per activity with purpose, categories of data subjects and data, recipients, transfers outside the EU/EEA (if any, and the safeguard), retention, security measures in short, named owner. Version the file; never overwrite the previous version.

   Izdarīts, kad the new version is saved in the documents module and the diff between versions matches S4.

6. S6

   Check processorsaģents

   For every supplier in the register: is a data-processing agreement (Art. 28) on file, and does it name the same supplier entity that actually holds the data? List any gap.

   Izdarīts, kad each supplier has "DPA on file — dated" or "missing — task created".

7. S7

   Create follow-up tasksaģents

   For each gap from S5 and S6: a task with an owner and a due date (missing DPA → chase the supplier; dead activity → confirm data deleted or anonymised; new transfer → check the safeguard).

   Izdarīts, kad every gap has a task id, and none is assigned to "someone".

8. S8

   Record the runaģents

   Write the review note: date, register version now in force, changes approved, gaps found, tasks opened, the owner's approval in S4. Link the note to the register file.

   Izdarīts, kad the note exists, is linked, and next quarter's date is in the calendar.

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

• Pick three rows at random and verify each against the live system: the tool exists, the data it holds
• Every supplier in the register appears in the DPA check from S6 with a status — none "unknown".
• The register file is versioned: the previous version is still retrievable, and the diff equals S4's decisions.
• The review note names the approver and the date; the register states the version it describes.

Ja noiet greizi

Ko atstāj katrs solis

1. S1every module owner has answered or the deadline has passed and the silence is recorded.
2. S2there is one list of systems that nobody disputes, dated today.
3. S3every row has a mark and every unmatched system has a proposed new row.
4. S4the owner has approved or corrected each proposed change, with the date recorded.
5. S5the new version is saved in the documents module and the diff between versions matches S4.
6. S6each supplier has "DPA on file — dated" or "missing — task created".
7. S7every gap has a task id, and none is assigned to "someone".
8. S8the note exists, is linked, and next quarter's date is in the calendar.

Ko saglabāt

Register version id and its diff · the S2 inventory list with date · S4 approval (who, when, what) · S6 DPA statuses with document links · task ids opened in S7 · the review note.

Kā šī procedūra uzlabojas

After four runs ask: did any activity surface that had run unregistered for more than one quarter, and where did it come from (a tool nobody owned, a supplier nobody listed)? Did any S6 gap repeat — if so the fix is in ops.new-supplier (make the DPA a step there), not in more chasing here. How long did S1 take, and would a standing checklist per module owner shorten it? A new version changes the step that let the gap through, and says so in its change note.