Records & DPIA depth
How this is scored
The DSMS core: records of processing (RoPA/VVT), data protection impact assessments, processor/DPA management and TOMs — how deeply the legal artifacts are modeled and connected.
0 — Document templates in a folder tree; the "register" is a Word file with version numbers in the filename.
3 — A structured RoPA with basic fields and a DPIA questionnaire, but processors, TOMs and legal bases live outside the system.
5 — RoPA and DPIA as linked modules with templates; processor management and TOM assignment exist but are shallow, and group reuse is copy-paste.
8 — A connected data model — processing activities linked to systems, processors, TOMs and legal bases — with DPIA triggers derived from the record, reusable group templates, and outputs a supervisory authority accepts.
10 — Privacy records as a system of record: the RoPA drives DPIAs, processor management and TOM coverage from one data model, multi-client/mandate capability included, and the documentation is audit-ready without manual assembly.
The Drafted Generalist
The record of processing is a guided form through every mandatory field — purpose, data categories, legal bases, recipients, third-country transfers, retention — and the links run on to systems, TOMs and contracts in a graphical relationship view, which is exactly the software-knows-the-law experience I need. DPIA handling sits on the same record with Art. 35 necessity checks and a Schrems II assessment, and multi-client handling with cross-client inheritance is built in rather than copy-paste. Missing contract links are flagged automatically but you wire some of them by hand, which is what keeps this a rung below a fully self-driving register. 16 17 1 2 11