Data Classification: Complete Guide to Categorizing Sensitive Data

Data classification is the process of organizing data assets into defined categories based on their sensitivity, content type, regulatory requirements, or business value. By assigning classification labels to datasets, tables, columns, and files, organizations create a systematic foundation for access control, data protection, privacy compliance, and risk management. Without classification, data governance is essentially guesswork: teams cannot protect what they cannot identify, and they cannot comply with regulations they cannot demonstrate adherence to.

Why Data Classification Matters

Classification is a prerequisite for almost every downstream data governance activity. Data masking policies depend on knowing which columns contain sensitive data. Access control frameworks depend on knowing which datasets fall under which sensitivity levels. GDPR and CCPA compliance depends on knowing exactly where personal data resides across the organization. Data retention policies depend on knowing which data is subject to legal hold requirements. Classification provides the metadata foundation that makes all of these policies executable.

The scale of modern data environments makes purely manual classification hard to sustain. A large organization might have hundreds of databases, thousands of tables, and millions of columns spread across cloud data warehouses, data lakes, SaaS applications, and on-premises systems. Without some automation, the data governance team struggles to identify systematically where sensitive data lives, what regulations apply to it, or whether appropriate controls are in place.

Beyond compliance, classification enables proportionate security. Not all data deserves the same level of protection. Applying maximum security controls to every dataset is prohibitively expensive and operationally impractical. Classification allows organizations to apply strong controls where they are genuinely needed - on sensitive PII, financial records, and confidential intellectual property - while maintaining frictionless access to public and internal data that poses little risk if accessed broadly.

Classification Levels: A Standard Framework

Many organizations adopt a tiered classification framework, typically with three to five levels. A widely used four-tier model has the following levels:

• Public - Information intended for unrestricted public access. This includes published marketing materials, public-facing website content, press releases, and open datasets. Public data can be shared freely without restrictions and does not require special handling controls.
• Internal - Information intended for use within the organization but not for public disclosure. This includes internal policies, operational procedures, employee directories, and internal communications. Internal data should not be shared outside the organization but does not require the same level of protection as confidential or restricted data.
• Confidential - Sensitive information that could cause significant harm if disclosed inappropriately. This includes customer personal data, financial records, business strategies, legal documents, and employee compensation information. Confidential data requires access controls, encryption in transit and at rest, and audit logging of access.
• Restricted - The most sensitive category, including information whose disclosure would cause severe harm: medical records, payment card data, trade secrets, and information subject to legal privilege. Restricted data requires the strongest available controls, strict need-to-know access, and additional oversight for any movement or processing.

The four-tier model is a starting point, not a mandate. Highly regulated industries such as healthcare, financial services, and government often require more granular frameworks that reflect sector-specific regulatory categories. Organizations should resist the temptation to create overly complex frameworks with many fine-grained levels. A framework that nobody can remember or apply consistently is worse than a simpler framework that is actually used.

Classification by Data Type: PII, PHI, and Financial Data

In addition to sensitivity levels, data is commonly classified by content type, particularly for compliance purposes. Personally Identifiable Information (PII) is any information that can be used to identify a specific individual, either directly or in combination with other data. Direct identifiers include name, email address, phone number, national ID number, passport number, and date of birth. Indirect identifiers include IP addresses, device identifiers, location data, and behavioral data that can be linked back to individuals through re-identification.

Protected Health Information (PHI) under HIPAA is individually identifiable health information, in electronic or any other form, that relates to a person's health, care, or payment for care. The HIPAA Safe Harbor de-identification method lists 18 specific identifiers that must be removed for health data to be considered de-identified, including names, geographic subdivisions smaller than a state, dates (other than year) related to the individual, and full-face photographs.

Payment Card Industry (PCI) data covers cardholder data (the primary account number or PAN, cardholder name, expiration date, and service code) and sensitive authentication data such as card verification codes, full track data, and PINs. PCI DSS imposes strict requirements on the storage, transmission, and processing of this data: Requirement 3.3.1 prohibits storing sensitive authentication data after authorization, even if encrypted.

Financial data encompasses a broad range of sensitive information including bank account numbers, tax identifiers, salary information, financial statements, and trading activity. Financial data is subject to multiple overlapping regulatory frameworks depending on jurisdiction and industry sector.

Classification Methods: Manual, Rule-Based, and ML-Based

Manual classification relies on data stewards and domain experts to review and label data assets. It is the most accurate classification method for well-understood, stable datasets - an experienced data steward who knows the business domain will correctly identify sensitive columns that automated tools might miss. However, manual classification does not scale to large, dynamic data environments. It is also inconsistent: different stewards may apply the same classification standards differently, and manual labels quickly become stale as new data sources are added.

Rule-based classification uses pattern matching, regular expressions, and keyword dictionaries to identify sensitive data automatically. Examples include recognising credit card numbers by their digit pattern and Luhn checksum, identifying email addresses using a regex pattern, or flagging columns named "ssn" or "tax_id" as containing national identifier data. Rule-based classification is fast, scalable, and transparent: the rules can be audited, explained, and adjusted. Its limitation is precision - simple patterns generate both false positives and false negatives.

ML-based classification uses trained models to identify sensitive data based on column statistics, sample values, column names, and contextual signals from surrounding columns and table names. ML models can identify sensitive data in columns with non-standard names, detect partial matches, and handle multi-lingual data that rule sets struggle with. Modern ML-based classification systems combine named entity recognition (NER) models with metadata signals such as column name patterns and statistical distributions of values.

The best practice is to combine all three approaches: ML-based automated classification at scale, with rule-based checks for well-defined categories like credit card numbers and email addresses, and manual review workflows for low-confidence suggestions and high-risk datasets.

