DPMS — Data Protection Management

Automatic pseudonymization on every AI call

DPMS is AI-assisted throughout — and protects exactly the data that data protection is about. Before every AI call, personal data is automatically masked and reinserted into the response. Personal identifiers don't leave the tenant in clear text, while the AI can still work with the case. Pseudonymization is switchable per tenant and on by default.

Record of processing (Art. 30 GDPR)

Every controller must maintain a record of its processing activities. The DPMS module provides the structure for this: per processing activity — purpose, legal basis, categories of data subjects, categories of personal data (incl. special categories under Art. 9), recipients, third-country transfers, retention periods and linked technical and organizational measures (TOMs). With tenant-wide RoPA defaults, filtering, versioning and export as an authority-style Art. 30 template PDF, as a full report and as a CSV/PDF register.

An AI assistant drafts RoPA entries from a free-text description and suggests legal basis and data categories (draft for review). Templates for typical processing activities (HR, accounting, CRM, applicant management, video surveillance) are included and customizable per tenant.

Technical and organizational measures (Art. 32 GDPR)

The module maintains a TOM catalog across the eight BDSG control categories — each measure with implementation status, review interval and evidence. A library of 41 standard measures allows one-click adoption; every measure can be mapped to individual processing activities and assets. So it's demonstrable at the press of a button which safeguards apply to which processing.

Data protection impact assessment (Art. 35)

Where processing is likely to result in a high risk to the rights and freedoms of data subjects, a DPIA is mandatory. The module guides through the DPIA process: risk assessment, description of processing, assessment of necessity and proportionality, safeguards, consultation with the data protection officer. The result is a structured document, exported and anchored in the audit log.

DPA review (Art. 28 GDPR)

SMEs are often simultaneously DPA principals (toward service providers) and DPA processors (toward business customers). The module manages both sides — and reviews along the way:

• AI import of the DPA PDF: processor master data and guarantees are extracted and the form pre-filled — no manual retyping.
• 28-point AI review: clause extraction and risk flags against the mandatory elements of Art. 28 — as a draft alongside the assessment by the responsible person. The agreement is now bound to the processor record itself rather than merely naming it, so the review lands a result on the right object.
• Incoming DPAs (you as processor): DPAs linked to clients, TOMs, sub-processor lists, conditions.
• Outgoing DPAs (you as controller): DPAs with service providers, TOMs review, sub-processor approvals.
• Link to contract management — every DPA is also a contract with term and termination.
• Sub-processor tracking — changes are reflected with notification obligation and right to object.

Data subject rights (Art. 12–22 GDPR)

Access, rectification, erasure and objection requests are not rare — and must be answered within one month. An AI assistant captures the request from text or document, classifies the request type and identifies the requesting person. An identity-verification gate secures the response. Grounded in the record of processing, an AI response draft is produced that can be materialized as a ready-to-send letter (DIN 5008). The module sets the 30-day deadline automatically and documents the handling; anonymized statistics show management the count and processing time.

Incident response (Art. 33, 34 GDPR)

A data protection incident must be reported to the supervisory authority within 72 hours unless it is unlikely to result in a risk. An AI quick-triage supports the intake: classification, risk assessment, notification-obligation recommendation and a measures guide — all as drafts. A 72-hour clock runs automatically. The notification to the supervisory authority (Art. 33) and the notification of affected persons (Art. 34) are produced as ready-to-send letters. Every step is traceable in the audit log.

Recipient register (Art. 19 GDPR)

Recipients of a processing activity used to sit as free text inside that activity. That is enough to print an Art. 30 record and nothing else: "Tax adviser Miller" in one activity and "TA Miller" in the next are two unrelated strings.

The cost is Art. 19 GDPR, which requires the controller to communicate every rectification, erasure or restriction to each recipient to whom the data have been disclosed — and, on request, to inform the data subject about those recipients. A free-text list cannot be enumerated, so the duty was answered by hand or not at all.

In the register each recipient is recorded once and referenced by every processing activity that discloses to it. What is maintained: the recipient category (what Art. 30(1)(d) actually asks for, including recipients in third countries), the type of recipient (processor, joint controller, independent third party, public authority, web service, internal unit), and — where a third country is involved — the transfer instrument: adequacy decision, standard contractual clauses, binding corporate rules, another safeguard, or an Art. 49 derogation. Where a recipient is also a processor, the row points at the existing catalog entry instead of carrying the name a second time.

