What is GDPR compliance software? The six types and what each one solves
GDPR compliance software is not one product but six categories of tools, each covering a different part of the regulation. See what they do, which GDPR articles they support and what none of them solve.
Ask ten vendors what GDPR compliance software is and you will get ten different answers. One sells a cookie banner, another a data scanner, a third a platform for records and assessments. All of them call it GDPR software. They are not wrong, but they are not describing the same thing.
This article sorts the market into its six categories, maps each one to the GDPR articles it supports and is candid about what each cannot do. It is not a buyer's guide. If you want to know which features matter, read our article on features in GDPR compliance software. If you are still deciding whether you need software at all, start with do you need GDPR compliance software.
The short answer: what is GDPR compliance software?
GDPR compliance software is any tool that helps a controller meet and evidence its obligations under the General Data Protection Regulation. In practice the term covers six categories: GRC and privacy management platforms for records, assessments, processor contracts and breaches, consent management platforms for cookies, DSAR tools for data subject requests, vendor management for suppliers and processors, data discovery that finds personal data across your systems, and DLP that stops it leaving the organisation.
None of them makes you compliant on its own. Under Article 5(2) and Article 24(1) GDPR, the controller must be able to demonstrate compliance, whatever tools it uses. Software supports that work. It does not replace it.
Six categories sold under one label
The market took off in the run-up to 25 May 2018, when the GDPR began to apply. When the IAPP started cataloguing privacy tech vendors in 2017, its list grew from 51 to 99 vendors between January and October that year. The categories have become clearer since, but vendors still use the same words for very different products.
The table shows the six categories you are most likely to meet when you look for GDPR compliance software.
| Category | What it does | Mainly supports | Does not solve |
|---|---|---|---|
| 1. GRC and privacy management | Holds the record of processing, DPIAs, processor agreements, breach log, policies and tasks in one place | Articles 5(2), 24, 28, 30, 33(5) and 35 | Does not find data in your systems or stop any leak |
| 2. Consent management (CMP) | Shows the consent banner, holds back non-essential cookies until consent and logs choices | ePrivacy Directive Article 5(3), GDPR Article 7(1) | Anything that happens to the data after collection |
| 3. DSAR | Receives, verifies, routes and answers data subject requests within the deadline | Articles 12 and 15 to 22 | Does not know where the data sits |
| 4. Vendor management | Supplier register, risk rating, questionnaires, audits and contracts | Article 28, Chapter V, NIS2 Article 21(2)(d) | Does not make the supplier secure. A completed questionnaire is not evidence |
| 5. Data discovery | Scans databases, file shares, email and cloud for personal data and classifies what it finds | Article 5(1)(c) and (e), Article 15, an accurate record | Knows nothing about purpose or lawful basis, and produces false positives |
| 6. DLP | Monitors and blocks outbound data by rule, for example national ID numbers in email | Article 32 | Documents nothing, and raises its own questions about employee monitoring |
Analysts use other labels. Forrester calls the first category "privacy management software", and when the same platform also covers ISO 27001 and NIS2 it is usually called GRC software. The label matters less than the question of which obligation a tool actually helps you meet.
What GDPR compliance software is not
Searches on this topic often blur four different things: the law, a standard, a certification and the software itself. That creates the wrong expectations, so here they are side by side.
| Term | What it is | What it means for you |
|---|---|---|
| GDPR | Regulation (EU) 2016/679, adopted 27 April 2016 and applicable from 25 May 2018. Covers processing of personal data of people in the EU/EEA (Article 3) | You comply with it. You cannot install it |
| National law | Each Member State adds its own data protection act and transposes the ePrivacy Directive | Rules on cookies, employee data and fines differ by country |
| ISO/IEC 27701:2025 | International standard for a privacy information management system (PIMS). Published 14 October 2025 and now a standalone standard | A voluntary, certifiable framework. Not the same as complying with the GDPR |
| Article 42 certification | Certification of specific processing operations under approved schemes, such as the Europrivacy seal | Covers processing operations, not the organisation as a whole |
| GDPR compliance software | Tools that support meeting and evidencing obligations | A tool. Accountability stays with the controller |
Two consequences follow. First, no vendor can deliver "automatic GDPR compliance". The regulation requires judgements only you can make: the purpose, the lawful basis under Article 6, necessity and risk. Software can structure those judgements, track the deadlines and keep the evidence.
Second, the vendor of your GDPR tool is often a processor itself. A DSAR tool holds data about the people who made requests, and a CMP stores consent logs with online identifiers. That calls for a data processing agreement under Article 28(3), and the vendor belongs in your record and your processor audits.
GRC and privacy management: the backbone
The first category is what most people mean by GDPR compliance software. It holds the documentation for the whole data protection programme and lets you show that you comply. It is the accountability principle in Article 5(2) turned into practice.
What the category covers
The core is the record of processing activities under Article 30. It is the controller's duty, not the DPO's. The exemption in Article 30(5) for organisations with fewer than 250 employees falls away when processing is not occasional, is likely to result in a risk or includes special categories of data. In practice most organisations with 50 or more employees need a record.
Around the record sits the rest of the documentation. Data protection impact assessments under Article 35 when processing is likely to result in a high risk. Processor agreements under Article 28. Policies, awareness training and recurring controls in an annual cycle. And a log of every personal data breach, because Article 33(5) requires you to document all breaches, including those you do not have to notify.
The breach log is not a formality. DLA Piper's GDPR fines and data breach survey, published in February 2026, counted an average of 443 breach notifications a day across the countries it surveys between 28 January 2025 and 27 January 2026. That is up 22% from 363 the year before and the first time the daily average has passed 400. Notification to the supervisory authority is due within 72 hours under Article 33(1). Data subjects must be told without undue delay under Article 34 when the breach is likely to result in a high risk to them. Our article on security breaches covers the handling in detail.
What the category does not solve
A GRC platform is only as good as what goes into it. It will not notice that marketing has started using a new newsletter tool, or that there are twelve-year-old job applications on a shared drive. It blocks no cookies and stops no emails. Its strength is structure, reuse and overview. Its weakness is documentation that goes stale when nobody owns the tasks.
Many organisations begin this category in spreadsheets. We compare the two approaches in GDPR in Excel or software. If your needs also include ISO 27001 and NIS2, see our overview of GRC software.
Consent management platforms: consent on the website
A consent management platform (CMP) is the cookie banner you meet on most websites. It presents the choices, holds back non-essential cookies and similar technologies until the visitor consents, and keeps a log of the choices.
The legal basis is not the GDPR alone. The consent requirement for storing or accessing information on a user's device comes from Article 5(3) of the ePrivacy Directive (2002/58/EC), transposed into national law in every Member State. The GDPR supplies the definition of consent and governs the personal data processing that follows. Because each country transposes the directive itself, the enforcing authority varies. In many Member States it is the data protection authority. In Denmark, for example, the Agency for Digital Government supervises the cookie rules, whilst the Danish DPA handles the personal data side.
The EDPB's Guidelines 2/2023 on the technical scope of Article 5(3), adopted in final form in October 2024, confirm that the rule is technology neutral. It reaches tracking pixels, URL tracking and similar techniques, not only cookies.
Consent must meet the GDPR definition in Article 4(11): freely given, specific, informed and unambiguous. Refusing must be as easy as accepting. It does not have to be "explicit". That stricter standard applies to special category data under Article 9(2)(a) and to transfers under Article 49(1)(a). Strictly necessary cookies, such as those for login or a shopping basket, need no consent. And consent is only one of the six lawful bases in Article 6.
The rules may change. On 19 November 2025 the European Commission tabled the Digital Omnibus proposal, COM(2025) 837, which among other things would move the cookie rules into the GDPR as new Articles 88a and 88b and give browser-level consent signals legal effect. The proposal is still before the European Parliament and the Council and had not been adopted as of September 2026, according to the Parliament's legislative train.
What a CMP does not solve: everything that happens to the data afterwards. Analytics data in a CRM, retargeting audiences and sharing with advertising partners are processing activities that belong in the record and need a lawful basis. A banner does not touch HR data, customer service or suppliers. Read more on consent and the GDPR.
DSAR tools: data subject requests
DSAR stands for data subject access request. A DSAR tool handles requests under Articles 15 to 22: access, rectification, erasure, restriction, portability and objection. It typically offers an intake portal, identity checks, deadline tracking, collection from connected systems, redaction of third-party data and an archive of responses.
The deadline sits in Article 12(3): 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, and the data subject must be told within the first month.
The right of access is where regulators have looked most closely. In 2024, 30 European supervisory authorities examined how 1,185 controllers handled it. The EDPB report of 20 January 2025 identified seven challenges, among them a lack of documented internal procedures and excessive identification demands. Large controllers and those receiving many requests did best, and self-service download options were singled out as good practice. The EDPB's Guidelines 01/2022 on the right of access remain the reference point.
What a DSAR tool does not solve: it does not know where the data sits. Without an up-to-date record or a scan of your systems, it can only pull from the systems someone has connected. The legal assessment of restrictions, such as Article 15(4) and national exemptions, is still a human call. See our guides to data subject access requests and data subject rights.
Vendor management: suppliers and processors
Vendor management tools keep track of suppliers: who they are, what data they touch, how risky they are and when they were last assessed. For GDPR purposes the core is your processors.
Article 28(1) allows you to use only processors that provide sufficient guarantees. Article 28(3)(h) gives you the right to audits and inspections. The GDPR does not set a frequency, so most organisations scale the depth and cadence of audits to the risk each processor presents. The requirement for a processing agreement applies to processors only. An auditor, a bank or another business acting as an independent controller does not need one. Where a supplier or its sub-processors sit outside the EU/EEA, the third-country transfer rules in Chapter V apply.
The category overlaps with NIS2. Directive (EU) 2022/2555 requires essential and important entities to manage supply chain security under Article 21(2)(d). Suppliers are not covered directly, but they receive those requirements through their customers. Transposition is national and uneven. Denmark's NIS2 act, for example, has applied since 1 July 2025. One supplier register can serve both regimes.
What vendor management does not solve: it does not make a supplier secure. A completed questionnaire is the supplier's own claim. For your most critical processors you need independent assurance, such as an ISAE 3000 report, and a judgement on whether it covers your processing. Our article on auditing data processors explains how to scale that work.
Data discovery: finding the personal data
Data discovery tools connect to databases, file shares, email and cloud services and look for personal data. They use patterns such as national ID numbers, email addresses and account numbers, and they classify findings by sensitivity. The result is a technical picture of where the data actually is.
That supports several GDPR requirements. Data minimisation and storage limitation in Article 5(1)(c) and (e) are hard to meet if you do not know what sits on the shared drive. An access request under Article 15 requires you to find the data. And a record built only on interviews tends to miss the systems nobody thinks about. Read more on data discovery.
Data discovery is often confused with data mapping. Discovery is a technical scan that answers where. Mapping documents processing activities, data flows and purposes, and answers why and on what basis. A national ID number in a file does not tell you whether it should be there.
What data discovery does not solve: purpose, lawful basis and retention period. The tools also produce false positives, and the scan itself is processing of personal data that needs wide access rights. It should be scoped and documented.
DLP: stopping data leaving the organisation
Data loss prevention (DLP) monitors data in motion and at rest on endpoints, in email and in cloud services. Rules can block an email carrying ID numbers to an external recipient, or prevent a customer list being uploaded to a personal cloud account. DLP is a security control, not a documentation tool.
Article 32 GDPR requires appropriate technical and organisational measures based on risk. It names pseudonymisation and encryption as examples. It does not name DLP. DLP can be an appropriate measure if your risk assessment points to misdirected emails or data exfiltration as a real threat. Read more on data loss prevention.
What DLP does not solve: it evidences nothing to a regulator, and it raises GDPR questions of its own. A tool that reads employees' email and files is processing personal data about those employees. That needs a lawful basis, transparency under Article 13 and often a DPIA under Article 35. National employment rules may add further limits.
How the categories cover the core obligations
Line the categories up against the regulation's obligations and a pattern appears. The table shows which category carries each requirement and which one helps.
| Obligation | Legal source | Primary category | Supporting category |
|---|---|---|---|
| Record of processing | GDPR Article 30 | GRC and privacy management | Data discovery |
| DPIA | GDPR Article 35 | GRC and privacy management | None |
| Processor agreements and audits | GDPR Article 28 | Vendor management | GRC and privacy management |
| Access and erasure | GDPR Articles 12, 15 and 17 | DSAR | Data discovery |
| Cookie consent | ePrivacy Directive Article 5(3), national law | Consent management | GRC (the processing that follows) |
| Transparency | GDPR Articles 13 and 14 | GRC (the record as source) | Consent management (cookie notice) |
| Security of processing | GDPR Article 32 | DLP and other technical tools | GRC (risk assessment and policies) |
| Personal data breaches | GDPR Articles 33 and 34 | GRC (breach log and notification) | DLP (prevention) |
| International transfers | GDPR Articles 44 to 49 | Vendor management | GRC and privacy management |
The GRC layer appears in almost every row. That is because accountability in the GDPR means being able to demonstrate. The other categories perform a task, but it is the documentation that shows a regulator the task was done. That is why most organisations start with the first category and add specialist tools when volume or risk makes it necessary.
A worked example: which tools does Harbourline need?
Harbourline Logistics and Anna de Vries are fictional. We invented them for this article, and they are neither customers nor a case study.
Harbourline Logistics has 180 employees across three EU countries, a web shop and a customer portal. It uses 42 suppliers, of which 17 are processors and three sit outside the EU/EEA. It receives around 30 access requests a year, mostly from former employees. Its shared drives hold HR folders dating back to 2013. Anna de Vries is the data protection officer (DPO) and has been asked which GDPR compliance software the company is missing.
She works through the categories one by one and tests each against what the business actually needs.
| Category | Need at Harbourline | Anna's assessment |
|---|---|---|
| GRC and privacy management | Record of processing (180 staff, no exemption), 17 processor agreements, breach log | Essential. Start here |
| Consent management | Web shop and customer portal in three countries | Already in place via the web agency. Check the reject option and national rules in each market |
| DSAR | About 30 requests a year | Too few for a dedicated tool. A documented procedure with deadline tasks in the GRC platform is enough |
| Vendor management | 17 processors, three in third countries, NIS2 demands from two customers | Essential. Risk-based audits of the five most critical each year |
| Data discovery | HR folders from 2013 on shared drives | One scoped clean-up project, not a permanent licence |
| DLP | Two misdirected payslip emails in 2025 | The existing email platform has DLP rules. Switch them on and update the DPIA on employee monitoring |
The outcome is one core platform with a vendor module, one scoped scanning project and better use of a tool the company already owns. Not six licences. Had Harbourline received 3,000 requests a year instead of 30, or run a large consumer web shop with many advertising partners, the picture would look different.
The point of the example is that the categories answer specific obligations. The need is driven by the number of data subjects, the number of processors and the risk in the processing, not by a vendor's product page. How to choose a vendor once you know the need is covered in our guide to buying GDPR compliance software.
What is shifting in 2026
Three developments affect how the categories are used right now.
Transparency is under the spotlight. On 19 March 2026 the EDPB launched its coordinated enforcement action for the year, focused on transparency and information duties under Articles 12, 13 and 14. 25 authorities are taking part. A privacy notice that does not match the record of processing is exactly what such a review finds. A GRC platform in which the record feeds the notices helps here.
The cookie rules may move into the GDPR. If the Digital Omnibus is adopted as proposed, CMPs will need to honour browser consent signals. Until then the ePrivacy Directive and its national transpositions apply.
ISO/IEC 27701:2025 now stands on its own. Organisations that want to show a structured privacy programme without first holding ISO 27001 can use it as a framework. That raises demand for platforms that map one control to several frameworks. UK organisations work under the UK GDPR and PECR, but the six categories and their limits are the same.
How .legal supports GDPR compliance
.legal sits in the first category: GRC and privacy management. The platform's GDPR module brings the Article 30 record, risk assessments, DPIAs, processor agreements, security measures and policies into one place, and Data Mapping links processing activities to systems and suppliers, so transparency notices and access requests start from the same source.
Suppliers are covered by Vendor Management and, if you want help with the audits themselves, by our data processor audit service. Recurring work such as the annual review of the record, awareness and supplier audits runs through compliance task management. If you also work with ISO 27001 or NIS2, Frameworks reuses the same controls across them.
For cookie banners, DLP and technical scanning of file servers you will use specialist tools alongside. The platform is where those tools are documented in the record, the risk assessments and the supplier register. Book a demo if you want to see how it fits together in practice.
.png?width=600&height=400&name=securitybreach-feature%20(1).png)
.legal compliance platform
Experience GDPR Compliance Software in Action
-
Complete Records of Processing Activities (ROPA) automation
-
Cross-border data transfer management and documentation
-
Role-based dashboards for DPOs and compliance teams
-
Continuous regulatory updates built into the platform
.jpeg?width=131&height=26&name=right_people_logo%20(1).jpeg){kind=small}
.jpg?width=58&height=26&name=Praktiserende%20L%C3%A6gers%20Organisation%20(1).jpg){kind=small}
.jpg?width=108&height=26&name=finans%20danmark%20(1).jpg){kind=small}
.jpg?width=89&height=26&name=klasselotteri%20(1).jpg){kind=small}
-1.png?width=34&height=26&name=bws_shipping_rgb%20-%20Kopi%20(2)-1.png){kind=small}
.jpeg?width=135&height=26&name=AH%20industries%20(1).jpeg){kind=small}
.jpg?width=225&height=26&name=KAUFMANN%20(1).jpg){kind=small}
