Below is an article from 2018 highlighting the best ways for development teams to tackle GDPR compliance whilst minimising the impact on your existing processes and teams. A great summary of best practice and cultural improvements to keep yourselves protected and ethical when working with sensitive data.
Practical guidance for developers to shape their GDPR strategy
What final steps should system architects and developers take now to ensure they have all bases covered?
Despite the huge volume of publicity there’s been around General Data Protection Regulation (GDPR), there was a heightened sense of concern at a developer event I attended recently.
At the end of the session, several people came forward, asking for clear guidance on what GDPR means at a practical level for developers and architects working with people’s personal data. Despite having made various preparations, they wanted to understand how other companies are addressing the common problems, recommended thought processes when evaluating work, and how to more fully address the risks and issues in their decision-making.
It doesn’t help that this is chiefly a compliance exercise. So, while companies recognise they must put in place robust measures, they don’t really want to expend more energy or budget on this than they need to. So how can they cover themselves comprehensively, without taking too much of their resources and focus from the core functionality and differentiating qualities of their products?
Practising a duty of care
In my last conference presentation I threw my wallet into the audience, reeling off my expectations of the person who caught it – as its temporary custodian. Keep it within sight, don’t pass it on to anyone else, and so on. When people share personal data with us, they have similarly reasonable assumptions. That custodians of their personal assets treat them with respect and will not abuse the access privileges they’ve been given.
In sharing something about themselves, individuals might hope to enjoy greater convenience and a more personalised service, for instance. If those benefits feel real, the trade is a fair one and everyone is happy. But if all they get in return is unsolicited third-party marketing or a general sense of unease that someone might hack into their personal details, people’s desire to disclose information about themselves diminishes. Empowered by the new provisions under GDPR, they may take steps to ensure their data is locked down or deleted.
And that becomes a hassle for everyone concerned – including the customer who receives a poorer service and the company that is forced to take a big step backwards in its customer intimacy and the sophistication of its marketing.
Covering the basics
When Uber had 57 million customer accounts stolen in a major breach of its security, it turned out to be because developers had stored customers’ passwords in GitHub, a central portal for managing version control for application source code. Although all developers know not to do this kind of thing (another common error being to use real data in testing), pressures to deliver features to deadlines can prompt development teams to cut corners.
GDPR compliance at a practical level, then, isn’t about board-level box checking and a badge on the company website. It’s about understanding where and how systems and processes touch and use sensitive personal data, and then putting operational checks in to ensure that nothing is left to chance. And this must be tasked to people who know what they’re doing.
The good news is that there’s a lot of practical help out there if companies want to manage GDPR themselves – to ensure that suitable security and data protection is built into a development team’s pipeline of checks, before code goes live. Tools and tips include the ‘privacy by design’ protocol, the Open Web Application Security Project (OWASP) and SANS Institute vulnerability checklists.
Balancing innovation and housekeeping
The other alternative is to simplify your GDPR position by letting someone else be the keeper of people’s personal data, their permissions and how these are managed. Development communities already recognise the convenience of third-party logins for managing access to applications (‘log in using Facebook’, for example). So, one practical workaround to GDPR is to extend a similar approach to personal data management.
Given that no business came to dominate its market through its ‘world-beating compliance’ credentials (a condition of doing business, rather than a differentiator), it may well be better to hand the responsibility to an expert. Certainly, it would alleviate a whole heap of worry for developers who, in an agile-obsessed, fast-fail world, have enough on their plates delivering the latest service innovation. I’ll be picking up this theme at Devoxx in London, which takes place May 9-11.
MyLife Digital has a developer API programme. Let our platform handle key aspects of security and management of personal data and people’s rights so that you can focus development effort on customer features. Go to our developer page to register.