Data Classification and Sensitivity Mapping

Data classification and sensitivity mapping are foundational customer responsibilities because providers cannot decide what your data means. A cloud platform can store, encrypt, replicate, and process data. It cannot decide whether a field is public, internal, confidential, regulated, export-controlled, health-related, or highly sensitive. Those judgments depend on business context, legal obligation, and risk appetite, so they stay on the customer side of the model.

This is why data classification should happen before teams discuss storage features or encryption defaults. If the organization does not know how sensitive the data is, it cannot choose appropriate access controls, residency rules, logging requirements, retention periods, or recovery targets.

The decision path is usually customer-led from the start:

    flowchart TD
	    A["Customer identifies data set"] --> B["Customer assigns classification and sensitivity level"]
	    B --> C["Protection requirements are chosen"]
	    C --> D["Provider services are configured to support those requirements"]

What to notice:

• protection starts with customer judgment, not with provider defaults
• the provider supports the control implementation but does not define the data category
• weak classification leads to weak downstream protection choices

What Sensitivity Mapping Usually Drives

Once a classification exists, it often drives:

• who may access the data
• which environments may contain it
• whether customer-managed keys are required
• how much logging and monitoring is needed
• what backup and restore expectations apply
• whether external sharing is prohibited

These are all downstream decisions that depend on the customer first naming the data correctly.

A Practical Classification Map

 1data_classes:
 2  public:
 3    examples:
 4      - marketing-pages
 5    controls:
 6      - minimal-access-restrictions
 7
 8  confidential:
 9    examples:
10      - customer-invoices
11    controls:
12      - least-privilege-access
13      - audit-logging
14      - approved-retention-policy
15
16  regulated:
17    examples:
18      - health-records
19    controls:
20      - residency-restrictions
21      - stronger-key-governance
22      - deletion-and-disclosure-workflows

What this demonstrates:

• data classes should lead to concrete control expectations
• the customer owns the mapping between data meaning and control strength
• provider services become implementation tools after the classification exists

Why Providers Cannot Do This for You

Even if a provider offers tags, labels, data discovery features, or policy engines, those are still support tools. They cannot replace the customer’s understanding of legal obligations, business use, confidentiality expectations, or sector-specific restrictions. Classification is a business and governance decision before it becomes a technical one.

Common Mistakes

• storing data before classifying it
• treating every data set as if it had the same sensitivity
• letting engineering teams infer classification informally without policy support
• assuming encryption alone means the data no longer needs classification

Design Review Question

A team stores a new customer analytics dataset in a managed warehouse and says classification can wait because the warehouse has encryption and role-based access controls enabled. Is that a strong approach?

No. The stronger answer is that classification should come first, because it determines whether the data belongs in that platform, what access is acceptable, what retention is allowed, and what additional controls are needed. Platform features do not substitute for knowing what the data is.

Check Your Understanding