Data Classification & Handling

You cannot protect data well if you do not know how sensitive it is. Classification is the simple habit of labelling data by sensitivity, so the right protection follows automatically. Public information and a customer's passport scan should never be treated the same way.

Every field we store sits somewhere on a sensitivity scale. The protection it needs follows from that: who can see it, whether it is encrypted, how long it is kept, and whether it can leave the country. Classification gives everyone shared terms, so those decisions are consistent instead of one-off. It is the foundation under Data Protection & Privacy and Handling Customer Data.

A simple, practical set of levels is enough: Public, Internal, Confidential (personal data), and Restricted (special-category, such as biometric and KYC data, and secrets). What matters is that you know which level you are handling and apply the matching rules.

Know what you're handling

• DoClassify data by sensitivity (Public, Internal, Confidential, Restricted) and let the level drive storage, access, encryption, retention, and residency decisions.
• DoGive the most sensitive levels (special-category KYC and biometric data, secrets) the strongest controls: encryption, tight least-privilege access, and tenant isolation.
• DoKeep the classification with the data as it flows into caches, exports, logs, analytics, and backups, so protection is not lost along the way.
• ConsiderDocumenting a simple data catalogue or map: what we hold, its classification, where it lives, and who can access it.
• AlwaysApply the protection that matches the most sensitive field present. A record is only as safe as its most sensitive part.

Handle by level

• DoDefault to the more cautious classification when you are unsure, and ask. Under-protecting sensitive data is the costly mistake.
• AvoidCopying Confidential or Restricted data into lower-trust places, such as spreadsheets, personal drives, screenshots, or dev environments. If you must, strip or mask it first.
• NeverLog Restricted data (special-category, secrets, full PII), return it in an API response, or send it to an external service (see Observability & Logging Hygiene).
• NeverCopy production Confidential or Restricted data into dev, test, or personal environments. Use synthetic or masked data (see Test Data & Environments).

Self-review checklist

• AskWhat is the classification of the data in this feature, and is it protected to that level?
• AskIs the most sensitive field driving how the whole record is handled?
• AskCould this data flow into a log, export, cache, or non-prod environment that loses its protection?
• AskIf I am unsure of the level, have I defaulted to cautious and asked?