Unlabeled Data: Where Access Control Breaks Down
Access control works only as well as the objects it applies to are labeled. As long as data classification is done manually — by an analyst's gut feeling or from the service owner's memory — the catalog will inevitably contain tables, exports, and backups without labels.
Policies are not applied to them: since there is no label, the system does not know that this is personal data or a trade secret, and it grants access on a residual basis — to whoever already has rights to the schema or bucket.
Then accumulation kicks in. An analyst copies a sample into personal storage "for a couple of days," a developer spins up a test environment from a production dump, an integration writes a log with request bodies.
Each such shadow copy is no longer a single protected environment but a dozen unmanaged ones, and none of them makes it into the report on where sensitive data actually resides.
Data labeling done once when a table is created becomes hopelessly outdated by the time it is copied: the schema changed, fields were added, but the label remained the same.
The cost shows up in two places. First — an incident: when investigating a leak, no one can answer within minutes exactly which records and in which storage systems were affected, and damage assessment drags on for weeks.
Second — compliance checks: an auditor asks you to prove that access to sensitive data is restricted and confirmed, and there is nothing to present but a manual register that diverges from reality the very next day after it is compiled.
The compliance risks here are not in the absence of a policy as a document, but in the gap between the policy and the actual placement of data.
Automatic classification closes this gap by ceasing to be a one-time exercise. Scanning sources, recognizing sensitive fields by content and context, applying labels and their inheritance during copying — all of this works as an ongoing process, not as a project with an end date.
Let's break down how this is structured and what changes in access control when every object gets a label.
What automatic data labeling provides
Automatic labeling removes the routine of continuous review from people: rules label data by type (personal, payment, trade secret) as it appears in the storage, rather than based on the results of a quarterly sweep. An engineer gets a sensitivity map in real time, not a snapshot from six months ago.
The first measurable effect is a reduction in manual auditing. Continuous sampling is replaced by exception checking: the system itself shows where a label did not match the content, and a person reviews dozens of discrepancies instead of thousands of files.
The speed of regulatory checks grows proportionally: a report on labeled data is assembled from ready-made slices, rather than from correspondence with system owners.
The second is a reduction in the severity class of incidents. When a label is applied at the point of entry, access and encryption policies are applied to the object automatically, and a leak is confined to a single perimeter instead of the entire storage.
An incident moves from the "mass leak" category to "local violation," and that means a different volume of notifications, different downtime, and a different level of reputational damage.
The third is predictability of timelines. Labeling flows alongside data loading, so new sources fall under the same rules without a separate project.
Pre-release checking takes hours: the team sees which datasets fall outside the perimeter before rollout, not after the security department raises the issue.
It is worth remembering the limits: false positives on non-standard formats and historical archives require calibration of the rules.
The first weeks go into tuning thresholds and resolving disputed labels — after that, the system runs on maintenance rather than on a one-off heroic audit.
Classification approaches: engine, rules, hybrid
Classification is the assignment of a label to each object: "personal data," "commercial secret," "public." The label determines who has access, where the object can be copied, and after how many years it should be deleted.
The method of assigning labels is chosen based on the data volume and regulatory requirements — below are three approaches most often compared at the start.
| Approach | When it fits | Limitations |
|---|---|---|
| Manual labeling by rules | Small document flow, stable structure, strict audit requirements | Does not scale: as volume grows severalfold, the staff of labelers grows, and with it the share of omissions and discrepancies between people |
| Rules and templates | Data is uniform: invoices, contracts, exports from accounting systems | Breaks on non-standard formats: a renamed file or a new column bypasses the rule, and the label is not applied |
| Classification by a model | Large volumes, heterogeneous sources, changing formats | Requires a labeled sample for training and quality control: the model makes mistakes, and errors must be caught |
Manual labeling delivers maximum accuracy on a small volume, but its cost grows linearly with the data. Rules are cheap to maintain and predictable for audit — each label can be explained by reference to a specific condition, which matters during review.
A model works where rules no longer cover the diversity: it generalizes features and labels new types of documents without rewriting conditions.
In practice, a hybrid is chosen: rules cover obvious cases and serve as a foundation for audit, the model labels what did not fall under a template, and manual review remains for the sample and for disputed objects.
Such a loop yields a share of automatic labeling above 90% with a controlled error rate, and each label remains explainable — this is precisely the requirement that a reviewer raises first.
How we implement data classification: stages
Implementing data classification is not about installing a scanner, but a sequence of work where each subsequent stage relies on the result of the previous one.
We start with an inventory of sources: we find databases, file storages, queues, exports to analytics, and backups, and record the owners and the actual volume.
Without a complete map of sources, any labeling will be incomplete, and policies will be inapplicable to part of the data.
How the implementation proceeds
- Data inventory. We compile a list of systems and storages, identify owners, actual copying flows, and retention periods. The output is a map of sources with priorities: where personal data is, where trade secrets are, where official information is.
- Agreement on levels and rules. We determine how many sensitivity levels the business needs and which labels are tied to them. We coordinate the rules with lawyers and system owners so that the labeling reflects the actual requirements of regulators, not an abstract scheme.
- Policy configuration. We specify what happens with each level: who sees it, to whom it is transferred, how it is masked during export, after how long it is deleted. We tie policies to labels, not to specific folders — otherwise, when data is moved, the rules are lost.
- Automatic labeling. We configure recognition rules based on patterns, dictionaries, and context so that the label is applied when data appears, not retroactively. Ambiguous cases go to manual review rather than being labeled at random.
- Labeling testing. We run it on historical data and check completeness: how many records are labeled, how many false positives there are, what happens with new sources. We record the metric before handover — it becomes the basis for monitoring.
- Handover of documentation and regulations. We hand over the map of sources, the description of levels, the labeling rules, and operating instructions. The client's team must be able to add a new source and change a policy without us.
- Post-launch support. For the first weeks, we monitor labeling metrics and adjust the rules — new data formats almost always require additional recognition tuning.
This order produces a predictable result: labeling covers the agreed share of sources, false positives remain within acceptable limits, and the regulations live within the client's team.
Describe your sources and regulator requirements — we will come back with an assessment and a work plan.
Access policies and label-based IAM roles
A label by itself does not prohibit anything — it becomes controlling only when the identity management system reads it at the moment of a request.
In the ABAC model, the decision is made not by the user's role, but by a combination of attributes: the resource label, the department, the device type, the time.
A role in such a scheme is not a set of static permissions, but a policy anchor point where permissions are computed dynamically.
In practice, it looks like this: an analyst from the risk department gets access to a table labeled "personal data" only when their department matches the owner's label and when connecting from the corporate perimeter.
The same employee loses access if the label changes to "trade secret" — without manual intervention by an administrator. This is precisely what dynamic permissions are: they follow the classification, not an exception list that someone forgot to update.
NIST describes this approach in the ABAC model as the primary way to link classification with access control. In practice, we tie policies to resource tags in the cloud and to attributes in the directory — this allows a single policy to cover hundreds of objects.
What the team configures as part of the implementation:
- IAM roles with conditions on the resource label, rather than on its name or path
- access policies where the condition is a match between the classification label and the clearance level
- automatic inheritance of labels by child objects upon creation
- rules for reviewing permissions when a label changes: access is recalculated rather than remaining as before
- logging of every access decision, indicating the label that triggered it
- a test environment where policies are verified against a copy of the directory before rollout to production
- a regulation defining who changes the label itself and on what grounds
Such a framework closes the main problem of manual permission management: permissions stop diverging from the actual data classification. When the label changes, access changes along with it — and this is visible in the log.
Case study: how automatic labeling accelerated compliance review
What it was like before implementation
A company with a distributed infrastructure: several product teams, its own storage systems, analytical exports, and data exchange with contractors. Classification of sensitive data relied on agreements between teams and manual notes in spreadsheets.
Before a compliance review, engineers exported lists of objects, cross-checked them against the owner registry, and manually marked which were personal data, which were trade secrets, and which were anonymized datasets.
Preparation took weeks: some of the labels were already outdated by the time of the review, because new storage systems and exports had appeared in the meantime.
The cost of this approach was not only time. Without unified labeling, incidents involving leaks of sensitive data took a long time to investigate: it was unclear who owned an object, by what rules it should be stored, and who was allowed access. The class of critical incidents recurred quarter after quarter.
What was changed
We deployed automatic classification and labeling: scanners traverse storage systems on a schedule, determine the type of content by patterns and context, assign a label, and bind it to the owner and access policy.
Labels live together with the object — when copied or exported, they are carried over rather than lost. We also configured rules separately: each label has its own retention period, access scope, and encryption requirements.
Next, we linked labeling to compliance review. A report on demand is assembled from current labels rather than manual spreadsheets, and shows where rules are violated: an object without an owner, data with an expired retention period, access broader than allowed.
What the result was
Preparation for compliance review shrank from weeks to days — the report is generated from the current state of storage systems rather than data from a month ago.
The share of objects with a correct label grew from partial marking to almost full coverage, and the class of critical incidents related to access to sensitive data declined: violations are detected at the scanning stage rather than after a request.
A separate effect is predictability for teams. An engineer sees the label and understands by what rules the object lives, without exchanging messages with the owner. Incident analysis begins with ready-made context rather than with gathering information.
We built a similar approach on projects with HashiCorp Vault — the same logic applies there: access policy is tied to the object, not to agreements.
How does classification differ from labeling?
Classification is the decision about the sensitivity level: which category an object belongs to and by what rules it can be handled. Labeling is the recording of an already-made decision in the form of a tag that travels with the data.
The first answers the question "what is this and how critical is it," the second — "how is it marked and who will see it." Confusion arises because in mature systems both steps are performed by a single pipeline and from the outside look like one operation.
The difference manifests at the moment of change. The sensitivity level is revised when policy, a regulatory requirement, or the nature of the data itself changes: yesterday's anonymized dataset may today contain identifiers, and classification is obliged to reflect this.
The label, however, is a derivative: it either updates following the level, or becomes outdated and starts lying.
It is outdated labels that produce that class of incidents where a file with personal data sits quietly in a shared storage because at the time of marking it was assigned a low level and no one has revisited it since.
Terminologically, it is convenient to keep three layers. Sensitivity levels — a limited set of values such as public, internal, confidential, strict: there are few of them, they are defined by policy and change rarely.
Data labels — specific values assigned to an object: a tag in a catalog, a field in a schema, an entry in a registry. Rules — the logic that links one to the other and determines what to do upon detection: mask, encrypt, restrict access, or block export.
The practical takeaway for an engineer: classification without labeling is useless, because the decision is not recorded anywhere and is not applied automatically.
Labeling without classification is dangerous, because the label is assigned at random and creates false confidence in control.
A workable scheme is to first define the levels and the rules for assigning them, then automatically apply labels when data appears and on every change, and surface discrepancies between the declared level and the actual content in a report.
Then compliance verification relies on the state of the data, not on the memory of the person responsible.
Common technical concerns about data labeling
Data labeling doesn't hinge on the model, but on how it's integrated into the data flow and what happens with errors.
Below are the questions that most often come up during the pilot stage, when the client has already seen a demo and wants to understand what this will mean in their environment.
What about false positives — won't they block operations?
False positives can't be eliminated entirely, but their cost can be managed. The classifier is tuned to a confidence threshold: above the threshold — the label is applied automatically, below — the object goes into a queue for manual review.
The threshold is selected based on the error matrix on your corpus, not on abstract accuracy. Additionally, exception rules are introduced: number patterns, test ranges, service prefixes — they remove the bulk of the noise before it reaches people.
Will storage and production service performance degrade?
Labeling runs asynchronously, in a separate stream, and doesn't get in the way of user requests. New objects are processed as they arrive, and the accumulated array — in batches during a low-load window.
The result is written to a separate metadata index, not to the data itself, so reads and writes to storage remain unchanged. During the pilot, we take measurements before and after: response time, the share of objects processed in batch mode, queue depth.
How does this integrate with our existing storage?
We work through standard access interfaces to object storage, file shares, and databases — without exporting data outside. Labels are stored alongside the object and synchronized with the catalog.
If you already have manual labeling or labeling in another tool, we migrate it as a training set: accuracy on your data grows instead of starting from scratch.
What happens when the volume grows severalfold?
Classification scales horizontally: handlers are added to match the volume, and the queue smooths out peaks. The bottleneck is usually not the model, but the throughput of access to storage — we verify it during the pilot and build in headroom.
Rollback is also provided for: rules and thresholds are versioned, and you can revert to a previous labeling configuration.
Let's discuss your data classification task
We start the conversation not with a presentation, but with your infrastructure: where the data resides, which sources are already connected, which systems must receive the labels.
It's important for us to understand what already works and what has to be done manually — it's the manual operations that typically eat up the team's time and create the risk of errors in reporting.
Next, we structure the work in stages so that you have a clear result at every step:
- Analysis of the current landscape: data sources, storage, catalogs, accounting systems — we record what is being classified now and where labels are lost.
- Agreement on rules: which data categories are needed, by which attributes they are determined, who owns each category.
- Choosing the labeling approach: automatic determination by content, by source metadata, or a hybrid scheme — taking into account your accuracy requirements.
- A pilot on a limited data set: we check that the rules produce the expected result and don't break existing processes.
- Integration with the infrastructure: connecting to storage and the catalog, setting up the transfer of labels to the systems that use them.
- Verification and handover: reconciliation of results, documentation on the rules, training your team to work with the classifier.
- Development plan: expansion to new sources and categories without rebuilding the entire landscape.
After the analysis, you receive an estimate of timelines and scope of work, an implementation scheme, and a list of next steps — without vague wording. Describe your task and current infrastructure: we'll come back with a plan and an estimate.