Ten Tips to Avoid Wasting Thousands on Privacy Tools You Don't Need

Originally published on LinkedIn, August 2019.

Buying privacy technology is one of the fastest ways to waste significant budget in a data protection programme. Every week, organisations invest in tools that fail to meet expectations — and in some cases, tools they did not need in the first place. These ten tips will help you avoid the most common and costly mistakes before you sign anything.

The Problem with Privacy Tech Procurement #

A leading privacy professional body publishes an annual Privacy Tech Vendor Report that maps the landscape of available tools. Reviewing it is a useful exercise — but it also serves as a reminder of how many purchasing decisions go wrong.

Vendor promises can be seductive:

“…the only solution that can solve GDPR.”

“…the most user-friendly comprehensive GDPR documentation tool on the market.”

A tool that works well for one organisation is not necessarily right for yours. The following tips apply regardless of which tools you are evaluating.

1. Understand the different categories of tools #

Privacy technology broadly divides into two areas. Privacy Programme Management covers assessment managers, consent managers, data mapping, incident response, privacy information managers, and website scanning. Enterprise Privacy Management covers activity monitoring, data discovery, de-identification and pseudonymisation, and enterprise communications.

Diagram showing a holistic view of a typical privacy programme system for a data-fuelled business

Within those categories, tools range from narrow specialists to broad platforms that attempt to cover many areas at once. It is difficult to compare them meaningfully until you know precisely why you need them. Your requirements will differ from other organisations based on the nature of your business, sector, scale of operations, data volumes, geographical spread, integration requirements, programme maturity, executive buy-in, and available budget.

Diagram mapping IAPP privacy tool categories onto a privacy programme system

2. Do you really need a new tool? #

Before evaluating anything new, audit what you already have. Existing tools — Excel, SharePoint, your existing case management or workflow systems — may be adequate, or adaptable, for your needs.

Diagram showing how SharePoint was configured as a ROPA in 2016, with linked lists for processing activities, documentation, and gap and risk logs

The diagram above shows how SharePoint was configured as a working Records of Processing Activities (ROPA — the register of data processing activities required under GDPR Article 30) for a client in 2016. It was fit for purpose at that time. The point is not that SharePoint is the right answer, but that the right answer is not always a new purchase.

3. Write a requirements specification #

Document your functional and non-functional requirements before you look at a single vendor. These become your evaluation criteria. Prioritise them and agree the selection weighting before any tool enters the picture.

Develop use cases that describe how your team actually works in specific parts of the programme. The tool should support your working practices — not force you to redesign them to fit the software.

Include integration requirements. A tool that connects cleanly to your existing landscape reduces manual effort and awkward workarounds. If you cannot produce the requirements specification yourself, bring in a business analyst to elicit requirements across the organisation.

4. Align with company policies and technology standards #

Your organisation may have a procurement policy, a technology strategy, preferred vendor lists, or existing framework agreements that constrain or simplify your options. Check before you spend time evaluating tools that are never going to pass internal approval. A preferred vendor may already have a solution that meets your needs.

5. Build a proper business case #

Illustration of a calculator and spreadsheet, representing financial planning for a tool investment

A business case is essential — and most organisations require one. It should cover why the tool is needed, the full cost to implement and run it, the risks involved, expected benefits or savings, and how benefits realisation will be tracked.

Pay particular attention to the cost to run. Tools often require dedicated people to manage them, configure them, and — critically — to interpret the outputs they generate. These are headcount costs that are frequently omitted from initial business cases.

Even a “free” tool carries hidden costs: training, integration work, custom APIs, service management overhead, and potentially weak SLAs or security standards. I learned this the hard way when putting together a business case for a DLP (Data Loss Prevention — technology that monitors and controls data transfers to prevent unauthorised disclosure) tool. It turned out to require a small team just to handle the volume of alerts it generated. An expensive oversight. There is no such thing as a free lunch.

6. Use an RFP and involve procurement #

Illustration of a shopping trolley, representing a structured procurement process

Engage your procurement or sourcing team early. They will manage the RFP (Request for Proposal — a formal process for inviting and comparing vendor bids) process, apply the weighted selection criteria consistently, and bring contract negotiation experience that you may not have in-house.

Do not alter the selection criteria or weightings after the process has begun in order to favour a particular vendor. Your procurement colleagues will also conduct vendor due diligence — financial viability, track record, reputation — which is valuable protection against a poor long-term commitment.

Illustration of a paper tiger — representing tools that look impressive but offer no real substance

Some tools promise to generate a complete suite of GDPR-compliant documentation from minimal inputs: your company name, a few job titles, a tick-box list of generic processing activities — and suddenly you are “compliant.”

Avoid these paper tigers. Genuine compliance requires understanding your specific processing activities, your legal bases, your risks, and your organisational context. No tool can substitute for that work, and documentation generated without it provides false assurance rather than real protection.

8. Does the vendor actually understand data protection? #

Privacy technology vendors should practise what they sell. Before shortlisting any vendor, spend ten minutes on their website.

Illustration of two contrasting vendor interactions — one confrontational, one collaborative and engaged

How compliant is their cookie consent? What does their privacy notice look like — does it read as though it was written to inform and respect you as a data subject, or does it feel like it was written purely to protect the vendor? A privacy notice reveals a great deal about how an organisation actually thinks about data protection. If the vendor cannot get their own house in order, treat their product claims with appropriate scepticism.

9. Scalability and localisation #

Illustration of a globe with flight paths, representing international operations

If your organisation has multiple legal entities across multiple countries, can the tool reflect that structure? Can it accommodate the organisational hierarchy you actually operate with?

How localised is it? If you have offices in the UK, Denmark, France, Germany, Spain, Brazil, the UAE, and India, can staff in each location navigate the tool in their working language? Localisation is frequently an afterthought for vendors — but it matters significantly for adoption and accuracy across a distributed organisation.

If a tool is calibrated solely to the guidance of a single supervisory authority — Datatilsynet in Denmark, the ICO in the UK, the CNIL in France — or covers only GDPR, it may not serve your needs if your organisation is subject to other applicable privacy laws and regulations.

Organisations operating globally or across multiple jurisdictions need tools that can accommodate a broader regulatory scope. Check what the tool actually covers before assuming it maps to your full compliance landscape.

Frequently Asked Questions #

How do I know whether I need a dedicated privacy tool or whether existing systems will do? Start by documenting what you are actually trying to manage — your processing activities, your assessments, your incidents, your consent records. Then check whether your existing tools (a well-structured SharePoint, a configured Excel workbook, your existing GRC platform) can support that work adequately. If the gaps are significant, or if volume and complexity have outgrown manual approaches, that is the point at which a specialist tool earns its investment.

What is the biggest mistake organisations make when buying privacy technology? Skipping the requirements specification. Organisations that go straight from “we need a tool” to “let’s see what vendors offer” end up buying against vendor demos rather than their own needs. The requirements spec — written before any vendor conversation — is what keeps the evaluation honest and the selection defensible.

Should a small organisation bother with a formal RFP process? Not necessarily a full formal RFP, but the underlying discipline still applies: document what you need, evaluate options against consistent criteria, and build a basic business case that accounts for the real cost of running the tool. The formality scales with the size of the investment and the complexity of the organisation — but the thinking behind it does not.

If you found this useful, the Purpose and Means newsletter covers GDPR, data governance, and privacy strategy — fortnightly, in plain language.

Purpose and Means works with organisations on data protection strategy, governance, and compliance - going beyond the legal text to focus on how things actually get done. If you’d like to discuss what this means for your organisation, book a call or explore our services.