Data Classification and Document Labels: a 60-Day Model

Why implement labels at all and what do we want to fix

Without a clear system, data classification becomes guesswork. One department stores contracts haphazardly, another grants access “just in case”, a third sends files by email without checks. Risks accumulate quietly until an incident happens.

Labels solve several practical problems.

First, they reduce the likelihood of leaks: a document containing personal or financial data should indicate how it must be handled.

Second, they help tidy up access. If a file has a clear level, it’s easier to set rules for storage, forwarding, and printing.

Third, they reduce the impact of common mistakes: “sent to the wrong person”, “put in the wrong folder”, “forgot to set a password”, “forwarded an old version”.

Simple example: an employee prepares a report with national ID and salaries and forwards it to a general chat “for approval.” If the document is labeled “Confidential: personal data,” the system can warn of the risk or block external sending. InfoSec then has a clear view of where such files live and how they move.

Success is not “everyone labeled everything,” but measurable changes: fewer, clearer rules that people actually use. In 60 days you should expect fewer manual errors and a higher share of documents that employees label without prompts and disputes.

It’s better to set project boundaries for 60 days in advance. In that time you can typically agree on 3–5 simple levels, enable labeling in 1–2 key scenarios (for example, mail and office files), run a pilot in one function and one data type, and set up basic controls and reporting for InfoSec.

What to postpone: trying to cover all systems at once, fine-tuning dozens of exceptions, and “perfect” auto-classification across every source.

Start with teams and documents where the cost of error is highest. Most often these are finance, legal, HR, procurement, project offices, and units working with client or patient data. In regulated organizations (public sector, banks, healthcare, education) the effect is visible faster: access and storage requirements usually exist, but they are not backed by convenient rules in tools.

Document labels in simple terms: what they are and how they work

A document label is a clear name you assign to a file or email so the system knows how to handle it. For example: “Public,” “Internal,” “Confidential,” “Strictly Confidential.” A label only makes sense if it changes system behavior, not just displays as a tag.

Similar terms are often confused. A helpful separation:

• Classification — the decision which level the information belongs to (by meaning and risk).
• Label — the chosen level attached to a specific file, email, or message.
• Policy — rules for what to do with objects with that label (e.g., can it be sent outside).
• Encryption — protection so only authorized people can open the content.
• DLP (data loss prevention) — control of attempts to send or remove data, with blocking or warning.

Where labels “live” in daily work: office files, mail, collaboration, when documents are forwarded, opened from shared locations, or copied. A good label “travels” with the content and isn’t lost during normal actions.

Labeling can be manual or automatic. Manual is when an employee picks the label (best when the system suggests and doesn’t force long thought). Automatic is when the system suggests or sets a label by indicators: document type, template, presence of national ID/contract number, keywords, media metadata, etc.

Example: an accountant sends a report to a contractor. If the report is labeled “Internal,” the policy can warn on sending to an external email. If labeled “Strictly Confidential,” the system can block forwarding and enable encryption. Then the label becomes a security and governance tool, not a formality.

How to choose a label model: levels, names, logic

A good model follows a simple rule: an employee chooses a label in a few seconds and almost never hesitates. If there are too many labels or similar names, people start choosing “anything,” and it becomes formal.

For a start 3–5 levels are enough. Fewer makes risk differentiation hard, more makes remembering and applying them difficult. The clearest option is a ladder from open to sensitive.

Example for short introductory training:

• Public (can be published outside the company)
• Internal (for employees and contracted vendors)
• Confidential (limited audience; risk of harm)
• Strictly Confidential (critical: finance, personal data, key projects)

Choose human-friendly names, not bureaucratic terms. Prefer “Internal” to “For official use only”, unless that wording is required by your regulations. In each label description leave one short answer to two questions: “Who can this be sent to?” and “What is forbidden?” That resolves most doubts.

Decide rules for raising and lowering labels in advance. Practically, it’s safer if any author can raise a label (if unsure — raise), but lowering is allowed only for the document owner or a designated role (e.g., data owner in the unit) after review. Lowering should leave an audit: who, when, why.

Handle templates separately: standard contracts, invoices, commercial offers, customer letters. If many files are created from templates, set a default label there and show a prompt when it should be changed.

