Compliance › Software

GDPR software features: 10 to test before you choose

GDPR software features only matter if they carry what the regulation requires. See the 10 features mapped to the GDPR, a demo scorecard and the red flags to watch for.

Watch video of features

A GDPR software dashboard with ten feature tiles and a scorecard for rating them in a demo

Anyone who has shortlisted GDPR software knows the feeling. Three vendors show three polished dashboards, all of them say "RoPA", "risk assessment" and "vendor management", and after the last demo nobody in the room can say what the real difference was.

The difference rarely sits in the feature list. It sits in whether each feature can carry what the regulation asks of you. A breach module that starts the 72-hour clock at the wrong moment is worse than no module at all.

This guide sets out the 10 GDPR software features that matter and ties each one to the article of the GDPR it supports. You then get a scorecard to take into your next demo, a worked example with three vendors and a list of red flags. If you are still deciding whether you need a tool at all, start with our article on whether you need GDPR compliance software.

The short answer: which GDPR software features matter?

GDPR software should help you document and maintain five things: what you process (the record under Article 30), why and for how long (lawful basis and retention), where the risk is (Articles 24, 32 and 35), who processes on your behalf (Article 28) and what happens when something goes wrong or an individual gets in touch (Articles 33-34 and 12-22). On top of that, the system has to assign tasks, control roles and keep a history, so you can demonstrate compliance under the accountability principle in Article 5(2).

Test every feature with a concrete scenario rather than a guided tour. And be sceptical of any vendor promising "automatic compliance". No software makes the legal judgements for you.

What GDPR software is, and what it is not

Searches for "GDPR software" and "best GDPR software" mix four different product categories. They solve different problems, and a vendor strong in one is rarely strong in the others. Our overview of what GDPR compliance software is covers them in depth.

Category	What it does	Typical GDPR articles	Covered here?
Documentation and management platform	Record of processing, risk assessments, DPIAs, processors, tasks, breach and rights logs	Art. 5(2), 24, 28, 30, 32-35	Yes, this is the main subject
Consent and cookie tool (CMP)	Cookie banner and consent records on websites and apps	Art. 7 and national ePrivacy rules	Only to draw the boundary
Data discovery and DLP	Scans systems for personal data and blocks unwanted sharing	Supports Art. 32	Only to draw the boundary
Secure communication and deletion tools	Encrypted email, automated deletion inside specific systems	Supports Art. 5(1)(e) and 32	No

The GDPR software features below belong to the first category, because that is what most compliance managers, DPOs and in-house lawyers mean by GDPR software. Cookie consent is a separate purchase, governed by national ePrivacy rules as well as the GDPR.

The 10 GDPR software features mapped to the regulation

The table shows each feature, the provision it supports and the fine tier a breach of that provision falls into under Article 83 of the GDPR (Regulation (EU) 2016/679). In most member states the supervisory authority imposes the fine itself. Denmark and Estonia are the exceptions, where fines are imposed by the courts under Article 83(9).

Feature	Supports	Fine tier (Art. 83)
1. Record of processing and data mapping	Art. 30(1)-(5)	Up to EUR 10m / 2% (Art. 83(4))
2. Purpose, lawful basis and retention	Art. 5(1)(b) and (e), Art. 6 and 9	Up to EUR 20m / 4% (Art. 83(5))
3. Risk assessment	Art. 24 and 32	Up to EUR 10m / 2% for Art. 32
4. Data protection impact assessment	Art. 35 and 36	Up to EUR 10m / 2%
5. Processors and vendors	Art. 28 and Art. 44-46	Art. 28: EUR 10m / 2%. Transfers: EUR 20m / 4%
6. Breach logging and notification	Art. 33 and 34	Up to EUR 10m / 2%
7. Data subject rights	Art. 12(3) and Art. 15-22	Up to EUR 20m / 4%
8. Task management and compliance calendar	Art. 24(1) and Art. 32(1)(d)	Depends on the obligation missed
9. Roles, access and group structure	Art. 32 and Art. 38(1)	Up to EUR 10m / 2%
10. Audit trail and reporting	Art. 5(2) and Art. 30(4)	Depends on the obligation you cannot evidence

Ten numbered GDPR software features, from record of processing to audit trail, each tagged with the GDPR articles it supports

