Purpose 

The purpose of this article is to provide assistance on how different regulatory agencies recommend classifying data. 

Frameworks

NIST SP 800 - 53 - 

Recommends using three categories as it pertains to each security objective within confidentiality, integrity, and availability - 

• Low Impact
• Moderate Impact
• High Impact

Recommends the use of "high watermark" when labeling media with mixed impacts. 

ISO 27001 - 

This framework does not have a specific set of requirements but instead recommends that the organization follow their own written and self directed procedures and policies. 

GDPR - 

GDPR does not provide exact recommendations for how data should be classified under an organization's stewardship. However, it does provide exact instruction that an organization should know and understand what data is being stored about citizens and how that data is being used. Therefore, we can assume that one classification standard could be: 

• Personally Identifiable Information

This is defined as: name, an identification number, location data, an online identifier, one or more factors specific to the physical, physiological, genetic, mental, economic, cultural, or social identify of the subject. Under GDPR, organization should taken inventory of their data to determine the type, how they will protect it, the categories of the subjects they are collecting information about, and the categories of any recipients of that collected data. 

Microsoft on Data Classification Frameworks - 

While Microsoft does not recommend a specific framework for classifying data, they do provide several helpful suggestions on creating a data classification framework: 

• 3 - 5 classification levels
• includes three elements - name, description, and real-world examples
• No more than 5 top level classifications
• Each top level with five sublevels

The sample list that Microsoft provided included: 

• Public
• Internal
• Confidential
• High Confidential

Microsoft also suggests documenting the control sets for each level. This might include: 

• Storage type and location
• Encryption
• Access Control
• Data destruction
• Data loss prevention
• public disclosure
• logging and tracking access

These items could be appended to each component as questionnaires with specific answers (select no to data loss prevention) importing a specific threat, risk pattern, or use case. 

Source - https://docs.microsoft.com/en-us/compliance/assurance/assurance-data-classification-and-labels

PCC DSS - 

PCI Security standards dictate that systems be classified to determine if they are in scope or out of scope for PCI DSS. Examples of data which constitute PCI DSS protected information include: 

• Card holder's name
• Service code
• Expiration data
• CVC2, CVV23, or CID value, PIN or PIN block
• contents of the card card's magnetic stripe

Generally included in scope include the systems and components which dictate and control security for systems with these asset types as well. 

Source - https://docs-prv.pcisecuritystandards.org/Guidance%20Document/PCI%20DSS%20General/Guidance-PCI-DSS-Scoping-and-Segmentation_v1_1.pdf

HIPAA - 

HIPAA does not provide exact statements on how data should be classifying data according to "levels of sensitivity". Due to this level of abstraction, a three or four tier system could be used in health care organization for classifying data. Similar to the Microsoft recommendation above, the following standard could be used:

• Restricted data
• Confidential data
• Internal data
• Public data

This article is not meant to provide legal or regulatory guidance on data classification. It is likely that each organization's legal team has established standards on data classifications. 

For assistance with creating security classifications for assets, please see the following articles: 

• How to create new security classifications
• How to create new assets