Regulatory requirements and internal policies are better embedded in 1–2 strictest levels, not by creating a label for each law or department. For example, documents with personal and financial data can be defined as not lower than “Confidential,” with exceptions documented as rare cases.

In regulated sectors (public bodies, finance, healthcare) it’s useful to agree the model with InfoSec and legal before the pilot. System integrators like GSE.kz often help run this alignment quickly without extra levels or complex wording.

Roles and responsibilities: who is responsible for what

Labels work only when it’s clear who makes decisions and who operates the system daily. Otherwise the project quickly becomes a department dispute and long email threads.

Basic roles and their responsibilities

Usually 5–6 roles suffice with clear boundaries.

A business data owner decides how sensitive information is and who needs it for work. InfoSec sets protection requirements (encryption, external-sending restrictions, shared-access controls) and ensures rules are feasible. IT configures tools (for example, Microsoft Purview or an alternative), templates, policies and integrations, and is responsible for stability.

Legal helps where contractual restrictions, personal data and retention periods matter. HR is responsible for training and ensuring new hires understand the rules from day one. Business custodians (head of direction or project) ensure departments don’t create their own labels.

To keep it simple, assign a straightforward scheme:

• Approves the label model: InfoSec and legal, with final say by the risk/InfoSec lead or an authorized committee.
• Defines label meaning: business data owners.
• Implements and maintains technically: IT.
• Trains and reminds: HR and InfoSec.
• Initiates changes: any data owner via a clear request.

Who resolves disputed cases

Handle disputes in a second-line process, not in every chat. Typical examples: tender documentation, medical records, financial reports, client and employee data.

Working practice: first line (employee or manager) chooses the label using a short rule. If unsure — escalate to the data owner. If the data owner is uncertain — InfoSec and legal decide (sometimes with the CFO for financial documents).

Scenario: a team prepares a package for a public procurement. Some files can be shown to a partner, some contain prices and terms. The data owner pre-defines what is “Internal” vs “Confidential.” InfoSec ties external-sending restrictions and encryption requirements to these levels.

Employee support: where to write and how long to wait

Without support, people label at random or avoid labels. Create one channel for questions (for example, the service desk) and set response times: quick answers to simple questions within one business day; complex cases requiring InfoSec and legal review within 2–3 business days. IT provides short instructions; InfoSec and data owners populate a library of examples: “supplier contract”, “medical exam results”, “payroll”, “project documentation.”

If you have branches or distributed support, appoint local “champions” in units. This reduces central load and makes rules closer to daily work.

UX for employees: make labels not get in the way

In labeling projects UX often matters more than ideal theory. An employee should not guess which button to press every time or fear making a mistake. The best approach: minimal choices, maximum clarity.

First rule: reduce the set of labels visible to a person. Even if you have 10 levels, most roles need 3–4 options. Keep the rest in rules and exceptions, not the interface.

Hints: when to pick a label and why

A label should appear at a moment when the person is already deciding: creating from a template, saving, sending, or placing a document in a shared space.

The hint should answer two simple questions: “what does this change” and “why am I seeing this.” A good hint is short: “This document contains national ID and employee data. Recommended: Confidential (personal data).” A bad hint is a long policy excerpt.

Defaults and quiet auto-suggestions

Reasonable defaults solve most problems. For HR the default might be “Internal” or “Confidential”; for marketing — “Public” or “Internal.” The same applies by document type: contract, invoice, medical record, memo.

To avoid annoyance, make auto-labeling an assistant:

• Offer auto-suggestions instead of forced labels where mistakes are possible.
• Use a higher confidence threshold for sensitive levels.
• Provide a “Why?” button with a short explanation (1–2 reasons).
• Allow changing the label in a couple of clicks without a request.
• Exclude templates and system documents from constant pop-ups.

Example: an accountant saves a contract with counterparty and bank details. The system suggests “Confidential (finance)” and shows the reason: found national ID/company code and account number. If it’s a draft without real data, the employee picks “Internal” and you get a signal to adjust the rule.

