Practical criteria for choosing an auditable GDPR software

To select the right platform, define measurable acceptance criteria before you compare feature lists. Decide in advance which outcomes must be demonstrable, which shortcomings are tolerable and which are deal-breakers.

Start from a narrow process and build outward

Begin with a bounded process—e.g., a periodic access review for systems processing personal data. Define the operational owner, the verifier and the recipient of remediation. Don’t automatically designate the Data Protection Officer as owner of every task: procurement should separate privacy supervision from operational execution.

Regulatory texts such as the GDPR require controllers to be able to demonstrate compliance. They do not mandate a specific product or every technical capability discussed here. Translate your operational need into observable results: rebuild a review, find an expired piece of evidence, follow a remediation to closure and deliver a complete package to an outside auditor.

The guidance below is practical procurement and operational criteria, not legal advice for individual processing activities.

Turn generic features into acceptance conditions

Statements like “document management” are too vague for a tender. Specify what must happen when evidence changes, when an owner leaves the organisation or when an external auditor cannot access the platform.

A simple matrix helps separate vendor promises from verifiable results:

• Responsibility: ask for evidence of an assigned control with identifiable executor and reviewer. Block acceptance if closed activities do not show responsible individuals.
• Audit history: require a reconstruction of changes with actor, timestamp and previous version. Block acceptance if content is overwritten without trace.
• Access control: test with operational, reviewer and unauthorised profiles. Block acceptance if confidential documents are visible indiscriminately.
• Exportability: require an evidence pack that is readable outside the platform and links back to controls and findings. Block acceptance if exported files lack context or relationships.

Adapt these conditions to your risk appetite and scope; they are procurement criteria, not regulatory mandates.

Identity, ownership and handovers

The software must distinguish who uploaded evidence, who executed a control and who verified the outcome. These roles can coincide in some workflows, but the choice must be explicit—not hidden behind shared accounts.

In an acceptance test, change the owner of an open task and verify that the new owner finds the deadline, context and previously collected evidence, while the history still shows the actions of the former owner. Check how the product behaves when an account is deactivated: removing access should not anonymise historic activities needed for reconstruction. Ask the vendor how they balance data minimisation and forensic traceability and what configuration options exist.

For sensitive tasks, require a separation between execution and verification in the contract. If your team cannot provide a separate verifier, document the compensating control.

Audit trails and integrity: what to request

“We have logs” is not specific enough. Ask to see records of metadata edits, attachment replacements, status changes, approvals and permission changes that matter for your process.

Every piece of evidence should answer four questions: who acted, when, on what object and with what effect. A single ‘last updated’ timestamp does not reconstruct a sequence of decisions.

Review administrator capabilities separately: can admins delete events, retroactively change an approval or alter an already exported version? Don’t assume that “audit trail” implies immutability. Our article on best practices for verifiable audit trails (/en/blog/audit-trail-best-practices) explains how to specify these requirements without conflating application history and integrity guarantees.

Hashes are useful but limited: they show whether a file changed compared with a recorded fingerprint, but they don’t prove the original content was correct.

Link controls, evidence and anomalies

A credible evaluation checks that evidence is not just stored, but linked to the relevant control, the time period reviewed and the review outcome. A policy updated today does not prove a six‑month‑old control was executed.

The system should be able to mark evidence as collected versus verified, and mark items that have become obsolete. State labels matter less than clear operational definitions.

A robust evidence model also shows the relationship between a finding, the corrective action and the closure verification. Without that chain, many completed items may exist without proof the underlying problem was resolved. Ask for a full reconstruction of a case, not just a dashboard screenshot.

Vet the vendor before uploading real data

The service that will host documents and metadata must be assessed. Where the vendor processes personal data on your behalf, collect the Data Processing Agreement, the list of subprocessors, treatment locations and declared security measures. Referential articles of the GDPR (e.g., Article 28 on processors, Article 32 on security and Chapter V on transfers) are a useful checklist for what to collect; legal teams should evaluate contractual bases and guarantees.

On the technical side, request evidence on access control, incident response and backup & recovery procedures. Marketing statements such as “high security” are not a substitute for verifiable descriptions.

Server location in the EU simplifies parts of the analysis but does not conclude it: examine support access, subprocessors and real access patterns. If a vendor’s reply is incomplete, keep the requirement open rather than accepting an implied yes.

If the offer includes AI features

If the product includes AI, clarify which documents can be sent to the model, whether those inputs are retained by the AI provider, who may enable the feature and whether data may be used for training. A practical filtering approach—based on data criticality, integration and reversibility—helps frame selection questions but does not replace privacy risk assessment.

