Classify and Handle of Sensitive Data

Building effective control documents for sensitive data classification and handling requires balance between business need and business reality. This research advises security and risk management leaders on how to craft their control documents to achieve implementation success.

Structure Control Documents to Manage Classification Responsibilities and Handling Requirements Separately

To address the full scope of sensitive data classification and handling, it is best to have three types of documents:

• Data classification policy: This document outlines the companywide responsibilities for identifying sensitive data through classification. Many organizations include a basic framework in this top-level policy and define classification levels that must be used, but without providing specific information-handling guidance.
• Data-handling standards or guidelines: This is a living document that provides companywide guidance on how to classify data and that defines handling requirements based on data classifications. It is best to have this as a separate document from the classification policy to avoid a complex approval process every time there is a change to classification guidance or protection requirements.
• Departmental data-handling standards or guidelines (optional): If a department has special and/or unique needs, then it may, with the written approval of the legal department, create its own departmental information-handling guidelines. The format of these departmental guidelines should follow the same format as the information-handling guidelines document, and should not conflict with the information classification policy document.
  The decision whether to make data-handling documents “standards” or “guidelines” should be risk driven and consistent with business and security objectives. Keep in mind that mandatory requirements yield more consistency than discretionary ones.

Create a Basic Classification Policy

Classification is foundational to data security, but it does not protect data by itself. And so, organizations have a tendency to overload their data classification policies with security requirements without understanding the impact to business processes.
Characteristics of an effective, high-level classification policy include:

• It is short, should be only a few pages in length.
• It has no more than three to four classification levels and establishes a basis for the business to understand degrees of sensitivity.
• It is flexible, not draconian. It allows for exceptions and supports decisions that balance protection with business need.
• It avoids references to technology, departments and data types that age.

A basic classification policy should:

• Provide a rationale for the policy and link to the security policy framework and standards that are already in place within the organization.
• Describe the classification scheme.
• Make clear the responsibility and accountability of relevant roles

The fundamental idea is to provide a policy that will raise awareness in the organization and give business unit managers the ability to make conscious decisions about the protection of sensitive data.

Minimize the Number of Classifications in Your Scheme and Communicate Them Clearly

Policy complexity is a common problem during implementation, so keep the number of classifications to a minimum. In most organizations, there should be no more than three or four classifications. They typically include a public category, a sensitive or internal category, and one or two highly sensitive categories to address data such as executive communication or regulatory requirements.

Gartner client experience has demonstrated that more-complex schemes that seem to work well on paper typically do not translate into action. Nobody can figure out how to classify data because the scheme is too complex and/or it is insufficiently supported by training and documentation. Defining the scheme is one challenge; communicating it clearly for implementation is another. The categories in a scheme are typically defined to group together datasets that represent similar risks and have similar handling requirements. They tend to be described at a high level in terms of the impact to the business if that data is mishandled along with some key data examples. But that is typically not sufficient to educate or provide a reliable reference for users to consistently and accurately classify data across the organization. This high-level scheme description is adequate for your basic classification policy, but be prepared to provide more extensive guidance as part of your sensitive data-handling guidelines or as a separate procedure to make classification successful. The best methodologies to communicate what data fits in what classifications vary from organization to organization based on prevalent data sets and culture, but include:

• Reference lists of critical or representative documents and/or data types for each classification, organized by department
• A weighted scorecard that yields a classification based on aggregated risk
• Decision trees that yield a classification based on a minimal set of yes-no questions

Lists can be burdensome to maintain and can grow to be difficult to use, however. Organizations using lists should focus on key examples and documents that have a history of misclassification, and train their users to match general documents and data to the provided examples. A default classification is also desirable to ensure a minimum level of security until the data classification can be established or to simplify labelling requirements. Depending on the mission or culture of an organization, this default classification could be “public” but most often is one level above that and a variation of “internal.”

Define Standards or Guidelines for Data Handling Based on Classification

It is best not to embed these guidelines in the classification policy because they may change periodically as technologies evolve and as an organization processes mature.

Characteristics of an effective, sensitive data-handling document include:

It provides an overview of the classification definitions.

• It defines handling requirements based on classification.
• It is focused on the common set of requirements based on classification and reference exceptions rather than overloading the document with them.
• It avoids embedding requirements (in particular around labelling and encryption) that will have unmitigated negative or unknown impact to business operations.
• It covers the relevant stages of the data life cycle.
• It allows for individual business units or functions to register their own approved handling guidelines to address unique requirements.

Create a companywide handling matrix (see the sample in Table 2) for the different levels that are required. This is another area where clear communication is critical. The matrix format not only lets the reader quickly find the intersection of the situation and classification they are looking for, but also promotes a clear visual understanding of the differences in data treatment depending on classification.

Evaluate and Mitigate the Impact on Lines of Business

Data classification and handling control documents affect business processes and cannot be effectively crafted without input and buy-in from the business side of an organization. Authoring such documents under an information security governance framework or, at the very least, involving the business in assessing the impact of the policies can be extremely useful in overcoming cultural push-back from the business.
For organizations new to classification, it will take years to effect cultural change and get the business to fully respond to new classification and handling requirements. Expect the business to push back hard in the beginning, and ensure that you have top-down support or the effort will be undermined at every step of the process. A phased implementation starting with specific at-risk
datasets can help, but every organization will have unique challenges (see “How to Overcome Pitfalls in Data Classification Initiatives”). Table 3 provides examples of challenges and how they were addressed. Not all issues can be uncovered ahead of time, however. So make sure that the responsibilities — as defined in your policy — include monitoring and lead to sustainable classification processes. If classification is not happening consistently or accurately, the reasons why need to be understood. It might be, for example, that: The classification scheme is vague or not well-understood, and that more clarity, guidance or training is needed.

• The classification process is too cumbersome for users, and it should be reviewed or better supported by data classification technologies.
• Certain classifications are avoided by users because associated controls break business processes, and policy changes or additional technology support might be required.