Data Classification Policy: Levels, Labels and a Template

TL;DR: A data classification policy sorts data into three or four levels, names who assigns each level and ties every level to specific controls. Published policies from Maryland, New Hampshire and Lycoming College follow the same order, from Public to Restricted. The label matters less than what it triggers: encryption, access limits, handling rules. Set a default for unlabeled data, write an exceptions path with expiry dates, and review the policy at least annually.

What a data classification policy is and what it has to do

A data classification policy sorts an organization's data into a small number of levels. It names who decides each item's level and ties each level to a set of controls. If it works, a person holding a file can tell from its label what they may do with it.

AvePoint's overview states that classification is based on three criteria: how sensitive data is, how valuable it is to the business and which regulations apply to it. The State of New Hampshire's policy gives its purpose in one line: to differentiate the treatment of data based on its classification. That is the job in short. Data that differs gets handled differently.

The levels

Published policies tend to use three or four levels. The names differ, but the order from open to tightly held is similar.

AvePoint makes the point that labels are not the substance: "What matters is that each level maps to a defined set of controls, not the name itself." In our reading, a reader comparing policies should check the controls column before the label column.

Who decides

A policy has to say who assigns the level. Maryland puts creators and owners on the hook for classifying their data, and data users on the hook for following the handling rules. Lycoming makes the data owner and data stewards ultimately responsible for the data under their management.

A default level matters as much as the owner. Lycoming treats any institutional data not explicitly classified as Restricted or Public as Private. Unlabeled data therefore gets middle-tier protection rather than none.

What each level gets

The controls are where a policy becomes checkable. Maryland requires Confidential data to be encrypted at rest and in transit and accessible to authorized users only. Lycoming says Restricted data must never be transmitted via email or text.

Maryland also sets a floor: data may carry security levels above its classification, but not below. It warns against padding in the other direction, saying higher protection than needed may lessen transparency and needed access. AvePoint describes the same trade-off. Without classification, organizations either protect everything at the same level or protect too little.

We think over-classification is the quieter failure. When everything is marked Confidential, the label stops telling anyone anything.

Three things to check in your own policy:

• Each level names its controls, not only a definition.
• An owner role is named for assigning levels, with a default for unlabeled data.
• There is a rule against handling data below its level.

How many classification levels should you use

No rule fixes the number of levels. In one auditor's summary, most compliance standards and requirements are not prescriptive about which classification levels an organization should use. The count is a design choice. Most commercial organizations use four levels, and some use a simpler three-tier model of high, medium and low sensitivity.

Lycoming's shorter scheme, described in the previous section, keeps a single tier at the top.

Where the fourth tier sits

In most four-tier schemes the extra level splits the sensitive end. Maryland keeps Restricted for data where federal and/or state laws or regulations mandate specific controls throughout its lifecycle. One commercial model gives Confidential role-based access, encryption, DLP and sharing restrictions, where DLP means data loss prevention. Restricted adds least privilege, encryption at rest and in transit, multifactor authentication and audit logging.

The split can also sit low. Lewis-Clark State defines Internal as data whose disclosure would cause minimal risk but could hamper operations or create confusion. The same college also treats its top two tiers as one group for some purposes. Copilot will be restricted from accessing Level 3 and Level 4 data.

Names matter less than what each tier triggers. Some organizations use General and Highly Confidential in place of Internal and Restricted.

Our view: three or four

We think three tiers are enough when:

• Your regulated data falls under one or two regimes with similar handling rules.
• No tool or process treats your top two tiers differently.
• Staff label by hand, and every extra choice is another chance to pick wrong.

In our reading, four tiers earn their keep when:

• A specific law imposes controls on some data that would be excessive for the rest of your sensitive material. Tax and criminal justice data at Maryland are the pattern.
• Your tools enforce different rules per tier, such as stronger authentication or audit logging on the top tier only.
• You need a non-public tier for routine internal material, so that Confidential stays meaningful.

What belongs in each level, with examples

The level follows the damage an unauthorized disclosure would do, not the subject of the file. Lewis-Clark State College sorts data by its sensitivity and the potential impact of unauthorized disclosure. Maryland's policy offers the same fallback: where a dataset has no clear classification, the impact described in its Table 1 can guide the level of protection.

The Lewis-Clark State examples map cleanly onto a four-level scheme.

Maryland adds a useful internal case. Draft statistical or factual material used for internal analysis should be classified as Protected/Internal Use Only, not published as open data. Its Confidential list is broad: it includes personal information, precise geolocation data, protected health information (PHI), credit card and financial information, and student records.

The same data can land at different levels

Lycoming College uses three tiers and states the impact test plainly. Data is Private when disclosure would cause a moderate level of risk, and Restricted when it would cause a significant level of risk. Lycoming lists FERPA-protected educational records as Private. Lewis-Clark State puts FERPA records in its top tier.

