#3 Privacy is not Security

You’re likely familiar with Abraham Maslow’s Hierarchy of Needs. It’s a psychological framework developed in the 1940s which describes various motivations of human behaviour, often visualised as a pyramid …

You can see that security comes immediately after physiological needs, which would include the real basics like food and water.

In our work in data and analytics, we talk about security a lot, mostly as a domain of knowledge (she’s a security expert) or a capability of an application. We don’t often discuss security as a human need, but our clients, customers and users know the difference. They want - they need - to know that their devices, their accounts and their data are secure. They want to feel safe. They also want privacy - to be free from intrusion or unwanted attention.

Our requirements for security are not quite universal, but very widely shared and mostly consistent across cultures and contexts. Privacy can more subtle. In India, people will often ask me how much I earn, or how old my wife is: a quite intolerable intrusion in Scotland. There can be similar differences in sensibility when it comes to sharing information online. Nowadays, thanks to privacy legislation such as the GDPR, CPRA and POPI we’re commonly asked to select from a menu of privacy options including cookies, even though Lou Montulli, the inventor of cookies, thinks the pop-up permissions dialogs a really silly idea. Nevertheless, the variety of options in the dialogs reflects not only the regulation, but the range of tolerance we may have as individuals for different boundaries to our privacy.

However, don’t make assumptions about how Indians and Scots may differ in their sense of privacy. As this paper shows, Cross-Cultural Privacy Differences are a fascinating topic: perhaps one for another article. Here, I want to call out a principal, a creative difference, that I find useful in thinking and talking about these needs.

If we take privacy to mean the freedom from unwanted attention or intrusion I mentioned earlier, and take security to mean the need to be free from threat, then a simple analogy might make the important distinction clear.

Curtains and keys

When I would visit the Qlik offices in the Central district of Hong Kong, it was easy to get distracted by the view. Out of one window, I could look across the extraordinary forest of skyscrapers fighting for space and light between the hills and the sea. From the other side of the office you could look across to a residential tower, straight into the rooms of people going about their everyday lives, without a care that they may be seen. All human life was there (along with dogs, cats and parrots ) and quite distracting

Without blinds or curtains closed, the residents of the tower had little privacy. Yet they were quite secure. It was a luxury building in a prime location and had gatekeepers, security systems and strong steel-plate apartment doors as is quite normal in Hong Kong. Yet their security did not provide privacy. They had to do that themselves - and mostly chose not to.

However if they did close their curtains or pull down their blinds, but the security systems were compromised, the gatekeepers on strike and the key to their apartment doors lost or stolen, then they had two problems. They were no longer secure and, because someone could walk into their apartment, they had no real privacy either.

This is important to note. Security does not guarantee privacy, but without security, other privacy protection may not be good enough.

In terms of data, think of the controls you have put in place to ensure the security of your network, such as firewalls and authentication. You might be secure from unauthorized access, but if you have not taken care to ensure that even authenticated users can’t casually see what they were not meant to see you aren’t genuinely protecting privacy.

On the other hand, perhaps you put protections in place to ensure that only users who do have the right permissions can see certain data. You’ve done your best to protect privacy in that context. Yet, if the network is vulnerable, unauthorized users can still insinuate themselves; if they acquire the right privileges, both security and privacy will be breached.

In every scenario, it’s important to ask, what are you protecting: security or privacy? The answer is often both, but you’ll still find it best to consider them as separate scenarios.

Protecting both privacy and security

With an understanding that security and privacy are separate but associated subject areas, I think it is often a good idea to create two separate but associated initiatives, co-ordinated by a virtual team. These teams are not provisional. As Alan Watts said in a different context, In the best of times security has never been more than temporary and apparent.

The continuing focus of a privacy team should be on the appropriate legislation that determines processing, protection, and retention requirements. The program must also take into account consumer expectations: their cultural and contextual demands. Realistically, compliance with regulations will be top of the agenda, but do remember that we’re still talking about human needs. Users need to feel comfortable.

The requirements identified by the privacy program can be passed to the security program for implementation. However, privacy program team members often don’t need to (and sometimes cannot) specify the specific processes or technology to be implemented, although they’ll likely have well-informed suggestions.

It’s the security team who has the knowledge and capability to set up suitable protections and controls to meet the needs identified by the privacy team. An important advantage of keeping the two separated in this way is that the interpretation of regulations won’t be unduly influenced by concerns about technical limitations. As a result, when the security team reviews the unbiased requirements from the privacy program, it’s possible they’ll identify technical demands that require new, or different, tools and platforms.

My suggestion is to ask yourself - or your team - pointedly about this topic when the next related issue arises. Is this a privacy or security matter? If one, how is it related to the other? You’ll be surprised how often this simple question leads to a better understanding of the problem and how often it reveals that more work needs to be done.