Data classification

Data classification assigns each piece of information a sensitivity level (for example public, internal, confidential, restricted) so that everything downstream can key off that label: who may access it, whether it must be encrypted, how long it is kept, and whether it may leave the organisation. Good classification follows the harm that disclosure would cause, and it maps to regulatory categories such as personal data or the levels of a compliance scheme. The label is the anchor for policy; the policy is enforced by other controls (access management, encryption, data loss prevention) that read the label and act on it. Without those enforcing controls, a classification scheme is a taxonomy with no teeth.

The overstatement to avoid is that classified data is protected automatically. Labelling something confidential does nothing on its own; enforcement requires tooling that recognises the label and acts, and that tooling frequently does not exist for the channel where the data actually leaves. The other failure is decay: classification is done once, at a project’s start, and then the data moves, is copied, is transformed, and the labels do not follow. From an attacker’s or an insider’s view, the interesting data is often the unlabelled copy: the export to a spreadsheet, the backup, the dataset a team pulled for analysis, none of which inherited the original’s controls.

We assess classification by whether the labels actually drive protection: is sensitive data identified, do the enforcing controls read the labels, and does the classification survive as data is copied and moved. We look for the unlabelled copies, because that is where the exposure hides, and we tie the review to the regulatory categories that determine obligations, such as ENS security categories. Where reducing scope is possible, we point at tokenisation. The finding is written against the gap between the label and the control. This is part of how we assess data handling against classification.