The push for data classification rarely comes from IT. It comes from sales. A major customer sends a security questionnaire, and on page three sits the question about your classification policy. Two weeks later a policy with four levels exists, IT switches on labels in Microsoft 365, the questionnaire goes back, the contract arrives.
A year later almost no document carries a label. And the data your business depends on sits exactly where it sat before.
This is not a delivery failure. Data classification in an SME nearly always fails at the same point: nobody ever decided which data counts. The scheme existed before the question was asked.
Data classification is a business decision about what a particular loss of data costs. The Swiss Confederation protects its national interests with three levels, and an SME rarely needs more. What is missing in an SME is rarely levels. It is names: the five to fifteen data sets that carry revenue, margin or operations, and one person per set who stands behind it.
Why classification projects in an SME run into the sand
The usual data classification scheme comes from a template. It defines the levels in the abstract: confidential means data whose disclosure would cause the company considerable harm. Everyone nods in the workshop. Nobody can apply it at their desk, because "considerable harm" is not a property of a document. It is a judgement about the business, and the person saving a quotation is not the one who makes that judgement.
So what always happens in that situation happens. Either everything becomes internal, because that is never wrong. Or nothing gets set at all, because that is faster still. From the outside both look the same: a rollout that took place, and protection that does not exist.
The second reason is the order of events. Data classification gets set up as a technical exercise. Configure labels, publish the policy, twenty minutes of awareness training. But a label is the end of a chain of decisions, not its beginning. Hand out the stickers first and ask afterwards what should be written on them, and you get stickers. Nothing more.
What does data classification in an SME mean in practice?
Data classification means recording, for every important data set, how bad it would be if it became public, if somebody altered it unnoticed, or if it were unavailable for a week. Everything else follows from that answer: who may have access, how long it is kept, how much protection can be justified. The label on the document is only the visible end of it.
The three questions do not carry equal weight. Most SMEs think about data classification purely in terms of confidentiality, meaning secrecy. In a Swiss manufacturing or trading business the more expensive failure is often a different one. When master data in the ERP goes quietly wrong, the company produces against a faulty bill of materials for days. When production planning is down for a week, it makes no difference that nobody read it. A scheme that sorts only by degree of secrecy leaves both cases out.
The Swiss Confederation manages with three levels
The Informationssicherheitsgesetz (ISG, the Swiss Information Security Act) governs how the Confederation protects its own information. It deals with national interests, foreign policy, the armed forces. The number of classification levels the legislator considered necessary for that: three. Internal, confidential and secret, graded by whether disclosure to unauthorised persons could impair, considerably impair or seriously impair those interests. Set out in Article 13 of the Information Security Act (SR 128).
More protection comes from fewer levels here, not more. Every additional level doubles the cases where somebody has to stop and think, and multiplies the rules somebody has to maintain. A scheme your staff do not carry in their heads protects nothing. It only documents that somebody thought about it.
We regularly see SMEs with five levels, three of which are indistinguishable day to day. In none of those cases was the difference between "confidential" and "strictly confidential" tied to a different control. Same storage, same permissions, same email handling. Two levels that produce the same result are not precision. They are a decision somebody did not want to make.
How many levels does an SME need?
Three, in the large majority of cases: public, internal, confidential. Internal is the normal case and requires no action from anyone. Public and confidential are the two exceptions that get decided deliberately. A fourth level only pays off when there is a data set that calls for different devices, different rooms or different contracts.
The default matters more than the count. When your standard setting is "internal" and applies automatically, nobody has to do anything for the normal case to be right. People then decide only at the edges, which is exactly where they should be deciding. Schemes that demand an active choice for every document generate a thousand small decisions a week and not one good one.
There is one special case. The revised Swiss Data Protection Act (nDSG) recognises particularly sensitive personal data, including data on health, on religious or trade union views, biometric data, and data on social assistance and criminal proceedings, set out in Article 5 letter c of the Data Protection Act. Every SME with its own HR department holds some of it: medical certificates, reasons for absence, wage garnishments. This does not need a level of its own. It needs a location with tight permissions and somebody who knows the data is there.
Which data counts: the data your business hangs on
In a company with 50 to 500 employees there are, in our experience, between five and fifteen data sets that carry revenue, margin or operations. Usually they are variants of the same six:
- Design, formulation or source code data
- Costings, margins and the basis for quotations
- Customer contracts with their terms, and the customer list with revenues
- Personnel files and payroll data
- ERP master data that production and invoicing depend on
- Credentials and keys to the systems carrying all of the above
It is rarely more than that, and your management team can put this list together in a single meeting, if you ask them the right way.
Asking the right way means not "what level does this document have", but "what happens to our business if this data sits with a competitor tomorrow, has been quietly altered, or is gone for a week". A management team cannot answer the first question. It answers the second in about a minute per data set. That is the whole difference between a data classification that gets used and one that gets filed.
An anonymised example from a mandate. A supplier near Zurich, a good 200 employees, was asked by a large German customer about its classification policy. The policy was ready in two weeks, four levels, cleanly written, never challenged in a customer audit. Not quite a year later, the only documents carrying a label were essentially the ones IT had created itself. That same week a permissions review turned up the fact that the design data for the assembly with the best margin sat in a folder that temporary staff from the assembly line could also open. Grown over time, never malicious, never noticed by anyone.
The policy was not wrong. It had never mentioned this data, because nobody had ever named it. The finding was uncomfortable and the correction was small: one folder, one permissions group, two weeks of discussion about who owns the design data. No tool, no project, no new licence.
What does data classification cost in an SME?
The licence is rarely the problem. In most SMEs the technical labelling is already paid for inside the existing Microsoft 365 or ERP contract and goes unused. The effort sits elsewhere: in the decisions your management team has to make, which in our experience rarely cost more than half a day in total, and in the clean-up afterwards, when it becomes visible who has access to what today.
The reverse order is what gets expensive. Buy a classification or data discovery tool before the list of relevant data sets exists, and you are paying licence fees to ask a question you should have answered yourself. The tool will then reliably find every file containing a Swiss social security number and sort them by location. Which of them carries the business appears in no scan result.
The pleasant part: once the list stands and the permissions are tidied up, a good share of what additional tools usually get bought for resolves itself. That is the same arithmetic as everywhere else in security, more protection through better sizing rather than through buying more, and it sits openly in our packages and fixed prices.
Who owns the classification
A data classification without named owners falls apart within a year. Not because people are careless, but because the business moves: a new product line, a new CRM, another site, a service provider gone. When nobody is responsible for a data set, nobody notices.
The owner sits in the business, not in IT. The design data belongs to the head of engineering, the personnel files to HR, the costings to the CFO. IT runs the storage and implements the permissions, but it cannot judge what a data set is worth to the business. This mistake is the most common one in the whole exercise, and it is the reason so many classifications exist formally and belong to nobody in practice.
Once a year somebody goes through the list with your management team and asks whether it still describes how the company earns its money. That is the same muscle that decides whether you have a living ISMS rather than a paper one, and the same groundwork that lets you answer a customer security questionnaire without guessing. Unglamorous leadership work, a few hours a year. It is the difference between a policy and effective protection.
Frequently asked questions
Do we need data classification even without ISO 27001?
Yes, though in a smaller form. Permissions, retention periods and emergency priorities all assume somebody knows which data matters more than the rest. Without certification pressure this needs no policy with a version number. It needs the list of relevant data sets and the owners that go with them.
Do we have to classify legacy data retrospectively?
Across the board almost never, and attempting it is a common reason these efforts stall. The reverse scope holds up better: the few data sets that carry the business get tidied up where they sit today. The large remainder stays on the internal default and gets replaced by new storage over time anyway.
Is it enough to settle classification in a policy?
For an audit often yes, for protection never. An auditor checks whether a rule exists and whether spot checks match it. An attacker, or an email sent to the wrong person, checks whether the permissions are right. The policy is the justification for the permissions, not a substitute for them. When the two drift apart, the permissions win every time.