Data Architecture

Data Classification Helper

Column names in, suggested classification tier and the handling it requires out.

Loading the tool…

Processing happens locally in your browser. What you paste or load is processed by this page and is not uploaded to a server. Nothing is stored unless you use a control that says it stores something, and you can clear anything this site has kept from the privacy page.

How to use this tool

  1. Paste your column names, one per line. Prefix them with the table if you are doing several at once.
  2. Select Classify columns.
  3. Start at the top: restricted columns set the handling requirement for the whole table unless you split it.
  4. Classify anything marked Not recognised by hand. An unhelpful column name hides more than a helpful one reveals.

What data classification helper does

Most classification exercises stall at the same place: someone produces a spreadsheet of columns with tiers next to them, everyone agrees it looks right, and nothing changes, because a tier with no consequence attached is a label rather than a control. The useful output is not the tier. It is the sentence that says what the tier requires you to do differently.

Every column here is matched against the patterns that identify government identifiers, payment details, credentials, special category data, names, contact details, locations, online identifiers and pseudonymous keys, and every row carries the handling requirement rather than just the label. A name is evidence and not proof, so unrecognised columns are reported as unrecognised rather than quietly marked safe, and the summary makes the point that a table is as sensitive as its most sensitive column unless you split it.

Frequently asked questions

No. It is a starting list, not an assessment. A name is evidence and often right, but a column called notes can hold anything at all, and a column called ref_2 tells you nothing while potentially holding a passport number. Use this to find the obvious cases quickly, then look at actual values for anything you were not certain about — including everything it reports as unrecognised.

They are the four levels most organisations converge on: restricted, confidential, internal and public. Your own scheme may use different words or five levels instead of four. Map the names to yours — the reasoning attached to each row does not change, and it is the handling requirement rather than the label that does the work.

On its own it is a pseudonym; the moment it is joined to the table that maps it to a name, it identifies someone. So its real classification is the classification of that join, which is a property of your access model rather than of the column. Under GDPR pseudonymised data is still personal data — the pseudonym reduces risk, it does not remove the obligation.

For access control, effectively yes, unless you split it. If one column in a wide table is restricted, then anyone with SELECT on that table has the restricted data, and every environment the table is copied to inherits the requirement. This is the usual argument for separating sensitive attributes into their own table with its own grants, rather than protecting the column with a policy everyone remembers to apply.

Further reading