I have been helping a friend at a small consultancy build a data-classification framework. The exercise has been more useful than I expected — both for them and for clarifying my own thinking. Worth writing up the structure I recommend for organisations without one.
What data classification is for
The basic idea: not all data is equally sensitive. Treating it all uniformly is either overkill (annoying, expensive) or underkill (insecure, risky). A classification framework lets you treat different categories of data differently.
For a small organisation, the classification needs to be simple enough to be applied without bureaucracy. Three categories are usually enough:
Public. Data that is intended to be visible to anyone. Marketing material, public-facing documentation, the company's address. No protection beyond ordinary integrity.
Internal. Data that is meant for staff but is not particularly sensitive. Internal procedures, internal contact lists, project plans, ordinary email. Protected against external access; not protected against staff with appropriate role.
Sensitive. Data that would cause real damage if exposed. Customer records, financial information, security configurations, personal employee data. Protected with explicit access control; tracked; subject to specific handling rules.
More categories than this start to be unwieldy at small scale. Some larger organisations need a Restricted/Confidential/Top-Secret-style hierarchy; smaller ones do not.
What the framework specifies
For each category:
Storage. Where can it be stored? What encryption is required? What backup discipline?
Transmission. How can it be moved? What channels are acceptable? Is encryption required in transit?
Access. Who can read it? Who can modify it? How is access reviewed?
Retention. How long is it kept? When is it deleted? What is the deletion procedure?
Incident handling. What happens if it is exposed? Who needs to be told? What are the regulatory implications?
The specifics are organisation-dependent, but the structure is the same.
A worked example
For my friend's small consultancy, the rules they ended up with:
Sensitive data (customer records, financial data, internal credentials):
- Stored only on encrypted volumes.
- Transmitted only via TLS or via personally-encrypted attachments.
- Access via named-user authentication, with quarterly access review.
- Retained per regulatory requirement (typically 7 years for financial); deletion by secure-erase procedure.
- Incident escalation to senior management within 24 hours of discovery.
Internal data (project plans, internal correspondence):
- Stored on standard internal systems (which are themselves protected against external access).
- Transmitted within the corporate network without specific encryption requirements; outside the network only via TLS.
- Access by role; review semi-annually.
- Retained as long as operationally useful; routine deletion.
- Incident handling at line-management level.
Public data (marketing, public-facing pages):
- Stored anywhere convenient.
- Transmitted over any channel.
- Read access universal; modify access by named role.
- Retained until obsolete.
- Incident handling for integrity concerns only (defacement etc).
What having the framework does
Four things, in roughly increasing order of value.
Decisions become routine. "This is a customer record, so it needs to be on the encrypted volume" is a one-step decision rather than a deliberation. The framework reduces decision overhead.
Onboarding becomes easier. New staff have a small document to read that covers the data-handling expectations. The implicit knowledge becomes explicit.
Incident handling becomes faster. When an incident occurs, the framework specifies what to do. The response time is shorter than if everyone is making it up on the spot.
Audit becomes tractable. External auditors can verify that the organisation has a framework, that the framework is reasonable, and that the framework is followed. Without the framework, audit is exhausting.
What I am taking from the exercise
The framework is, on its own, simple. The hard work is the adoption — getting staff to apply the categorisation consistently, getting management to enforce it, getting it integrated into regular operations.
For my own work, I am thinking about whether to write a more detailed piece on this for the small-business audience I identified at the Manchester gathering. The framework is exactly the kind of thing small businesses lack and benefit from. The writing-down would be a useful contribution.
More as the year develops.