TOTAL: {[ getCartTotalCost() | currencyFilter ]} Update cart for total shopping_basket Checkout

The Privacy Advisor | Getting Privacy and IT Departments on the Same Team Related reading: A view from Brussels: EDPS sends signal on data transfers 

rss_feed

""

Privacy professionals and engineers are often tasked with the same goal: to protect personal information. Given that shared objective, why are there so many difficulties between IT and privacy teams?

That was the crux of the conversation Friday at the IAPP Privacy Academy and CSA Congress during the breakout session “Same Planet, Different Worlds: Getting IT and Privacy Teams to Work Together.”

“Privacy teams are good at saying what should be done, but it’s up to the engineers to do it,” said McAfee Director of Data Privacy Jonathan Fox, CIPP/US, CIPM. So communication between the two is essential, though challenging.

First off, privacy and IT teams speak different languages. GuruCul Solutions Chief Security and Strategy Officer Leslie Lambert, CIPP/US, CIPP/G, said it's like the Tower of Babel: “What you often see is teams communicating past each other, in different directions, instead of with one another.”

Plus, Fox pointed out, teams are not only speaking different languages but interpret the same words differently. An IT team interprets words such as “requirement” or “minimization” much differently than the privacy folks. Fox added, “My world needs lots of context, and when I ask, ‘How are you getting there?’ I get architectural flows, but I want a data flow chart. I need an itemized data map. Engineers don’t think that way.”

To illustrate the communication fissures, panelists used the need for an organization to delete data as an example. The privacy team notices that to reach compliance, or to meet various regulations, certain data must be properly disposed. On the privacy side, it’s a no-brainer: Just delete the data. But the IT side sees an entirely different set of challenges and obstacles.

“When people talk about the cloud, they think of it as one thing,” Lambert said, “but behind the curtain, we go, ‘Oh my god,’ think about all the data servers.” IT teams have to locate all the copies of the specified data and anywhere else that might source that data.

One lesson for privacy folks is to pinpoint needs ahead of time and communicate those with the IT folks. Really, that could be one consideration that’s designed into an organization’s architecture, Lambert said.

“Understanding process is really important,” Fox added. “I can ask to please have all that data deleted, or I could ask what the backup process is and know to delete the data in the source system,” for example.

Fieldfisher Partner Phil Lee, CIPP/E, CIPM, said he often hears a similar sentiment. Under pressure to get a product or service to market, engineering teams might go ahead and build it, and the privacy team finds out last minute, leading to retroactive fixes that are usually expensive. Opening up lines of communication to help prevent this could go a long way.

Fox and Lambert agreed.

“Build relationships,” Fox said. “Go to their turf for a meeting, or go out to dinner or lunch together. Keep those channels open.”

Lambert said it’s also important to learn each other’s space and take the time to become educated about “the other side of the world.”

“Learn the language,” Fox recommended. “Explain things more than halfway. Explain what ‘data minimization’ means and use examples, break things into word equations: I need X to do Y. If I don’t have X, I cannot do Y,” and “make your requirements in plain English.”

He also said to use case studies and be willing to be stupid. “I’m just a country privacy person,” he often tells people.

Understanding differing language also means understanding data classification, Lee pointed out. “One thing I’ve experienced, privacy pros tend to focus on protecting PII, but the engineering focus is on security and confidentiality of data assets.” But how you map the data—what’s public, what’s private, what’s confidential—can be extremely challenging.

“Data classification is always considered an arduous activity,” Lambert said, noting that PII can be differentiated into two nuances: the attributes of you as a real person—height, weight, date of birth—and your digital identity; e.g., your IP address or shopping preferences. The lines are becoming muddled, though, so it’s critical to identify “the different flavors and tiers” of data in order to prioritize what needs more protection.

The rise of the privacy engineer may indeed help diminish the separation between the IT and privacy folks, and Fox was optimistic, saying, “I do think the gap between the privacy and IT teams is closing.”

2 Comments

If you want to comment on this post, you need to login.

  • comment James • Sep 24, 2014
    "Fox added, “My world needs lots of context, and when I ask, ‘How are you getting there?’ I get architectural flows, but I want a data flow chart. I need an itemized data map. Engineers don’t think that way.”
    
    This seems like a case of 'ask a stupid question, get a stupid answer'. I can assure you that engineers (particularly those versed in privacy) are well aware of what a data flow diagram looks like. I know from personal experience that people at big tech firms use them, and various shops even have some customized tool support for creating them using static or dynamic analysis.
    
    “Build relationships,” Fox said. “Go to their turf for a meeting, or go out to dinner or lunch together. Keep those channels open.”
    
    I'd say a better plan is to hire people with competence in both domains. If you have utterly no technical skill, why on earth do you imagine that you are well placed to work in a company that builds products, in which you will be communicating with engineers. Not that there is anything wrong with relationship building and all the rest, but if you don't have the foggiest clue about the basics, you aren't going to ask particularly good questions and you aren't going to have much credibility.
  • comment Jeff • Sep 24, 2014
    As someone who works in both camps, helping technology folks understand privacy requirements and privacy folks understand technical options/limitations, this is certainly an area for improvement.  Agree with many of the points in this article.
    
    The development of an internationally recognized glossary of terms from professional organizations like IAPP and others might be helpful in this area.  "When I say 'X,' 'Y,' or 'Z' I'm referring to the definition in the common glossary …" similar to what CNSSI 4009 did for the U.S. Federal Government.
    
    Jeff, CIPT (formerly known as CIPP/IT)