The data classification debate in 2026 is, in the end, mostly a debate that nobody is going to win, with the debate being the same debate the security teams have been having for the last fifteen years, the debate being the debate that produces the same four tier schema every time, and the debate being the debate that nobody has the authority to resolve. The data classification becomes the work the security team has been asking the data team to do, the data classification sits as the work the data team has been asking the security team to define, and the data classification stands as the work the privacy team has been asking the legal team to enforce. The data classification serves as the work that the compliance team is going to be auditing, the data classification counts as the work the executive team is going to be reporting on, and the data classification becomes the work that nobody is going to be happy with.
Why the debate goes nowhere
The debate goes nowhere because the participants are arguing about different things. The security team is arguing about the risk exposure of the data, the data team is arguing about the operational cost of labelling the data, the privacy team is arguing about the regulatory requirement for labelling the data, and the legal team is arguing about the contractual obligation for labelling the data. The four teams are talking past each other, the four teams are using the same words to mean different things, and the four teams are not going to converge on a single answer because the four teams are answering different questions.
The right way to break the deadlock is to pick the minimum useful schema and to ship the minimum useful schema. The minimum useful schema is three categories: public, internal, and restricted. The minimum useful schema does not try to capture every nuance of the regulatory landscape, the minimum useful schema does not try to capture every nuance of the data lifecycle, and the minimum useful schema does not try to capture every nuance of the operational reality. The minimum useful schema sits as the schema the team can maintain, the minimum useful schema amounts to the schema the team can audit, and the minimum useful schema amounts to the schema the team can use to make the day to day decisions.
What the practical minimum looks like
The three category schema runs as the practical minimum. The public category covers the data the organisation has decided to publish, the public category covers the press releases the marketing team has approved, and the public category covers the documentation the developer relations team has written. The internal category covers the data the organisation uses to run the business, the internal category covers the customer data the support team needs, and the internal category covers the financial data the finance team uses. The restricted category covers the data that has a regulatory or contractual sensitivity, the restricted category covers the authentication data, the payment data, the health data, and the personal data, and the restricted category sits as the data that has the controls the audit is going to be looking for.
The three categories are enough for the day to day decisions, the three categories are enough for the audit, the three categories are enough for the regulatory framework, and the three categories are enough for the contractual obligation. The teams that try to do more are the teams that end up with the schema nobody uses, the teams that try to do more are the teams that end up with the labels nobody maintains, and the teams that try to do more are the teams that end up with the audit finding that the labels are out of date.
What to skip
The four things to skip are the seven tier schema, the per row label, the auto classification tool, and the annual relabelling exercise. The seven tier schema sits as the schema the compliance team dreams of, the seven tier schema runs as the schema the data team cannot maintain, and the seven tier schema amounts to the schema that ends up being a spreadsheet nobody updates. The per row label becomes the dream of the privacy team, the per row label becomes the cost the data team is going to push back on, and the per row label stands as the work that is going to be deprioritised the first time the team is busy. The auto classification tool becomes the tool the vendor sells as the silver bullet, the auto classification tool becomes the tool that has a 70 percent accuracy on the training data, and the auto classification tool amounts to the tool that is going to produce the wrong label on the sensitive data the most. The annual relabelling exercise amounts to the exercise the compliance team schedules, the annual relabelling exercise becomes the exercise the data team treats as a chore, and the annual relabelling exercise sits as the exercise that produces the labels that are out of date within a quarter.
The four things to skip are the things the security team is going to keep being sold by the vendors, the four things to skip are the things the data team is going to keep pushing back on, and the four things to skip are the things the audit is going to keep finding out of date.
What the schema needs to do
The schema needs to do three things. The schema needs to drive the access control, the schema needs to drive the retention policy, and the schema needs to drive the breach notification. The schema that drives the access control sits as the schema that the IAM team is going to use, the schema that drives the retention policy amounts to the schema that the storage team is going to use, and the schema that drives the breach notification runs as the schema that the security team is going to use. The schema that does not drive any of these three things amounts to the schema that nobody is going to use.
The schema that drives the access control sits as the schema that has the right granularity, the schema that drives the access control becomes the schema that maps to the IAM policies, and the schema that drives the access control amounts to the schema the security team is going to be able to audit. The schema that drives the retention policy runs as the schema that maps to the storage tier, the schema that drives the retention policy stands as the schema the storage team is going to be able to enforce, and the schema that drives the retention policy serves as the schema the privacy team is going to be able to report on. The schema that drives the breach notification sits as the schema that maps to the regulatory requirement, the schema that drives the breach notification runs as the schema the legal team is going to be able to invoke, and the schema that drives the breach notification amounts to the schema the executive team is going to be able to use when the breach happens.
How to maintain the schema
The schema is maintained by the data team, with the security team providing the policy and the audit team providing the validation. The data team stands as the team that owns the data, the data team amounts to the team that labels the data at the point of creation, and the data team counts as the team that is accountable for the labels being current. The security team sits as the team that defines what each label means in terms of the controls, the security team amounts to the team that audits whether the controls are being applied, and the security team stands as the team that reports to the board on the state of the data classification.
The maintenance serves as the part nobody wants to do, the maintenance serves as the part the team is going to skip when the team is busy, and the maintenance counts as the part the audit is going to find out of date. The fix is to make the maintenance part of the normal operations work, with the maintenance as part of the data creation workflow, with the maintenance as part of the storage provisioning workflow, and with the maintenance as part of the data deletion workflow. The maintenance that is part of the operations work becomes the maintenance that gets done, and the maintenance that is part of the operations work serves as the maintenance the audit is going to find up to date.
What good looks like
A good data classification programme has three properties. First, the schema is three categories, the schema is documented in two pages, and the schema is taught to every new employee in their first week. Second, the labels are applied at the point of creation, the labels are part of the metadata that travels with the data, and the labels are part of the access control that the IAM team enforces. Third, the audit validates the labels annually, the audit reports the state of the labels to the board, and the audit amounts to the artefact the regulator is going to be looking for.
A good data classification programme is also boring. The programme becomes the structure the data team uses, the programme stands as the framework the security team reports against, and the programme stands as the artefact the audit team validates. The programme is not the thing the organisation talks about at the conference, the programme is not the thing the organisation uses to look good, and the programme is not the thing the organisation does in the run up to the audit.
The bottom line
The data classification debate in 2026 sits as the debate that nobody is going to win. The right answer counts as the three category schema, the right answer becomes the schema the team can maintain, and the right answer amounts to the schema the audit can validate. The teams that are doing this well are the ones that have picked the minimum useful schema and shipped the minimum useful schema, and the teams that are doing this poorly are the ones that are still debating the seventh tier.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
