At Immuta, we’re laser-focused on enabling compliance with the most complex regulatory regimes on the planet. And for many of our customers, GDPR sits at the top of that list.
While we spend most of our time thinking about the impact these regulatory regimes will have on the Immuta platform itself, we thought it might be helpful – and perhaps even fun – to step into the shoes of a customer and put a memo together on GDPR compliant data usage using Immuta. In other words, to lay out in memo form what it will look like to use Immuta on May 25, 2018, once the GDPR is in full force.
That guidance is exactly what we’ve put together here.
A lot of analysis went into the memo (and, of course, into the way we’ve designed Immuta to enable GDPR compliance), but here are a few insights from that analysis about key tenets for GDPR-compliant policies and their relation to Immuta:
- Complying with Article 5 principles: These principles are broadly applicable requirements on how to collect, manage, and protect most organizational data. (Within the data science context, the GDPR’s scope is pretty much most data in practice; as I heard one practitioner say recently, if you’re making money off of it and there’s EU data involved, the GDPR applies.) Particularly, Article 5 (1)(b) states that data must be “collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes.” For most organizations, this is a pretty huge (and pretty alien) imposition, mandating that they track how and why all their data is used, which Immuta supports with purpose-based restrictions on data. A separate, but equally fascinating issue, is how secondary purposes can be associated with data – which gets complicated. (See, for example, Articles 13(3) and 89 for two different ways the GDPR might allow this.)
- Article 6 restrictions on purposes: Article 6 outlines the allowable purposes for processing in further detail – the most important of which are likely to be consent and legitimate purposes. Each organization will interpret these differently in practice, depending on their direct data protection authority, their own legal judgement, and larger developments in the world of GDPR. Within Immuta, governance teams can encode a list of acceptable purposes within our governance user interface. When a data scientist needs a purpose to select, they will only have the list of allowable purposes to choose from (like Marketing, Fraud, etc.).
- Data visibility requirements: Articles 12-22 (pretty much all of Chapter III), among elsewhere in the GDPR, mandate an unprecedented level of visibility into how data is being processed and accessed within large organizations. Under Article 15, for example, data subjects have a general right to understand whether their personal data is being processed, and if so, the purpose of the processing, what type of data is being used, and more. This is exactly why we’ve built a compliance report function into Immuta, which allows governance personnel to immediately know what data is being used, for what purposes, and by whom, all easily exportable as .CSV files and printable so the results can be quickly digested (and, if desired, quickly shared with regulators too).
- Data protection by design and default: This requirement is, as stated broadly in Article 25, a mandate to emphasize privacy in every aspect of organizational data processing, rather than adding in privacy protections as post hoc features (as is all too standard). These defaults are, to put it mildly, baked into every aspect of the Immuta platform, where we’ve prioritized protecting and restricting access to sensitive data through advanced anonymization techniques, granular controls on data, and more.
- Records of processing: Article 30 sets forth similar requirements as Articles 12-22, outlined above as visibility requirements. Again, the big takeaway here is that organizations have an increased burden to understand what data they’re sitting on, how they’re using it, and who’s accessing it. (See, in particular, Article 30(1)(a-g).)
- Security of processing: Article 32 lays out the GDPR’s data security requirements, which are, in practice, a blend of industry-specific information security best practices and practices tailored to each unique organization (measured by the “varying likelihood and severity” of the risk dependent on the context of the data processing, to quote Article 32). Two points I think are most important, and most interesting, about these provisions: First, the pseudonymisation requirement in 1(a), which will require the imposition of advanced anonymization policies by default, and which Immuta easily provides. The second point is that, in the US at least, security and privacy are generally regarded as separate features associated with data processing – but in the EU, these distinctions are blending, if not vanishing altogether. The GDPR is a testament to this trend.
- Case-by-case transfers: Chapter V outlines the conditions under which data can be transferred to third countries or international organizations. Big picture, this means that sharing of certain datasets needs to take place within boundaries that are easy to control and monitor, which is exactly what we’ve built our “projects” feature to accomplish. And even though this requirement might not seem related to data localization (which makes a more intense appearance in other regulatory regimes), this makes virtualized approaches to data sharing like Immuta’s more important – where organizations can control and understand their data and share it at the same time, without the raw data leaving its place of storage.
For teams thinking about what the highpoints of GDPR are, I’d also recommend the August statement of intent for the UK’s Data Protection Bill, which gives a good sense of how the UK government is thinking about the GDPR and how to comply with it themselves.
Most importantly, and most surprisingly, is how simple we’ve made GDPR compliance, which I think the sample memo attests to.
For more information on the sample memo itself, our analysis of the GDPR, or Immuta in general, please feel free to reach out to our Governance Team at firstname.lastname@example.org.