Deep-dive · Design 2.3
Every other obligation, DSARs, breach notice, retention, transfers, assumes you know where personal data enters, lives, moves, and leaves. The Record of Processing Activities is the first thing a regulator asks for. Scroll to build the map.
DSARs, breach notification, retention and transfer rules all need you to know where the data actually is. And the RoPA is the first artefact a supervisory authority asks for; if it is missing or obviously wrong, the conversation gets worse immediately.
Map where personal data enters, where it lives, where it moves, and where it leaves: from sources, through your own systems, out to the processors you send it to.
If your processor runs on AWS, AWS is your sub-processor and belongs on the map. The chain has to be visible to the bottom, not stop at the first vendor.
Every backup, DR replica, analytics copy and dev/test environment is a place the data lives, and each must appear on the map. These are exactly the copies that get missed.
Each entry records purpose, lawful basis, data categories, subject categories, recipients (including sub-processors), transfers outside the EEA, retention, and the security measures. Keep controller-mode and processor-mode activities in the same register (Art. 30(1) vs 30(2)).
Treat the diagram as code (Mermaid in the repo, updated on PR). Tag every bucket, queue, table and topic with its processing activity at provisioning time. Re-derive the RoPA from the cloud regularly: if the manual register disagrees with reality, the cloud wins, and the diff is a finding.