Data classification is the process of deciding how sensitive each piece of information is and labelling it accordingly. This guide covers classification levels, content- and context-based methods, the link to DLP and DSPM, KVKK and GDPR relevance, and a practical rollout plan.
Key Takeaway
Data classification gives every piece of data a written answer to one question: “How much harm would we suffer if this leaked?” Without classification, a DLP policy either blocks everything or blocks nothing. Classification tells tools such as DLP and DSPM which data to protect.
- Four levels are enough for most organizations: Public, Internal, Confidential and Restricted.
- There are three core methods: content-based, context-based and user-driven classification. Effective programs combine all three.
- ISO/IEC 27001:2022 Annex A 5.12 defines classification of information as a control, and 5.13 defines labelling of information.
- GDPR Article 9 defines special categories of personal data; Turkey’s KVKK Article 6 has a similar list. These belong at the highest level.
- Classification is not a one-off project. New data is created every day, so discovery and labelling must run continuously.
1. What is data classification?
Data classification is the process of grouping an organization’s information by its sensitivity and by the impact that unauthorized disclosure would cause. Each group gets a level name, and each level has its own rules: who can access it, where it can be stored, how it can leave the organization and how long it is kept.
The US National Institute of Standards and Technology (NIST) defines low, moderate and high impact levels for confidentiality, integrity and availability in FIPS 199. NIST SP 800-60 gives guidance on mapping information types to those impact levels. In business practice, this approach is usually translated into simpler labels such as “Public – Internal – Confidential – Restricted”.
This guide is written for IT managers, information security leads and privacy compliance teams. It is not legal advice. Confirm the obligations that apply to your organization with your legal counsel.
2. Classification levels: a four-level model
The more levels you define, the harder it is for users to pick the right one. That is why most organizations start with three or four. The table below shows a common four-level model and the typical controls at each level. Treat the examples as guidance and adapt them to your own risk assessment.
| Level | Definition | Example data | Typical control |
|---|---|---|---|
| Public | Disclosure causes no harm | Website content, press releases, product brochures | Integrity control only; no egress restriction |
| Internal | For employees only; a leak causes limited harm | Internal announcements, procedures, org charts | Warning on external sharing; authenticated access |
| Confidential | A leak causes serious financial, legal or reputational harm | Customer lists, contracts, payroll, personal data | Role-based access, encryption, block or approval on USB and personal cloud |
| Restricted | A leak causes severe harm or legal penalties | Special-category personal data, card data, source code, M&A documents | Named access list, mandatory encryption, block on all egress channels, detailed logging |
3. Classification methods
Content-based classification
The file content is inspected using regular expressions, checksum algorithms and keyword dictionaries. For example, payment card numbers can be validated with the Luhn algorithm, and Turkish national ID numbers carry check digits. Using validation reduces false positives from random numbers. This method is objective, but it does not understand context: a fake card number in a test file can also be flagged.
Context-based classification
Instead of the content, the method looks at the surroundings: which application created the file, which folder it sits in, which department the owner belongs to, which system it was exported from. Treating every file exported from the HR system as “Confidential” is a simple and effective rule. This method is fast, but it does not verify the content.
User-driven classification
The person who creates the file selects the level. The data owner knows the context best, which makes this valuable for legal, strategy and R&D documents. The weakness is inconsistency: users in a hurry pick the lowest level. Support user choice with automatic suggestions and require a justification when someone downgrades a label.
Practical tip
Use content-based classification for structured, identifiable data (national IDs, IBANs, card numbers); context-based classification for data coming out of specific systems; and user-driven classification for strategic and unstructured documents.
4. How data classification relates to DLP and DSPM
Classification does not protect data by itself; it says which data must be protected. The protection happens in other layers:
- DSPM (Data Security Posture Management) discovers where sensitive data lives: file servers, endpoints and cloud storage. It is the “inventory” side of classification. Details: /en/products/dspm.
- DLP (Data Loss Prevention) controls how classified data leaves through USB, email, web upload, clipboard and print. It is the “enforcement” side of classification. Details: /en/products/dlp.
- Access management decides who can open the data at each level.
Moftgate DLP combines content-based detection on the endpoint (for example national ID, tax ID, IBAN and card number patterns) with context rules, and applies policy by data level: warn and require approval for “Confidential” data, block for “Restricted” data. Moftgate DSPM reports where sensitive data sits, so the classification program is based on a real inventory, not on guesses. For the basics, see our “What Is DLP? Data Loss Prevention Guide”; for the difference between the two, see “What Is DSPM”.
5. Data classification under GDPR and KVKK
GDPR Article 9 defines special categories of personal data, such as data revealing racial or ethnic origin, political opinions, religious beliefs, trade union membership, genetic and biometric data, and data concerning health or sex life. Article 32 requires security appropriate to the risk, and Article 30 requires records of processing activities. The regulation does not use the word “classification”, but an organization that cannot tell these data apart cannot apply the right level of protection.
Turkey’s Personal Data Protection Law No. 6698 (KVKK) follows the same logic. Article 6 lists special categories of personal data, and the KVKK Board’s decision 2018/10 of 31 January 2018 sets additional “adequate measures” for them. Article 12 requires technical and administrative measures that ensure an appropriate level of security. Classification is the documented form of that “appropriate level”.
6. Step-by-step rollout plan
- 1. Write the policy: put the levels, definitions, examples and rules for each level into a one-page document. Get executive sign-off.
- 2. Assign data owners: name a person in each department who decides the level of that department’s data.
- 3. Discover: use DSPM or a discovery scan to find which servers, endpoints and cloud stores hold sensitive data.
- 4. Define rules: configure content patterns, context rules and user labelling options.
- 5. Start in monitor mode: run DLP policies in log-only mode first and remove false positives.
- 6. Enforce gradually: first block on “Restricted” data, then turn on warn-and-approve flows for “Confidential” data.
- 7. Train: explain the levels to employees with real examples and show why the label matters.
- 8. Measure and review: report incident count, false-positive rate and the share of unlabelled files; update the policy at least once a year.
7. Common mistakes
- Too many levels: six or seven levels confuse users and lead to inconsistent labels.
- Marking everything “Confidential”: if everything is confidential, nothing is, and users start ignoring warnings.
- Classifying only new files: aged data on legacy file servers is often the biggest risk.
- Not connecting labels to tools: if DLP and access rules ignore the label, the label is decoration.
- Skipping monitor mode: starting with blocking breaks workflows and creates resistance to the project.
- No data owner: without someone to decide the level, every debate stays with the IT team.
Conclusion
Data classification is the foundation of GDPR, KVKK and ISO 27001 compliance and of an effective DLP program. Start small: four levels, clear examples, discovery first, then monitoring, then blocking.
Over 15 years of enterprise infrastructure security, reverse engineering, and DLP systems design. Directed sovereign endpoint security transformations across 100,000+ nodes in banking and critical infrastructure.
Expert Answers to Core Practitioner Questions
What is data classification?
It is the process of grouping and labelling an organization’s information by sensitivity and by the impact a leak would cause. Each level has different access, storage and sharing rules.
How many classification levels should we use?
Three or four levels are enough for most organizations: Public, Internal, Confidential and Restricted. More levels make it harder for users to choose correctly.
Does GDPR require data classification?
GDPR does not use the word “classification”. But Article 9 defines special categories and Article 32 requires security appropriate to the risk. In practice you cannot apply the right controls without telling these data apart.
What is the difference between data classification and DLP?
Classification decides which data is sensitive. DLP prevents that data from leaving through channels such as USB, email, web and cloud. DLP acts on the result of classification.
Is automatic classification enough?
Automatic content detection is reliable for structured data such as national IDs, IBANs and card numbers. Unstructured data such as strategy and legal documents needs a decision by the user or data owner. The best results come from combining both.
Authoritative Sources & Regulatory Standards
- •
- •
- •
- •
- •
- •