Your Organization's Data

Your organization has data scattered across shared drives, cloud buckets, email inboxes, Slack channels, personal devices, and that one spreadsheet someone emailed to themselves two years ago. Some of it is public marketing material. Some of it contains every customer’s Social Security number. Right now, both piles are sitting behind the same controls — which means you’re either spending too much protecting press releases or too little protecting the crown jewels. Probably both.

Classification fixes this. Not by adding bureaucracy, but by forcing the question: what actually matters, and what happens if it walks out the door?

DO / DON’T

DO:

• Create a classification scheme with no more than four levels
• Assign a named data owner to every data category — a person, not a team
• Define specific handling rules for each classification level
• Automate labeling for structured data (SSNs, credit card numbers, medical identifiers)
• Train everyone who touches data, not just IT
• Review classifications annually or when business changes occur
• Deploy DLP tools to enforce classification-based rules

DON’T:

• Create more than four classification levels — complexity kills compliance
• Let data exist without a label — unlabeled data defaults to unprotected
• Assume people will classify correctly without training and tools
• Mark everything “Confidential” — if everything is the highest level, nothing is
• Build a classification policy without an enforcement mechanism
• Forget about shadow IT — data on personal devices and unapproved cloud services is still your data

Building Your Classification Scheme

Step 1: Define Your Levels

Keep it simple. Four levels work for most organizations. Three is fine for smaller ones. Every level you add reduces the chance people will actually use them correctly.

A standard four-tier scheme:

• Public — Information intended for external audiences. Press releases, marketing content, published financials. No restrictions on sharing.
• Internal — Not for public consumption, but no real damage if disclosed. Company policies, org charts, internal memos, meeting notes.
• Confidential — Disclosure would cause measurable harm. Customer data, employee records, contracts, financial details, source code, strategic plans.
• Restricted — The highest sensitivity. Raw PII datasets, encryption keys, authentication credentials, M&A plans, trade secrets. Breach of this data triggers legal obligations, regulatory penalties, and board-level conversations.

Write a one-sentence description of each level that anyone in your organization can understand. If the description requires a legal dictionary, rewrite it.

Step 2: Assign Data Owners

Every data category needs a named owner. Not “the engineering team” — a specific person who is accountable for classification decisions about that data.

• Customer data — Head of Customer Success or Chief Privacy Officer
• Financial data — CFO or Controller
• Source code — VP of Engineering or CTO
• Employee records — Head of HR
• Marketing materials — Head of Marketing

Data owners don’t implement controls. They decide the classification and are answerable when their data ends up somewhere it shouldn’t be. The IT team (data custodians) implements the technical controls. Make this distinction clear in your policy, or nobody will know who’s responsible for what — which means nobody is responsible for anything.

Step 3: Create Labeling Standards

Labels should be visible and consistent. Every document, file, database, and system should carry its classification.

For documents: Header and footer on every page. “CONFIDENTIAL” or “RESTRICTED” in red. Use document templates that include the label by default — don’t rely on people remembering to add it.

For emails: Subject line prefix or classification banner. Microsoft 365 and Google Workspace both support sensitivity labels that can be applied automatically or by the sender. CISA recommends marking sensitive communications clearly to prevent accidental disclosure.

For files and folders: Naming conventions that include classification. Metadata tags. Folder structures that separate classification levels. A “Restricted” file should not live in the same share as “Public” files.

For databases and systems: System-level classification. If a database contains any Restricted data, the entire system inherits the Restricted classification and its handling requirements.

Step 4: Define Handling Requirements

Each classification level needs a clear set of rules covering storage, transmission, access, and disposal.

Public:

• Storage: No special requirements
• Transmission: Any method
• Access: Unrestricted
• Disposal: Standard deletion

Internal:

• Storage: Company-managed systems only
• Transmission: Company email or approved file sharing
• Access: All employees
• Disposal: Standard deletion

Confidential:

• Storage: Encrypted at rest, company-managed systems with access logging
• Transmission: Encrypted channels only (TLS email, approved secure file sharing)
• Access: Role-based, need-to-know within relevant teams
• Disposal: Secure deletion per NIST SP 800-88

Restricted:

• Storage: Encrypted at rest, dedicated systems with enhanced monitoring, access logging with alerting
• Transmission: Encrypted end-to-end, approved channels only, no email attachments
• Access: Named individuals only, multi-factor authentication required, access reviewed quarterly
• Disposal: Cryptographic erasure or physical destruction with certificate of destruction

Step 5: Implement DLP Controls

Classification without enforcement is a suggestion. Deploy Data Loss Prevention tools that enforce your handling requirements automatically.

Start with the highest-risk scenarios:

• Block emails containing Restricted data patterns (SSNs, credit card numbers) to external addresses
• Alert on bulk downloads from Confidential or Restricted systems
• Prevent uploads of classified data to unapproved cloud services
• Monitor USB transfers from systems containing sensitive data

Microsoft Purview, Google DLP, Symantec DLP, and open-source options like OpenDLP can scan for sensitive data patterns and enforce policies. The tool matters less than having one. Any DLP is better than no DLP.

Step 6: Train Your People

The most elegant classification scheme fails if the people creating and handling data don’t understand it. Training should cover:

• What the classification levels mean — with examples specific to your organization
• How to classify new data — decision tree or flowchart, not a 40-page policy document
• How to handle each level — what they can and can’t do with Confidential vs Internal data
• What to do when they’re unsure — default to the higher classification and ask the data owner
• What happens when classification is violated — make consequences real but proportionate

Run this training annually. Make it part of onboarding. Keep it under 30 minutes. If it takes longer, your scheme is too complicated.

If It Already Happened

If you’ve discovered unclassified sensitive data in an unprotected location:

• Immediately restrict access to the data. Don’t move it yet — moving creates copies.
• Notify the data owner (or the most relevant executive if no owner is assigned).
• Assess whether unauthorized access has occurred. Check access logs if available.
• Classify the data and apply the appropriate controls.
• If personal data was exposed, consult legal about breach notification obligations. GDPR requires notification within 72 hours. Various U.S. state laws have their own timelines.
• Document everything. The incident response matters, but so does the paper trail.

Making It Stick

Classification programs fail for three reasons: too many levels, no enforcement, and no executive support. Keep the levels simple. Deploy DLP. Get a C-suite sponsor who will hold data owners accountable. Review and update annually.

The goal isn’t perfection. It’s knowing the difference between your press releases and your crown jewels — and treating them accordingly. Start with your most sensitive data. Get that classified and protected. Then work outward. One category at a time, one data owner at a time.

Here’s your first step: identify the three most sensitive data types in your organization. Assign an owner to each. Define their classification and handling requirements. Do it this week. Everything else builds from there.