Although all the discussion was for the most part captivating, the most intriguing part of the conference though was the final panel on regulatory sandboxes. This ended up having direct parallels to the privacy regulations I’m most interested in and working on each day — especially when Youssef Sneifer of Microsoft Payments remarked that it was no small feat to acclimate the software developers in his part of Microsoft to the realities of working in a regulated environment – something that most software developers don’t have experience with. And he’s not alone in this remark!
Although I’ve worked in regulated industry most of my career, first CE/UL/FCC for satellite communications hardware and then later laws like HIPAA while developing software for medical devices, his point really struck me – because most of the web and app developers tackling the changes needed for privacy laws like the GDPR have little to no experience working in a regulated environment – they are more likely to be told to “move fast and break things” and that’s just not the way things work when working with radio or healthcare – and now it is no longer the way when working with people’s personal data.
So I asked, how does one help create a culture of compliance where there formerly was little or no regulation or enforcement, like in the case of privacy? Youssef replied that it had to start at the top, that the leadership had to set the tone that compliance was a top priority, was non-negotiable and that developers and managers were responsible to understand the requirements of the law and make it happen. Lucinda Fazio, the sole regulator on the panel, added that, when a regulator sees that regulatory compliance is being reinforced in the company, the regulator reacts differently if/when that company makes a misstep. Aaron Gregory of Remitly added that ultimately it becomes about trust and ideally becomes part of your brand – becomes a fundamental for your employees.
Later, another attendee mentioned that he agreed with Youssef but that you especially needed to get the sales team on-board too for compliance culture to catch. Shortly after that a third attendee stopped me in the hallway and mentioned the importance of finding the distinct “whys” (they’ll be different) for different groups or individuals throughout the organization – why regulatory compliance should matter to them, whether financial law or privacy law or what have you.
I think they were all right – you need a strong privacy mandate from the top down AND you need sales and marketing to see regulatory compliance as something marketable and not just an encumbrance AND you need to find the whys for the software developers and other roles in your company to begin make compliance – financial, privacy, or what have you – part of a company’s culture. And that’s the challenge for all of us working on the web and on apps now – in a post GDPR world – helping to get those cultures started and flourishing in our companies.
When I signed into Twitter today, they informed me of “Important Updates” – which take effect on May 25, 2018 (coincidentally the same day the GDPR takes effect, but the GDPR is not mentioned.)
Instead of the lovely bold “Got It” button, I went for the “Review settings” link below it in fine print:
I was surprised how much was enabled:
But not anymore!
Props to Twitter for 1) notifying me of the changes when I log in, 2) providing a link to review the settings (even though it was tiny, it was there) and 3) making it easy for me (even as a non EU resident) to opt-out of individual uses of my personal data. You’ve set an example for others to follow.
Administrators are well advised to first deactivate any plugins they no longer need – a good security practice in itself. But don’t delete it right away! If you suspect that plugin might have collected personal data, you’ll want to contact the developer and make sure that deleting their plugin will also clean up any personal data it collected.
What data the plugin collects from site users and visitors
What the plugin does with the data / why the data is collected
What third-parties does the plugin share the data with
Where does the plugin store data (both on the site itself and on any cloud based resource), how access to the data is protected
How long the plugin retains the data
What options administrators and users have about data collection and use
How the administrator or users can access, update or delete the data the plugin collects
Assurance that, when deleted, the plugin also cleans up any data it collected
With the GDPR deadline looming, it is an excellent time for WordPress plugin developers to finish adding or updating that often skipped, often neglected plugin uninstall code – you know, the “clean-up” code that deletes options and meta data and tables that the plugin added to the site?
There are, of course, other aspects of the GDPR that apply to the way plugins handle personal data or expose site visitors to data collection by 3rd parties, and solutions to those are coming in WordPress core (see below), but this area (data clean-up on plugin deletion) is one area that developers can attend to now if they haven’t already.
Not a bad overview at all – I think it is useful to clarify that:
the GDPR covers not EU citizens but EU residents, and
that data portability (Article 20) requires being able to request and send a machine readable copy of data to another controller but doesn’t require that controller to have software ready to actually read it