In our reading, that gap is the point. Each institution judged the harm for itself, so a template's example list is a starting draft, not a ruling.

Lycoming also places passwords, password hashes, encryption keys and authentication tokens in Restricted. We think this is an entry many policies miss, because credentials are not personal data in the usual sense, yet their exposure opens everything else.

Combination and de-identification move the level

Maryland notes that single data elements may not be personal information, but the combination of disparate data elements can make them so and raise the level. The reverse also holds: data that is anonymized so a person cannot reasonably be re-identified may drop to a lower level.

Three checks to run when filling in your own example lists:

• Ask what a disclosure would cost: operational confusion, harm to a person, a regulatory fine.
• Look at merged exports and reports, where harmless fields join into identifiable records.
• Put credentials and keys on the list by name.

Who owns the classification decision

Most published policies split the classification decision across several roles. One person assigns the level, another approves exceptions, and a third applies the controls. The useful question for a security leader is which of those jobs sits with the business and which sits with security.

The roles published policies name

Lycoming College goes further and gives each role a written duty list. Maryland assigns system protection to security staff: information security personnel use the classification levels to set the system security level.

In our reading, this split keeps security out of the business call on value. The steward decides how sensitive the data is. The custodian and security staff decide how to protect it.

Who signs the policy itself

Maryland's revision history lists three approvers, drawn from the security, data and privacy functions. We think a joint sign-off like this is worth copying. It stops the policy from being read as a security document alone. For reporting lines around that sign-off, see /guides/ciso-reporting-structure.

Exceptions and risk-based adjustments

Its examples are only guidelines with the exception of those classes of data expressly protected by statute, contract, or industry regulation. In our reading, in practice, a steward can move a set of internal memos between levels, but cannot reclassify payment card data on business grounds. Maryland also names a cost of erring high: over-protection may impact data protection resource requirements and lessen transparency and needed access.

Keep a written exception record for every adjustment. Each record should hold these fields:

• Requester: the steward or owner asking for the change.
• Data type: the data set or system, named specifically.
• Level: the current classification and the requested one.
• Compensating control: what offsets the change, such as encryption or a narrower access group.
• Approver: the data owner, after consulting security, privacy and legal counsel where the data is regulated.
• Risk assessment reference: the ID of the assessment that supports the change.
• Expiry date: when the exception lapses or comes back for review.

In our reading, an exception with no expiry date tends to become permanent policy. For more on who answers for these calls, see /guides/ciso-accountability.

Labeling and handling rules for each level

A level only works if it changes what people do with a file. The table below sets one vendor's control model beside the handling rules a college wrote into policy, so a reader can see how a level turns into a daily instruction.

The same model keeps the top level out of artificial intelligence (AI) grounding by default. That gives the label a second job: it now controls what an assistant can read.

Paper counts too

Write the rules so they cover every format. Lycoming's policy applies to data in any and all formats, including paper. Its Restricted rules reach physical storage: a locked drawer, a locked room or a controlled-access area. A printed payroll file and a payroll spreadsheet get the same level and the same care.

Retention and disposal follow a different axis

Sensitivity sets access and storage. Retention, archiving and disposal are driven by business value and regulatory categories. In our reading, the policy should point each level to the retention schedule, not try to set retention periods by sensitivity alone.

Labeling rules for users

Lewis-Clark State gives staff four plain rules that transfer well:

• Label a mixed document at the highest level present.
• Check the default. Its Office tools apply an auto-applied Level 2 label that users must change for public or sensitive content.
• Label documents as you create them, not at the point of sharing.
• Remember the cost of labeling too low: mislabeled sensitive files will not be encrypted.

When a user is unsure

Give people a default and a route. The college tells staff to temporarily use the higher classification while they wait for an answer. It also asks staff to keep a record of repeated questions for training and policy updates. We think that last step is the cheapest way to find where the level definitions are unclear.

How classification feeds DLP, DSPM and AI controls

Labels do their real work after they leave the policy document. Every automated control downstream reads them, and the controls behave only as well as the labels are consistent.

Why DLP and DSPM depend on consistent labels

Data loss prevention (DLP) blocks or flags data on the move. Data security posture management (DSPM) looks for sensitive data sitting where it should not be, or open to the wrong people. Both need a label or a content match to act on. As one vendor explainer put it, DLP, encryption and access policies all need to know what a file or record contains before they can treat it correctly.

The hard part is unstructured data. The same explainer calls it created constantly, copied freely and rarely labeled at the source. People do not fix this on their own, because manual labeling is inconsistent, often skipped and frequently overused. Over-labeling causes its own trouble. In our reading, a DLP rule that fires on everything marked Confidential gets tuned down or ignored once half the file share carries that label.

