Skip to main content

006: Define a data classification taxonomy for the organization based on data sensitivity

Overview

Different business assets, and in particular business data assets such as documents and emails, must be handled with different levels of precaution and under specific types of controls based on their sensitivity. Sensitivity can be associated with the confidentiality, criticality and business impact of each piece of information. Identify the different categories for data sensitivity, e.g. "personal, public, external business data, internal business data, confidential, highly confidential", and work with stakeholders across the organization to identify the right level of granularity required to properly compartmentalize data. Keep in mind that this classification is not the only method that will be used to compartmentalize data, so keep it at a high level. Think of these as "buckets" of confidentiality which define the principles for handling different types of data. Once a classification taxonomy has been defined, it can be implemented through sensitivity labels which can then be applied to different assets either automatically or manually.
Work with stakeholders in the business and in IT to define the right naming convention for the labeling taxonomy. A suitable sensitivity level taxonomy must meet the following requirements:

  1. Be simple. The taxonomy can't be formed of more than two layers of classification, and each layer should not show more than six different options to a user at any given time to avoid users ignoring them or choosing without careful consideration. Project, role or team-specific labels must be scoped so they aren't displayed unnecessarily to unrelated users.
  2. Reflect the business needs. Labels must be able to accommodate the different types of data assets in the organization, dividing them by their sensitivity, while providing the required security controls for each applicable scenario.
  3. Be easily understandable. Selecting the right label names is critical for users to be able to understand them at a glance. The ordering of the labels must be obvious (e.g. don't use simultaneously terms like "confidential" and "private" since users might not know which one implies a higher level of sensitivity, use terms like "confidential" and "highly confidential" instead), and the terms used must resonate with your users' accepted language.
  4. Be stable. While it is possible to adjust sensitivity label definitions over time, such changes should be minimized, and if at all possible be limited to changes in terminology or enforcement, avoiding changes in the structure of the labeling taxonomy as much as possible.

Your label taxonomy should have one or two levels. In most cases, the top level should be used to reflect the sensitivity of the data, while a second level (sublabels) can optionally be used to specify different forms of data matching the top-level sensitivity labels that require different levels of protection (e.g. Confidential/Internal and Confidential/External both represent confidential data but with different scope of restrictions). Create and deploy labels and label policies following the defined taxonomy, but without implementing any restrictions in them. Identify (but do not enforce at this time) access restrictions related to each sensitivity level and business scenario. For example, consider whether users might have a need for copying or printing highly confidential data, whether watermarks are needed to minimize risk of oversharing, and whether specific people in your organization need access at all to the specific types of assets.

Reference