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 In-House Counsel
The register is a genuinely connected model: every Article 30 mandatory field is guided in the record, activities are intelligently linked to systems, TOMs and contracts, and data processing agreements are matched to data recipients automatically by name with uncovered recipients flagged as missing. The Article 35 necessity and screening assessment is proposed from the activity itself, deletion classes derive deletion rules with deadlines and responsibilities, and external DPOs and groups can run hundreds of mandates with cross-client inheritance plus one-click status reports, procedure files and the Bavarian authority questionnaire. I hold back the top mark because missing processor connections are closed by hand, and I found no public information on TOM coverage being computed and reported off the register. 1 16 17 2 2 7