Selecting a GDPR-focused tool can streamline a DPO’s work—but it can also reproduce the same weaknesses you already have in spreadsheets: incomplete registers, unclear responsibilities and documents with no reliable version history. The right question before adoption is not how many features exist, but which privacy processes will work better with the tool and how you will prove they do.
This guide focuses on operational checks: run a small pilot, prepare and reconcile your data, involve the people who must keep records updated, and decide with documented evidence whether to proceed. It does not replace legal assessment of processing activities nor does buying software guarantee compliance with GDPR, NIS2, DORA, ISO standards or local regulations.
Start from a single process and the people who must maintain it
Begin with a tightly scoped process—for example, the register of customer-service processing or a supplier onboarding workflow. Identify:
- who knows what the processing is in practice,
- who can provide technical evidence (logs, configs),
- who decides on corrective actions.
Avoid starting with the entire privacy programme: that makes it hard to tell whether issues are due to the tool or to organisational gaps.
Remember the separation of roles in GDPR: controllers’ obligations are distinct from the DPO’s advisory and monitoring functions (see Articles 24, 38 and 39). The operational configuration should preserve that distinction: the tool should not automatically make the DPO the executor or approver of every action.
Before you create user accounts, appoint an operational owner for the pilot process and verify they can dedicate time to keep records updated. The DPO’s role is to comment and monitor outcomes; the operational owner must be able to gather evidence from systems and people.
Expected first deliverable: for each activity in the pilot you must be able to answer who acted, who decided, and which document records the outcome.
Run a focused pilot: entry and exit conditions
A pilot is not a sales demo. Its purpose is to confirm whether a small team can complete a real lifecycle: an item emerges, an action is assigned and the closure is verifiable.
Prepare an initial dossier: a processing record, a supplier description and one open finding. You may use synthetic data initially, switching to real data only after access rules and processing conditions are validated.
Define success criteria in advance so you won’t retro-fit them to what the product happens to show. Examples of pilot checks and required evidence:
- Update to a processing record — evidence: comparison between initial and updated versions; condition: the change is attributable and explainable.
- Attachment of an external document — evidence: document linked to the request and the processing record; condition: origin and relevance are verifiable.
- Handling of an open finding — evidence: assignment, action taken, and final verification; condition: closure supported by evidence.
- Compilation of a case file — evidence: export and review outside the platform; condition: an external reviewer can reconstruct the case.
Log the manual interventions required to complete the cycle. If the pilot requires repeated private messages or DPO reconstructions to finish, the process is not yet reliable—even if every screen looks filled.
Migrate only verified information, not everything you own
Bulk import is a common operational risk. Historical registers often include obsolete suppliers, copied purposes and documents never validated. Importing them does not make them current.
Classify data before import into at least three states: verified information, information to be confirmed, and historical material. Preserve provenance: source system, date of last verification and the name of the person responsible for clarifying content.
Do not record the migration date as the processing review date. Those are different events; conflating them creates the appearance of a review without the underlying work.
For attached documents, ensure the filename is not the only identifier. Store references to the processing activity or control, the relevant version, and the reason the document constitutes usable evidence. Use structured rules for audit evidence to avoid large but unverifiable archives—for example, see our guidance on building usable audit evidence: /en/blog/evidenze-di-audit
Before full migration, perform a reconciliation on the pilot sample: compare source and target entries, verify links and note exceptions. Any incomplete record should remain marked as such, with an assigned action to complete it.
Treat the platform itself as a processing activity
A GDPR tool can contain personal data about staff, data subjects and supplier contacts. Comments, attachments and activity logs may include personal information. Your evaluation should therefore extend beyond registry entries to the platform as a whole.
Ask which data the tool genuinely needs. To show a request was handled, a reference record with controlled pointers may be sufficient—no need to duplicate identity documents or full message threads.
If the vendor processes personal data as a processor, assess the Article 28 arrangements. Also evaluate technical and organisational measures under Article 32 and any cross-border transfer mechanisms under Chapter V of the GDPR. A vendor’s declared data-centre location is not the whole story.
Operational checks to request from the vendor: support access procedures, sub-processor lists, incident handling and data return/deletion policies. Keep records of examined contract clauses, open questions and governance decisions. The contractual and transfer review requires the right legal and procurement expertise; the pilot dossier should make that review visible, not replace it with a tick box.
Include a real external dependency in the pilot
A meaningful pilot should involve at least one external supplier. For example, an e-commerce optimisation project may include analytics, third-party integrations and customer-interaction tools—areas where the DPO cannot gather all facts alone.
Choose a concrete change for the pilot (e.g., deploying a chat support service). Ask the project owner to document data elements involved, receiving systems, expected accesses and existing documentation. Don’t assume every supplier has the same privacy role: classification must match actual activities.
The tool should link request, response, received document and internal decision. If a supplier’s response is missing, the record should remain open with an assigned owner and due date, not become an empty attachment marked complete.
Note explicitly what is out of scope. A supplier listed in the master data but not analysed for the pilot should not appear as assessed simply because it exists in the system.
Prove handovers, absences and revoked access
The process must work when the person who configured it is absent. Have an authorised substitute complete a task without verbal handover. They should be able to understand what is missing, which version to use and who to contact.
Simulate a change of responsibility: replace the process owner and check that open activities are reassigned and the history continues to show distinction between previous and new actions.
A useful GDPR tool reduces informal reconstructions. To test that, pick a change and reconstruct author, time, content and rationale from what the system records. Do not assume that an access log alone documents content changes—ensure the audit trail captures meaningful events. See audit trail best practices: /en/blog/audit-trail-best-practices
Finally, revoke a test user’s access and confirm they can no longer view the previous scope and that any sharing links behave as configured. Keep the results of the test, including anomalies and corrective steps.
Make the go/no-go decision and plan the exit
The pilot must end with a documented decision, not a subjective impression. Typical outcomes are: proceed, proceed with restrictions, or pause extension until critical issues are resolved.
A middling score does not outweigh a serious blocker: a good UI cannot compensate for excessive access rights or the inability to reconstruct evidence. Distinguish between desirable improvements and problems that prevent controlled use.
Before rolling out, ensure these four conditions:
- Responsibilities covered: every recurring task has an owner and a substitution procedure.
- Data reconciled: pilot sample has been compared with sources and exceptions tracked.
- Issues managed: outstanding risks have temporary mitigations, owners and review dates.
- Exit validated: data and documents can be exported in a usable form, with links and context preserved.
Test the export before committing: open the files outside the platform and check whether an external reviewer can follow the case without access to the application.
The final record should describe the authorised scope, limitations, residual risks and decision-makers. Address post-termination deletion separately from mere data export capability.
FAQ
Can software alone certify GDPR compliance? No. Tools support information collection, traceability and reviews, but compliance depends on actual processing activities, governance decisions and implemented measures. A comprehensive report does not automatically prove that declared practices are followed.
Do I have to upload all privacy documents? No. A GDPR tool should contain what is necessary for the defined process and avoid needless duplication. If a document stays in another system, ensure the reference is stable, accessible to authorised users and points to the correct version.
Does “app” mean a mobile app is required? Not necessarily. In this context, “app” means the operational tool and not necessarily a smartphone app. If mobile access is needed, include authentication, downloads, notifications and device management in the pilot—don’t assume parity with desktop behaviour.
Use the pilot dossier as your verification trail
If you want to evaluate AuditReady in practice, request a demo of the GDPR solution at /auditready/lp/gdpr and use the pilot dossier to verify how the product links evidence, responsibilities and open tasks. Keep operational verification distinct from legal opinions required for your context.
audit-ready evidence pack demo / not legal advice