1. Record of processing and data mapping (Article 30)

The record of processing activities is the backbone. Article 30(1) requires the controller to record, for each processing activity, the purposes, the categories of data subjects and personal data, the recipients, any third-country transfers and, where possible, the retention periods and a general description of security measures. Processors keep a shorter record of their own under Article 30(2).

The exemption in Article 30(5) for organisations with fewer than 250 employees falls away as soon as processing is not occasional, is likely to result in a risk, or includes special category or criminal offence data. The Article 29 Working Party's position paper on Article 30(5) of April 2018 made the point that an organisation regularly processing employee data is not processing occasionally. In practice the exemption rarely helps an organisation with staff and customers.

Look for a structure where processing activities, IT systems and vendors are separate objects linked to one another. You update a system once, and every activity that uses it follows. The data map should also show which data categories relate to which data subjects and recipients. Our guide to the record of processing activities covers the content requirements in detail.

2. Purpose, lawful basis and retention (Articles 5, 6 and 9)

Every processing activity needs a purpose and a lawful basis. Consent is one of six bases in Article 6(1), and far from the most common in an organisation with employees and business customers. Payroll typically rests on legal obligation and contract. Health data in a care setting typically rests on Article 9(2)(h). Explicit consent is only needed in specific cases under Articles 9, 22 and 49. A tool that only has a "consent" field was built for a different use case.

Retention is the feature most often missing. The storage limitation principle in Article 5(1)(e) means each category of data needs a defined period. The EDPB's coordinated enforcement action on the right to erasure, whose report was adopted on 18 February 2026, found that many controllers struggled to set retention periods and to deal with backups. The software will not delete data in your HR system, but it should record a period per data category and remind the owner to check that deletion happens.

3. Risk assessment (Articles 24 and 32)

Article 32 requires security appropriate to the risk to individuals. Encryption and pseudonymisation are examples, not requirements, so you need to show how you assessed the risk before you can justify your measures.

A good risk module assesses impact and likelihood for the data subjects, not only for the business. It should use one method for activities, systems and vendors and show residual risk after controls. Our article on information security risk management shows how one method can cover GDPR, NIS2 and ISO 27001 at once.

4. Data protection impact assessment (Article 35)

Where processing is likely to result in a high risk, Article 35 requires a DPIA. Article 35(7) sets four minimum elements: a systematic description, an assessment of necessity and proportionality, an assessment of the risks and the measures to address them. The EDPB-endorsed WP248 guidelines list nine criteria and say that processing meeting two or more of them will in most cases need a DPIA.

Test two things in the demo. Does the tool help with the initial screening, using WP248 and your national list? And does the template have a separate section on necessity and proportionality? Many templates jump straight to a risk matrix, which leaves out a mandatory element. If residual risk stays high, Article 36 requires prior consultation with the supervisory authority, and the tool should let you record it. Read more in our guide to the data protection impact assessment.

5. Processors and vendor management (Article 28)

A data processing agreement is only required with processors, meaning vendors that process personal data on your behalf and on your instructions. Not with every third party. Article 28 requires you to use only processors providing sufficient guarantees (Article 28(1)), to authorise sub-processors (Article 28(2) and (4)) and to secure audit rights in the contract (Article 28(3)(h)).

Oversight is where most organisations fall short. The EDPB's Opinion 22/2024 of October 2024 says controllers should have information on the identity of all processors and sub-processors in the chain readily available. A good vendor module can therefore record sub-processors, attach assurance reports such as ISAE 3000, schedule audits by risk and show third-country transfers with their transfer mechanism. Our articles on auditing data processors and third-country transfers go deeper.

6. Breach logging and notification (Articles 33 and 34)

Data protection authorities across Europe received an average of 443 breach notifications a day between 28 January 2025 and 27 January 2026, up 22% on the year before, according to the DLA Piper GDPR Fines and Data Breach Survey of January 2026.

Article 33(1) requires notification to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the breach, unless it is unlikely to result in a risk. Under Article 34, individuals must be told without undue delay when the breach is likely to result in a high risk to them. The 72 hours apply to the regulator, not to the individuals. And Article 33(5) requires every breach to be documented, including those you do not notify.

