GDPR Rules for Business Software: Which Tools Can Employees Use?
Your marketing manager uses Canva to create visuals. The sales team works in a free CRM that nobody approved. And someone in finance just found an AI tool that can summarize invoices.
Sound familiar? That phenomenon has a name: shadow IT. Software that employees install on their own, without IT or management knowing about it.
And it makes sense. People want to be productive and grab whatever tool works fastest. But the GDPR rules for business software are clear. Every tool that processes personal data without your knowledge falls under your responsibility as an organization. That responsibility also applies to software employees signed up for themselves.
The problem: employees choose their own tools
Shadow IT sounds dramatic, but it's actually very common. Think of Trello boards that nobody requested, ChatGPT sessions where customer data gets pasted in, WhatsApp groups for work discussions, or a Dropbox account to "quickly" share a file.
A concrete example: an employee creates a free account with a project management tool and invites the whole team. Within a week, there are customer names, deadlines, and internal notes in there. Nobody checked where that data is stored, who has access, or whether there's a Data Processing Agreement in place. But the tool is running, with real personal data in it.
These tools aren't necessarily bad. But nobody verified whether they handle personal data safely. And that's your obligation under the GDPR.
According to Gartner, 41% of employees use technology that falls outside IT's visibility. At smaller organizations, that number is often higher, simply because there's no formal approval process.
What the GDPR says about Data Processing Agreements
The GDPR is pretty clear here. Article 28 says: if an external party processes personal data on your behalf, you need a Data Processing Agreement (DPA). Without that document, you're processing personal data without a legal basis.
This applies to every SaaS tool and every cloud service that has access to data from your customers, employees, or contacts. The responsibility lies with you as an organization, not with the employee who created the account.
"We didn't know" is not a defense the Data Protection Authority accepts. You're expected to know which tools are running and whether the right agreements are in place.
Want to learn more about the vendor side? Read our article on vendor management and the GDPR.
Which tools are risky? A practical assessment
Not every tool carries the same risk. It helps to split them into three categories.
The first category is harmless: tools that don't process personal data. A calculator app, an internal whiteboard without user accounts. Low risk, though it's still smart to document them.
The second category is where most tools fall: software that processes names, email addresses, or phone numbers. Your CRM, your email marketing platform, your project management tool. A Data Processing Agreement is required here.
The third category needs the most attention. These are tools that work with sensitive or special categories of personal data: health data, national identification numbers, financial information. Think HR software or payroll administration. On top of a Data Processing Agreement, you also need to document additional security measures. The GDPR calls this "appropriate technical and organizational measures," and for sensitive data the bar is higher than for standard contact details.
How do you approve a tool? A simple process
You don't need weeks of research. Five questions will get you most of the way:
- Where is the data stored? Within the EU or outside? Storage outside the EU comes with additional rules.
- Who has access? Only your team, or also the vendor and third parties?
- Is there a Data Processing Agreement? Most serious SaaS providers have one ready. If they don't, that's a warning sign in itself.
- Can data be deleted? If a customer or employee requests deletion, that needs to be possible.
- What happens during a data breach? Does the vendor notify you in time?
Based on the answers, you approve the tool, reject it, or allow it conditionally. Conditionally means, for example: "We use this tool, but only for non-sensitive data, and we re-evaluate it in six months." Always document why you make that decision. It prevents discussions later and gives you something concrete to fall back on if the Data Protection Authority asks.
Want to set up this process step by step? Check out our guide to approving tools.
What do you do with tools already in use?
Most organizations don't start from scratch. There are already dozens of tools running, some for years, and nobody ever checked whether they're GDPR-compliant. Not ideal, but not the end of the world either. You can still set things right.
- Inventory everything. Ask every team which software they use. Don't forget the tools that were "just tried out" and never went away.
- Categorize them by risk. Use the three categories above. Which ones process personal data? Which ones process sensitive data?
- Check the Data Processing Agreements. For every tool in category two and three: is there a valid agreement? If not, contact the vendor.
- Decide per tool. Some you approve after all. Others you replace. And a few you simply turn off, because they turn out to be unnecessary.
- Document your decisions. Record what you decided and why. If the Data Protection Authority ever comes knocking, that is your evidence.
Recognize this problem? Then our article on 5 signs you need to audit your software stack is a good starting point.
How do you make sure employees follow the policy?
Setting up rules is the easy part. Getting people to actually follow them is harder.
What helps: keep your policy short. Nobody reads a twenty-page document. One page with three core rules is enough:
- Only use approved tools for work involving personal data
- Want to use a new tool? Report it to IT or your manager
- Never enter customer or employee data into tools that haven't been approved
Also explain why those rules exist. "We protect customer data and prevent fines" works better than "the GDPR requires it." People follow rules they understand.
Just as important: make it easy to suggest new tools. If your approval process is too complicated, people will work around it. In ComplianceHive, employees can add a tool to the software register themselves and request approval, so nobody feels like they're talking to a wall.
And bring it up in team meetings occasionally. Not as a lecture, but as a normal part of how you work. Just ask: "Has anyone found a new tool in the past few months that could be useful?" Once a quarter is enough to catch shadow IT early.
What should your software register contain?
A software register isn't something you fill in once and then forget about. It grows with your organization. For each tool, document at least the following:
- Name and vendor
- Which personal data is processed
- Where the data is stored (country or region)
- Whether there is a Data Processing Agreement, and where it is filed
- Risk category: no personal data, standard, or sensitive
- Status: approved, rejected, or under review
- Who within your organization is responsible for it
It sounds like a lot of work, but most of it you fill in once. After that, it's just maintenance: new tool added, old tool removed, Data Processing Agreement renewed. A register like this doesn't just help with GDPR compliance. It also gives you insight into costs, overlap between tools, and vendor dependencies. Learn more about how to discover what's missing in your tool landscape.
Ready to get a grip on your business software?
In ComplianceHive, you build an overview of all tools, Data Processing Agreements, and risk categories. That way you know where you stand and what the next step is. Assign tasks to your team and track progress. Try it free for 30 days.