In recent years, the term "privacy engineering" has entered the professional lexicon. It's a term that's bandied about, usually with high regard — heck, it even has a Wikipedia page — but it's not always clear what a privacy engineer is or does, at least generally speaking. Is a privacy engineer someone who has a Ph.D in computer science and codes notions of privacy (whatever that is) into IT systems, services and products? Or is the work of a privacy engineer more broad in scope than that? 

To help unpack this burgeoning discipline, practitioners explored the role and function of the privacy engineer last week during the IAPP's inaugural

ADVERTISEMENT

Cassie IAPP Leaderboard - Future-proofing your data, 2025 and beyond

In 2014, Fox, along with Michelle Dennedy, CIPP/US, CIPM, and Thomas Finneran, published what has now become a seminal resource in the field. The Privacy Engineer's Manifesto set out "to provide, for data and privacy practitioners (and their management and support personnel), a systematic engineering approach to develop privacy policies based on enterprise goals and appropriate government regulations. Privacy procedures, standards, guidelines, best practices, privacy rules, and privacy mechanisms can then be designed and implemented according to a system's engineering set of methodologies, models, and patterns that are well known and well regarded but are also presented in a creative way. A proposed quality assurance checklist methodology and possible value models are described." 

Got it?

Okay, that's a detailed, if not overwhelming, start, but it lays out the breadth and significance of the role. Privacy engineering is not just about coding. Privacy engineering supports the business model through a multitude of systems, methodologies and frameworks that continues to evolve, particularly in light of the EU General Data Protection Regulation.  

Senzing CPO John Bliss, CIPP/E, CIPP/US, CIPM, went so far as to suggest that a privacy engineer is "anyone in the business of developing a privacy program." 

In the latter half to the forum, attendees split into three groups to discuss who should fill the privacy engineer role, where they should fit within the organization, and how their value can be demonstrated to senior leadership. The working groups generated enough dynamic discussions about privacy engineering that Annie Anton, who emceed the event and chairs the IAPP Privacy Engineering Section Advisory Board, extended the discussions. Clearly, more discussions are needed. 

At one point during the group discussions, an attendee noted, "That's privacy engineering: Building systems to ensure we're using data correctly." 

"That's privacy engineering: Building systems to ensure we're using data correctly." 

Microsoft Corporate External and Legal Affairs Principle Program Manager Javier Salido, CIPP/US, CIPT, described a more concrete skill set that's often found in the privacy engineering field, bunching them up into five groups. First, there are the developers. These are the employees with the technical skills to code and develop software products. Then there are the data administrators. These "are the guardians of the well," so to speak. "They decide how to move data around the company, determine how it's protected and all the details that go along with ensuring the infrastructure" is supported. Third, there are the data scientists and analysts. These are the mathematicians and statisticians who help derive value from data sets while protecting privacy. Fourth, there are the policy and compliance folks, who focus on and understand the law and how that applies to the organization's business objectives.

Finally, and this was brought up by Google Principal Engineer Lea Kissner, there are the user experience people. These are the employees who work to understand how the user will interact with the product or service and ensure privacy is embedded into that experience. 

"Privacy engineering is working toward building great things with great respect for privacy," Kissner said. But it take lots of research to get there. "Privacy is not a well understood field," she continued. It involves consulting, program management, compliance, all the while understanding privacy-preserving technology. 

Kissner explained how she helps her teams make good decisions. This is done through aligning incentives and stressing that privacy is something needed in a great product. Part of that involves creating an infrastructure "that makes doing the right thing automatic."

Salido echoed the need for infrastructure. "You need to have a common understanding of what the approach to privacy is going to be for your company," he said, noting that Microsoft has privacy standards that offer clarity on things like notice, choice and regulatory compliance. A good infrastructure will facilitate these principles. "We've talked for a long time about data governance," Salido said, "but the list of companies that have implemented that is zero. The GDPR's arrival has forced companies to take significant steps they have not taken before: What data do we have; who is using it; how is it moving around? The infrastructure in place to make this possible is hugely important." 

He also said the bevy of privacy technology tools coming into play will facilitate this infrastructure. And privacy engineers have a big role to play here. 

"When we hire people," Kissner explained, "we see lots of backgrounds." There are those who have the computer science PhDs, or who have software engineering experience, but she said Google hires folks with a wide variety of backgrounds, from an ex-reporter who's "really good at breaking things," to a social worker who is passionate about fairness in machine learning. 

"What they all have in common," Kissner noted, "is that they care deeply about this, and they can solve difficult problems from principles."