The feature needs a field for the moment you became aware, a risk assessment that leads to a documented decision on notification, and a log of all breaches. The EDPB adopted a common breach notification template on 10 June 2026 and consulted on it until 5 August 2026, so ask whether the vendor plans to align its fields with it. If you are also in scope of NIS2, the same incident may trigger reporting at 24 hours, 72 hours and one month. See our article on security breaches.

7. Data subject rights (Articles 12-22)

The deadline is one month, not 30 days. Article 12(3) requires a response without undue delay and at the latest within one month of receipt. It can be extended by two further months where requests are complex or numerous, but the individual must be told of the extension within the first month. A tool counting 30 days gets it wrong in most months of the year.

The EDPB's coordinated action on the right of access, reported on 20 January 2025 after 30 authorities examined 1,185 controllers, named the lack of documented internal procedures as a key problem. The feature should log each request (access under Article 15, rectification, erasure, restriction, portability, objection), the identity check, the deadline and the response. Our article on the data subject access request covers the process.

8. Task management and compliance calendar (Article 24)

Article 24(1) requires measures to be reviewed and updated where necessary. Article 32(1)(d) requires a process for regularly testing and evaluating them. Both say that compliance is recurring work, and recurring work needs a feature that plans it.

Look for recurring tasks with owners, deadlines, reminders and evidence attached on completion. The most revealing test is whether a colleague outside the compliance team can complete a task without training.

9. Roles, access and group structure (Articles 32 and 38)

Once documentation is spread across the organisation, the system itself has to meet Article 32. That means role-based access, so an HR manager can edit HR activities without seeing the whole vendor portfolio. Article 38(1) requires the data protection officer to be involved properly and in a timely manner, so the DPO should be able to read everything and comment. The record of processing is the controller's duty, not the DPO's, and the roles in the tool should reflect that.

If you run several legal entities, test whether documentation can be shared at group level whilst staying separate per entity, because each entity is a controller in its own right.

10. Audit trail and reporting (Article 5(2))

The accountability principle in Article 5(2) is one of the seven GDPR principles and requires you to be able to demonstrate compliance. Article 30(4) requires the record to be made available to the supervisory authority on request. The software must therefore export the record in a readable format and show who changed what, and when.

Reporting to management is the other half. A status per entity on open tasks, risks and vendor audits helps the board carry its Article 24 responsibility.

Scorecard: how to test GDPR software features in a demo

A demo run by the vendor shows what works best. Send your own scenarios a week in advance and ask the vendor to solve them live. Score on a scale of 0 to 3: 0 is not supported, 1 is possible with a workaround, 2 is supported, 3 is supported and easy for a non-specialist.

Feature	Ask the vendor to show	Pass when	Suggested weight
1. Record of processing	Create a recruitment activity with two systems and one vendor	Data categories link to data subject categories and recipients, and the record exports	15
2. Lawful basis and retention	Record payroll on legal obligation and contract, and health data under Art. 9	Several bases per activity, Art. 9 conditions and a retention period per data category	10
3. Risk assessment	Assess a CRM system and show residual risk after controls	Impact on individuals, residual risk and the same method for systems and vendors	10
4. DPIA	Start a DPIA for a new AI tool in HR	Screening step, section on necessity and proportionality, option to record Art. 36 consultation	10
5. Processors	Add a cloud vendor with two sub-processors, one outside the EEA	Sub-processors, transfer mechanism, assurance reports and a risk-based audit plan	15
6. Breach	Log a misdirected email containing ID numbers at 4pm on a Friday	Time of awareness, calculated 72-hour deadline, documented decision and a log of unnotified breaches	10
7. Rights	Log an access request received on 31 January	Deadline calculated as one month, extension recordable, identity check logged	5
8. Calendar	Set up an annual HR record review with a reminder	Recurring task, owner, reminder and evidence on completion	10
9. Roles and group	Give an HR manager access to HR activities in one entity	Role-based access, read access for the DPO and separation per entity	10
10. Audit trail	Show who changed a retention period last week	Field-level change log and export to a management report	5

The weights are a starting point. Many consumer customers means rights should weigh more. Eighty processors means the vendor module should. Set the weights before the first demo, or you will end up weighting whatever the last vendor did well.

Run the process like this:

Agree the weights and any knockout criteria in the project group.
Send the 10 scenarios to the vendors at least a week before the demo.
Have someone outside the compliance team try at least two tasks themselves.
Score each vendor independently straight after the demo.
Compare weighted scores and knockout criteria, then take up references with the leader.