Data map, subject-access dossier & register search

The data map answers the question on which access and erasure requests actually founder: which system holds this person's data? Not as prose in a concept, but as an overview derived from your processing activities and their systems.

The subject-access dossier is the working list for a specific request: which activities are affected, which systems to search, which recipients to notify under Art. 19. Derived from your records rather than hand-written — and therefore reproducible when the same request arrives again six months later.

Alongside them, a search across every register — processing activities, TOMs, recipients, processors, incidents, requests and policies in one search field — plus disposal measures for files, storage media and devices as a documented activity in its own right.

Transparency register (Art. 13 GDPR)

Art. 13 requires you to inform the data subject at the point of collection — among other things about "the recipients or categories of recipients of the personal data" (Art. 13(1)(e)). That is the same fact Art. 30(1)(d) demands internally, only in a second place and for a different audience. And that is exactly where organisations drift apart: the record gets maintained, the privacy notice on the 2021 form does not.

The transparency register maintains the Art. 13 notices per touchpoint — form, website, application, contract — and sets them against the corresponding processing activity. Where the outward presentation diverges from the internal record, that is reported. Deviation detection does not fire on every typo: it is deliberately tuned to substantive divergence — a recipient present internally and missing externally; a legal basis that has changed. A check that turns red on every rewording is a check people switch off.

Executable deletion concept

A deletion concept that only describes when data ought to be deleted is a document for the supervisory authority and nothing more. Retention periods from the processing activities now produce deletion runs, and every run leaves a deletion log — what, when, on what basis, released by whom. That turns the accountability duty (Art. 5(2)) into evidence rather than an assertion.

Governance layer & data protection quick check

The governance layer covers the organisational side that otherwise lives in binders: the appointment of the data protection officer including the mandatory assessment under § 38 BDSG, confidentiality undertakings, and controls with results and follow-up.

The quick check computes the classics against your actual holdings: processing without a legal basis, without a retention period, without assigned measures; third-country recipients without a transfer instrument; processors without a data processing agreement. Not a questionnaire — a calculation on your data, and it uses no AI at all.

Data protection concept & policies

A living, 20-section document per organisation, generated from your existing DPMS records: organisation, responsibilities, legal bases, retention periods, TOMs, processing on behalf, data subject rights, incidents, training. What is already in the record does not have to be written a second time. Each derived section carries its own as-of date and can be regenerated individually; text you write yourself is preserved. A section without a data basis is flagged as an open point — and a published version says on its cover page that it is incomplete rather than reading as finished.

Beneath it sit the policies per area, function, process or cross-cutting topic (data breaches, home office). The DPO reviews, management releases — two separate, traceable steps. For every published policy it is recorded who acknowledged which version; a new version requires a new acknowledgement. The DPO involvement matrix sets out once when the data protection officer must be involved — per trigger, with involvement level, timing and deputy; as long as no deputy is named, that is flagged as an open point.

Industry text templates for all eight sectors — service providers, software companies, financial services, manufacturing, retail and online shops, trades and construction, staffing agencies, and marketing and advertising agencies. A template is a draft, not a finding: existing text is never overwritten, and anything only your organisation can know remains as [to complete: …] and therefore visible as an open point.

The reverse path works too: an organisation without a record can write the concept first; the purposes, legal bases, retention periods and data categories named in it can then be adopted as catalog entries — they land in the staging area first, and nothing is written until you release it. Concept and policies can be maintained bilingually; the English rendition translates our structure, that is headings and labels, while content from your record stays exactly as you entered it. It is never published automatically and shows the same open points as the original.

Master data, import & export

To get productive fast, the system ships with editable catalogs: data subject and data categories, 131 German retention periods under HGB/AO, purposes, legal bases and TOMs. Plus registers for processors, software, IT assets and locations. An Excel import template and pre-filled industry templates speed up initial capture; a staging check validates the data before adoption, an AI completeness assessment flags gaps per record, and a duplicate-free round-trip export hands the entire inventory back out.

Audit trail across the entire DPMS

Data protection compliance is not about creating a record once — it is about evidence that the record lives. The module logs every change to the record, every DPIA revision, every DPA renewal, every data subject request, every incident. On a supervisory authority inspection, the system delivers full evidence at the press of a button — no last-minute Excel reconstruction.

Want DPMS in the beta? If you depend on any of the modules described above, let us know. We'll add you to the beta and get back to you once the module is enabled for you.