GDPR Compliance Software

GDPR compliance software is the category of tools that help organisations document, automate, and demonstrate conformance with the General Data Protection Regulation. It spans consent management, data subject request handling, records of processing activities (ROPA), data mapping, and breach notification workflows.

This guide covers what the software must do, how to evaluate vendors, what implementation looks like in practice, and the criteria that determine whether a tool will survive an audit.

What GDPR compliance software must do

The Regulation imposes obligations on controllers and processors. Software earns its place only if it reduces the manual effort required to meet those obligations — and produces evidence that auditors can inspect.

The six functions that matter in practice:

1. Consent management

Capture, store, and honour individual consent choices at the point of collection. A consent management platform (CMP) records the exact wording shown, the timestamp, the version of the privacy notice, and the channel. Consent must be withdrawable as easily as it was given — the software must propagate withdrawals downstream to every system that acts on that consent.

2. Data Subject Access Requests (DSAR)

Article 15–22 gives individuals rights to access, rectify, erase, and port their data. The software needs a ticketed workflow with a 30-day deadline tracker, automated data discovery across systems, and a redaction layer for third-party data before responses go out.

3. Records of Processing Activities (ROPA)

Article 30 requires controllers with more than 250 employees (and processors in certain situations) to maintain a ROPA. This is a live inventory: processing purpose, lawful basis, data categories, retention period, third-party transfers, and safeguards. Spreadsheets fail here because they go stale. Software that auto-discovers processing activities from integrations is materially better than one requiring manual entry.

4. Data mapping and transfer impact assessments

Cross-border transfers to non-adequate countries require a Transfer Impact Assessment (TIA) since the Schrems II ruling invalidated Privacy Shield. Software that maps data flows and flags transfers that cross an adequacy threshold saves weeks of manual work during each assessment cycle.

5. Breach notification

Article 33 requires notification to the supervisory authority within 72 hours of becoming aware of a breach. The software must support incident logging, severity classification, and notification drafting — ideally with a regulatory calendar that tracks which authority in which jurisdiction has which obligation.

6. Audit evidence packaging

Supervisory authorities do not inspect dashboards. They request documentation: processing registers, consent records with timestamps, TIAs, DPIAs, and DSAR logs. Software that can export these in a structured format — not screen captures — reduces audit response time from weeks to hours.

How GDPR maps onto CRM systems

Most GDPR enforcement in B2B contexts is a CRM problem. CRM systems hold contact records, interaction histories, and marketing consent — the three categories with the most regulatory surface area.

GDPR obligation	CRM configuration required
Lawful basis documented per contact	Custom field on contact record; basis recorded at point of capture
Consent stored with timestamp + notice version	Linked consent record, not a checkbox field
Right to erasure honoured cross-system	Erasure event triggers API call to every connected tool
Marketing suppression enforced	Opt-out status synced to email, SMS, and ad platforms in real time
Data retention enforced	Automated archival or deletion based on last-interaction date
DSAR response	Contact data export includes all interaction records, enrichment sources, and consent history

The failure pattern is not usually missing fields — it is consent captured but not honoured downstream. A contact marked as withdrawn in the CRM continues receiving email because the marketing automation platform has a separate suppression list that was not updated. Software that does not enforce cross-system propagation is not GDPR-compliant regardless of what the consent capture looks like.

Selection criteria

Evaluate GDPR compliance software against these five criteria:

1. Integration depth

A compliance tool that cannot read your CRM, marketing platform, and data warehouse is a documentation tool, not a compliance tool. Evaluate the connector library against your actual stack. Native connectors with real-time sync are materially better than CSV imports.

2. Evidence portability

Can the system export consent records, ROPA entries, and DSAR responses in a format a supervisory authority will accept? XML and JSON exports are standard. Proprietary formats are a lock-in risk and an audit risk simultaneously.

3. Multi-jurisdiction support

GDPR is the baseline, but UK GDPR, Swiss nDSG, and national implementations vary. If you operate in multiple jurisdictions, the software must maintain separate consent models and notice versions per jurisdiction without requiring a separate instance.

4. Processor/controller separation

If your organisation acts as both a controller and a processor for different clients, the software must model both relationships. A single-mode tool will require workarounds that introduce audit gaps.

5. Audit trail immutability

Consent records and ROPA entries must be immutable after the fact — editable by designated administrators, but with a full change history that cannot be deleted. This is not a nice-to-have; a supervisory authority can request historical records going back to May 2018.

Implementation sequence

A GDPR compliance software implementation is not a configuration project — it is a data discovery and governance project with a software component.

Phase 1 — Data inventory (weeks 1–4)

Identify every system that holds personal data. Include CRM, marketing automation, support platforms, finance systems, HR, and any third-party processors. This inventory becomes the input to the ROPA and the data mapping exercise.

Phase 2 — Lawful basis mapping (weeks 3–6)

For each processing activity identified, document the lawful basis: consent, contract, legal obligation, vital interests, public task, or legitimate interests. Where the basis is legitimate interests, complete a Legitimate Interests Assessment (LIA). This is the step most implementations skip, and it is the most common audit finding.

Phase 3 — Consent architecture (weeks 5–10)

Design the consent model: granularity, withdrawal mechanism, downstream propagation. This is where CRM configuration intersects with the CMP. If consent is captured in a form platform and stored in the CRM, both systems must hold the same record.

Phase 4 — DSAR workflow (weeks 8–12)

Configure the intake form, the routing rules, the 30-day tracker, the data discovery query, and the response assembly workflow. Test with synthetic DSARs across each data category.

Phase 5 — Ongoing: ROPA maintenance and breach readiness

Schedule ROPA reviews quarterly. Ensure the incident log is accessible to the DPO and the legal team. Maintain regulator contact lists for each jurisdiction.

Common failure modes

Consent captured but not honoured. Withdrawal updates the CMP but not the downstream email platform. Contact continues receiving marketing. This is the most common enforcement trigger because it is visible to the data subject.

ROPA maintained as a spreadsheet. Stale within weeks of a system change. A live ROPA requires integration with the systems that do the processing — manual maintenance at scale is not credible to an auditor.

DSAR handled without legal review. Responses that include third-party data, or that erase data subject to a legal hold, create liability in the opposite direction. The workflow must include a legal review gate.

No TIA for sub-processors in non-adequate countries. Standard Contractual Clauses alone are not sufficient post-Schrems II. A TIA is required for every transfer. Software that does not prompt for TIAs when a cross-border transfer is logged is leaving the hardest part of the work to manual process.