Data classification policy template
A data classification policy is a short document that tells everyone in your company how to treat the data they touch. This guide gives you a template you can copy, adapt and publish in an afternoon: four classification levels with definitions, examples and handling rules; the roles that make the policy real; a review cadence that keeps it current; and an implementation checklist to start from.
What a data classification policy is for
Labels only matter if they change behavior. A classification policy connects each label to concrete handling rules — who may see the data, where it may be stored, how it may be shared, and when it must be deleted. Without one, every sharing decision is improvised: the accountant emails the spreadsheet, the consultant gets the link, and nobody records what left.
A policy also answers the questions that arrive from outside: customers asking how their data is protected, insurers asking about controls, regulators asking what personal data you hold and how long you keep it. And when something goes wrong, the policy is the map. It tells responders which classes of data were in the exposed system, and therefore what the incident response has to cover.
Keep it short. A one-page policy people actually follow beats a twenty-page policy nobody reads. The template below is deliberately minimal — adapt it, do not expand it unless a real requirement forces you to.
The template
Copy the sections below and replace the bracketed parts. It assumes the four-level scheme that fits most small and mid-sized businesses.
[Company name] Data Classification Policy
Purpose. This policy defines how [Company name] classifies information and the handling rules that apply to each level.
Scope. All [Company name] data, wherever it is stored: file shares, cloud drives, mailboxes, devices, backups and SaaS tools.
Classification levels
| Level | Definition | Examples | Handling rules |
|---|---|---|---|
| Public | Approved for anyone to see | Published marketing material, job postings, press releases | No access restrictions. Publish only after review by [owner]. |
| Internal | Day-to-day business data not meant for people outside the company | Internal announcements, org charts, project plans, most internal email | Company accounts only. Do not forward outside the company without the data owner's approval. Store on company-managed services. |
| Confidential | Would cause material harm to [Company], a customer or an employee if disclosed | Contracts, employee records, financial statements, customer lists, source code | Need-to-know access approved by the data owner. Share only through company accounts, with access expiry. No personal accounts or unmanaged devices. Report suspected exposure to [contact] within [24] hours. |
| Restricted | Regulated or highest-harm data; disclosure is a reportable incident | Social Security numbers, payment card numbers, bank account and routing numbers, health identifiers (MRN, NPI, diagnosis codes), passport and driver's license numbers, credentials and private keys, tax returns | Access limited to named individuals, and logged. Collect only when required, with a retention date set at collection. Never send by email except through an approved encrypted channel. Store only in designated systems. Delete as soon as the purpose is met. |
If you are unsure where a category belongs, ask one question: if this file appeared on the public internet tomorrow, what would it cost — in dollars, in legal exposure, in customer trust? Anything whose answer is "a reportable incident" belongs in Restricted. Restricted is defined by the kind of data, not the folder it sits in: one spreadsheet of card numbers makes that spreadsheet Restricted even if it lives in an otherwise Internal directory.
Roles within the policy
- Executive sponsor — owns the policy and approves exceptions.
- Data owners — one per department or data category (finance, HR, operations). They approve access to their data and review who has it.
- IT, or your managed service provider — implements the technical handling: access controls, approved storage locations, retention.
- Every employee — applies the handling rules, labels the data they create, and reports suspected exposure.
In a small company these are three people, or one person wearing three hats. That is fine. What matters is that each responsibility has a name attached, so nothing is everyone's job.
Exceptions
Any exception requires the executive sponsor's written approval and an expiry date. Record exceptions with the data they cover.
Review cadence
- The policy itself: reviewed [annually], and immediately after a security incident, a new regulation that applies to [Company], or a major new system.
- Access to Restricted data: reviewed [quarterly] by the data owners.
- Retention: an [annual] sweep deletes Restricted and Confidential data past its retention date.
Implementation checklist
- Adopt the four levels — or three, by merging Confidential and Restricted if you hold no regulated data.
- Fill in the roles with actual names.
- List every place data lives: file shares, NAS, cloud drives, mailboxes, SaaS tools, backups.
- Note the highest level each store is likely to hold.
- Complete the handling rules and retention periods.
- Publish the one-pager and walk the team through it — thirty minutes is enough.
- Inventory Restricted data first; that is where harm concentrates.
- Review Restricted access quarterly, and re-check the inventory after incidents and new systems.
Common mistakes
- Too many levels. Five or six levels look rigorous and get ignored. Four is enough for almost every small business; three is fine if you hold no regulated data.
- No named owners. A policy that says "management" is responsible for access reviews guarantees the reviews never happen.
- Writing the policy before the inventory. You will classify what you remember, not what you have. Even a rough inventory first makes the levels concrete.
- Exceptions without expiry. A permanent exception is just a weaker policy. Every exception needs a date.
Finding the data that goes in each level
A policy written from memory describes the data you remember. The data that hurts you is the data you forgot: the payroll export from three years ago, the spreadsheet with card numbers, the private key in a backed-up folder on the NAS. Handling rules cannot apply to data nobody has found. That inventory step is what data classification software does.
Myrikeep is one. A small agent runs inside your network and connects to your sources read-only — SMB file shares and NAS, local folders and NFS mounts, Amazon S3 and S3-compatible storage, Azure Blob, IMAP mailboxes, Microsoft 365 and Google Workspace (both marked pilot), and personal Google Drive or OneDrive accounts. Detection runs inside the agent, and what comes back is labels, counts and file locations — never file contents or matched values.
The detectors map to the levels in your policy. The Restricted examples above — Social Security numbers, payment card numbers, bank routing and account numbers, health identifiers like MRN, NPI and ICD-10 diagnosis codes, passports and driver's licenses, dates of birth, plus leaked API keys and private keys — are exactly what Myrikeep looks for. It also flags files that are sensitive by type without opening them, such as KeePass password vaults, certificate keystores and QuickBooks or TurboTax files.
It reports exposure alongside labels: for sensitive files, whether they are public, anyone-with-the-link, shared externally or with a broad group — as categories and counts, never names. Files not modified in 24 months are flagged for review by default. It is deliberately not a blocking tool: Myrikeep does not revoke links, edit permissions, quarantine or delete files. It shows you where data sits and how broadly it is shared, so you can apply the policy's handling rules in the source system and rescan to confirm the fix.
One honesty note that matters when you evaluate any scanning tool: coverage is explicit. Common text formats, PDF text and modern Office formats get full parsers; other formats get strings-only checks; text in images and scanned PDFs needs the optional OCR feature. Each scan reports what was sampled, parsed and skipped on a Coverage page, and IMAP scans read attachments (subject lines are opt-in) but never message bodies. A completed scan is a record of what was examined, not a blanket guarantee.
To see it on real data, try Test Drive with a few of your own files, or follow the getting-started guide to install an agent and connect a source.