Data Classification: A Practical How-to Guide

Data classification is the practice of sorting an organization's data into a few levels according to the harm that would follow if the data leaked, were altered, or were lost, and attaching a label to the data so each level gets matching protection. In a draft report (NIST IR 8496), NIST defines it as the process an organization uses to characterize its data assets using persistent labels so they can be managed properly. This article is a pair with What Is DLP? Data Loss Prevention and Shadow AI Risk, because DLP can only protect data well when the organization already knows which data matters.

Why classify data

If every kind of data gets the same protection, an organization must choose between two poor options. One is strong protection everywhere, which is costly and slows work. The other is light protection everywhere, which leaves important data exposed. Classification tells you which data needs which controls. The NIST draft IR 8496 lists several benefits, for example:

• Apply the right controls: a data asset's classification tells you which security and privacy requirements apply to it
• Know which laws, regulations, and contracts apply to a given data asset: no need to work it out again each time someone asks or an audit arrives
• Share data safely with partners and contractors: the level helps decide which data may go out and how it must be handled
• Limit access to and transfer of intellectual property: for example source code and business plans

One caution: NIST IR 8496 is a draft whose development NIST ended on 10 December 2025, and it remains available as a historical reference. This article therefore borrows only its terms and ideas as background, not as a binding standard. The long-standing formal way to decide levels is FIPS 199 (a NIST standard) and NIST SP 800-60, covered in the next sections.

Four terms to know first

These four terms recur throughout the article. The definitions are adapted from the glossary at the end of the NIST IR 8496 draft:

• Data asset: an information-based resource, such as a file, a database, an email, or a paper document
• Classification level: a level the organization defines, such as "internal" or "confidential", based on the harm if the data leaks or is damaged
• Label: a metadata attribute (metadata is data that describes other data) that records which classification a data asset has
• Business owner: the person on the business side who understands where the data came from, what it is for, and how important it is. The NIST draft calls this role key to deciding classifications

Decide the level by impact

The well-known way to decide is the one in FIPS 199, a NIST standard published in February 2004. It applies to US federal agencies, and it says state and local governments and private-sector critical infrastructure operators in the United States may consider using it. Organizations in Thailand are not bound by it, but can use it as a reference. The idea is to ask how severe the effect on the organization and on individuals would be if the data were harmed, and to ask separately for three security objectives:

• Confidentiality: unauthorized people cannot see or obtain the information
• Integrity: the information is not modified or destroyed without authorization
• Availability: the information can be reached and used in a timely and reliable way

FIPS 199 defines three impact levels: low, moderate, and high. In short they mean:

• Low: a limited adverse effect, for example the main functions still work but noticeably less effectively, or minor damage to assets, money, or individuals
• Moderate: a serious adverse effect, for example a significant loss of effectiveness, significant damage to assets or money, or significant harm to individuals short of loss of life or life-threatening injury
• High: a severe or catastrophic adverse effect, for example the organization cannot perform one or more primary functions, major damage or loss, or loss of life or life-threatening injury to individuals

FIPS 199 writes the result for one type of information as a set of three values: the impact for confidentiality, for integrity, and for availability. One example in the standard is public information on a web server: no confidentiality requirement, but a moderate impact for loss of integrity and for loss of availability. Another is extremely sensitive investigative information: high for confidentiality and moderate for the other two. The lesson is that confidentiality is only one of three dimensions, and data that anyone may read can still need protection from being changed.

NIST SP 800-60 (Volume I, Revision 1, August 2008) builds on FIPS 199 and describes how to map information types to impact levels in four steps: identify the information types a system handles, select a provisional impact level for each type, review and adjust the levels for the organization's context, and set the level of the whole system from the highest value for each objective across all its information types. This highest-value rule is called the high water mark. The document is written for the US federal government. Revision 2 exists as an initial working draft that NIST released in January 2024, and when we checked NIST's page in October 2026 it showed no newer draft or final version, so check the latest status before citing it.

Six steps to classify your data

This sequence is our own summary, based on the five functions in the NIST IR 8496 draft (define policy, identify data, analyze, label, and monitor) and the steps in SP 800-60. The steps are:

• Name owners and a deciding team: have business owners, compliance, and technology owners decide together
• Define a few levels: write a clear meaning and example data for each level
• Find and list your data: include newly created data, data newly found in systems, and data received from outside
• Decide the level for each type of data: consider the impact on confidentiality, integrity, and availability, plus the laws or contracts that apply
• Label the data: attach the level to the data so it can travel with it
• Link to controls and review regularly: set how each level is encrypted and access-limited, then review when the data or the law changes

The NIST draft says that in most situations three groups need to work together. The business owner knows the origin and importance of the data and is key to deciding the classification. Compliance staff know which laws and regulations apply to each class and handle auditing and reporting. Technology owners know where the data lives and put the protections into practice.

The same draft gives two pieces of advice worth following from the start. First, define classifications separately from protection requirements, because protection methods change often as technology changes, while the classification of a given kind of data tends to stay the same. Second, classify as soon as possible after the data is created or found, because metadata collected at the start helps you decide more accurately, and the later it is collected, the less useful it generally is.

An example scheme with four levels

The following example is our own proposal, not taken from any standard. Adjust the names and the number of levels to fit your organization, but do not use many, because the NIST draft notes that a more detailed scheme makes classifying new or changed data more difficult and costly. The example is:

• Public: already free to publish, such as brochures and website notices, but still protected from being altered
• Internal: for use inside the organization, with limited harm if leaked, such as general work procedures and org charts
• Confidential: significant harm to the business or to people if leaked, such as customer contracts, source code, and personal data. Only those who need it see it, and it is encrypted when sent outside
• Restricted: severe harm if leaked, such as health data, encryption keys, administrator passwords, and unannounced business plans. Only named people have access, and every access is logged

