Skip to main content
DataRidge
Category: Data Classification

Sensitivity Levels

Also known as: Data Sensitivity Levels, Data Classification Levels
Simply put

Sensitivity levels are labels that rank data according to how much protection it needs, so that more damaging information receives stronger controls than routine information. Organizations commonly use a small set of tiers, such as Public, Internal, Confidential, and Restricted, to guide how data should be stored, shared, and secured. The right number and names of tiers vary by organization and are a matter of internal policy rather than a single universal standard.

Formal definition

A sensitivity level is a classification value assigned to a data asset (for example a project, table, file store, or document) that expresses the degree of protection warranted, generally framed in terms of the potential impact on confidentiality, integrity, and availability if the data were exposed or compromised. In practice, schemes typically use a small ordered set of tiers, such as Public, Internal/General, Confidential, and Restricted/Highly Confidential, that map to differentiated handling, access, and security controls. Sensitivity classification is primarily a data governance construct that supports control selection; it should not be conflated with information security controls themselves, which enforce the protections that a given level implies. It is also distinct from regulatory categories: a high sensitivity level does not automatically equate to 'personal data' or 'special category / sensitive data' under a specific legal regime such as the EU GDPR or UK GDPR, and applicable classification of regulated data must be determined against the relevant instrument. This entry defines the concept only; it does not specify a mandated taxonomy, retention rules, cross-border transfer treatment, or the specific technical controls required at each tier, all of which depend on jurisdiction, sector, and implementation. Accountability under governance frameworks generally requires that assigned levels and their handling rules be documented and demonstrable, not merely stated.

Why it matters

Sensitivity levels are the connective tissue between an organization's data governance policy and the protective controls it actually applies. Without a consistent way to rank data by the degree of protection it warrants, organizations tend to over-protect routine information (adding friction and cost) while under-protecting the data whose exposure would be most damaging. A workable tiered scheme, such as Public, Internal, Confidential, and Restricted, lets teams make repeatable decisions about how data should be stored, shared, and secured, and gives auditors a reference point against which handling can be checked.

The practical value depends on the labels being applied consistently and on the handling rules being documented rather than merely assumed. Sensitivity classification is a governance construct that guides which controls to select; it does not itself enforce anything. A high sensitivity level tells you data warrants strong protection, but the confidentiality, integrity, and availability controls that deliver that protection are a separate matter of information security implementation. Organizations that treat the label as the safeguard, rather than as a trigger for safeguards, leave a gap between stated policy and actual protection.

Who it's relevant to

Information Governance and Data Stewardship Leads
Governance leads own the classification taxonomy: defining the tiers, the criteria for assigning each level, and the handling rules that attach to them. Their responsibility is to keep the scheme consistent and documented so that classification decisions are repeatable and defensible, recognizing that the label guides control selection rather than enforcing protection itself.
Information Security Teams
Security teams implement the confidentiality, integrity, and availability controls that a given sensitivity level implies. They rely on accurate classification to prioritize protective effort, but they should treat the level as a trigger for controls rather than a control in its own right. The specific technical safeguards required at each tier depend on jurisdiction, sector, and implementation and are out of scope for the classification scheme itself.
Data Protection Officers and Privacy Professionals
DPOs and privacy staff should note that sensitivity levels are distinct from regulatory categories. A high sensitivity level does not automatically equate to personal data or to special category or sensitive data under a specific legal regime such as the EU GDPR or UK GDPR. Whether data is regulated must be determined against the relevant instrument, so internal classification and legal classification should be maintained as related but separate exercises.
Compliance and Audit Functions
Compliance and audit rely on documented sensitivity levels and their handling rules as evidence that governance operates as claimed. Accountability generally requires that assigned levels be demonstrable, not merely stated, so these functions assess whether classification is applied consistently and whether the associated controls are actually in place.

Inside Sensitivity Levels

Data Classification Tiers
Sensitivity levels are typically expressed as an ordered set of tiers (for example, public, internal, confidential, and restricted) that rank data according to the potential harm from unauthorized disclosure, alteration, or loss. The exact number and labeling of tiers is an organizational choice rather than a universal standard.
Classification Criteria
Each level is defined by criteria that determine assignment, such as the nature of the data, regulatory obligations attached to it, and the impact of a compromise. Special category or sensitive personal data under regimes such as the EU or UK GDPR often maps to higher sensitivity tiers, but the sensitivity label is an internal governance construct and does not itself change the legal classification of the data.
Handling and Control Requirements
Sensitivity levels drive differentiated handling rules, including access restrictions, storage conditions, transmission controls, and disposal expectations. This is where governance classification intersects with information security controls, though the classification scheme itself is a governance artifact rather than a security control.
Ownership and Stewardship
Assigning and maintaining sensitivity levels is a stewardship responsibility, requiring named owners accountable for correct classification and periodic review. Accountability under governance frameworks requires demonstrable evidence of these decisions, not merely a stated policy.
Alignment with Frameworks
Sensitivity schemes are commonly documented within information governance policies and can be mapped to frameworks such as ISO/IEC 27701 or the NIST Privacy Framework, but no single instrument prescribes one canonical set of levels. Organizations generally tailor their scheme to their regulatory and operational context.

