Personal Data Management Applications within a Company in Accordance with the GDPR
Most organisations begin with a record of processing activities, but the register alone does not ensure GDPR compliance without knowledge of the actual data. What classes of applications make up complete personal data management?
Most organisations begin building their own set of GDPR tools with an application for maintaining a record of processing activities. This choice is understandable: Article 30 of the GDPR is an explicitly stated obligation, and the record is often the first document requested by the Personal Data Protection Office (UODO); in Poland, the formal requirements of this regulation have been in force since 25 May 2018. The problem is that the record describes what the organisation has declared, rather than what is actually stored in its databases, file repositories and backups. An application that organises only the declarative layer improves the quality of documentation, but does not in itself ensure compliance with the GDPR if it does not cover the actual data and risks. For the management of key and important entities covered by the amended Act on the National Cybersecurity System (KSC) and for financial institutions operating under DORA, this distinction is no longer merely theoretical. Discrepancies between the register and the actual state of the systems are the most common finding during audits, and in the event of a data breach, they determine whether an organisation is able to establish the scope of the incident within the required timeframe. Below are the five categories of applications that, in practice, make up personal data management in medium-sized and large organisations, along with the criteria that actually distinguish them.
Five categories of personal data processing applications and the problem each one solves
Data detection and classification. Tools that connect to data sources, analyse the structure and samples, and then identify in which tables, columns or files personal data - including special categories of data - is located. This is the factual layer - the only one that allows the others to be verified. The key distinction here is between structured data (databases, data warehouses, line-of-business systems) and unstructured data (documents, scans, attachments in repositories and on shared drives). These are two different technologies and, in practice, two different products; an organisation that has implemented only one of them has half the picture, whilst the full picture supports the principle of data minimisation and helps to limit unnecessary data sets without a legitimate purpose. Documentation and accountability. The record of processing activities and the register of categories of processing activities, the data protection impact assessment (DPIA), the breach register, authorisations, and the register of data processing agreements and subcontractors. This category fulfils the GDPR's principle of accountability and is valuable precisely to the extent that its content corresponds to the results of data detection. A GRC application fed solely by questionnaires completed by process owners reproduces, within a new interface, the very problem it was intended to solve. Organisations must carry out a GDPR audit, and its risk assessment and broader analysis should relate to actual processing activities, not merely to documentation. Retention and deletion. A declared data retention period without a mechanism to enforce deletion or anonymisation once it expires is a procedural fiction. This class of tools configures retention rules based on time, business events or external triggers and executes them across multiple systems simultaneously - whilst also handling GDPR data erasure requests. The difficulty lies not in deleting a record itself, but in maintaining consistency: the same data subject may simultaneously be subject to a deletion obligation in one system and an archiving obligation, arising from tax or sector-specific regulations, in another. Anonymisation and pseudonymisation. A separate category, primarily serving non-production environments. Production copies in test, development and training environments are one of the most frequently overlooked sources of exposure - they usually have weaker security measures and a wider access group than the system from which they originate. A requirement that rules out most simple solutions is the need to maintain referential integrity: the data must remain usable for performance and integration testing, and the same identifier must be replaced consistently across all related systems. Handling requests from data subjects. Exercising the rights under Articles 15-22 of the GDPR within one month requires locating all instances of a single individual's data. Without properly functioning detection, every access request becomes a manual investigation across systems, and the response is incomplete in a way that the organisation cannot rule out. In practice, this involves responding to requests from data subjects within the framework of personal data protection, including when handling complaints, requests and enquiries from employees.
Personal data protection criteria that actually set tools apart
Coverage of data sources. The first question to ask a supplier is not 'what features does it have?', but 'what does it connect to?': which database engines, which file repositories, which ERP, CRM and HR systems, and whether it covers archives and backups. A tool that cannot see half of the environment creates an illusory sense of control over the other half, and the choice of solution depends on the specific nature of your company's operations and where the data is stored. Accountability of operations. The event log is the end product here, just as important as the operation itself. It serves as proof that the deletion took place on time, on the correct grounds and within the approved scope - and in an audit, proof is what an organisation presents instead of mere declarations. Protection against over-deletion. A tool that deletes data automatically can also compromise the integrity of source systems and delete records subject to retention obligations. Application-side control mechanisms - rule validation, simulation mode, the ability to roll back - are criteria for assessing operational risk, not an afterthought. Such automation of the procedure should support security and confidentiality, not merely the speed of the process. Integration between classes. Four separate applications from four different suppliers mean four separate inventories that must be manually reconciled - and discrepancies between them arise at the first major change to the source systems. The ability of a retention tool to utilise data discovery results, rather than maintaining its own independent list of tables and fields, is the difference between a self-updating process and yet another document for annual review. Deployment model and supplier status. By definition, each of these applications has privileged access to the organisation's most sensitive data sets. In the SaaS model, the provider is a data processor within the meaning of Article 28 of the GDPR, which triggers contractual obligations, including appropriate contracts with data processors, the supply chain assessment required by the KSC Act, and verification of the location of processing and any transfers outside the EEA; With cloud-based data, encryption, the location of servers within the EU and the level of security are also crucial. In the on-premises model, this issue disappears, but the responsibility for maintenance arises. When selecting an application, it is worth considering support for the Data Protection Officer, the appointment of whom is sometimes mandatory for certain personal data controllers. In ISO 27001 terminology, we are referring here to the security controls listed in Annex A - including information deletion and data masking - to which owners must be assigned within the Information Security Management System (ISMS) and which must undergo effectiveness reviews. The tool implements the security measures; it is not a substitute for them. It is worth noting something that is rarely mentioned at the purchase stage: the map of sensitive data generated by the data discovery tool also serves as a ready-made list of the organisation's most important assets. The personal data management application itself becomes a highly critical asset, requiring its own risk owner, access controls and a place in the risk management plan.
How Wizards' portfolio corresponds to these tool categories
Four Wizards products fulfil the functions described above and are integrated with one another. This setup supports the automation of personal data management processes. Detecto detects personal and sensitive data in databases - it classifies columns based on rules, regular expressions, dictionaries and heuristics, and also flags changes to the database schema before a new table becomes an asset beyond control. It operates as a one-off scan or continuous monitoring. Revelio achieves the same objectives with unstructured data, detecting personal data in documents and file repositories. Oblivio implements data retention and the right to be forgotten: it configures sources and rules based on time, business events or external triggers, and carries out deletion or anonymisation on a scheduled basis or on demand, with full accountability for operations and protection against over-deletion. It utilises the results from Detecto and Revelio to locate data subject to retention. Nocturno automates the anonymisation and pseudonymisation of personal data across multiple systems simultaneously whilst maintaining referential consistency, and generates synthetic data for test environments, analytics, model training and staff training. This arrangement has practical significance: the documentation layer is then populated with results from the systems, rather than declarations by process owners, and such an implementation facilitates the DPO's implementation of procedures ensuring compliance with the GDPR, as well as the subsequent updating of documents and records following a GDPR audit. For the board of directors, which, following the amendment to the Act on the National Cybersecurity System (KSC), is personally responsible for cybersecurity, the conclusion is clear. The order in which purchases are made is not without significance. Following a GDPR audit, it is essential to implement changes to systems, authorisations and documentation, rather than relying solely on declarations. A documentation application purchased before a data detection tool organises a picture of the reality that the organisation is still unaware of - and it is precisely this gap that becomes apparent during the first serious incident, when the scope of the breach must be determined within 72 hours.