What types of data protection software are there?
The term is broad. Most tools can be assigned to one or more of these types:
| Type | What for | Where it stops |
|---|---|---|
| Consent and cookies | Obtaining and managing consent on websites and in apps | only covers data collected through these channels |
| Documentation and registers | Record of processing activities, impact assessments, policies, questionnaires | describes obligations but does not implement them in the systems |
| Finding and classifying | Tracking down personal data in file storage, databases and cloud services | shows where data is stored – but nothing has been deleted yet |
| Data subject requests | Recording access and erasure requests, monitoring deadlines, responding | often without searching your own systems and without deletion |
| Deletion across systems | Deleting data that is due in core systems, peripheral systems and archives, and proving it | requires the systems to be connected |
| AI data | Controlling stored prompts, transcripts and AI output | does not replace general AI governance |
| Protected sharing | Sharing data in masked or pseudonymised form, for example for testing or AI | only as good as the detection of personal data |
The most important distinction: documenting or implementing
Many tools record what is supposed to happen: which data is retained for how long, who is responsible, which measures apply. That is necessary – but it does not delete a single record.
Whether an obligation has been fulfilled is decided in the systems: whether data that is due has actually been deleted, whether an access request has been answered completely, whether data is only shared in pseudonymised form. If you have to show proof to internal audit and the regulator, you therefore need tools that take effect in the systems and log every step.
The two are not mutually exclusive: the documentation provides the requirements, an implementing tool puts them into practice and reports back what has happened.
Suite or individual tools?
A suite covers several types, an individual tool covers one. Both have advantages and disadvantages:
| Criterion | Suite | Individual tools |
|---|---|---|
| Working together | findings, deadlines and proof flow without a separate interface project | interfaces between the tools required |
| Getting started | good if modules can be licensed individually | targeted at a single problem |
| Costs | often lower as soon as several tasks are to be covered | low for one tool, rising with each additional one |
| Dependency | on one vendor | on several vendors and their interfaces |
| Day-to-day use | one user interface, one role model | a separate user interface and permissions for each tool |
What matters is less the number of features than whether you can start with what is pressing today – and expand later without starting over.
Selection criteria
These questions help you compare vendors:
- Does the software reach into your systems – including legacy core systems, archives and in-house developments?
- Where does it run: in your data centre, in your cloud or at the vendor? Which data leaves your premises?
- Does it deliver proof that internal audit and the regulator accept – such as a log per deletion run?
- Does it cover the obligations that apply to you, for example under the Swiss FADP and the GDPR?
- Are there roles and approvals, so that sensitive steps cannot be triggered by one person alone?
- Can modules be licensed individually and added later?
- How long does implementation take, and who supports you?
- Can specialists from data protection, IT and internal audit understand the user interface without lengthy training?
Questions you should ask every vendor
A demo shows what software can do. These questions show whether it is right for you:
- “Show me a deletion in a system like ours – and the proof for it.”
- “Which of our data leaves our premises, and where does it go?”
- “How do you connect a system for which there is no ready-made connector?”
- “What do internal audit and the regulator see when they ask for evidence?”
- “What can we start with, and what does expanding cost?”
- “Where is your software in production use today?”
How to approach the selection
- 1Inventory: where is personal data stored, which obligations are outstanding, what is pressing?
- 2Define requirements – with the most pressing problem as the yardstick
- 3A demo with your own cases instead of standard slides
- 4A proof of concept in your environment, with success criteria agreed in advance
- 5Step-by-step implementation, starting with one module or one system
Common mistakes
- buying according to the length of the feature list instead of the most pressing problem
- only documenting and postponing implementation until later
- clarifying the place of operation only after the purchase
- wanting to introduce all modules at once
- underestimating the effort of connecting your own systems