CCSP: Cloud Data Classification Policies, Data Mapping and Labeling

Data classification is the practice of assigning every data set a sensitivity level, based on the harm its compromise would cause, so that it receives protection proportionate to that harm. A data classification policy is the document that makes this repeatable: it defines the levels, the criteria for choosing a level, the roles that decide and apply levels, and the handling requirements that each level triggers.

Classification sits in the middle of the cloud data security process. Discovery (sub-domain 2.4) finds where data is and what it contains; classification decides how sensitive it is; protection technologies such as encryption, masking, DLP and rights management (2.3 and 2.6) and retention rules (2.7) then act on the level. Classify before you protect: a control chosen without a level is a guess.

One policy for the whole organization

The same customer record is equally sensitive in a SaaS application, an IaaS virtual machine, a PaaS database or an on-premises file share. An organization therefore needs one organization-wide classification scheme applied in every cloud and data center. When separate teams each write their own scheme, the same data ends up with different levels in different places, and copying it between environments silently changes its protection. The drift comes from having several schemes, so the remedy is one scheme for the whole organization. Mapping between schemes is for exchanges with separate organizations, which keep their own (see the data mapping section).

Scope by content, not by a list of systems

A policy that lists the systems it covers (for example the CRM and the HR system) misses every other place the same data lands: caches, message queues, analytics extracts, spreadsheets exported from those systems, and test copies. Adding each newly found store to the list closes today's gap and leaves tomorrow's open. The durable scope is all data the organization holds, classified by what it contains, whatever its format or system.

What a classification policy is not

A data set's level is decided by the impact on the organization if the data were compromised, weighed across three kinds of harm and two further drivers:

• Confidentiality impact: the damage if the data were disclosed to the wrong people.
• Integrity impact: the damage if the data were altered or corrupted.
• Availability impact: the damage if the data were lost or could not be reached when needed.
• Legal, regulatory and contractual obligations: personal data, health data, cardholder data and data covered by contracts carry minimum protection duties.
• Business value: what the data is worth to the organization and to its competitors, such as trade secrets, formulas, source code and unreleased plans.

The criteria describe the content and the obligations attached to it, not the container or how the data is used. Location changes which controls are available and which laws apply, but the same data is just as sensitive wherever it sits.

Common mistakes in applying the criteria

• Confidentiality-only schemes. Public data can still be critical. Published operational data (a timetable, an outage map, a price list) has no confidentiality impact, but corrupting or losing it can cause real harm. A scheme that rates only disclosure never weighs that integrity and availability impact.
• Treating regulation as the only criterion. A law sets minimum handling for the data it covers, but it does not make that data the most harmful to lose. An unregulated trade secret whose leak would let competitors copy the main product can need a higher level than a lightly sensitive data set that a privacy law happens to cover.
• Treating criteria as checkboxes. Each criterion is a scale; the level reflects the degree of harm, judged across all of them together.

The data owner assigns and changes a data set's classification. The owner is the business role accountable for the information (for example the finance director for finance data, or the head of a clinical service for patient records) because only the business knows the data's value and the harm its loss would cause. Everyone else implements the consequences of that decision.

Two consequences follow:

• A custodian who finds mislabeled data raises it with the owner, who decides the correction through the policy's change process. Any fix the custodian makes alone, however quick, bypasses the owner's accountability.
• Tools and providers can propose or assign a level, but accountability never moves. In every service model, including SaaS services whose built-in classifiers assign labels, the customer's data owner remains accountable for the classification and must review and correct wrong levels. Contracts can give the customer remedies against a provider, but accountability for the customer's own data cannot be contracted away.

A good scheme has a small number of clearly defined levels, each with criteria and concrete examples, plus a stated default for data that has not yet been classified. Many organizations use three to five levels; the names vary, and an illustrative four-level scheme looks like this:

Too many levels defeat the purpose. When staff cannot reliably tell nine levels apart, the same type of document gets labeled several different ways. The inconsistency comes from the scheme's design, so the correction belongs in the scheme: a few well-defined levels, each with examples staff can recognise.

