When thinking about how to properly secure your company’s systems and information, it’s easy to approach it from strictly a technical point of view. You might be worried about things like making sure systems are protected with antivirus, that you have an effective firewall protecting your network perimeter, and that your data is backed up. In the context of SOC 2 data classification, you must ask what kind of protections are you wrapping around the day-to-day handling of the data itself? How would you know if a piece of information was appropriate only for internal use or acceptable to share on the company’s public Web site?
A SOC 2 data classification policy provides a way to ensure sensitive information is handled according to the risk it poses to the organization. Through this policy, you will define how company data should be classified based on sensitivity and then create security policies appropriate to each class. There are generally three classes of data, determined by sensitivity:
Consider confidential data to be your company’s crown jewels. This is the kind of data that, if it were to get out of your hands, could cause your organization severe reputational and financial harm. Some examples include financial reports, customer databases, your CRM, a list of prospective customers, credit card information, PII/PHI or virtually anything that provides your business with a strategic advantage. To say this another way, confidential data is often what companies use as the focal point for building out the rest of their administrative, physical and technical controls.
Internal data is information that would cause moderate risk or harm to the company if it was leaked. Examples of internal data would be encryption keys, API keys, company policies and handbooks, root passwords and other administrative credentials.
One way to think of public data is any information that would be included on your corporate Web site. Essentially, there is no consequence if public data is leaked because it’s already intended to be shared with the public. Other examples of public data include store hours, brochures, press releases and sales slicks.
Some organizations might use the “Confidential” label for data that could affect operations (such as vendor contracts and employee reviews) and create a fourth category called “Restricted” for credit card information, IP, PHI, etc. Regardless of what category scheme you choose, aim to keep it simple so that making category decisions is as straightforward as possible for your SOC 2 data classification policy. Creating too many options will ultimately frustrate your users and increase the risk of data being labeled inappropriately.
Once the data has been classified, begin applying the classifications to some internal data. One easy place to start is your company handbook or binder of policies. Edit the policies to include an “Internal” label that is visible. Continue sifting through other company documentation and make sure you have labeled some examples of each classification type.
Next, train existing employees on how to properly handle each type of data class, using the information you’ve already labeled as examples. Developing a few training modules called “How to classify data” and “How to handle each type of data class” might be appropriate. At the same time, you will want to document this training to benefit your future hires as well.
As you get momentum in this process, you will likely find that you can easily categorize some information, but need to involve other business units to make classification decisions about other data. Some questions that can help guide you:
- Where is this data located?
- Who is responsible for backing it up and enforcing access permissions?
- Who can speak to the sensitivity of the data?
- What department budgets for the expenses associated with collecting, storing and processing the information?
To keep this effort a bit easier for everyone involved, leverage tools to help automate and streamline the classification process. These tools typically analyze and categorize data based on predetermined parameters and can process large data sets quickly. You can also add your own rules to classify data based on sensitivity. Once the classifications efforts are complete, review them on a yearly basis to certify they are still accurate. And remember to update your procedures around handling data sets if you change their classification.
A SOC 2 data classification policy is a critical policy. You will lean heavily on it as you build proper data security practices. You first need to take inventory of your data so you know where it lives and how sensitive it is and then label it properly so it is controlled appropriately.