Once upon a time security was an afterthought. And the security profession tried to convince everyone that building security in from the start was cheaper, easier and more effective. Ok, increased prototyping costs, but then, prototyping without understanding the impact of security might be claimed to be somewhat pointless. Then DevSecOps appeared. (Yes, Gartner has written on this). All of a sudden, security architects could integrate into DevOps workflows (mostly) transparently and security could be part of the team!
Now we have privacy as the primary concern for many of our clients and the privacy industry looks much as security used to. We need to ‘bake privacy in’, or as the GDPR puts it; do ‘privacy by design’ and ‘privacy by default’. Organizations cannot ignore privacy legislation and ignoring privacy goals is bad for the modern enterprise and modern consumer. Luckily for those having to do this, the technology is there, and is big enough and bad enough to do what’s needed. But we do continue to see privacy being treated as a bolt-on: one that conflicts with the business.
In all fairness, enterprises have a large investment in their current tools and techniques for data processing. Bolting-on controls is often the only economic way. But as IT refresh happens, there’s no real excuse for ‘keeping the old ways’.
Hold on, but DevOps?
Privacy Engineering is very similar to DevSecOps – seamless and transparent integration of privacy principles into fast paced environments – with as little friction as possible.
Privacy Engineering is the integration of privacy principles and compliance requirements into Data Operations (DataOps) and Data Centric Security Architectures (DCSAs) as seamlessly and transparently as possible, ideally without reducing the agility or speed of enterprises and data scientists.
It’s also maturing fast. Yes there’s lots of country-specific (or region-specific if you’re in the EU) legislation. But that legislation doesn’t actually conflict as much as some other types do. There’s enough consistency that the OECD Privacy Principles (of which there are eight) can be used as a basis for most use cases. Take a look at them at http://oecdprivacy.org/
There’s one implication for this:
- The way enterprises implement privacy goals will (and must) change.
- Privacy is no threat to industry.
- Privacy analysts can’t count
Implementation must change because enterprise customers will expect data-centric security products to have privacy features built-in. This is like DLP, which is being included in so many products today. They want products that reduce compliance risk, not just technical risk. They will expect to be able to configure tools for privacy goals naturally in the products and services they deploy and consume. They will want those tools to integrate. Personal data has a life-cycle in the enterprise, they don’t want to re-invent the privacy wheel every stage of it’s journey.
The world is changing
Privacy-specific products aren’t common today, although it’s a growing market. Neither are there many products with privacy-specific features and they aren’t cheao. Many are extensions of DLP or classification tools. But this will change.
My colleague Joerg Fritsch believes that this capability will quickly become table-stakes. A vendor that is unable to deliver may find it’s a deal-breaker for enterprises looking to purchase data-centric security products. He suggests we will soon be seeing privacy features becoming commodity along with the development of privacy regulations.
Personal data is the newest asset class – but not one that an enterprise owns,. Instead it ‘borrows’ this asset from data subjects until they revoke consent. Sometimes though, not owning something is an enabler. Techcrunch (2015) writes:
“Uber, the world’s largest taxi company, owns no vehicles. Facebook, the world’s most popular media owner, creates no content. Alibaba, the most valuable retailer, has no inventory. And Airbnb, the world’s largest accommodation provider, owns no real estate.”
You can be successful without owning something. But there are obligations, nonetheless. Uber has to check cars they do not own for road-worthiness and legality. Similarly, data processors must implement privacy principles and follow data subject rights for processing worthiness and legality. Privacy Engineering will prove to be the key enabler.
And the goal is?
What the security architect must do is show the business that privacy goals can enable new opportunities. Demonstrate that privacy by design and default (as part of privacy engineering) will give higher and continuous confidence that existing processes are compliant and ethical. From this, enterprises will mature as data custodians – understand the importance of personal data, treat it with respect and protect it properly. Your clients will love you for it.
Joerg and I are publishing on this topic very shortly – comments always welcome!
Five Board Questions That Security and Risk Leaders Must Be Prepared to Answer
As board members realize how critical security and risk management is, they are asking leaders more complex and nuanced questions. This research helps security and risk management leaders decipher five categories of questions they must be prepared to answer at any board or executive meeting.Read Free Gartner Research
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.