editione1.0.0
Updated October 9, 2023Once you have defined your classification levels, you need to find all data of each type and ensure that it is labeled correctly to communicate its sensitivity.
Figure: The first step in implementing a classification system is to find, classify, and label your data.
Now, let’s not get literal here. Nobody needs your young company to have “top secret” messages at the top of every document, and only Tom Cruise movies need to blow up their documents when they’ve been read.
When we talk about labeling our data, what we really mean is to make it simple for people to understand how sensitive data is when they are interacting with it. There are a range of approaches to labeling your data. You’ll find some of the most common ones in the table below.
| Labeling Strategy | Description | Example Use Case |
|---|---|---|
| File Names | Include the classification in the name of the file. | myfile_confidential.txt |
| Folder Names | Sort and store your files according to their sensitivity and label the folder with the appropriate classification level. | myfolder_confidential/file1.txt myfolder_confidential/file2.txt myfolder_confidential/file3.txt |
| Color Coding | Using color to signify classification in documents or artifacts | |
| Labels and Tagging | Including keywords or tags in file, page or artifact metadata. (In this case, metadata is the data stored about the file such as the size, date created and theme, rather than the contents of the file itself) | Myfile.txt Size: 25 MB Keywords: confidential |
| Storage Location | Dedicating entire data stores such as databases, shared drives or filestores to a specific classification of data. | C://CompanyPublic D://Company Confidential |
Once you have decided on a labeling strategy, there are a couple of important steps you need to take to make sure it sticks:
Make sure everyone understands your new systems. Your team can’t follow your new system if they don’t know why they are doing it or what it means. Keep it simple, communicate it well, and model the behaviors you expect to see. How you communicate this will depend on your team’s style. Whether you should roll out a poster or a specific meme in slack—the key is to catch people’s attention, make it easy to digest, and almost impossible not to follow. Embedding this message when a new person joins the team can also go a long way to making sure people understand your systems from day one.
Automate labeling wherever possible. While not always possible, remember that the system you don’t have to remember to operate is often the most effective. It’s OK to make things easier for yourself and create automations or configurations that make this and other repetitive tasks easier.
So you know where all of the data is within your organization and you have labeled it all. Fantastic! You can’t stop now, though—it’s time to define what these labels mean.
When we defined our classification system, we described the sensitivity of the data and how it would impact our company, systems, or customers if it were mishandled, but that isn’t the whole picture.
To move from conscious understanding of the risk posed by our data to protecting it from harm, we need to look at the steps we will take to reduce this risk. In the case of data classification, this is the creation of our data handling guidelines.
Data handling guidelines explicitly state the ways in which data can and cannot be treated. When deciding your guidelines, consider these elements:
Storage: Where will you keep your data, and for how long?
Access: Who can touch the data, and what can they do with it?
Purpose: Why do you have this data?
Sharing: Who outside of your organization might need access to the data, and how will you share it?
Transport: How will you move data around, whether internally or externally?
Destruction: When you don’t need this data anymore, how will you dispose of it?
When implementing your data classification system, it is important to articulate any specific requirements or policy governing these data handling elements, and then implement processes and technologies that turn these policies into repeatable actions from your team and systems.
As information classification systems exist to focus our attention on that data that poses the most risk, it therefore follows that the higher the classification, the higher the risk, and the more policy and process will be needed to keep the data safe and secure.
| Classification | Storage | Access | Purpose | Sharing | Transport | Destruction |
|---|---|---|---|---|---|---|
| Public Example: Public marketing materials | Can be stored anywhere on the company filestore for as long as they are needed. | All team members can access. Marketing team members can edit. | To support the sales process and customer success. | Can be shared externally with all potential customers, investors or interested parties. | Can be shared by email or online via website. | No special requirements. |
| Internal Example: Internal operating procedures | Can be stored in the company shared drive for as long as they are needed. | All team members can access and most can suggest edits. Documents have an owner. | To share how common business actions are carried out. | Can be shared between all team members. Can only be shared externally with prior permission. | Can be shared by email. | No special requirements. |
| Restricted Example: Customer analytics and metrics | Can be stored in a specific directory for the period they are needed or as per customer contract requirements. | Only team members with a specific business need may access. Specific permissions are needed to update or edit. | To understand customer satisfaction, company performance or behaviors. | Can be shared with other authorized team members. Not to be shared externally. | Cannot be transported without prior approval and the removal of identifying or sensitive information. Must be sent over an encrypted connection. | Data must be destroyed in line with customer requirements and contracts. |
| Confidential Example: Customer data | Can be stored only in specific customer data environment which is defined by customer contract and operating policy. | Only limited team members with authorization may access for a limited time period. Data must not be edited or changed without written permission and creation of suitable audit logs. | To serve the customers needs and supply your product or service. | Access requires written approval from the system owner. Data cannot be shared without explicit customer consent. | Cannot be transported without prior approval from the customer and adherence to their data handling requirements. Must be sent over an encrypted connection. | Data must be destroyed in line with customer requirements and contracts. |
Now that we have defined our expectations for each classification level in the form of our policy, we need to turn these expectations into actions, processes, and procedures that can be followed, implemented, or automated consistently across the business.
important The further from policy towards technology we move with our implementation, the more you may need to get assistance from your technology service provider or technical team members. Your role is to define the policy and expectation, and then find the right people to make your policy into an actionable reality.
Let’s take a look at one of the classification levels above as an example and a possible data handling policy:
Classification: Restricted
Example: Customer analytics and metrics
Purpose: To understand customer satisfaction, company performance, or behaviors
| Policy | Process | Technology | |
|---|---|---|---|
| Storage | Can be stored in a specific directory for the period they are needed or as per customer contract requirements. | Communicate with your team and tell them where this data type should be stored. Provide a simple mechanism for getting help if unsure about data storage or if they spot data that seems mishandled. | Create a specific folder for the storage of analytics and metrics. If choosing an analytics platform or online tool, review their data storage policy, configuration options and retention settings. |
| Access | Only team members with a specific business need may access. Specific permissions are needed to update or edit. | Deny access by default—if a team member needs access they must request it and that request must be recorded (for example in a service ticket, email or other document). Review access annually or on significant change to business or team. | Restrict access to only those team members with prior approval. Consider group based permissions to simplify and improve consistency. For online tools, choose a tool that implements single sign on or has a fine grain permissions scheme that can be used to meet these requirements. |
| Sharing | Can be shared with other authorized team members. Not to be shared externally. | Educate your team on how to safely share data and why it’s important that some data is not shared. Review customer contracts to ensure they have explicit definitions around data sharing, storage and retention. Review sharing regularly to ensure data is only shared for the period it needs to be shared. | Restrict data sharing to prevent sharing outside of the team, names of individuals or organizations—this could be in tool configuration or as part of your identity and access management system. |
| Transport | Cannot be transported without prior approval and the removal of identifying or sensitive information. Must be sent over an encrypted connection. | Educate your team on how to send data of this kind safely. For engineering teams, define a standard or design pattern for data transport security. | Configure all tools and systems to use an encrypted connection such as HTTPS or SFTP. Restrict outbound and inbound traffic to company systems or networks to only allow authorized connections to specified systems. Implement monitoring and alerting to identify unusual data transportation, sharing, or connectivity patterns. |
| Destruction | Data must be destroyed in line with customer requirements and contracts. | Define a process where team members can request the destruction of data and this request is recorded. | Use a secure data destruction tool to ensure disks are sufficiently clean when decommissioned. |
While you may have defined a classification system for information when it is stored and processed within your organization, you also need to understand the expected classification and requirements imposed on you by your partners or customers.
In some cases, particularly when dealing with larger organizations or government departments, these inherited or expected classification systems or expectations may be much more formal than your own.
To make these relationships successful (and safe):
Communicate clearly with your partners when establishing this relationship to understand these requirements and translate them into a language and approach that works within your organization.
Ensure in return that any differences in your systems or approaches are communicated to your partners so that they can understand and assess any risk that arises from this situation.
With classification settled, let’s look at how to ensure security is a key part of your software development process.