Common questions

Answers to the questions practitioners most commonly ask about Sensitivity Levels.

Does classifying data at a higher sensitivity level make it 'special category' or 'sensitive' data in the regulatory sense?
No. An internal sensitivity level is an organizational classification used to drive handling and control decisions; it is not the same as the legally defined categories such as special category data under the EU or UK GDPR, or sensitive personal information under the CCPA as amended by the CPRA. An organization may label commercially confidential data as highly sensitive even though it contains no personal data at all, and conversely may under-classify data that does meet a legal special category definition. The regulatory status of data is determined by the applicable instrument and its criteria, not by the label an organization assigns. Sensitivity levels should be mapped to those legal categories deliberately, but the two remain distinct.
If we apply strong encryption or tokenization to data in our highest sensitivity tier, does that remove it from scope as personal data?
No. Encryption and tokenization are security controls that generally reduce risk and may satisfy control requirements associated with a higher sensitivity level, but they do not make data non-personal. Where the data can be re-identified or restored to a readable form, whether through a key, a token vault, or other means, it typically remains personal data and remains in scope of applicable regimes. This corresponds to pseudonymization rather than anonymization. Sensitivity classification informs which controls to apply; it does not change the underlying regulatory characterization of the data.
How many sensitivity levels should we define in our scheme?
There is no universally required number; schemes commonly use a small set of tiers to keep classification usable and consistently applied. The appropriate count depends on your data landscape, regulatory obligations, and the distinct handling regimes you can actually enforce. Adding tiers that do not map to meaningfully different controls tends to create classification drift and inconsistent labeling. This entry does not prescribe a specific number or a specific control set; those should be determined against your applicable requirements and risk appetite.
Who is accountable for assigning and maintaining sensitivity levels?
Accountability generally sits with defined data governance roles, such as data owners and stewards, rather than with individual users acting ad hoc. Under most governance frameworks, accountability requires demonstrable evidence, meaning documented classification criteria, records of how data was classified, and periodic review, not merely a stated policy. Where the data is personal data, classification decisions should align with the controller's broader obligations. This entry does not assign specific statutory roles, which vary by jurisdiction and instrument.
How do sensitivity levels connect to handling rules like access, retention, and transfer?
Sensitivity levels are typically used as a bridge between classification and control, where each tier is associated with baseline handling expectations such as access restrictions, logging, and encryption. However, this entry does not cover the specifics of retention scheduling or cross-border transfer mechanics, which are governed by separate rules and, for personal data, by the applicable regime. A sensitivity level can inform those decisions but does not by itself establish lawful retention periods or a valid transfer mechanism; those must be determined under the relevant legal and policy requirements.
How should we keep sensitivity classifications accurate over time?
Classifications generally require periodic review because the sensitivity of data can change as it is combined, aggregated, or as its context shifts, and because misclassification undermines the controls that depend on it. Effective practice typically includes clear classification criteria, mechanisms to reclassify when data changes, and evidence that reviews occur, consistent with the accountability expectations of governance frameworks. This entry does not specify review intervals or tooling; those should be set according to your risk profile and obligations.

Common misconceptions

Assigning a high sensitivity level to a dataset is itself a security control that protects the data.
A sensitivity level is a governance classification that signals how data should be handled; it provides no protection on its own. Actual protection depends on the confidentiality, integrity, and availability controls implemented to enforce the requirements associated with that level. Classification and enforcement are distinct.
The highest sensitivity tier is equivalent to special category or sensitive personal data under data protection law.
Sensitivity levels are internal constructs and do not determine legal classification. Special category or sensitive data is defined by the applicable regime, and its treatment differs across the EU GDPR, UK GDPR, CCPA and CPRA, and HIPAA. Mapping such data to a high tier is common practice, but the internal label neither creates nor removes the underlying legal obligations.
Applying encryption or tokenization allows data to be moved to a lower sensitivity level because it is no longer personal.
Encryption and tokenization are protective measures and generally do not render data non-personal; the underlying data typically remains personal and, where reversible, may constitute pseudonymized rather than anonymized data. Downgrading a sensitivity level solely on this basis is generally inappropriate.

Best practices

Document the sensitivity scheme in governance policy with clear, evidence-backed criteria for assigning each level, so classification decisions are demonstrable rather than merely stated.
Assign named owners or stewards responsible for classifying, reviewing, and re-evaluating sensitivity levels as data and regulatory context change.
Map each sensitivity level to specific handling requirements covering access, storage, transmission, and disposal, and ensure corresponding security controls actually enforce those requirements.
Where higher tiers correspond to special category or sensitive personal data, confirm the mapping against the applicable regime rather than assuming a single universal definition, since treatment differs across jurisdictions.
Avoid downgrading a sensitivity level solely because encryption or tokenization has been applied, since such data typically remains personal.
Review classifications periodically and retain records of classification decisions to support accountability under governance frameworks.