How the NIST draft framed discovery and labeling

The National Institute of Standards and Technology (NIST) published the initial public draft of SP 1800-39, Data Classification Practices, in a notice created February 10, 2026. The project set out to show how to discover, identify, and label unstructured data using commercially available technology. The project team created a synthetic dataset to test the tools. The comment period is now closed.

The project's framing helps when you make the case to a board. It argues that standardized mechanisms for communicating data characteristics and protection requirements are needed for data-centric security to work at scale. It also ties classification to AI model training that requires labeled data. It says plainly that it will not replace current risk management practices, laws, regulations, or mandates.

Why AI assistants inherit what you already have

An AI assistant does not reclassify your estate before it answers a question. It reads what the user can read. The vendor explainer states it directly: AI assistants and agents inherit existing labels and permissions, so unclassified data becomes AI exposure. In our reading, this is why the four-level model described earlier keeps the top tier out of AI grounding by default.

Context rules can help. In one example, a file saved to a finance site may inherit a Confidential label. Automation still needs people. The same source notes that human review of low-confidence results keeps automated outcomes accurate and defensible.

How the policy maps to NIST controls and compliance frameworks

New Hampshire's statewide policy shows one way to tie a classification policy to a control framework. Its Department of Information Technology mapped the policy to a single National Institute of Standards and Technology (NIST) control, listed as NIST SP 800-53 Rev. 5 Controls: RA-02.

The mapping is stated in the document. It is not left implied. In our reading, the same tag sits in the procedure's metadata, so an auditor or a governance tool can find the control without reading the full text.

What the RA-02 link asks of the classifier

The policy does not treat a label as a matter of taste. Agencies classify information according to applicable statutory, regulatory and contractual requirements and according to the information's sensitivity. That sits alongside an assessment of risk from a loss of confidentiality, integrity, availability or privacy.

The top level, Restricted, is defined partly by legal consequence: it covers information where penalties, notification provisions, or other mandates could follow an unauthorized disclosure. In our reading, that wording makes the compliance tie explicit at the level definition. A reader can trace a regulated data type straight to a level.

Regulated data types named in the policy

Where legal questions go

The policy names an owner for legal interpretation. Questions about which laws apply should be directed to the Agency's Legal Counsel. We think this is the right split for a security team: the policy records the mapping, and counsel decides what a statute requires.

Framework flexibility and review

Frameworks rarely dictate your level names. An audit firm's guide notes that most compliance standards are not prescriptive in specifying the information classification levels an organization should use. You can keep your own scheme as long as the mapping holds.

The mapping also ages. Requirements can impose more stringent data security requirements, or a new service can bring a new category of data. The same guide says an annual review can help find gaps.

A short check for your own control mappings:

• Each regulated data type points to one classification level.
• Level definitions reference legal or contractual consequence where it applies.
• A named role, usually counsel, owns questions of legal scope.
• A review date is recorded and has not passed.

For how disclosure rules reach the security function, see our guide to the SEC rules.

A template outline and the first steps to put it in place

Most published policies follow the same skeleton. Hyperproof's outline runs from purpose and scope through roles and categories, and its scope section explains whether this policy applies to all information systems within an organization or whether there are certain exceptions. The table below is our template. The middle column is our reading of what each section needs to settle.

Two of these sections are often written loosely. On scope, Maryland's policy covers all data, whether in electronic or non-electronic formats, which closes the paper-records gap in one clause. On authority, the same policy says that in a conflict with applicable law, the provisions of applicable law shall control.

Maryland also sets a floor in plain words: data may be protected above its level but should not have security levels below its classification. We think that sentence belongs in every handling section.

First steps

1. Set a default level. Lycoming College treats anything not explicitly classified as Restricted or Public as Private. A default means unlabeled data starts protected.
2. Write the exceptions path before the first request. Lycoming allows adjustment based on risk assessment or documented business need. Name the approver and give every exception an end date.
3. Start small on levels. Hyperproof's advice is to keep the policy simple with as few classifications as possible. Add a level only when a handling rule truly differs.
4. Put version control on page one. New Hampshire's header carries a document number, version 3 and an effective date of 8/7/24. Maryland's revision block shows it was issued 10/01/2024 and last revised 08/03/2026. A reader can tell at a glance whether the copy is current.
5. Fix the review cycle in the document. New Hampshire states a review period of annual, and Hyperproof recommends review at least annually. Assign the review to a named role, not a committee.

In our reading, a new security leader can draft this skeleton in the first month and publish the first version before the levels are perfect. The revision history then records each change. For sequencing it alongside other early work, see the first 90 days plan.

What this guide does not cover

This guide does not set retention periods for each level or explain what any particular statute requires. For the rules and the record behind it, see CISO Reporting Structure, the Five Models and What the Filings Show.