Data Classification vs Data Confidentiality: Why You Need Two Fields

In many of the companies where we have delivered consulting, data classification is a single list. It usually looks something like this: Public, Internal, Confidential, Personal Data, Sensitive Data. It feels tidy, and everybody understands it in five minutes. The trouble starts a few months later, when people try to use it.

The list mixes two different questions. Once you separate them, a lot of everyday problems in data projects get easier to solve.

Two questions that look like one

Data confidentiality asks how much damage a leak would cause. The answer is a ladder, from harmless to severe. Data classification asks what kind of data you are dealing with, and above all whether it relates to people. That answer is a category, and it brings legal duties such as GDPR or the Swiss FADP.

A ladder and a set of categories cannot share one list. Is "Personal Data" above or below "Confidential"? Nobody can answer that, so every team decides for itself.

Where the mixed list goes wrong

Here are three situations we see again and again. They are typical cases, not single clients.

The staff directory. It is an internal document, so it gets Internal. But it contains names, phone numbers and job titles, which is personal data. When the data protection officer asks where employee data is stored, the directory does not show up. If the team chose Personal Data instead, the directory loses its confidentiality level, and nobody knows how carefully it must be shared.

The two teams. Finance labels a report Confidential. HR labels a similar report Sensitive. Both are right by their own logic, but a manager who wants to see the most protected assets cannot sort them, because the labels are not on the same scale.

The audit request. Someone asks which systems hold personal data. With a mixed list, the honest answer is that somebody has to open every asset and decide again. That is weeks of work for a question that should take a minute.

In all three cases the label carried too much meaning, so it ended up carrying very little.

How two fields fix it

Give every asset both values. Data Confidentiality uses four levels: Public, Internal, Confidential and Highly Confidential. Data Classification uses three: No personal data, Personal data and Sensitive personal data. Both fields also have a Not classified state, so you can tell an asset nobody has reviewed from one that was reviewed and found harmless.

The staff directory becomes Internal plus Personal data. A customer health record becomes Highly Confidential plus Sensitive personal data. A technical flow that moves sensor readings becomes Internal plus No personal data. Each label is short and clear, and nothing is lost.

The two fields still work together. Personal data sets a minimum confidentiality level, and sensitive personal data sets a higher one. Your organisation can adjust these floors to match its own policy.

Set it once, let it travel

Nobody wants to classify hundreds of assets by hand. In Asset Navigator you set the values on the dataset. Audit Findings, for example, is Highly Confidential. When you link that dataset to a relationship between two assets, both assets pick up the level automatically.

Each asset keeps its own declared value and receives an inherited value from its datasets. The effective level is the higher of the two. Because nothing is overwritten, the level recalculates on its own when you unlink a dataset or change its level. Every asset also shows where its level comes from, for example "inherited from Audit Findings via the relationship between Flow A and Report B".

Two safeguards keep this useful. Lowering a level needs a written reason and is logged, because an anonymised or aggregated report can be less sensitive than its source, but that is a claim someone should stand behind. And the spread stops at the direct ends of the relationship. Assets further downstream get a suggestion to review, not an automatic label, so everything does not slowly turn red.

Planning a change as a project lead

This is where the two fields pay off. Imagine you lead a project that replaces a reporting flow, or moves a set of views out of an old data lake.

1. Search for the asset in Asset Navigator and open its relationships. You see what it feeds and what feeds it.
2. Filter the affected assets by confidentiality and classification. How many are Highly Confidential? How many contain personal data?
3. Involve the right people early. Personal data means the data protection officer joins the project. Highly Confidential assets mean security reviews the access model.
4. Link your Jira tickets to the affected assets, so the sensitivity of the work is visible where the team plans it.
5. Adjust your plan. Test data, access rights, rollout order and communication all depend on what you found.

Without this, teams find the sensitive assets at the end of the project, usually in a review nobody planned time for. With it, the risk is on the table when you estimate.

Where to start

Start small. Classify the datasets that are clearly sensitive first, and let the relationships carry the values to the assets around them. Define each confidentiality level by what a leak would cause, not by data types, so people classify the same way. Then work through the Not classified list over time.

One list feels simpler on day one. Two fields are simpler every day after that.