If an employee thinks labeling is “just for reports,” they’ll pick the first option. If a label helps avoid mistakes when sending, restrict access and prevent leaks, it becomes a habit.

Step-by-step 60-day implementation plan

Sixty days is about a working minimum that sticks. Better to roll out a simple label model on a limited set of documents than argue for months about the “right” levels.

Weeks 1–2: preparation and draft rules

In week one inventory what types of data you have (contracts, invoices, personal data, technical docs, correspondence), where they live (mail, network folders, SharePoint/file services), and who owns them. Conduct 6–10 short 20-minute interviews with data owners. Ask: which documents most often leak or get lost, and where do employees most often worry about making mistakes.

In week two draft a label model and rules for only 2–3 critical scenarios. For example: sending to external recipients, sharing publicly, internal forwarding. Names should be understandable without a 30-page policy.

Weeks 3–8: pilot, training, scaling

Weeks 3–4 run a pilot in one function with many sensitive documents (often finance or HR). Choose 20–30 “reference” documents and agree which labels should apply. In the pilot test behavior: where people get confused and where rules block task completion.

Week 5 — short training. Instead of one long webinar, run 3–4 sessions of 25 minutes and one-page cheat sheets with real cases: “how to send an invoice to a contractor”, “how to share a resume with a manager”, “how to export a report for an auditor.” Add one channel for questions and quick answers.

Weeks 6–7 — expand to 2–3 departments and configure exceptions. Exceptions should be rare and documented; otherwise they become the norm. Typical example: procurement exchanges files with suppliers frequently and needs clear external-sharing rules.

Week 8 — document what works and prepare the next wave.

By day 60 you should have: a simple label model, 2–3 proven rules, one-page instructions, a list of exceptions and owners. Also agreements on who approves changes, who trains, and who handles feedback. Plus a continuation plan: which data types and departments go next and what to improve after the pilot.

Microsoft Purview and alternatives: how to compare without too much theory

Microsoft Purview is often chosen if you already use Microsoft 365 and need unified policies for documents, mail and collaboration. Then labels, DLP rules and reports live in one place and users don’t have to learn a second interface.

When comparing Purview to alternatives, focus on practice: where labels will be applied and who will maintain them. The solution should cover main channels and provide clear progress reports.

Key comparison points:

• Channel coverage: mail, file stores, shared folders, cloud and hybrid scenarios.
• Integrations: office apps, mobile, document management systems, IAM/AD, SIEM.
• Employee convenience: how easy it is to set a label, how hints look, what happens on errors.
• Reporting and audit: can you see who uses labels, how many violations, which departments lagging.
• Administration: who changes rules, how exceptions work, how much time support requires.

Define criteria as “what we need in 60 days,” not as a long feature wishlist. Often the winner is not the most powerful tool but the one you can launch quickly and maintain with your team while meeting local requirements (data residency, access, logging). Count total cost of ownership separately: licenses, implementation, training, support and admin time.

To avoid vendor lock-in, first describe rules on paper: label levels, who assigns them, consequences (encryption, block forwarding, watermarks), and where auto-classification is required. Then the tool should implement your rules, not invent them.

Before purchase and scaling, test the solution in a pilot across 5 scenarios:

• A user creates a document labeled “Internal” and sends it to an external recipient.
• A financial file with personal data lands in a shared resource and should be automatically labeled.
• A user attempts to lower a label; the system explains and records the action.
• A manager requests an exception for a project; check how it is issued and controlled.
• InfoSec receives a weekly report that clearly shows what to fix and who to train.

If you operate in Kazakhstan with many compliance and corporate integration requirements, it makes sense to involve a systems integrator who compares options using your data and processes rather than marketing materials. For example, GSE.kz can help align the label model with real processes and then configure policies and reporting so results are measurable in 60 days.

Measurable outcomes to check after 60 days

After 60 days of the pilot you need reproducible numbers, not impressions. Most of this is available in reports from Microsoft Purview and similar tools if you agreed on rules and enabled logging.

Start small: measure only the pilot teams and selected repositories (for example mail and OneDrive/SharePoint or network folders). This lets you compare the same scope over time.

Five numbers for leadership (and for a 90-day check)