Five steps for testing GDPR software in a demo, from agreeing weights to comparing scores, with the 0-3 scoring scale below

Worked example: three vendors on the scorecard

Harbourline Freight B.V. and Anna de Vries are fictional. We invented them for this article, and vendors A, B and C are not real products.

Harbourline Freight has 430 employees across three EU entities and uses around 60 processors, several of which rely on sub-processors in the United States. Its customers are businesses, so it receives few access requests. Anna de Vries is the compliance manager and keeps the record of processing in a spreadsheet with 14 tabs. She uses the weights from the table above and sets one knockout criterion: the system must record sub-processors, because Harbourline cannot meet Article 28(2) and (4) otherwise.

Feature (weight)	Vendor A	Vendor B	Vendor C
1. Record of processing (15)	3	2	3
2. Lawful basis and retention (10)	2	1	3
3. Risk assessment (10)	2	3	1
4. DPIA (10)	2	3	1
5. Processors (15)	3	1	2
6. Breach (10)	2	3	1
7. Rights (5)	1	3	2
8. Calendar (10)	3	2	1
9. Roles and group (10)	3	1	2
10. Audit trail (5)	2	3	1
Weighted total (max. 300)	245	205	180
Score as a percentage	81.7%	68.3%	60.0%
Knockouts and red flags	None	Cannot record sub-processors	Breach module has no field for time of awareness

The score is weight times points, summed and divided by 3. Vendor B was the strongest in the room on DPIAs, breaches and rights, and nearly won Anna over. But B failed the knockout, because sub-processors could only be noted in a free-text field. For an organisation with 60 processors, that is not a detail.

Vendor C had the best record of processing, but its breach module counted 72 hours from when the incident was logged rather than from when Harbourline became aware of it. Anna chose A and wrote its two weakest points into the contract as roadmap commitments.

Bar chart: fictional vendor A scores 81.7% and is chosen, B 68.3% fails the sub-processor knockout, C 60.0% has a red flag

Red flags in a demo

Some claims about GDPR software features tell you more about the vendor than the screens do.

Red flag	Why it is a problem
"Our system makes you GDPR compliant automatically"	Compliance needs legal judgements on lawful basis, proportionality and risk. No software makes them for you
"The 30-day response deadline"	Article 12(3) says one month, extendable by two. Wrong deadlines in the tool become wrong deadlines in practice
"GDPR requires consent before you process data"	Consent is one of six bases in Article 6. A vendor who believes otherwise has built the wrong data model
"We automatically discover all your personal data"	Discovery needs integrations and produces false positives. The record still needs purposes and bases, which no scanner finds
The 72-hour clock starts when the breach is logged	Article 33 counts from when you became aware of the breach
The DPIA template is just a risk matrix	Article 35(7)(b) requires an assessment of necessity and proportionality
No export of the record of processing	Article 30(4) requires it to be available to the regulator, and you need your data back if you switch
Per-user pricing that makes inviting colleagues expensive	Documentation improves as more system owners contribute. A price model that penalises this works against features 8 and 9
The vendor cannot say where your data is hosted	Then the vendor is itself a processor you cannot oversee

What GDPR software will not do for you

Even the best GDPR software is a tool for documentation and management. It does not choose your lawful basis, delete records in your payroll system or detect an intrusion on your network. Nor does it replace the DPO or legal advice.

Software can also create false comfort. A record of 200 activities nobody has reviewed in two years is worse than a spreadsheet, because it looks up to date. The value arrives when the tool is tied to a compliance calendar and system owners actually log in. If you are still weighing up a spreadsheet, see our comparison of GDPR in Excel or software.

What may change in the rules?

On 19 November 2025 the European Commission tabled its Digital Omnibus proposal, which would among other things raise the breach notification threshold to high risk, extend the deadline to 96 hours and create a single reporting entry point across GDPR, NIS2 and DORA. In May 2025 the Commission's Omnibus IV package had already proposed extending the Article 30(5) exemption to organisations with fewer than 750 employees, unless the processing is likely to result in a high risk. None of these GDPR amendments had been finally adopted as of September 2026.

