Subscribe to our blog
Get ahead with our award-winning insights on the latest developments in the fraud and compliance landscape. Enter your email below to receive our blog posts directly to your inbox.

Introduction

Between Facebook / Cambridge Analytica and the GDPR enforcement milestone, data privacy has been a hot topic in recent months. Whereas much of the debate historically has been about data protection (e.g. hackers looking to steal your data), now the debate is focused on “how your vendors are using your data”.

IdentityMind, since its founding, has been very focused on data privacy. After all, with a platform that allows our clients to create digital identity assets representing their own users, data privacy is of paramount importance. Fortunately our core founding team has a deep background in data and network security, and in data privacy.

A basic tenet of our platform is that a client will only ever be able to see personal data about their customers that they themselves provided to us. For instance, our data model allows clients to see relationships across their customers in the context of anti-money laundering controls, even if that relationship includes other clients. We provide this, however, without providing any visibility into personal data that they themselves do not already have. The careful and consistent application of cryptographic techniques help provide this visibility and still help shield personal data from both malicious and accidental misuse.

A side effect of how we architected the platform is that it cannot be used for marketing purposes, much to the chagrin of some of the potential investors we have met with over the years. But this early choice and commitment meant that the technical controls of GDPR compliance were all in place long before the regulators began to demand their presence.

GDPR – Privacy by design

At the start of my career in the late 1980s software security was a secondary concern; as a line developer deep in the bowels of our software stack it was not always at the front of mind. A standalone “security team” performed security reviews and analysis. Nowadays within modern development organizations, security is embedded into the mindset and day-to-day activities of everyone in the engineering organizations, sometimes described as “devSecOps”.

In a similar fashion, Privacy by Design requirements push an emphasis on user privacy deep into the organization, early in the development process, where issues are more efficiently resolved. The Product Management team need to be thinking about how this new feature will impact the privacy of end users; the development and test teams need to be a check on the feature definition and be thinking of the best technical means of protecting the users; and the operations team need to ensure the infrastructure is up to the protection task. Privacy is not the responsibility of the Data Protection Officer, but is on all of us. Maybe it is time for a new term, “devPrivSecOps”? While that particular term may be unwieldy, the concept behind it is not.

I believe that the remainder of this decade will bring privacy awareness to the forefront much as the early 2000s did for data and network security. But to do this right, our industry needs to think of this as an opportunity to do the right thing for the customer and not as a burden of regulation. This time, it should be easier since much of the security infrastructure can and is already being reused to support privacy. For example, the Open Web Application Security Project (OWASP) has already published privacy guidelines and cheatsheets similar to their guidance for vulnerability and secure coding. Today, the automated tooling in the development pipeline to support privacy protection is limited but one can imagine, for example, a SolarQube plugin that would statically examine code flagging calls to third parties that are passing personal data, where personal data is being written to a data store without adequate encryption, or the use of a weak hashing function.

Additionally, GDPR should be treated as an opportunity for our industry to clean up its data handling and for each organization to get its arms back around its data. As a small company we just “knew” where the data resided, how it was protected, and why we had collected it. With our growth it is of course no longer possible for us old timers to know every point in the company where data is being collected, particularly for our non-core datasets such as marketing and sales leads. A unexpected benefit of GDPR is that we have now fully documented our data in our processing records (effectively our data map) and institutionalized the ongoing maintenance of this. Obviously this is a requirement for GDPR compliance, but it is also the right thing to do, and will help us to maintain our security and privacy posture as we continue to grow.

While the trend is that consumers are are more and more willing to trade personal data for services, the forcing function of GDPR is an opportunity for companies such as ours to differentiate ourselves from competitors through our deep respect for the rights and freedoms of the consumer.

GDPR, IdentityMind, and You