10 May 2018, 22:07

Software developers are your biggest GDPR risk

At Raygun, we’ve been investing in GDPR compliance for many months now. It’s been a useful exercise and ensures our customers can keep using Raygun without concern.

But it did get me thinking.

One of the biggest reasons folks tell us that they didn’t choose to pay for Raygun is “We are going to build something ourselves”.

I’ve gone back to several folks recently asking how these home built systems are complying with GDPR. “Oh shit” is about the most common response. The second most common is “GD what?”. 

Now, forget Crash Reporting, Real User Monitoring or Application Performance Monitoring tools. These are what Raygun sell, but start thinking of all the things your engineering team has built.

Things to consider

  • Log files that every random tool, service or process generates. Often these dump helpful debug information. The sort of data that often contains customer details.
  • Information that goes into things like the Windows Event Log.
  • Data that your teams might pull from production into staging environments. This is bad, but very common.
  • Bots or services written to send data into other tools or locations like GitHub, Slack, Shared Inboxes, etc.
  • Each open-source system the team have stood up. Being community developed, it’s unlikely to have had compliance features built in. 

Everything that deals with your customer data needs to be GDPR compliant for you to be GDPR compliant. This means (and it’s not an exhaustive list!) each tool, service, etc needs to at least have:

  • The ability to audit for customer data (e.g. scan log files, error logs, event logs, etc) to identify a customer’s data.
  • The ability to export that data for your customer in the event of a request.
  • The ability to remove that data at the customer’s request.

So the next time somebody thinks they could build a quick service to solve a problem, ask: How will it will support GDPR?

Failure to comply

It was already non-economic to have your expensive team members building tools that they could pay a few hundred dollars for. 

But now, for some extra downside, your organization can be fined up to 4% of top line revenue for failing to comply. That’s not of profits, it’s 4% of everything the company took in this year.

I recently spoke with one person from a large business who said “we’ll probably need to be fined to take this seriously”. I wondered if they’d be saying that if the CEO, Board of Directors or Compliance Officer had been there. I wish this mindset was rare, but I’ve found it is the mentality that is pervasive in software teams.

This isn’t slap-on-the-wrist stuff and should be treated seriously. Not only because of GDPR, but because customer data is sensitive and should be treated as such.

Risk Center

I witness this all the time. I’m a software developer myself and I know it’s sexy to build our own stuff. It’s fun to do those projects. The proliferation of tools and services that you had no idea had been internally built will surprise you.

If you’re the CIO, Data Protection Officer or Compliance Officer, go and talk to engineering. Brace yourself

Businesses shouldn’t be building things yourself without factoring in GDPR requirements. 

Be compliant with Raygun

This post isn’t about being an advert, this is just a common problem I’ve seen. It’s something we have been talking about a lot internally as part of our own compliance work.

However, if you are looking for a GDPR compliant solution to Software Crash Reporting, Real User Monitoring or Application Performance Monitoring, check out Raygun. A few less things to worry about.