Define a small set of data classes, list which of your data types fall into each, and state the handling rule for each class: who can access it, how it is encrypted, how long it is kept. Three or four classes are enough. A short scheme you follow beats a long one you do not.
Why buyers ask
A reviewer cannot judge your controls without knowing what they protect. If you hold only business contact details, the bar is different from a service that stores health records, payment data or source code. The question also exposes whether you know your own data, which is a basic sign of maturity.
NIST's FIPS 199 provides a standard for categorizing federal information and systems according to an agency's level of concern for confidentiality, integrity and availability, and the potential impact if they are compromised. You do not need to follow it, since it is written for federal use, but its idea is a sound template: think about the harm from a breach of each of those three properties.
A simple scheme
| Class | Example data | Typical handling |
|---|---|---|
| Public | Marketing content, public docs | No restriction |
| Internal | Policies, internal plans | Staff only, standard access controls |
| Customer confidential | Customer uploads, records, configuration | Tenant scoped access, encryption in transit and at rest, logged access |
| Restricted | Credentials, keys, regulated personal data | Minimum named staff, stronger controls, shorter retention |
Rename classes to fit you. What matters is that each has a rule and an owner.
Steps to build it
- List your data. Walk through the product and the company: what do you collect, generate, store and send onward?
- Group it. Place each item in a class by asking what harm a leak, change or loss would cause.
- Assign rules. For each class, define access, encryption, retention and deletion.
- Map to systems. Note which stores hold each class. This is the same list your data flow diagram uses. See what belongs in a security architecture diagram.
- Review yearly, and whenever you add a feature that takes new data.
How to word the answer
"We use four data classes. Customer content is classed as customer confidential and is encrypted in transit and at rest, accessible to staff only on a need basis, with access logged. Credentials and keys are restricted, stored in a managed secrets store with named owners. Retention and deletion follow the schedule in our data retention policy."
Add attachments: the classification table and the retention policy.
Pitfalls
- Claiming you hold no personal data. Almost every SaaS holds some, such as user names, emails and IP addresses in logs. Say what you hold.
- Treating prompts, logs and analytics as unclassified. These often contain customer content. Classify them.
- A classification no one applies. If a reviewer asks to see how a ticket is labelled and nothing is, the answer fails.
- Mixing up classification and compliance scope. Classifying data as personal or regulated is a factual step. What laws apply is a legal question for your counsel.
Link to other answers
Data class feeds retention, deletion, encryption and residency answers. See what happens to customer data when a contract ends and answer encryption questions in security questionnaires.
Safeguard's asset discovery can help you build the inventory of systems that step four depends on.
Quick check
How many classification levels do we need?
Usually three or four. More levels create confusion about which rule applies, and staff stop using them.
Do we classify customer data on the customer's behalf?
You usually treat all customer content as confidential by default, since you cannot know its sensitivity. Where customers can label data, support their labels.
Sources
- NIST, FIPS 199, Standards for Security Categorization of Federal Information and Information Systems
Last reviewed: 19 October 2026.
