In an otherwise unseasonable late winter day in Washington, DC, the Marquis Marriott was abuzz Wednesday with a flurry of connection and conversation that only the Global Privacy Summit provides. Being “precon” day meant the day was reserved for a deep dive into essential education for a wide range of privacy pros.
One morning session was dedicated to the emerging, yet perhaps still mysterious, profession of privacy engineering. Anchored by a fantastic panel of privacy engineers, policy analysts as well as privacy and security experts, “Piecing Together the Privacy Engineering Puzzle” was not for the faint of heart. Understanding and conceptualizing this field is no small task, but bridging the gap between the technologists and the policy experts is and will continue to be essential in a world driven by technology.
But what the heck is “privacy engineering,” anyway?
Think about the Smart Grid, for example. “Communities aren’t concerned that their information isn’t securely protected,” explained National Institution of Standards and Technology (NIST) Senior Privacy Policy Analyst Naomi Lefkovitz, “they’re concerned that their behavior is being monitored by power companies.” There’s a reliance on security, but security doesn’t equal privacy. “If policy was enough, we wouldn’t be here…”
Plus, since privacy engineering is such an emerging field, you can look to at least four serious but divergent definitions of the concept. Each one—provided by the NIST, MITRE, Nokia or The Privacy Engineer’s Manifesto—has a different take on the definition, but each one has common threads.
“There are many different, non-agreed-upon definitions of privacy engineering,” said Lefkovitz, “but a methodology for mitigating risk tends to be a thread through many of the different definitions.”
Speaking to a packed room, MITRE Principal Information Privacy and Security Engineer Stuart Shapiro, CIPP/US, CIPP/G, took a bird’s eye view of privacy engineering by describing what he calls the “biome.” The privacy biome, or ecosystem, includes three main components as defined by Shapiro: the community of practice, information infrastructure and the personal data ecosystem. Each component has its own elements – so the community of practice includes methods, codes, standards and professionalism; while social, local, technical and global factors comprise the information infrastructure, and individuals, collectors, users and brokers form the personal data ecosystem.
In all, Shapiro was describing a holistic view of a messy privacy ecosystem to demonstrate its complexity and variety of moving parts. As a result, cherry picking specific components of the biome will only provide specific, and thus limited, solutions. By looking at the broader view, Shapiro argued, bigger solutions could be possible.
Hogan Lovells Partner Harriet Pearson, CIPP/US, drilled down further by describing how things work within organizations. She said legal, policy and operation considerations must be addressed when implementing privacy engineering. Plus, she pointed out, you have to know what standards you’re going to engineer against. “There isn’t one engineering standard,” Pearson said, “and you’ll likely come up with company-specific standards.”
I spoke with one attendee who wholeheartedly agreed, noting that company-specific standards are successfully applied within her organization.
As is often the case, one major problem for those working to bridge the gap between those in policy with those in technology is finding a common language. NIST Privacy Engineer Sean Brooks said, for example, transparency has a much different definition to an IT specialist than it does for a lawyer.
MITRE Lead Information Security Engineer Julie Snyder, CIPP/US, CIPP/G, CIPM, pointed out that there are ethics and principles that privacy engineering can look to—including the FIPPs, Privacy by Design and the Generally Accepted Privacy Principles—but overall, there are not the sort of codes seen in other engineering fields.
Fittingly, the half-day session had a structured feel to it. We started up on high looking down at the big picture and methodically dove deeper and deeper into the issues driving this emerging field. The session finished with a use case having to do with drones and public land. Attendees were tasked with creating a map of the data flows, identifying risks and vulnerabilities and possible outcomes. This, I can assure you, was not easy.
Also fittingly, everyone at my table was just getting into privacy from other fields, including IT security, data science and law. As we worked together on this use case—with our vastly different professional backgrounds—what become most clear is that there is a lot of work to do on this still mysterious field, but, if done correctly, privacy engineering will be an essential piece of an organization's operations.