Lately, I’ve been thinking a lot about language.

As a former (recovering) attorney, I spent many a day pouring over contracts, writing policies, and explaining how the law interprets a given word or phrase to my clients. Lawyers spend their careers arguing over language — working with words to create beneficial outcomes for their clients, whether in a contract, or in front of a court. But here’s the thing: for all our skill with parsing words and stringing sentences together, we lawyers are actually rubbish when it comes to clearly communicating with our fellow homo sapiens.

For example, when was the last time you read (and really understood) a data processing agreement? Or even the last time you were clear on all the details of how a website was ‘processing’ your ‘personal data’ ? Lawyers write this stuff for other lawyers (and to avoid liability). They seldom write it with non-lawyers in mind.

We’re All Speaking Different Languages

The cynics among us might assert that this is by design. Lawyers/solicitors purposely obfuscate and complicate on purpose, they claim. I’m certain that some do (whether purposefully or not). But mostly, I think it’s a mater of miscommunication and misinterpretation. Words have different meanings depending on who the audience is. Context, culture, and perspective matter.

I recently launched a query on Twitter and LinkedIn, exploring this very topic:

#infosec / #lawyer / #dataprotection Twitter: I’m delving into a topic area on language (and miscommunication) and I’d love your insight. Words like ‘ownership’ ‘deletion’ ‘encryption’ and ‘personal data’ often have different meanings for lawyers and programmers.

It’s a struggle I see a lot as a consultant. I’m curious – what words do you regularly see cases of misinterpretation or where legal and engineering peeps are speaking different languages at one another?

— Galactic Cat DPO 🇺🇦🌻 (@PrivaCat) April 17, 2022

Now, I focus on the disconnects between lawyers and engineers because I married an engineer. We have these sorts of conversations regularly (‘What’s ‘personal data’? Is it different than PII? What does ‘processing’ mean? What do you mean by ‘userID’?). Clearly, we lead exciting lives.

Usually, the conversation comes up in context: he discovers a bug where ‘PII’ might be exposed. Or some dev proposes doing a thing with ‘metadata’ that seems fine on its face, but might be sketchy. And because my husband is a patient, loving man who listens and actually remembers when I harp on about data protection, he’s learned to think about these things differently. Sometimes, he describes a problem generally and asks my thoughts about its implications on privacy, but often he tries to dig in to find out exactly what’s going on by asking the colleague/team proposing the change.

Similarly, when I’m trying to better understand a concept or a problem (like limits on implementing ‘encryption’ at scale, or exactly how some piece of code is exposing data, or why automating everything usually just creates more problems), I go to him. In the 10 years we’ve known each other, I’ve slowly begun to think more like an engineer, and he more like a lawyer. Like bilingual couples everywhere, we’ve each learned the important phrases and terms in the others’ language.

Breaking Down Language Barriers

Experts advise that when two people are trying to communicate, but don’t share the same language, strategies should be taken to bridge the gap. For example, Kate Berardo, an international trainer and consultant, suggested the following:

1. Speak slowly and clearly
2. Ask for clarification
3. Frequently check for understanding
4. Avoid idioms
5. Watch your jargon
6. Define the basics
7. Be specific
8. Choose your medium of communication effectively
9. Provide information via multiple channels
10. Be patient.

I’d argue that each of these apply just as well when communicating with others who may speak the same core language (e.g., English), but may be less-well-versed in the particular dialect (e.g., Legalese).

It’s also important to think about reducing abstractions — especially when it comes to technology. A big challenge I have to overcome as a consultant is helping clients apply data protection and privacy concepts in practice. The GDPR talks a great deal about mechanisms for protecting personal data/privacy by design, but is exceptionally light on the details.

Terms like ‘data breach’, ‘encryption’, and ‘pseudonymous’ are vague to the point of being unhelpful. A lawyer’s vision of ‘processing’ is almost guaranteed to be broader and yet more simplistic than an engineer’s — not because the engineer doesn’t care about data protection or the lawyer is dumb, but because ‘processing’ occurs up and down the software stack, in ways neither party is likely to be considering.

Floor Terra suggested a good all-around approach – ask and get to an agreement on “What is X?” because it’s easy to be misinformed about a step or action, but also easier to clarify and resolve definitions around once identified. Move away from abstractions and higher concepts.

For example, instead of “What processing activities are you doing with personal data?” ask the other side to walk through their process or design or plan in detail (points 2 and 7). Diagrams and pictures often help here (point 9). Get through the levels of abstraction; really break the steps down and come to a consensus on what is being done with data (points 1, 3 & 6). Opt for an in-person meeting – it’s easy to forget all of this without immediate feedback (point 8).

Just like the language guidance mentioned above, these apply to all parties involved in the conversation — not just the lawyers/data protection people. No matter what your functional area is in the organisation, we all need to be able to communicate in ways that are understandable to others who don’t speak our language fluently.

Eventually, with time, I’ve begun to notice that my clients think a bit more like data protection pros, and I’ve started to think a bit more like an engineer, HR rep, marketer, etc., We start to understand one another and our respective pain points. Just like all those married multilingual couples.

[image credit: Photos: Ahmed Rabea/CC BY-SA 2.0; Pexels]