Data classification: sensitivity tagged in code, enforced by tests

What does the capability do?

It makes “which data is sensitive, and how sensitive” a fact the system holds and acts on, rather than a spreadsheet nobody maintains.

• Two-dimensional scheme. A sensitivity tier records how damaging exposure would be; handling overlays record why a field needs care. A single field can be restricted and flagged as special-category health data at once. An asset takes the highest tier any of its fields demands.
• Tagged in code. Each sensitive property carries a classification attribute holding its label and overlays. The same attribute drives every classification-aware control, so redaction, obfuscation, and blob tagging read one source rather than each keeping its own list.
• Labelled in the database. Classified columns carry native SQL sensitivity classifications with an information type and rank, so engine-level auditing and data-discovery tooling can act on them, not just the application.
• Carried onto stored files. Documents and media are uploaded with blob index tags built from their classification, so storage-side tooling can enumerate every restricted file without opening it.
• Enforced by a coverage test. A test runs on every push and asserts both directions: every labelled column has a code attribute, and every attribute has a database label. A missing classification breaks the build.

Why enforcement is the detail that matters

Almost every organisation has a data classification policy. Very few have classification that does anything, because it lives in a document while the system lives in code, and the two drift apart within months.

The platform closes that gap by expressing one taxonomy in three places (the database, the code, and a documented inventory) and holding them in lockstep with a build-breaking test. Classification stops being a claim and becomes a contract. A developer cannot add a column holding a child’s medical note without classifying it everywhere, because the build will not let them.

Why it matters

Classification is what makes the rest of data protection tractable. Field-level redaction reads the label to decide what to mask. Non-production environments are obfuscated by blanking every classified field. Retention and erasure know which columns hold personal data because the classification tells them. Get classification machine-readable and enforced, and masking, retention, and breach response all become answerable from data. It is the same principle that runs through the whole platform: protection is designed in and enforced by tests, not bolted on and hoped for. Read more in our approach to GDPR and data protection by design.