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 register of processing activities, the impact assessment function, industry-specific processing templates, and measures with owners, deadlines and automatic email notification are all documented, and the GDPR page describes mapping processing directories, data flows, roles, risks, measures and checks in one structured system on a shared data basis with the IT inventory. As a non-lawyer I like that the records live next to the real systems list. We found no public information on how legal bases are modeled or whether impact assessments are triggered from the register itself, so I stop short of the fully connected data model. 2 3 7