I like to hack into Microsoft products in my free time – and that’s given me a pretty unique perspective on how we need to protect data in our digital world. Before anyone calls the authorities, I promise that it’s all kosher. In fact, Microsoft rewards people for discovering their vulnerabilities. 

Whitehat hacking and bug bounty programs are hardly new phenomena and are completely legal and ethical ways to scratch a hacker’s itch to break into systems. In the process, we friendly hackers can’t help but accumulate a great deal of understanding and knowledge of why even the biggest software companies still suffer from major breaches. In my opinion, it comes down to two things: They aren’t leveraging their developers or GDPR enough.

Every hack, whether the intentions behind them are good or bad, follows the same story. Find a vulnerability, technically exploit it, and then use it to get inside someone’s system. Of course, the bad guys typically take it one step further, often with the intention of exploiting the data they gain access to in the process. This is one of the reasons why many in the industry refer to these high-priority targets as “the crown jewels.” But there’s a way to make breaches inconsequential – and it’s not by only continuing to fight malware and viruses. Instead, I’m advocating to build more secure infrastructure from the get-go and for engineering teams to embrace GDPR like their own personal bible.

Good data security requires you to know assets, protect them, and build out applications with disciplines of security and privacy by design. GDPR, in so many ways, offers the perfect blueprint to achieve this. And yet, most enterprises still treat it as a pesky privacy regulation at best or a complete thorn in their side at worst. In either case, most end up doing the bare minimum to achieve compliance to avoid repercussions and fines. Perhaps, if we fleshed out the acronym to General Data Protection Regulation, we might better appreciate how much it has to offer as a guide for protecting our data.

For our purposes, I’d like to focus on GDPR’s loopholes for enterprises through their invention of categorizing breaches as illegitimate or legitimate. In essence, data breaches are considered inconsequential when data is anonymized – meaning that if the data breached cannot be linked back to its subject, the breach is harmless.  Even better, GDPR actually explains how to do this! By my interpretation, harmless and illegitimate are synonymous, and the end result is the same. No harm, no foul, and no need to report the breach. This is revolutionary and massively overlooked. 

For the first time, we have an official greenlight to completely rethink how data can remain protected. We have an unofficial acknowledgement that breaches will always remain a risk and workaround for this painful enterprise security reality. Even better, it’s in a language that developers can understand so that we can finally get them meaningfully involved in the process. 

In a single document, we now have instructions for how to store data, where to store it (technically and geographically), and when to delete it.  We even have a solution to the madness of enterprises collecting every piece of data possible just for the sake of it. There has never been a clearer mandate for developers and other data protection stakeholders to ensure that data is stored securely and that the privacy of individuals is protected at all times.

GDPR’s ability to provide developers with clear tasks for data protection is entirely unprecedented. By building infrastructure that is designed to protect data from the outset, according to GDPR’s stipulations, organizations can truly mitigate the risks associated with data breaches. This comes not a moment too soon. Sensitive data tends to be dispersed all over enterprise environments without special treatment. But, thanks to GDPR, it should be common knowledge that we must build out workflows that scrub data of links to their subjects while keeping the most sensitive information centralized and locked away. While hardly simple to achieve – it’s certainly not cheap either – this approach ticks off so many data privacy and security needs by providing clear visibility, standardized practices, and data breach immunity.

We need to move beyond compliance in a world where R&D velocity is constantly increasing, technology is becoming more complex, and the amount of data being collected is growing exponentially. Developers are pushed to build applications for business to run without optimizing their storage solutions to meet privacy and security needs. They have the technical knowhow, but neither the business incentive nor resources to do so. Legitimate breaches will continue until this changes and developers are encouraged to optimize their builds for reasons beyond mere performance. 

Until this happens, I will continue to financially benefit from breaking into major enterprise systems. So will the bad guys, and when they do, enterprises will have to incur even greater financial costs while real people suffer major privacy violations. The answers we need to endemic breaches has been with us since GDPR’s 2016 release, and we’ve long known that developers have become the new frontier for security. Data – especially given its importance – needs to become a priority for developers too.