Skip to main content

Data Classification

Assign data sensitivity, criticality, ownership, use, sharing, retention, and recovery requirements that drive technical controls.

Classification drives protection

Data classification assigns security and handling requirements based on harm from unauthorized disclosure, modification, destruction, unavailability, or inappropriate processing. It connects the value and context of data to collection, access, encryption, logging, sharing, retention, backup, recovery, and disposal controls.

A label without required behavior is only metadata. Each class needs an owner and concrete handling rules.

More than confidentiality

Classify confidentiality, integrity, availability, authenticity, accountability, privacy, and criticality as needed. Public software release data can have low confidentiality and high integrity. An access policy can have high integrity and availability. An audit record can need integrity and restricted disclosure. A recovery key can have extreme confidentiality and availability requirements.

Consider aggregation and inference. Many low-sensitivity records can become sensitive when combined. Derived data, metadata, access patterns, and logs can deserve a higher class than individual fields suggest.

Lifecycle and context

Record the data owner, purpose, subjects, source, systems, tenants, geographic or contractual constraints, allowed users, allowed uses, sharing, retention, backup, recovery, and disposal. Apply classification to generated exports, caches, replicas, test data, support bundles, telemetry, and machine-learning or agent context.

Use automatic labels and controls where the system knows the data type. Let owners review exceptions. Reclassify when purpose, aggregation, threat, law, or business impact changes.

Failure and residual risk

Too many classes cause inconsistent use. One broad secret label makes prioritization weak. User-supplied labels can be wrong. Encryption cannot satisfy availability or correct use. Classification can itself reveal sensitive purpose. A downstream copy can lose the label while retaining the data.

Pomerium boundary

Pomerium can restrict route access using identity and policy. It does not discover or classify application records. Application and data owners must map classes to route access, object authorization, storage, telemetry, export, backup, and retention. Pomerium logs and identity attributes also require their own classification and handling.

Evaluation checklist

  • Does each class define required handling for confidentiality, integrity, availability, privacy, retention, and recovery?
  • Are owner, purpose, source, subjects, users, systems, copies, and allowed uses recorded?
  • Are derived, aggregated, exported, cached, logged, test, backup, and support data included?
  • Does the label travel with the data or map reliably at each system boundary?
  • Can technical controls enforce the handling rules instead of relying only on training?
  • What event triggers reclassification or removal?

Sources and further reading

Keep learning

Security Engineering Foundations

Security Properties

Distinguish confidentiality, integrity, availability, authenticity, accountability, and privacy in a system claim.

Learn this term

Get a Personalized Demo

Schedule a Call with a Pomerium Engineer

Get a Demo