Data Protection

🚀 As explained by Laura

Getting to Know Your Data

Identifying and protecting that which has value for your organization and your customers is at the heart of how you should approach security. For many of us, that value lies in the data we store and process.

This includes customer data, commercial IP, and company operational data. Some of this data is created by your organization and did not exist before this point. Other data is entrusted to your organization as part of the product or service that you offer. These different data types, their sensitivity, and the pathway they take through your company are all important factors to understand when planning how to protect them.

When starting to define your data protection requirements, we begin by identifying all the data within your organizational context.

Then, for each set of data, we need to gather some information to understand the data and its security requirements better. Specifically, the information detailed in the below chart.

Table: Things to Know About Your Data

As you catalog the data within an organization, it starts to become obvious that the data landscape isn’t static. Data enters the organization, is used and handled, and at some point may leave the organization again. We call this a data lifecycle, a process of stages that data passes through whilst in the custody of a company.

An Example Data Lifecycle: Snapsy

Let’s take a look at the data lifecycle for some simple data types within a hypothetical organization we’ll call Snapsy. Snapsy is a Software as a Service (SaaS) company that provides photographic printing services via their mobile application. In the diagram below, we’ve visualized how data moves through Snapsy.

Figure: The data lifecycle for data within an example organization.

On the left of our diagram, data enters our organization via two different routes:

• Data is created: User records are created when a user is registered.

• Data is collected: Images are uploaded into the application when a user chooses to get them printed.

Once the data has entered our organization, it moves to the active usage phase of its lifecycle. In this stage, the data has purpose and is being used to serve our customers and deliver our intended products and services.

In the center of our diagram, our data is used in several ways at this stage:

• Images are processed, ready for printing.

• Images are analyzed to provide metrics and statistics for the company to measure their performance.

• Images, metadata, and metrics are stored for use later in the customer’s journey or as part of the ongoing analysis and operation of the company.

• Images are shared with local printing companies so that they can be printed and shipped to the customer.

At the point where the data is shared with the local printing company, it has left the control of the SaaS company. It is no longer within our company’s ability to protect this data, as it has started a new data lifecycle within the printing company.

​danger​ We should use caution when choosing our data-sharing partners and integrations because data transitions out of our control. These organizations are trusted to protect our data as we would want it to be protected. Take your time to verify this will be the case before you get too committed. Furthermore, it’s important to think about what the implications would be for your organization, if your partner or integration was breached and the data you shared with them lost or made public. While you cannot prevent this, you must plan for this worst-case scenario.

At the right of our diagram, the data has reached the end of its useful life within our company. This could be triggered by a number of factors. These include:

• the user deleting their data or closing their account.

• the data retention period expiring

• the data is no longer relevant to the current customer or business model.

At this stage, the data will either be destroyed or archived.

Don’t Lose Track of Your Data Lifecycles

Remember that as your organization, products, and services evolve, so do the life cycles that are applied to our data.

​important​ It is important to review and update your data life cycles at regular intervals to ensure that they remain accurate and the security controls you apply to them remain appropriate to reduce the risk of data loss, destruction, or exposure.

While you may not choose to formally document your data life cycles, have a run through on a white board at least once a year or on significant business changes to ensure you have a clear understanding and an actionable plan for weaving security through them. Engage with people from around your organization to work through this. The people who interact with the data the most are often the best to help define the data life cycles.

As you carry out this process, you and your team will naturally start to form a language to describe sensitive data, whenever and wherever you find it.

​Definition​ The process of flagging specific types of data and giving it a name, label, or description that communicates its importance is known as information classification.

To get the most out of your data life cycles we need to go a little further into this important subject. With our data and the life cycles identified, it’s time to build an information classification system.

Not All Data Needs to Be Secured

You might be forgiven for dreading this section. Phrases like “information classification system” rarely spark excitement. But stay with me—let’s move past the dry language and dig into what this phrase means and why it matters to our company and its data.

The importance of this section starts with a truth: just because our organization generates, stores, or processes a piece of information, that doesn’t mean it is sensitive or needs securing.

Some of the data we handle, generate, or process poses little to no risk to our organization, no matter what we do with it. Conversely, there are data types that we encounter that can have significant impacts on our organization, our systems, or our customers—if they are mishandled.

​Definition​ An information classification system is, at its core, a way to label the data within your organization according to how sensitive it is and how much impact it would have on your organization if it were to be improperly handled or shared.

By identifying all of the data stored and handled within your context and dividing it into groups in this way, you can start to define processes and policy for how each group of data should be treated. Typically this includes how the information is used, where it is stored, who it is shared with, and how it is shared.

Once we have this structure of policy defined, we can allocate and prioritize our resources to protect the confidentiality, integrity, and availability of our most sensitive data. The more sensitive the data, the more effort and resources we need to keep it safe.

Let’s take a look at a typical information classification system and examples of the data we might expect to find in it.

Table: Common Information Classifications

Building Your Own Classification System

While these standard definitions will work for a large number of scenarios and provide a quite generic framework for understanding and communicating the sensitivity of your data, there are some cases where you may choose to define your own classification system. This custom classification system provides a way to communicate any data security or handling requirements that are unique to your organization, risk profile, or context.

Reasons you might want a custom classification system:

• Coherence and consistency. Organizations that interact with or partner with government organizations, for example, may choose to reflect the classification systems of their more regulated government partners when defining their own system. This helps create a consistent understanding of data security expectations across the two organizations and make communication of risk simpler and coherent.

• Culture. Another reason for choosing a custom classification system might be to echo or reflect other cultural patterns in your organization. If you have a strong communication style and language conventions in your organization, then echoing that language style in your security policy and process can help this process connect with the wider company and be easy to understand. Remember that the more relatable and easy to understand our language choices are, the less effort is needed to understand and comprehend its meaning. Easy to understand often means easy to action, and can be a real benefit when trying to roll out a security program.

• Increased granularity. Perhaps your organization has more complex or varied data requirements that are challenging to split into the relatively small number of classifications provided by the more traditional classification systems we explained earlier in this section. In these more complex situations you may wish to have more granular requirements or options. Remember, though, that the more complicated your system, the harder it is to implement consistently and check for issues. If choosing this path, be sure to create the “minimum viable classification system” for your needs. A smaller set of requirements and behaviors will be easier to implement, explain, and monitor.

Implementing Your New Classification System

Step 1: Label Your Data

Once 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.

Example: Strategies for Labeling Data

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.

Step 2: Define Your Data Handling Guidelines

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.

Example: Data Handling Policy per Classification Level

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

Example: A Data Handling Policy for Restricted Data

Respect the Classifications of Others

Many organizations share data with, or collect data from, customers or partners. These relationships require balance. Each party will have their own understanding of the value and sensitivity of the data, and their own expectations of how it should be handled throughout its life.

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.