Ten tips to avoid wasting thousands on privacy tools you don't need and ensure you get the ones you do need

The latest version of IAPP's Privacy Tech Vendor Report was published earlier this week. It reminded me that every week around the world, companies are probably squandering precious funds on tools that don't always meet their expectations.

In some cases, tools they don't even need.

I can't prove this. It's a hunch based on conversations I have with clients, with individuals in my network, at conferences and IAPP training sessions that I occasionally deliver.

There are many tools available, some very good and some not so good.

Some vendors offer tempting promises:

"...XXX is the only solution that can solve GDPR."

"...XXX is the most user-friendly comprehensive GDPR documentation tool on the market."

Of course, a tool that meets one company's expectations isn't necessarily going to meet yours.

Here are ten tips (in no particular order) to avoid wasting money and to ensure you're making the right investment.

1. Understand the different categories of tools

The first few pages of IAPP's Privacy Tech Vendor Report are well worth looking at to get an understanding of the various types of "Privacy Tech" tools. IAPP use the following categories:

Privacy Program Management:

• Assessment managers
• Consent managers
• Data mapping
• Incident response
• Privacy information managers
• Website scanning

Enterprise Privacy Management:

• Activity monitoring
• Data discovery
• De-identification/pseudonymity
• Enterprise communications

The following diagram represents a holistic view of a typical privacy program "system" for a business fuelled by personal data (employee data not represented):

Parts of the program may benefit from automation.

Applying the IAPP tool categories might look like this:

This is a quick approximation as some of the category definitions are quite broad.

Within the categories, there are many specialist tools and a few that cover off many categories.

It's difficult to compare tools unless you know why you need them, and your needs will be different to other companies.

I've personally used various tools working with a number of different clients.

Lots of different factors to consider not least the nature of your business, sector, scale of operation, volumes of data processed, geographical spread, integration requirements, maturity and not least, executive buy-in and...available budget.

2. Do you really need a new tool?

Existing tools you already use in your company may be adequate for your needs. Alternatively, adapting existing tools may meet new requirements. Most organizations use tools similar to Excel or SharePoint and depending upon the factors named above, they may be fit for your purpose.

Here's an overview of how SharePoint was adapted for a ROPA in 2016. It suited the client at that time and I imagine the client now has a more robust solution:

3. Requirements specification

Ensure you document functional and non-functional requirements. These will enable you to evaluate how the tools match up against your needs. Prioritise the requirements and baseline the selection criteria before you consider any tool.

Document several use cases that detail the ways you work in specific parts of your program. The tool should support the way you work; you should not have to overhaul how you work to fit the tool.

Remember to include integration requirements. Tools that integrate into your existing landscape will bring benefits and avoid manual steps or awkward interfaces.

If you can't produce the requirements spec. yourself, get help from a business analyst to elicit requirements across the organization and develop the use cases.

4. Align with company policies and technology standards

Your company may have a procurement policy that you must live up to. There may be a technology strategy that dictates the types of technology, prefered vendors, existing agreements, etc. A prefered vendor may have a solution that fits your needs.

5. Business case

A business case is essential. Many companies require one to:

• justify why the tool is needed
• how much it will cost to implement and run
• the risks involved
• expected business benefits and/or savings
• track benefits realization

Be particularly careful with "cost to run". Many companies forget to factor in that tools often need people to take responsibility for them, or to interpret the vast amounts of insights they often provide - headcount costs.

Even if the tool is offered "free" ensure you make a business case taking into account not just cost to run but other costs that may be hidden, How many FTEs are required to manage, or work with the tool?

How much training is involved? Integration to other systems, custom APIs, etc.

The tool probably needs to be added to your service management setup.

All this involves people, and requires time and effort.

Especially if your company has outsourced many of its services.

I learned the hard way a few years back, neglecting to factor such costs into the business case for a DLP tool. It required a small team to deal with the alerts.

Highly embarrassing, but an opportunity to learn.

Remember a free tool may come with poor SLAs, minimum levels of security, etc.

'There's no such thing as a free lunch' holds true here.

6. Use an RFP and involve procurement

Engage your procurement or sourcing department (if you have one). They will usually help manage the overall RFP (Request for Proposal) process and may have specific tools to compare the various proposals from vendors using the weighted selection criteria you documented earlier.

Do not change the original selection criteria, or weightings in order to "botch" the process in favour of a tool whose Account Manager took you to dinner the night before.

Your procurement colleagues will also bring plenty of contract negotiation experience to the table if this happens to be one of your weaknesses.

They will also probably conduct some due diligence on the vendor - are they financially viable, do they have a checkered history, etc.?

7. Avoid tools that will auto-generate "GDPR documentation"

There are some tools on the market that will generate a beautiful suite of documentation supposedly "GDPR compliant". It seems all you need to do is key in the name of your company, a few names and positions, tick-off some generic processing activities, and hey presto! You are compliant!

Avoid these paper tigers.

8. Does the vendor fully understand data protection?

Shouldn't Privacy Tech vendors take their own medicine?

Personally I want to work with vendors who fully understand the data protection requirements that I am also trying to address.

It's easy to get a feel for whether a vendor "gets it" by looking at their website.

How compliant is their use of cookies?

What does their privacy notice look like - does it represent your interests as a data subject, or is it geared to protect their interests?

A privacy notice reveals a lot about a company.

Do you feel threatened, or engaged?

9. Scalability and localization

If you are a large organisation with multiple legal entities that are perhaps spread across multiple countries, will you be able to establish the overall Group organisational structure in the tool?

How localized is the tool? You have offices in various markets, e.g., UK, Denmark, France, Germany, Spain, Brazil, UAE, India, etc. Will they be able to navigate the tool in their native language?

10. GDPR only?

If the tool is only aligned with the guidance of a specific Supervisory Authority, e.g. Datatilsynet in Denmark, ICO in the UK, CNIL in France...

OR

...is aligned only with GDPR (yet your organization is subject to applicable laws and regulations other than GDPR), then you may want to consider other solutions that can support global privacy programs.

Get in touch

I help Danish leaders develop their data protection strategy & roadmap aligned with business purpose and business goals to avoid meandering all over the place.

Interested? Let's get on a call and I'll outline the approach in more detail.

Book a time now.