Security programmes usually start with tools. A DLP product, an encryption policy, an access review. Each of them asks the same question in its configuration screen: which data is sensitive? And that is where the programme stalls, because nobody has answered it.
Classification is the unglamorous prerequisite. It means deciding, in writing, what categories of data the organisation holds and how each should be treated. A workable scheme has three or four levels, not eight. Public, internal, confidential, restricted is enough for most companies. More levels sound rigorous and produce arguments instead of decisions.
The mistake is trying to classify everything at once. Start with the data that would cause the most damage if it leaked, work outward, and accept that a large tail of files will stay unclassified for a long time. An organisation that has correctly identified and protected its customer database and its source code is in a far better position than one with a beautiful taxonomy applied to nothing.
Classification has to attach to the data, not to a spreadsheet describing the data. That means labels in the document management system, tags on cloud storage buckets, column-level markings in the warehouse. A classification that lives only in a policy document cannot be enforced by any tool.
Under India's DPDP framework, personal data carries obligations regardless of how you have labelled it internally. Classification does not change the law, but it does change whether you can answer questions about where that data lives when a regulator, an auditor or an enterprise buyer asks. That question arrives eventually, and the organisations that struggle with it are the ones that never did this step.