Automated Classification at Scale

Automation is what makes classification practical across large data estates. The key capabilities that modern automated classification platforms provide include:

• Discovery - automatically scan and inventory all data sources including databases, data warehouses, data lakes, SaaS applications, and file systems to identify all data assets requiring classification
• Detection - apply rule-based patterns and ML models to analyze column samples and metadata, generating classification suggestions with confidence scores
• Review workflows - route low-confidence suggestions to named data stewards for review and approval, with audit trails of all classification decisions
• Propagation - automatically propagate classification labels through data lineage chains so that derived columns inherit the sensitivity of their source columns
• Drift detection - monitor classified assets for changes in data content or schema that might invalidate existing classifications

Cloud-native classification services include Amazon Macie (which uses machine learning and pattern matching to discover sensitive data in Amazon S3), Google Cloud Sensitive Data Protection (which now includes Cloud DLP), and Microsoft Purview Information Protection. These services are well integrated with their respective cloud ecosystems and provide out-of-the-box detection for common sensitive data types.

Integration with Data Catalog

Data classification reaches its full potential when integrated with a data catalog. A catalog provides the metadata context that makes classification actionable: the list of all data assets across the organization, their technical metadata (schema, data types, row counts), their business metadata (owners, descriptions, glossary links), and their operational metadata (freshness, quality scores, lineage).

When classification labels are stored and managed in a data catalog, data governance teams can answer questions like: "Show me all tables containing PII in our AWS environment that were accessed by users outside the data team in the last 30 days." Or: "Which data products expose restricted financial data, and are they all covered by our masking policy?" These queries combine classification labels with lineage, access logs from the data platforms, and governance policy data, so the catalog has to be connected to the systems that hold each piece.

Database-native classification puts labels directly on tables and columns. Snowflake can classify sensitive columns automatically (Enterprise Edition or higher) and record the result in system tags; a tag map can apply your own tags at the same time, so a tag-based masking policy on those tags masks the classified data. In Databricks Unity Catalog, attribute-based access control policies use governed tags to apply row filters and column masks. Microsoft SQL Server's Data Discovery & Classification labels columns for reporting and auditing. Data masking driven by classification labels ensures that sensitive columns are automatically protected when accessed by users without the appropriate permissions.

GDPR and Data Classification

GDPR does not mandate a specific classification framework, but its requirements effectively require one. Article 30 requires organizations to maintain a record of processing activities (ROPA) that documents, among other things, the purposes of processing, the categories of data subjects and of personal data, the categories of recipients, transfers to third countries, and, where possible, time limits for erasure and a description of security measures. Without data classification, building and maintaining a ROPA is very hard at any meaningful scale.

GDPR's data minimisation principle - personal data must be adequate, relevant, and limited to what is necessary for the purpose (Article 5(1)(c)) - also depends on classification. You cannot minimise collection of data types you have not defined and identified. Similarly, the right to erasure (right to be forgotten) in practice requires the ability to identify and delete all records containing a specific individual's personal data across all systems, which requires comprehensive classification of personal data locations.

Special categories of personal data under Article 9 - racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data used to identify a person, health data, and data concerning sex life or sexual orientation - may be processed only where one of the Article 9(2) exceptions applies. Processing them on a large scale requires a data protection impact assessment under Article 35(3)(b). Classification is how organizations find these categories in their data before they process them.

A successful GDPR data classification programme covers four phases: inventory (discover all data sources and assets); framework definition (establish classification levels and content type categories with legal and compliance stakeholders); initial classification (apply automated tools and human review); and operationalisation (integrate labels into access control, masking, monitoring, and governance workflows).

Data Classification with Dawiso

In Dawiso, classification is recorded as metadata in the data catalog. Data stewards classify assets by linking each one to a PII level and a confidentiality value. Both come from code lists that your organization defines, and because the lists are ordinary catalog objects, they can be owned, stewarded, and changed without a release. Classification is a steward's decision: Dawiso does not scan data to detect PII.

The roll-up is automatic. An output port shows the highest classification among the assets it exposes, and a data product takes the highest value across its ports, so the most sensitive value wins. A steward can override the derived value by hand and clear the override to let it derive again. From a classification value's page you can see every object that carries it, which answers audit questions such as which data products expose confidential data.

The labels are descriptive. Dawiso does not block access or mask data based on them: access is granted through the data product's contract and your own access-provisioning process, and masking runs in the data platforms described above. What Dawiso adds is a shared, governed record of what is sensitive, who owns it, and which data products expose it.

Sources

• GDPR Article 5, Principles relating to processing of personal data (Art. 5(1)(c), data minimisation).
• GDPR Article 9, Processing of special categories of personal data.
• GDPR Article 17, Right to erasure.
• GDPR Article 30, Records of processing activities.
• GDPR Article 35, Data protection impact assessment (Art. 35(3)(b)).
• Legal Information Institute, 45 CFR 160.103, Definitions (protected health information).
• Legal Information Institute, 45 CFR 164.514, Other requirements relating to uses and disclosures of protected health information (Safe Harbor, 18 identifiers in (b)(2)).
• PCI Security Standards Council, For PCI DSS, can sensitive account data be stored before authorization? (Requirement 3.3.1).
• Amazon Web Services, What is Amazon Macie?.
• Google Cloud, Sensitive Data Protection overview.
• Snowflake, Introduction to sensitive data classification.
• Databricks, Attribute-based access control in Unity Catalog.
• Microsoft Learn, SQL Data Discovery & Classification.
• Dawiso Help, PII Level and Confidentiality.