The default level for unclassified data

Classification never keeps pace with creation, migrations bring in large volumes of unlabeled legacy data, and owners take time to review. The policy must therefore say what level unlabeled data is treated as. The default is a trade-off:

• A very high default (treat everything as Restricted) protects regulated content but blocks ordinary work and generates exception requests at scale.
• A low default keeps data usable but leaves regulated content under-protected until someone labels it.
• A common pattern is a moderate default (such as Internal) combined with discovery that finds the regulated or highly sensitive subset and raises it, while owners work through the rest. This keeps data usable and protects the exceptions before the full review is finished.

Handling requirements are the controls the policy requires for each level: how data at that level must be encrypted and who controls the keys, where it may be stored (regions, service types, approved providers), how it may be shared and with whom, how it is transmitted, masked or displayed, and how long it is retained and how it is destroyed. A level without handling requirements tells staff how sensitive data is but not what to do about it, so a policy that defines levels, descriptions and examples but no handling rules leaves people unable to act.

When a service cannot meet a level's rules

Cloud services will sometimes fall short of a handling rule, for example a collaboration service that can store data only in a region the level's location rule does not allow. The correct response is to keep the classification as assessed and treat the shortfall as a risk decision for the data owner: the owner formally accepts the gap, with any compensating controls, or rejects the tool. Never lower a classification to fit a tool: the level describes the data's impact, and relabeling it misstates the risk and weakens every other control keyed to it. Compensating controls can reduce the risk, but they do not replace the owner's decision.

Data created by combining or transforming other data is classified at least at the level of its most sensitive input, a rule known as the high-water mark. A reporting table that joins an Internal product catalog with a Confidential customer list is Confidential. The sensitive records inside it need the same protection they had at their source, however small a share of the result they are.

Aggregation can raise the level

The high-water mark is a minimum, not a ceiling. Combining data can reveal something that no input reveals on its own, which is the aggregation problem. Two Internal data sets, such as a staff roster and a list of project code names, can together reveal which named employees are working on an unannounced acquisition, a disclosure neither source carries. The combined data set or the view that displays it must be classified on what it reveals, which can be higher than any input. Any output that presents combined data is information in its own right and needs its own level, based on what it shows.

The high-water mark is a starting level, not a permanent one

Some derivations remove sensitivity: aggregated statistics over large groups with no identifiers, or properly de-identified data. The output still starts at its source's level under the high-water mark, and then the owner can review it and approve a lower level once the review confirms the sensitive content is gone.

Data should be reclassified whenever its sensitivity changes, and at least at each scheduled review. Sensitivity is not fixed for a data set's life: a tender bid is Confidential until the contract is awarded and the bid becomes public record; a press release is Internal until its embargo lifts and Public afterwards; a data set rises in sensitivity when a new field of health, financial or identity data is added. The owner leads the review and decides the new level, and label-driven controls then follow it.

Triggers for an unscheduled review

Changes to where or how data is stored or operated, with no change to what it contains or the obligations on it, do not by themselves change its level. Scheduled reviews (for example every one or two years) are a backstop; a known event that changes sensitivity should trigger reclassification immediately rather than waiting.

Fix the label, not the controls

When encryption, DLP, rights management, masking and access policies are keyed to classification labels, an out-of-date label causes every one of them to misbehave. The label is the one input all of those controls share, so the consistent approach is for the owner to reclassify the data at its source, so that every label-driven control follows the new level.

Data mapping in CCSP covers two related jobs: translating classification between schemes and data structures so that equivalent data keeps equivalent protection, and building data maps that record what data the organization holds, where, why and under which rules.

Mapping between classification schemes

When data moves between separate organizations (partners, joint ventures, suppliers, mergers and acquisitions), each side has its own scheme. Mapping one scheme's levels to the other's ensures that data Restricted on one side receives the matching level and handling on the other.

Levels rarely line up exactly. When one side's level spans two of the other side's levels, map to the stricter candidate, so the most sensitive data the source level covers is never under-protected and the sender's classification travels with the data. Agree the mapping before data flows, ideally in the contract or data-sharing agreement.

