Ga naar inhoud

ADR-0026: Each controller logs its own processing in an LDV logbook

Context and problem statement

A citizen and an auditor must be able to see which organization processed which personal data, and why. The decision log records decisions. It does not record processings, because a PDP decision is not a processing (F-63). The gap is at the processing itself (F-64):

  • The consent status lookup at the register.
  • The decryption at the source gateway.
  • The query at the source.

The Logius standard Logboek Dataverwerkingen (LDV, v1.0.0) records each processing in the logbook of its controller (verantwoordelijke). Only trace metadata crosses an organization boundary.

Decision

The decision has four parts:

  • Every component that GBO delivers and that processes personal data writes one LDV record per processing and per data subject. The record goes to the logbook of the controller of that component (REQ-72).
  • The record carries these values:
    • The trace context, as ADR-0035 decides.
    • The data subject in the pseudonym space of that controller, with an explicit data_subject_id_type. The data subject is never a BSN.
    • A versioned, resolvable processing_activity_id.
    • dpl.read.nextLogbookId, if the processing calls another party.
    • The FSC peer that the Inway verified, if the component is a processor on a lookup over FSC (REQ-76).
  • GBO ships the client. Each controller owns its logbook (P-10).
  • A component stores the record durably in a local outbox before the processing delivers. If the logbook is down, the record arrives later. The outage never loses the record, and it does not fail the request.

Considered options

  1. A logbook per controller, written by a shared client (chosen).
  2. One central GBO logbook. Not chosen: LDV keeps records at each controller, and only trace metadata crosses a boundary.
  3. OpenTelemetry spans, relabeled as LDV records. Not chosen: spans are sampled, and their delivery is not acknowledged (REQ-32).
  4. A failed request when the logbook is down (the first demo version). The outbox replaced this option, because a withheld response does not undo a processing that already happened.

Consequences

  • The demo runs one ldv-logboek image as seven logbooks: Belastingdienst, BRP, consent (register and portal), EUDI adapter, consumer (Hypotheek-BV and the integrator), LVG, and Installatie Register. Twelve components write to them.
  • The decryption at the source gateway is a processing at the source. Each logbook uses its own pseudonym space. As a result, a pseudonym does not travel between the logbooks of different controllers (F-69).
  • LDV records never hold a BSN. The logbook refuses any record with a run of nine digits that passes the BSN check digit test (elfproef).
  • A reader follows a chain forward from the start logbooks through nextLogbookId. In DvTP the chain starts at the consumer, and LDV does not bind the consumer (F-68, AV-02).
  • The consumer has no citizen identifier, so it logs under the consent ID (Q-27).
  • Citizen access works per controller, through the read extension of each logbook (F-65). A view of the processings per consent is not built in demo v0.9.0.

These points are open:

  • The register of processing activities is a stand-in without legal status. Retention and read access are open (Q-08).
  • Components write a local dpl.gbo.* extension that nobody ratified (Q-72).
  • No pointer leads from the decision at the source to the logbook of the consent register (toestemmingsregister) (Q-25).
  • In demo v0.9.0, the ASIP writes no LDV records.
  • Production needs WORM storage, hash chaining, or a notary for the logbooks (REQ-32).

Traceability