Teams handle data inconsistently — some over-protect trivial data, some expose sensitive data. What foundational control helps?
Short answer
Inconsistent handling usually means there's no shared definition of sensitivity, so the foundational control is a data classification scheme (e.g., public/internal/confidential/restricted) with defined handling, storage, and sharing requirements per level, letting teams apply proportionate controls. Encrypting nothing 'to keep things simple' or treating all data as public strips protection from data that needs it. Deleting all data older than a day destroys records the business and the law require. Only a classification scheme aligns the strength of controls to the actual sensitivity of the data.
When teams protect data inconsistently, the root cause is almost never a missing tool — it's that no one has agreed what the data is worth. Without a shared definition of sensitivity, each team improvises, so trivial data gets locked down while genuinely sensitive data leaks out. The foundational fix is a data classification scheme.
How classification fixes the problem
A classification scheme defines a small number of levels — commonly public, internal, confidential, restricted — and, for each level, the handling, storage, sharing, and disposal requirements. Once data is labelled, the control strength follows automatically: restricted data gets encryption, strict access control, and DLP; public data gets none of that overhead. This makes protection proportionate — neither wasted on trivia nor absent where it matters — and gives every team the same rulebook instead of relying on individual judgment.
Why the wrong answers fail
"Encrypt nothing to keep things simple" removes protection wholesale, leaving sensitive data exposed — the opposite of the goal. "Treat all data as public" is the same mistake stated as policy: it declares that nothing needs protection, which is false for any real organisation. "Delete all data older than a day" confuses retention with classification and is actively harmful — it destroys records the business needs and that legal, tax, or regulatory rules often require you to keep. None of these align controls to sensitivity; they apply a single blunt setting to everything.
The judgment being probed
The interviewer is checking that you reach for the enabling control that everything else hangs off. Classification is upstream of DLP, retention, access control, and encryption decisions — get it right and those controls become straightforward to target. Strong answers note that a data owner (not GRC alone) should set the classification, that labels must be usable or they become shelfware, and that the scheme only delivers value when it actually drives downstream controls. It's the difference between protecting data by sensitivity and protecting it by guesswork.
Likely follow-ups
- Who should decide a data set's classification — the owner, the GRC team, or an automated tool?
- How do you keep classification from becoming shelfware no one applies?
- How does classification connect to DLP, retention, and access control downstream?