Mapping between schemas

Migrations and integrations map fields from one data structure to another (an on-premises CRM to a SaaS CRM, one database schema to another). The classification field must be mapped like any other field. If the target structure has no matching field and the field is dropped, records arrive unlabeled and every control keyed to classification (sharing restrictions, DLP, retention, masking) treats sensitive records as unlabeled. Create a target field or label before migrating, and verify that labels survived.

Data maps: what data, where, why and under which rules

A data map is a record that links each category of data to the systems that hold and process it, the locations (cloud services, regions and countries), the purposes of processing and the regulations and contracts that apply. It underpins accountability duties such as records of processing, transfer assessments and answering data subject requests. Its subject is the organization's actual holdings and processing, rather than how components exchange data or what the scheme says.

• Every copy is a location. Backups, replicas, snapshots, disaster-recovery copies and exports are copies of the data, held physically where they are stored. If a service automatically replicates backups to a region on another continent, that region belongs in the map, and for EU personal data it triggers an assessment under the GDPR's rules on transfers to third countries (Chapter V: an adequacy decision, appropriate safeguards such as standard contractual clauses, or a narrow derogation). Provider-operated copies are still the customer's data to account for.
• Overlapping regimes all apply. When several regulations cover the same data, the map records all of them and handling must satisfy each at once. Each applies on its own terms: the GDPR's territorial scope (Article 3) covers processing in the context of a controller's or processor's establishment in the EU, and offering goods or services to, or monitoring, people in the EU, and PCI DSS applies wherever cardholder data is stored, processed or transmitted.

A label marks the data itself: classification stored in a file's or record's own metadata, a visible marking (header, footer, watermark), or a label attached to a database column or table. A tag is key-value metadata attached to a cloud resource, such as classification=confidential on a storage bucket, volume, database instance or virtual machine, so that automated policies can find and protect it.

The practical consequence: container-level tags stay with the container. A volume snapshot restored into a volume tagged internal is governed by the internal tag, whatever the source volume's tag said. Only a label carried in the data itself, in its own metadata and visible markings, keeps the level with the copy. (Some platforms also support per-object tags that are copied with the object; those behave like data labels in the sense used here.)

Label at the granularity where sensitivity differs

When one part of a structure is more sensitive than the rest, label at that level of detail. In an HR table where only the salary and bank-account columns are Restricted, column-level labels let label-driven masking and access policies protect those columns while managers keep using the rest. A coarser label forces a choice between over-protecting the whole structure and under-protecting its sensitive part.

Governing classification tags

When policies apply encryption and access automatically from a tag, whoever can edit the tag can change the protection. Governance therefore needs:

• Restricted change rights. Only data owners (or a process they approve) can change a classification tag, with the change logged. Anyone who edits a classification tag, for whatever operational reason, has in effect reclassified the data.
• Required tags enforced at creation. At cloud scale, the reliable way to guarantee every resource carries a valid tag is a preventive policy that denies creation of a resource without a tag from the allowed values. Anything that acts after creation leaves a window in which the resource exists without one.
• Content-free tag values. Tags appear in billing exports, asset inventories and management consoles that many staff can read. A tag should carry a level from the policy's allowed values (such as restricted), not a description of the contents.

Labels are applied in three ways, and a mature program combines them: automatic labeling by content, automatic labeling by context, and user labeling. The best point to apply a label is at creation, so data is never unprotected while it waits for a later scan.

Choosing between them is a matter of which signal is reliable. If content gives no signal but the location does, label by context; context labeling does not depend on reading the content at all. If neither content nor location identifies the documents, require the author to label them at creation.

Controlling downgrades

Policies usually let users raise a label freely but require a justification (logged, and sometimes approved) to lower one. Combined with automatic labeling at creation, this gives consistent labels from content and stops silent downgrades while still letting people correct a label upward.

Labels are what downstream controls consume: DLP rules, rights management templates (2.6), masking policies and retention rules (2.7) read the label. That is why labeling quality and tag governance matter as much as the scheme itself.