Specify how to distinguish AI‑generated summaries from approved documents. An automated summary can help reviewers but should not be treated as validated evidence simply because it appears in the evidence pack.

Design a repeatable acceptance test

Before signing, agree an isolated test environment with synthetic or minimised data. The acceptance test should follow a scripted checklist: input, action, expected result, observed result and any deviation.

Include your operational staff in the test, not only the vendor’s salesperson. Record which steps required vendor intervention, extra configuration or manual work outside the platform.

Test scenario: evidence modified after approval

Create an access review with owner, reviewer and deadline. Upload a synthetic user list, record a finding and associate a corrective action. After the reviewer approves, replace the attachment with an updated version.

The system must let you distinguish the file the reviewer examined from the later upload. Acceptable handling can include forcing a new review or clearly flagging that the approval applied to the prior version. The goal is to avoid ambiguous linkage between approval and evidence.

Export the case and ask a colleague who did not run the test to reconstruct the sequence. If they must call the owner to understand what happened, the evidence pack is not self‑sufficient.

Test scenario: closing a finding without proof

Open a finding for an unnecessary access and assign remediation to IT. Try to close the finding by adding only a comment such as “fixed”.

Acceptance does not require an automated block, but the closure must clearly indicate whether the access was removed and whether closure was verified. Check the ability to reopen a finding: the reason, new responsibility and deadline should remain linked to the original history. Creating a separate unrelated ticket makes it hard to tell whether the problem recurred.

Test scenario: export and offboarding

Request an export that includes attachments, identifiers, versions, responsibilities, states and relationships within the agreed scope. A readable PDF is useful for review but may be inadequate for migration.

Open the exported package without the platform. Ensure filenames are meaningful and an index or manifest allows mapping files back to controls. Reversibility—formats, timelines, costs and vendor support—must be negotiated up front. Ask how residual copies are handled after service termination and document these terms in the contract.

Score only after confirming blocking criteria

Do not let many secondary features compensate for a critical gap. Separate must‑have requirements from nice‑to‑have features before you compute any score.

A simple internal scale can help: 0 = requirement not demonstrated; 1 = achievable only with manual work outside the product; 2 = achievable with configuration; 3 = achievable in normal workflow. Keep evidence for each score and note dependencies (add‑on module, vendor work, internal procedure). If a blocking requirement remains unmet, stop the evaluation regardless of the total score.

Factor in total cost of ownership: migration, configuration, training, recurring owner work and export costs. A low license fee can be nullified by frequent manual reconciliations between spreadsheets, documents and ticketing systems.

Put test outcomes into contract and operations

Turn selection responses into operational references after purchase. Attach the scope, acceptance criteria, test outcomes and known limitations to the project file. Have legal and the relevant functions review contractual clauses.

Assign internal responsibilities: who maintains controls, who updates evidence, who verifies closures and who authorises access. No platform will fix a process without a designated owner.

For any accepted deficiency, document a temporary compensating measure, a deadline and proof of remediation. Avoid phrases like “will be handled during onboarding” without a named owner and a date.

Plan a verification after the first operational cycle: pre‑contract testing shows feasibility; the first real cycle shows whether evidence quality and ownership remain sustainable day‑to‑day.

Frequently asked questions

• Can a tool alone guarantee GDPR compliance? No. A platform can organise controls, responsibilities and evidence, but compliance also depends on processing decisions and the actual execution of measures. Vendor claims must be checked against your verified scope.

• Do I always need an immutable audit trail? Not universally. Define which events need reconstructability, who may change them and which protections are proportionate to the risk. Verify actual guarantees, not feature names.

• Are many templates enough to make a system auditable? Templates can help collect information, but auditability depends on links between controls, versions, responsibilities and verifications. A completed template is not, by itself, proof a control was executed.

• What if the vendor can’t demonstrate a declared function? Record the requirement as unverified. Request a repeatable demonstration or adequate documentation and assess the gap before signing. A roadmap item is not the same as a current capability.

Bring a full control to the demo

AuditReady centralises evidence with ownership, versions and an audit trail and supports management of controls, findings and remediation. The most effective way to assess fit is to bring a real, minimised control to the demo and verify the output you must deliver to an auditor.

Request a dedicated AuditReady GDPR demo (/auditready/lp/gdpr) that includes initial evidence, a finding, a corrective action and a final export. Use your acceptance criteria to validate the flow and surface any limitations before adoption.

audit-ready evidence pack demo / not legal advice