Labeling so the level travels with the data

A label is the metadata that records the classification. The NIST draft gives examples of ways to bind labels to data, such as cryptographic binding or recording the pair in a data catalog (a register that collects details of an organization's data). It calls making labels stay with data as it moves, especially to another organization, one of the largest challenges. It adds that no labeling approach works for all data and all organizations, and that the labels themselves must be protected from easy alteration or deletion. Common label forms are:

• Visible marks: header or footer text, watermarks, or a prefix on an email subject, so staff see at once that care is needed
• Metadata tags on files or storage: systems can read them automatically, so they can drive controls, for example letting DLP block a "confidential" file from leaving
• Entries in a data catalog or data inventory: suited to databases and systems where the label cannot sit on the data itself

Automation and unstructured data

The NIST draft divides data into three kinds. Structured data, such as database fields where it is already known what each field holds. Semi-structured data, such as JSON or XML files that describe their own structure. And unstructured data, such as documents and videos, which is the hardest to classify. The approaches the draft discusses are:

• Use metadata: such as file name, author, and location. It works well when storage is already controlled and separated by classification, but when files sit in a loosely controlled shared folder, location tells you nothing
• Analyze the content: search for keywords, match patterns with regular expressions (a way to search text by pattern, such as card numbers, phone numbers, emails), or use machine learning (computers learning from examples that are already classified). The draft says machine learning appears the most capable automatic approach, but it is complex to set up and manage
• Let people choose: necessary for ad hoc files, but hard to make consistent at scale and dependent on each person's understanding
• Reclassify data that arrives from outside: the draft says data imported from another organization should usually be reclassified, even if the sender supplied a classification

Connecting to standards and law

Classification underpins several security standards. The information below is an overview only, not legal advice:

• ISO/IEC 27001:2022: according to summaries by standards consultancies, Annex A contains control 5.12 classification of information and control 5.13 labelling of information. The full text must be bought from ISO and we did not read it from the original, so check it against the copy your organization holds
• NIST SP 800-53 Rev. 5: control RA-2 (Security Categorization) requires categorizing the system and the information it processes, stores, and transmits, and documenting the rationale. Control MP-3 (Media Marking) requires marking media with distribution limitations and handling caveats. Control MP-6 (Media Sanitization) requires sanitizing media before disposal or release with strength matched to the security category or classification of the information
• PDPA (Thailand's Personal Data Protection Act B.E. 2562 (2019)): an article by the law firm Tilleke & Gibbins (November 2022) says sensitive personal data, such as health, biometric, and genetic data, religious beliefs, and criminal records, generally requires explicit consent before processing, and that data controllers must have suitable security measures. It makes sense to give this group of data its own level or label. Before relying on it, check the list and the exceptions against the statute and the guidance of the Personal Data Protection Committee (PDPC)

Common mistakes

• So many levels that nobody remembers them: the more levels there are, the more staff pick wrongly or carelessly
• Thinking only about secrecy: ignoring integrity and availability, although FIPS 199 asks for all three
• Writing the protection method into the level name: when technology changes, the level names must change too, although the NIST draft advises keeping them separate
• Classifying once and never reviewing: data that changes or is combined, and changes in the law, can make the old level wrong
• Trusting a partner's label without checking: the sender may have misclassified it, or your organization may have extra requirements the sender does not
• Letting labels get lost along the way: labels that anyone can delete, or that vanish when a file moves, make label-based controls ineffective

Start today

• Draft 3-4 levels with examples: start from the example in this article and adapt it to your organization
• Pick the 5 most important types of data: for example customer data, contracts, source code, employee data, and financial data, then name an owner and a level for each
• Write minimum controls for each level: for example where it is stored, how it is sent, whether it is encrypted, and how long it is kept
• Pilot labeling in one department first: see whether staff understand and follow it before rolling it out everywhere
• Check that sensitive personal data is classified: give it its own level or label, and confirm with legal staff or whoever owns PDPA compliance

Once data is classified, the next step is to have systems help enforce it. Read more in What Is DLP? Data Loss Prevention and Shadow AI Risk. For data going into AI tools the organization has not approved, see What Is Shadow AI? Risks Organizations Can't See and How to Respond, and for data as one pillar of zero trust, see Zero Trust Architecture: Components and Roadmap.

To see where your organization's data protection stands, try the self-assessment.

Scope and accuracy

FIPS 199 and SP 800-60 are written for the US federal government. The four-level example scheme and the six-step sequence are our own proposals. The ISO/IEC 27001 content is taken from consultancy summaries, not from the original, and the PDPA content is taken from a law-firm article, not from the statute. All information was checked against sources opened on 22 October 2026. Confirm it against the latest documents and legal counsel before relying on it.

References and further reading

• NIST FIPS 199: the security categorization standard with low, moderate, and high impact levels
• NIST SP 800-60 Vol. 1 Rev. 1: how to map information types to impact levels
• NIST SP 800-60 Rev. 2 (initial working draft): the planned update, released January 2024
• NIST IR 8496 initial public draft: data classification concepts and terms (a draft whose development has ended)
• NIST SP 1800-39 Data Classification Practices: an NCCoE practice guide draft on discovering and labeling unstructured data (public draft, February 2026)
• NIST SP 800-53 Rev. 5: controls RA-2, MP-3, and MP-6
• ISO/IEC 27001:2022: the ISO standard page (full text is paid)
• Tilleke & Gibbins: PDPA lawful basis, sensitive personal data and safeguards: a law-firm article on sensitive personal data
• PDPC (Personal Data Protection Committee): the PDPA regulator's website