Meanwhile, 25 supervisory authorities are taking part in the EDPB's 2026 coordinated enforcement action on transparency under Articles 12-14, launched on 19 March 2026, and the common breach notification template awaits a decision on implementation. For GDPR software features this means one thing: deadlines, thresholds and fields must be configurable, so you are not waiting for a new release when the rules change.

Timeline May 2025 to September 2026: Omnibus IV and Digital Omnibus proposals, EDPB enforcement and breach template, nothing adopted yet

How .legal supports your GDPR programme

.legal is built around the same objects this article describes. In the GDPR module you map processing activities, systems and vendors and link them together, so the record of processing is built from your data mapping rather than maintained alongside it. Risk assessments use an impact and likelihood method and apply to activities, systems and vendors alike.

The vendor side is covered by Vendor Management, where data processing agreements, assurance reports and risk assessments sit together, and where you can plan audits of your data processors. Recurring work is planned in compliance task management with owners and reminders, and the platform supports group structures and role management. If you also work with NIS2 or ISO 27001, documentation can be reused through Frameworks.

We suggest you hold .legal to the same scorecard as every other vendor. Book a demo, send us your scenarios in advance, and see our pricing.

Frequently Asked Questions About GDPR Compliance Software Features

What is the best GDPR software?

There is no single best tool for everyone. The best GDPR software for you is the one that passes your own test scenarios on the record of processing, processors, breaches and rights, and that colleagues will actually use. Weight the features by your risk profile before any demo. An organisation with many consumers has different needs from a B2B firm with hundreds of vendors.

What is the difference between GDPR software and a cookie consent tool?

GDPR software documents and manages your data protection programme: the record of processing, risk assessments, DPIAs, processors and breaches. A consent management platform shows the cookie banner on your website and records visitors' choices. Cookies are governed by national ePrivacy rules together with the GDPR. Most organisations need both, but they are separate purchases with separate evaluation criteria.

Can GDPR software create the record of processing automatically?

Partly. The software can generate the record from the processing activities, systems and vendors you have registered, and keep it current when a system changes. It cannot decide purposes, lawful bases or retention periods for you. Those need a judgement from the people who own the process. Discovery tools that scan systems for personal data can support the work, but they do not replace it.

Do organisations with fewer than 250 employees need a record of processing?

In most cases, yes. The Article 30(5) exemption only applies where processing is occasional, unlikely to result in a risk and excludes special category or criminal offence data. Payroll and HR are not occasional. The Commission has proposed raising the threshold to 750 employees, but that change had not been finally adopted as of September 2026.

How long do you have to respond to a subject access request?

One month from receipt under Article 12(3). You can extend by two further months where the request is complex or you receive many, but you must tell the individual about the extension and the reasons within the first month. The deadline is not 30 days, and your tool should calculate it correctly, including for requests received at the end of a month.

Does the 72-hour deadline also apply to telling affected individuals?

No. The 72 hours in Article 33 apply to notifying the supervisory authority and run from when you became aware of the breach. Under Article 34, individuals must be told without undue delay when the breach is likely to result in a high risk to them. Every breach must be documented internally, including those you decide not to notify.

Do you need a data processing agreement with every vendor?

No, only with processors, meaning vendors that process personal data on your behalf and on your instructions. A payroll bureau or a cloud host is typically a processor. An auditor or a travel agency deciding its own purposes is usually an independent controller. GDPR software should let you record the role, so you do not sign agreements that do not fit the relationship.

Can GDPR software replace a data protection officer?

No. If you must appoint a DPO under Article 37, it has to be a person or function with expert knowledge and an independent position. The software can give the DPO an overview, assign tasks and document advice. It cannot monitor compliance or advise management on the DPO's behalf, which are the tasks Article 39 sets out.

How do you switch GDPR software without losing documentation?

Require in the contract that all data can be exported in a structured format, including history and attachments. Export the record of processing, risk assessments and processor register before the old agreement ends, and clean the data before importing, so outdated activities do not move across. Ask the new vendor whether they can import from your current format.

What should a DPIA template in GDPR software contain?

At least the four elements in Article 35(7): a systematic description of the processing, an assessment of necessity and proportionality, an assessment of the risks to individuals and the measures to address them. The template should also record the DPO's advice and allow you to log prior consultation with the supervisory authority under Article 36 where high risk remains.