Data Classification

Data Classification is the process of organizing data into categories based on its sensitivity and the impact if it were compromised. It determines which security controls to apply. It is also the prerequisite for almost everything else in data protection: you cannot decide what deserves a customer managed KMS key, strict access logging, or Macie monitoring until you know which data actually matters.

Classification Levels

• Public: information intended for public access (marketing materials, docs). Minimal controls.
• Internal: not sensitive but not public (internal tools, non-sensitive business data). Basic access control.
• Confidential: sensitive business data (financial reports, customer data, contracts). Encryption, access logging, need-to-know.
• Restricted: highest sensitivity (PII, PHI, payment data, credentials, IP). Encryption, strict access control, audit trails, DLP.

AWS Tools for Data Classification

• Amazon Macie: automatically discovers and classifies sensitive data in S3
• Resource Tags: tag resources with classification level for policy enforcement
• S3 Object Tags: classify individual objects within buckets
• Lake Formation: column-level and row-level access control for data lakes

Security Controls by Level

• Public: no encryption required, basic monitoring
• Internal: encryption at rest (SSE-S3), VPC-only access
• Confidential: encryption (KMS CMK), access logging, VPC endpoints
• Restricted: KMS CMK with key policy, Object Lock, Macie monitoring, DLP, audit trails

From Labels to Enforcement

A classification scheme only works if labels are machine-readable and policies act on them. On AWS the practical pattern is: define a small tag taxonomy (for example DataClassification with the four values above), apply it at bucket, table, and volume level, then write IAM and SCP conditions against aws:ResourceTag so the label carries consequences: only specific roles can read resources tagged Restricted, and nobody can remove or change the classification tag without a privileged role. Tag policies in AWS Organizations keep the taxonomy consistent so you do not end up with restricted, Restricted, and RESTRICTED as three different labels. Macie closes the loop from the other side: it inspects what is actually inside S3 objects and tells you when reality disagrees with the label.

How It Goes Wrong in Practice

The most common failure is classification on paper only: a policy document defines four beautiful levels, but no bucket is tagged, no policy references the tags, and enforcement is a wiki page. The second, sneakier failure is sensitive data drifting into low-classification locations. The canonical example is application logs: a developer logs a full request payload for debugging, and suddenly customer emails and access tokens are sitting in a CloudWatch Logs group and an S3 logging bucket that were classified "internal" and secured accordingly, readable by every developer. Backups, analytics exports, and ML training sets follow the same pattern: data gets copied downward into environments whose controls were sized for less sensitive content. This is exactly the gap automated discovery exists to catch, because humans classify containers once, while data moves daily.

A Practical Check: Is Discovery Actually Running?

If you rely on Macie for automated discovery, first verify it is enabled and not paused in each Region that holds data:

aws macie2 get-macie-session

The response includes a status field of ENABLED or PAUSED, plus the finding publishing frequency. A paused Macie session is functionally the same as no discovery at all, so treat PAUSED in a production Region as a finding in itself. From the console, the equivalent check is Amazon Macie, then Settings, in each active Region.

Frequently Asked Questions

How many classification levels should we use?

Three or four. Every additional level multiplies the policy matrix and the chance that people guess. If staff cannot decide a document's level in a few seconds, the scheme is too complicated, and everything ends up marked one level below Restricted "to be safe".

Is Amazon Macie enough for data classification by itself?

No. Macie discovers and reports sensitive data in S3, which solves the visibility half of the problem. Classification also needs the governance half: a tag taxonomy, controls conditioned on those tags, and processes for labeling data outside S3 (RDS, DynamoDB, EFS, data warehouses), which Macie does not scan.

How do classification levels map to encryption choices?

A workable default: internal data gets provider-managed encryption (SSE-S3), confidential data gets a customer managed KMS key so you control the key policy and get CloudTrail on every decrypt, and restricted data adds tight key policies, Object Lock where immutability matters, and continuous Macie monitoring. Public data needs integrity protection more than confidentiality.