It's toothless, though. Due to the nature of security moving so quickly, any certification or audit standard that actually prescribes specific security controls is inherently going to take so long to get approved by the standards organization that by the time it gets approved, it's already outdated.
The "fix" that has been attempted for this is to try and write security standards that are high level (read: vague) so that they have more "shelf life", but the result of that is that nearly anyone can pass the audit/certification because the requirements are so vague. See: NIST CSF, ISO 27001, HIPAA...
For that matter, it's entirely possible they had security testing "controls" too. But again, the audit/certification probably won't even care that the security testing team is one guy who sometimes tests the app login every couple of weeks. "Oh, Jim tested to make sure that the app only allows 3 password attempts? Security Testing: Check!"
Don't get me wrong, the ISO/NIST frameworks are absolutely a good thing. For a lot of my work, they've been my bible. They are fantastic guides to help companies who want to be more secure focus their efforts and understand how they measure up. But that's only for companies that really want to be more secure. For all of the companies out there that just want to check a checkbox or pass an audit, these frameworks are way way too easy to give a "false positive".
It's often frowned upon by engineers, because it's much more about processes and management structure than anything technical. But I've been involved in a few organizations that went from "technically good but unmanaged" to ISO certified. And I'm quite sure all of them got more secure and did more in terms of continuous improvement after certification.
I think in an ideal world data privacy should be addressed by open-source software enabling software developers to easily express data privacy as code and version control it and review it much like we do with our infrastructure.
There is an product [0] which is currently in Alpha aimed at doing this. (Full disclosure I am one of the core devs) We don't support S3 buckets yet - but it's on the roadmap.
The most exciting project I've found so far, who are working on this, is a project called Ceptr, who have open sourced a pattern called Holographic chain. It uses validation rules and open app logic to create completely distributed apps. Each user holds onto their own data. It is often called Protocol Cooperativism (close to Platform Cooperativism) You can find more about it in this medium post by one of the core contributors:
"It's a framework for writing fully distributed peer-to-peer applications. It is like a decentralized Ruby on Rails, a toolkit that produces stand-alone programs but for serverless high-profile applications." [1]
[1] https://medium.com/holochain/holochain-reinventing-applicati...
For example, the gov gives huge fines, and pierces the corporate veil.
Then insurers insure the risks for a data breach. They calculate the expensive premium, and lower it if you do what the consider the right thing, e.g. some ISO guidelines.
Now incentives are aligned: Corporations secure their infra to avoid expensive premiums.
Insurers give correct security guidance. If they overbear, they lose customers. If they are too lax, they pay huge insurance claims.
The governement's job is to make sure nobody is asleep at thehelm. After a while, make the insurance mandatory.
Basically, it's what works for fire insurance.
There are data-breach insurers already.
Again, that has not changed anything.
Then if you have a data breach you can investigate and potentially pull the license and assign personal liability similar to if a bridge fell over.
At the same time, you can ruin someone's life through a data-breach. Imagine you are on one of these dating apps and your boss takes a gander at the leaks and fires you because of your private life. Or worse, some bigots show up at your house and burn a cross in your yard.
So how do we fix a situation where the person responsible for securing your data has no skin in the game? Put their head on the block. Other engineering disciplines hold the PE liable for mistakes because they recognize the stakes involved. I think that assigning liability is absolutely appropriate for building systems with PII.
Product certifications would be great too, although that would be done by a PE so you'd kill two birds with one stone by licensing Data Engineers.
GDPR solves that because if you want to do business with European citizens you must comply with it no matter where you are. GDPR is not only about the fines, it stablishes protocols to communicate breaches, makes somebody responsible for it (the DPO) and makes distinctions between the different types of data and the requirements to handle it.
Also, enforcing GDPR is no joke, and we are still learning its consequences (http://www.london-registrars.co.uk/first-prison-sentence-ari...).
As I see it, Licensed Data Engineers won't make companies more careful with our data, since all they need to do is to sue them and fire them when there is a problem. We need laws that make data hard to use, so companies will only ask for what they really need, will use the data with a purpose and will store it only while it's useful.
Software is more similar to a car than it is to a bridge. Companies build and sell them all over the world. Cars are certified at each country as needed, but it doesn't matter who is building them, as long as they meet all the requirements. Software should be similar.
This implies there is a perfect scenario of security, but even the best security experts can still have breaches, it's unfair to punish people acting in good faith.
This big difference is that this isn't just "the bridge fell over". In the case of a cyber attack, it's more like "a terrorist detonated a bomb on the bridge and blew it up". And in such a case, I think it would be a pretty big stretch to blame the engineer who designed the bridge.
"Somone crashed into the bridge support pillar in the median and the bridge fell down" sounds like the fault of the engineer.
"A foreign nation sent a fighter jet" doesn't.
I don't have any ideas on how to have a reasonable standard of "this is the sort of attack you shouldn't fall to," though. How do you keep this from being years outdated very quickly?
I'm not suggesting that every data breach results in jail time, just like not every bridge collapse results in jail time either. There should be an investigation that determines the cause and whether that cause was foreseeable. The other engineering disciplines seem to have it adequately figured out, software isn't that different. I also don't think you should be facing life or anything, maybe something as small as a fine would work.
Ultimately the data breaches will continue to happen as long as the personal incentives of the people building data systems aren't aligned with the users, and the GDPR does nothing to address that.
i'm not saying this is good or bad just... keep that in mind. careful what you wish for.
It’s like we need an FDA for data.