Sort Finance Data into Sensitivity Classes

Before you paste anything into an AI tool, you need to know what kind of data you are holding. A sensitivity class is a label for how much harm a piece of data could cause if it reached the wrong place. This course uses six working classes:

• Customer identifiers: anything that points to a specific customer. Examples are customer IDs, names, emails, tax IDs, and invoice references tied to a person or company.
• Bank details: account numbers, IBANs, sort codes and card numbers.
• Credentials: passwords, logins, API keys and banking portal access.
• Unreleased results: results, forecasts and guidance that have not yet been published.
• Internal operational data: figures used inside the business that are not tied to a customer and are not unreleased results, such as cost centre codes or headcount by team.
• Public figures: numbers that have already been published.

The first four are restricted. That means they need the most care and should only go to tools your organisation has approved for them. For example, a payments file with a supplier's IBAN and a column of portal login names holds two restricted classes in the same sheet.

Most organisations already have a data classification scheme: an official set of labels with rules for each one. Common labels include Public, Internal, Confidential and Restricted, but yours may use different names or more levels.

The six working classes in this course are a sorting aid. They do not replace your organisation's labels. Map each working class onto your organisation's label and use that label in practice. For example, your scheme may put bank details and credentials under "Restricted" and customer identifiers under "Confidential". When the two disagree, your organisation's rules win.

Some fields will not fit cleanly. A column called "Ref 2" that sometimes holds a contract number and sometimes a contact name is one example. Don't guess. Ask the person who maintains the data handling rules, often someone in information security, data protection or finance systems. Until you have an answer, treat the field at the stricter of the possible levels.

If you don't yet know who maintains the rules, finding out is a prerequisite for this course. Write the name down now.

Work in two passes.

Pass 1: column level. Go through the file one column at a time and give each column a class. Read the header, then check a sample of the actual values, because headers can mislead. A column headed "Reference" may hold invoice numbers in most rows and customer emails in a few.

Pass 2: file level. A file takes the class of its most sensitive column. It does not matter if 19 of 20 columns are internal operational data. If one column holds IBANs, the whole file is handled as bank details.

The same rule applies to a workbook with several sheets. A clean summary sheet does not make the workbook safe if another tab holds a customer list.

This tells you two things. First, the file class decides where the file as a whole may go. Second, the column classes show exactly which columns you would need to remove, mask or summarise to lower the file's class. Later lessons cover how to do that.

A receivables ageing report lists unpaid customer invoices, grouped by how overdue they are. Here is a typical export with seven columns, classified column by column:

Column	Class	Why
Customer ID	Customer identifier	Points to one customer
Customer name	Customer identifier	Names the customer directly
IBAN	Bank detail	Bank account number
Invoice number	Customer identifier	Tied to a specific company
Amount	Internal	Not identifying on its own
Due date	Internal	Not identifying on its own
Collector notes	Review needed	Free text, could hold anything

The collector notes column needs care. Notes such as "Spoke to J. Patel, will pay Friday, call 07…" contain names and phone numbers. Treat this column as at least a customer identifier until you have read it.

At file level, the most sensitive column is the IBAN, so the whole export is handled as bank details. Three columns are customer identifiers. Only amount and due date are internal, and even those can identify a customer when combined with other fields, as a later step shows.

Restricted content often sits outside the columns you can see. Before you call a file clean, sweep it from the outside in:

1. File name. A name like "Q3_unreleased_results.xlsx" reveals unreleased results before anyone opens the file.
2. Document properties. These are the author, title, company and comment fields stored with the file. They may hold names or project titles.
3. Sheet tabs. Check for hidden sheets as well as visible ones. A tab named "Customer master" may be hidden but still in the file.
4. Hidden rows and columns. A hidden column of tax IDs travels with the file even when you can't see it.
5. Cell comments and notes. Reviewers often leave remarks such as "check with Acme's CFO".
6. Free-text fields. Memo, description and narrative columns may contain names, account numbers or even passwords that someone typed in.

In a spreadsheet, unhide all rows, columns and sheets, and open the comments pane before you classify. If you copy and paste only a selected range, check that the selection does not include hidden rows.

A field that is harmless on its own can identify a customer when it is combined with others.

Combined fields. Postcode, contract value and start date each look like ordinary data. Put them together, and there may be only one contract in that postcode, of that size, starting that month. Anyone who knows the business can work out who it is.

Small groups. A regional total looks like a summary. But if a region has only one large customer, the regional total is in effect that customer's revenue. The same applies to a product line with two clients, or a month with one big order.

Partial fields. The last four digits of an account number, or a customer name shortened to "Acme…", still narrow things down, especially when combined with an amount and a date.

So when you classify, ask two questions about each column. Does it identify someone on its own? Could it identify someone together with the other columns in the file? If the answer to the second question is yes, treat the combination as a customer identifier.

Try the explorer. Set the number of customers to 1 and see what the "average" now reveals.

The public class is narrower than it sounds. A figure is public only once it has actually been published, for example in a released annual report, a results press release or a filed statement that anyone can read.

These are not public:

• Quarterly results that will be announced next week. Today they are still unreleased results, even if the announcement is drafted and approved.
• A forecast or guidance figure discussed at a board meeting but not yet announced.
• A number that appeared in an internal town hall slide deck.
• A draft of the annual report sitting in a shared folder.

The test is simple: can you point to where it was published, and was that before today? If you can't, classify the figure as unreleased results or internal data.

This matters because public figures are your easiest route to using AI. Many questions, such as comparing your published margins with a competitor's, can be answered from public figures alone, with no restricted data involved at all. But the shortcut only works if the figures really are public.