Most organisations treat data classification as a technical tagging exercise. A checkbox. A compliance artefact. Something security teams worry about and everyone else ignores. The result is predictable: inconsistent classifications, unclear responsibilities, and systems that enforce rules no one understands.

But classification is not a technical activity. It is a modelling activity. And like all modelling, it only works when it respects the separation of conceptual, logical, and physical layers.

This article explores how to design and implement data classification for PII and sensitivity using the same layered discipline described in my earlier post on master data model design. When classification is modelled correctly, it becomes a strategic capability rather than a regulatory burden.

The Conceptual Layer: Defining the Meaning of Sensitivity

The conceptual layer is where classification begins. Not with fields. Not with systems. With meaning.

At this level, the organisation defines what “sensitive data” actually means. Not in legal terms, not in technical terms, but in business terms. This is where shared language is created.

The work here focuses on defining sensitivity classes such as Public, Internal, Confidential, and Highly Confidential. It also includes defining PII categories such as Non‑PII, Indirect PII, Direct PII, and Special‑category PII. Finally, the organisation clarifies why classification exists in the first place: risk reduction, regulatory compliance, access control, and data minimisation.

Nothing in this layer is tied to a system or a field. The organisation is simply agreeing on the semantics of sensitivity. Without this step, everything that follows becomes political, inconsistent, or purely technical. Executives engage at this level because the conversation is about risk, trust, and business impact—not encryption algorithms or masking rules.

The Logical Layer: Turning Sensitivity Into Behaviour

Once the organisation agrees on what sensitivity means, the next step is to define how it behaves. This is the logical layer: the operationalisation of classification.

This is where classification becomes actionable.

The work here includes defining classification rules such as “email address is direct PII” or “birthdate is indirect PII.” It includes defining handling requirements such as masking, encryption, retention, and access control. It includes defining lifecycle behaviour: how sensitive data is created, used, shared, archived, and deleted. And it includes defining stewardship responsibilities: who approves classification changes, who monitors compliance, and who owns remediation.

The logical layer is where classification stops being a label and becomes a set of obligations. It is also where governance becomes real. Without this layer, classification is just a taxonomy with no consequences.

The Physical Layer: Implementing Sensitivity in Systems

Only after the conceptual and logical layers are complete should classification be implemented in systems. This is where most organisations start—and where most classification efforts fail.

The physical layer is about translation, not interpretation.

This is where classification attributes such as SENSITIVITY_LEVEL and PII_CATEGORY are implemented in the MDM model. It is where masking and encryption rules are configured in the platform. It is where role‑based access control is tied to classification. It is where data quality rules enforce classification logic. And it is where lineage and audit capabilities track the movement of sensitive data.

At this layer, the organisation is not deciding what sensitivity means. It is simply encoding the decisions already made at the conceptual and logical layers. This is the difference between a classification model that works and one that collapses under its own ambiguity.

A Practical Blueprint for PII and Sensitivity Classification

Step	Purpose	Output
Define sensitivity classes	Establish shared language	Sensitivity taxonomy
Define PII categories	Align with regulation	PII taxonomy
Define rules and behaviours	Make classification operational	Handling rules, lifecycle, access
Map to processes	Ensure classification drives action	Stewardship and compliance model
Implement physically	Enforce classification	Attributes, masking, access control
Govern and evolve	Keep classification accurate	Governance framework

This blueprint works because it respects the separation of layers. It ensures that classification is not driven by system constraints or regulatory panic, but by business meaning and operational clarity.

Layered Classification Matters

Classification is one of the most misunderstood aspects of data governance. It is often treated as a technical exercise, delegated to security teams or buried inside system configuration. But classification is fundamentally a modelling discipline.

When classification is defined conceptually, operationalised logically, and implemented physically, it becomes a strategic asset. It enables trust. It reduces risk. It clarifies ownership. It aligns regulatory obligations with business behaviour.

When the layers are mixed, classification becomes noise. The layered approach is not just cleaner. It is the only approach that scales.

If you want, I can refine this further into a more narrative style, a more technical style, or a version tailored for executive consumption.