Quantcast
Channel: Data Security – Protegrity
Viewing all articles
Browse latest Browse all 113

5 Takeaways from The Privacy Engineer’s Manifesto

$
0
0

Privacy Engineers Manifesto CoverRecently, after connecting with Michelle Dennedy, Cisco’s Chief Privacy Officer, I took the time to read her book, The Privacy Engineer’s Manifesto. For those that will be at the RSA Conference this week, Michelle will be giving two sessions there. I have to say that I believe the book’s insights are of value to everyone involved in the data supply chain, from practitioners to business users and especially those in governance. In this blog, I will attempt to summarize my key takeaways from the book, which to be fair is chock full of insight that I will be hard pushed to get into a single post!

Privacy must be architected

I am not sure if everyone thinks this way but the manifesto asserts that privacy needs to be “purposefully architected” into the systems that run today’s enterprises. Doing this clearly matters where customer trust is an imperative or regulatory pressures exists. Dennedy (and her two co-authors and many notable contributors) explains that as the stages of the information age progress, what is needed to protect privacy and data also needs to progress. This chart aims to summarize the thinking here:

Privacy Manifesto

The move to the right has evolved because today’s era of creating and consuming intelligence is increasingly, “about people, devices, and systems seamlessly making handshakes, connecting, processing information, and providing services that are designed to improve the quality of life.”

In this environment, the only way to protect privacy, according to Dennedy, is to protect data itself rather than the things that surround it. Data-centric and person-centric protection requires a “proactively engineered system architecture.”

Designing Privacy

Dennedy argues that confidentiality does not equal privacy and security does not equal privacy, and that in fact these topics overlap, with the key differentiator being how data is accessed and used. Here, Dennedy suggests that privacy is defined as “authorized, fair, and legitimate processing of personal information.” As such, an organization’s privacy policy should govern the processing of personal information throughout the enterprise. For this reason, privacy frameworks and data governance are connected.

Dennedy advocates that organizations should be practicing ’Privacy by Design’. Developed by Ann Cavoukian, Executive Director of the Privacy and Big Data Institute, this approach consists of seven principles:

  • Proactive not reactive
  • Privacy as the default setting
  • Privacy embedded into design
  • Full functionality
  • End-to-end security
  • Visibility and transparency
  • Respect for user privacy

Dennedy also proposes that smart organizations worry about their entire architecture and have specific privacy requirements for potential and existing cloud vendors, but I wonder how many truly worry about this before engaging with SaaS, PaaS, or IaaS vendors?

Clearly, privacy needs to fit into the design phase for all projects and Dennedy advises that doing this well includes the creation of privacy data classes. These classes represent the things managed by the enterprise as well as the basis for data privacy requirements. From here a privacy component class model should be developed (a class clearly is a person, place, thing, or event deemed to be of significance to an enterprise), to allow rules based on privacy policies to be added and maintained.

Measuring impact

How do you know how well you are doing? Dennedy recommends conducting privacy impact assessments (PIAs) as a nice way to identify where privacy controls and measures are needed and, just as importantly, to confirm what controls are already in place.

PIAs should specifically determine whether the processing of personal information in a given situation meets the enterprise’s privacy requirements, and typically have five steps:

  • Information gathering
  • Analysis
  • Reporting
  • Remediation
  • Verification

A PIA should provide confirmation of accountability, compliance with internal guidelines, and confirmation of controls and measures. Key stakeholders here include internal and external regulators.

Getting organized for privacy

The first step is determining what is already in place in terms of privacy awareness and business risk. This involves determining current controls and measures used to protect personal information.

Next, define existing systems and processes by mapping all data flows for personal information. Dennedy says these efforts often produce, “a spaghetti-looking diagram of existing databases and data markets and, perhaps, a key to identity management systems and corresponding role definitions.” Better still, she says, is to create diagrams which include the data elements marked with corresponding and dated policies for processing as well as how data flows to and from third party systems and vendors. With this, PIAs and privacy readiness will be simplified while risk tolerance and privacy skills are improved.

Who matters to protecting privacy?

A number of people matter here. Data privacy needs to become a clear business goal; making this happen requires shared responsibility by the C-suite and the business and technology community within.

Privacy engineers are dependent on Information Technology and Information Security; both are requisite to ensuring privacy. Data governance is also critical: “Ultimately the organization’s privacy strategy is about data governance – how information is managed and used.” Alignment between data privacy and data governance is essential and privacy stewards should be identified as stakeholder roles in the governance steering committee.

Parting remarks

Clearly, there is much to do to get privacy right. Privacy needs to be by design and default, governed and managed. To me this starts with organizations maturing from perimeter and identity security to data-centric and person-centric security. Only then can organizations implement and govern policy based security, enterprise-wide, to properly protect people’s privacy and reduce business risk.

“It’s our thesis that privacy will be an integral part of the next wave in the technology revolution and that innovators who are emphasizing privacy as an integral part of the product life cycle are on the right track.”

The authors of The Privacy Engineer’s Manifesto: Getting from Policy to Code to QA to Value

Learn More About Managing Enterprise Security

Data in 2020: The Emergence of “Data First” Security

Data Security in a Data Driven World

Further Reading

4 critical data-driven challenges for today’s CIO

Extending COBIT 5 Data Security and Governance Guidance

How Should You Protect Your Enterprise’s Data?

Breach report blames leadership inaction for data loss

Twitter: @MylesSuer #MyDataMatters

The post 5 Takeaways from The Privacy Engineer’s Manifesto appeared first on Protegrity.


Viewing all articles
Browse latest Browse all 113

Trending Articles