Skip to Content
Business Trends
Author's profile photo Erica LAILHACAR

Five Ways to Keep Your BI Team on the Right Side of GDPR

There’s been a lot of press coverage on the European Union General Data Protection Regulation (GDPR), spurring organizations to proactively audit their data. But there’s been far less coverage and media noise on how to responsibly manage analytics, business intelligence processes, and reporting on sensitive data. And that’s a problem, especially for users who use business intelligence (BI) tools to access sensitive data on a regular basis.

How do you ensure there’s no maverick behavior—even when it’s done without malice, such as importing a database into  Microsoft Excel for a “quick project”—and ensure that everyone manipulating data understands what can and cannot happen and why?

GDPR Regulators Will Be Quick to Act

Chances are that regulators will be looking to make early examples of companies that breach GDPR requirements, which puts BI teams and analytics activity in the hot seat. How data records are stored and deleted, and how they are encrypted and transferred internationally, will all have to be reassessed. For business intelligence teams, this is even more acute, given the level of sensitive data at their disposal.

It’s a conversation I seem to be having more frequently with customers, so I thought I’d use this blog to outline five key points that BI teams need to consider as we approach the GDPR deadline in May.

1. Conduct Training and Risk Assessment

It may sound obvious, but all BI users need to understand the changes and implications of GDPR with regard to how reports are run, managed, stored, and destroyed. This is not business as usual. Risk-based obligations are spread throughout GDPR. This can be a positive development; low-risk systems shouldn’t need the same level of protection as high-risk systems. But it will mean that companies will have to go through the process of actually doing risk assessments on lines of business and departments that process EU personal data—and that includes BI activity.

2. Classify Your Data

Make sure your records are clearly labeled, as well as the BI assets such as reports and dashboards, especially if they contain sensitive information. Businesses need a policy in place to make sure sensitive data is handled in keeping with GDPR guidelines, particularly when that data is used for analysis and self-service BI. For example, if an individual triggers the right to be forgotten and requests that the company delete personal information, BI teams must have the confidence to know it’s not been duplicated in users’ personal folders or shared outside the organization.

3. Monitor Data Usage

Companies will to need to audit and monitor how users are working with data. What analytics are taking place, and who is exporting data to Microsoft Excel? In other words, you need to be doing BI on your BI system. Your BI team must have sight of any potential for data leaks, regardless of whether it’s deliberate behavior or accidental oversights.

4. Shut Down Ungoverned Silos

Identify all the potential places where data is stored to ensure that there are no ungoverned silos and no one is setting up an ad hoc database for a one-off campaign or copying data for a “quick report.” This is important, because old habits can be hard to break for some people. Anything not governed by the IT department that is subject to cause regulatory exposure needs to be shut down. No exceptions.

5. Delete or Archive Old Reports

Reporting tends to pile up, and as users continue to build new reports, it’s important to delete or archive what’s no longer relevant or required. If the data is sensitive, it must be destroyed if necessary and not sit idly in old reports. Having a system in place to manage the process is essential to ensure that nothing slips through the net undetected. While chief data officers and compliance teams may be in the firing line if something goes wrong, ultimately it is the responsibility of the whole business to understand and embrace the changes, ensuring that if any mistakes are made, they don’t turn out to be too costly. BI teams have much greater responsibility for that than ever before, and have an obligation to identify and root out potential weak links, cut away unnecessary systems, and implement BI governance practices to stay on the right side of the law.

Learn More

  • Visit SAP’s GDPR compliance webpage for more information and education about GDPR
  • Check out the GDPR product webpage for resources about which SAP solutions and services could help you govern your GDPR program and manage and protect your data for sustainable GDPR compliance
  • Read our other GDPR-specific blogs
NOTE: The information contained in this blog represents the author’s personal opinion and is for general guidance only and provided on the understanding that SAP is not herein engaged in rendering legal advice. As such, it should not be used as a substitute for legal consultation. SAP SE accepts no liability for any actions taken as response hereto. It is the customer’s responsibility to adopt measures that the customer deems appropriate to achieve GDPR compliance.

This blog originally appeared in the SAP D!gitalist magazine and has been republished with permission. 

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Great blog on a timely topic.
      Data privacy and security are increasing in importance in the digital age.
      European laws are setting the pace for global standards.

      Author's profile photo Former Member
      Former Member

      I would add another point, possibly at step 2. Know why you hold the data, and under what legal basis.

      The GDPR requires that data is process in line with one of six legal basis e.g. consent or contractual basis etc. Whilst nobody would wish to see a warehouse full of valuable business intelligence be deleted, the days of sucking up as much data as possible are long gone. The GDPR promotes the practice of data minimisation, which should be interpreted as the minimisation of personally identifiable data. Yes I wholeheartedly agree that scanning your data stores and classifying the data within them is a foundation step. However the next step is to ask if that data is Personally Identifiable, what the basis is for processing it and if there is no basis or the basis has expired whether the data should be deleted or de-identified.