Skip to main content

Sorry, no, this blog isn’t about spies and secret agents; it’s about the CIA triad, an idea that comes from Cyber Security. It stands for Confidentiality, Integrity, and Availability and provides a high-level categorization for the aspects that cyber security attempts to protect:

  • Keeping things private and preventing information from getting into the wrong hands maintains Confidentiality.
  • Keeping things safe from damage maintains their Integrity.
  • Protecting from outages or loss of access maintains Availability.

Over the past few years, the term “data protection” has become synonymous with the privacy of an individual’s personal information, courtesy of regulations like the General Data Protection Regulation (GDPR), which mandates that organizations holding personal information appoint a Data Protection Officer. This has led us to habitually link data protection specifically with privacy (aka the C in CIA). However, as our friends in Cyber Security would point out, this is only a third of what we should be considering.

In fact, GDPR – Article 5(1) requires that personal data shall be:

“processed in a manner that ensures appropriate security of the personal data, including protection against unauthorized or unlawful processing and against accidental loss, destruction, or damage, using appropriate technical or organizational measures (‘integrity and confidentiality’).”

So GDPR recognizes the I in CIA as well. However, if you look at industry press, the focus around GDPR is always on privacy, and protecting the integrity of personal data (or any other data you hold) isn’t really mentioned.

(Before we move forward, here’s a disclaimer: Please forgive me for making some sweeping generalizations in order to share this idea. Also, for any data protection specialists, I’ve had to avoid using the term “data protection” when I otherwise would, as it would lead to ambiguity here. As a result, I’ve had to lean on the word ‘backup’ a few times when I really mean “all approaches related to protecting data from damage or destruction,” which is a bit of a mouthful…)

Rewind about a decade or so, and the term “data protection” was used almost exclusively within IT departments to describe backups and maintaining multiple copies of data to protect against damage or destruction (data corruption, IT hardware failure, or a flood in the data center). That’s very much the Integrity side of things (and also reaches into Availability when you consider, as every backup specialist will tell you, that you have to think about restoring – when and if anything happens – as much as backing up). Perhaps it’s simply that this sort of thing is old hat, and it’s the privacy side of things that is newer, resulting in it dominating the conversation.

In summary, there is a risk that we neglect these other elements of data protection while we concentrate on privacy. I think it makes sense to reset a little and rethink data protection using the CIA triad as a basis.

Govern Integrity and Availability the way you govern Confidentiality

Backups et al. (i.e., the Integrity part of the triad) have been around for ages and were delivered in a world when the walls between IT and the business were well and truly up. Backup was an IT problem; the default ‘data owners’ were IT (if anybody ever really thought about it), and it was assumed they would handle the protection of data against damage. This tended to miss a key point – IT didn’t create the data and didn’t understand the importance of the data to the business.

Technical people would start asking about RPOs and RTOs and get blank expressions in return. The impact was that the business was not exploring the impact of the loss of certain data, enabling it to clearly articulate what levels of protection were required where. As a result, technology was duly invested in to protect data, but it was not governed in the sense that there was no clear link between what the data was and how it was protected.

Fast forward a bit, and now we are investing time and effort into privacy. We are doing it in a world where we understand the importance of the data being owned by those who create and use it, not by those who store it for you. We are increasingly embracing information sensitivity markings and policies which determine how privately we must store data based on how sensitive it is.

We need to loop back and apply this same level of governance to other aspects of data protection to ‘retrofit’ better governance to the way we do e.g., backups.


We talk about data classification a lot in data management and data governance, but we always tend to look at it from the privacy perspective – classifying data based on how sensitive it is so we can understand and mitigate the risk of it getting into the wrong hands. We develop policies to determine whether a document, data set, or data type is ‘Confidential’ or ‘Restricted’ and use that information to impose appropriate privacy controls.

We should do that for the rest of data protection.

That would mean classifying data in a way that determines how carefully we should protect that data from damage. But we can’t use sensitivity as our barometer – the sensitivity of data does not dictate the impact of us losing it. We need something else. In these terms, I think the metric is ‘value.’ You protect it from damage or destruction because it’s valuable, and the more valuable it is, the more time, effort, and money you want to invest into ensuring you don’t lose it. If we developed a data classification as mature as we use for privacy but based on value, then the IT department will be able to make much better and data-driven decisions on where to invest its budget. There is evidence of this happening – we can label data as ‘Critical Data’ to indicate it is somehow more important, but it’s certainly a few steps behind what we do around privacy.

Considering Availability

We should probably touch on the Availability side as well – this is a slightly less clear conversation. You can certainly imagine measuring the negative impact of data not being available, but it quickly becomes tightly linked to applications or services. Generally, data being unavailable (but not lost) results in you not being able to do something, so it should possibly be bundled in with conversations around general service availability. If you can’t get your money out of a cash machine, you don’t care whether it’s because the database is down or because the application has a bug – it’s all the same to you.

However, you could certainly recognize the impact on service to certain data being unavailable and quantify that in a way that allows you to classify data and to apply appropriate controls to ensure its availability. Again, the IT department will have a clearer view of the importance of keeping that data available and use that information to make better investment decisions.

The result of all this is that I propose that rather than simply classifying our data based on sensitivity in order to manage privacy, we also need to classify data based on its value in order to manage data integrity and classify data based on its impact on service in order to manage data availability. In summary,


Data Protection = Confidentiality + Integrity + Availability


What we need to know about our data = sensitivity + value + service impact

At Nephos, we combine technical expertise and the strategic business value of traditional professional service providers to deliver innovative data solutions. We understand that effective cybersecurity goes beyond just ensuring privacy. Click here to know more about how our comprehensive approach safeguards all aspects of the CIA triad.

Looking for similar resources? We have got you covered:

Allan Watkins

At the heart of Allan's professional journey, spanning more than 26 years, lies a deep-seated passion for acquiring knowledge and understanding the mechanics behind how things operate. His thought leadership content mirrors this curiosity, enabling readers to broaden their understanding of data governance and its complex web of policies.

Close Menu

© Nephos Technologies Ltd.