1. Coverage: share of documents/emails in the pilot with any label. Formula: labeled / all created (or modified) in the period. A realistic 60-day target for active teams: 60–80%.

2. Label quality: share of corrections (lowerings/raisings) among all labeled items. Record who corrected: employee, manager, admin. If corrections exceed 10–15%, names or hints are probably unclear.

3. Behavior without reminders: share of users who label at creation/sending without manual prompts. Practical proxy: how many users applied labels at least 5 times per week.

4. Risk and prevention: how often policies triggered (block, warning, justification request) and how many real incidents occurred (sent to wrong recipient, exposed to “everyone”, attempted data exfiltration). Distinguish policy triggers from actual harm.

5. Process stability: average response time to label-related queries and number of support requests per 100 users. This shows whether labeling became habitual rather than annoying.

To keep figures honest, log typical error reasons. Common issues: confusing “Internal” vs “Confidential” because of similar wording; default label not fitting and being corrected; unclear link between label and external sending; some materials living outside controlled repositories, so “coverage” looks worse than reality.

How to present a one-page report

Collect the five metrics above, add a 30-day vs 60-day comparison and one action per metric: what to change in UX, what to change in rules, what to keep. Repeat at 90 days to see trends, not a one-off spike.

Typical mistakes and pitfalls when launching

The most common problem is starting with a beautiful scheme and ending with no one understanding which label to use and why.

Mistake 1: too many levels and unclear names

With 8–12 levels and names like “Level 3B” or “Internal Extended” people will guess. Some documents get the strictest label “just in case”, others remain unlabeled.

Start with 3–4 clear levels: “Public”, “Internal”, “Confidential”, “Strictly Confidential”. The name should hint at actions: can it be forwarded, can it be shared, who can see it.

Mistake 2: trying to cover all data at once

A “we’ll label everything” project drowns in detail. Better to pick 2–3 priority flows where risk and value are obvious: contracts and invoices, HR documents, commercial offers. In public sector and healthcare, treat personal data separately.

Use a simple filter: what leaks most often, what matters for compliance and audits, what is created daily and can be labeled, and where you can quickly show benefit (fewer errors, fewer manual approvals).

Mistake 3: no data owners and no dispute resolution

If no data owner is assigned, disputed cases stall. Employees learn “nobody will decide” and label arbitrarily.

Minimum required: a data owner, an InfoSec representative and a business person who understands the process. Agree on how many days they have to answer “which label is correct?”.

Mistake 4: punitive tone and pressure

If communication sounds like “mistake — punishment”, people bypass rules: send files via personal messengers, rename, take screenshots, or store copies outside systems. Speak about support and give simple in-context hints.

Mistake 5: no update process — labels get outdated

Processes, templates and systems change; the model must follow. Start a review rhythm: a short meeting every 4–8 weeks to decide changes. It’s cheaper than redoing the whole project later.

Quick checklist and next steps

Before launch ensure the model works in real mail and files, not just on paper.

Readiness checklist

Check model simplicity. Levels must be clearly distinct. If employees hesitate between two labels in half the cases, simplify names or rules.

Check roles. Each data category must have an owner responsible for labeling rules and exceptions. Provide a clear support channel for urgent external sends.

Check daily UX. Provide defaults for typical files, short 1–2 phrase hints and clear consequences: can it be sent externally, does it require encryption.

Check the pilot’s realism. Choose 5–7 real scenarios: supplier contract, invoice, HR certificate, client presentation, CRM export, report for regulator.

Check 60-day metrics. They must be verifiable: share of labeled items, share of corrected labels, number of support requests, labeling time, number of mis-sends, training coverage.

Next steps

1. Agree the final pilot labels and rules (3–5 labels, no “petting zoo”).

2. Approve data owners and exception process: who can change labels and when.

3. Launch the pilot in one or two groups with external file exchange and clear value (for example, finance and procurement).

4. After 2 weeks collect feedback and fix what obstructs: label names, hints, auto-apply settings, training.

If you need help configuring Microsoft Purview or choosing alternatives, training or pilot support, it’s often convenient to work with a systems integrator. For example, GSE.kz can help align the label model with real processes, configure policies and reporting, and make the result measurable within 60 days.