In K3 you redacted log lines: classifications, redactors, [LoggerMessage] and a test with FakeLogger (lesson 3.3.3). That is
the tool. This lesson asks what it is used for and where. Which data does the Kladde hold at all, for what purpose, where do they
all sit, and when do they disappear again? And by what routes do they get, despite redaction, to places where they don't belong?
This lesson teaches data protection as engineering. It is not legal advice. What applies legally to an office, which legal basis supports a processing activity and which retention obligations exist is decided by the controller, if in doubt together with a lawyer. The engineering makes sure that these decisions really apply in the system.
What Article 25 asks of the engineering
Article 25 of the General Data Protection Regulation (GDPR) is titled "Data protection by design and by default". Read it yourself, it is short (link under Further reading). In essence it demands two things:
- By design (paragraph 1): Whoever processes personal data takes appropriate technical and organizational measures to implement the principles of data protection effectively, such as pseudonymization and data minimization. And already when the means of the processing are determined, that is, at design time, not only in operation.
- By default (paragraph 2): Without any action by the person, only the data necessary for the respective purpose are processed. This applies to the amount of data, the extent of processing, the period of storage and who can see them.
The principles that are meant to be implemented this way are in Article 5. For the design they turn into questions you ask of every data type:
| Principle (Article 5) | Question for the design | Example in the Kladde |
|---|---|---|
| Purpose limitation | What exactly do we need this for, and is it used only for that? | The email address of a booking serves the confirmation, not a newsletter. |
| Data minimization | Do we really need this field? Would less do, such as an id? | Events carry the CustomerId, never the name (lesson 4.3.4). |
| Accuracy | How is a wrong value corrected, and everywhere? | A contact is changed in one place; others read it through a contract. |
| Storage limitation | When is the purpose fulfilled, and what then deletes the data? | Unconfirmed bookings disappear after a day. |
| Integrity and confidentiality | Who can read the data, in logs, backups and exports too? | Rights per schema, redacted logs, encrypted stores. |
For architects this is familiar: They are quality goals with questions and answers. The difference is that here a regulation sets the goals.