Protecting data is about more than making backups and managing access. It involves an ever-evolving set of tools and techniques. The best way to make sure that all data is secure is to develop a specific policy to apply to any data your company collects or processes.
A data security policy aims to protect your assets from internal and external threats. It must state your objectives, and the rules and processes that your organization must follow in order to achieve them. Without a data security policy, you move forward blindly.
Data protection policy vs. Data security policy
While the terms are sometimes used interchangeably, there are some differences between data protection and data security. Data protection often refers to ensuring the integrity and availability of data. This could be through backups, access limits, and resilience measures.
Data security on the other hand is about protecting data from intentional threats. In addition, unlike a data protection policy that might be a single document, data security policies often contain multiple assets that work together to make up the policy—more on what those are shortly.
Data protection sometimes includes data security in some organizations, but it may not be the case in all instances. For this article, we’ll focus on how to create a policy for securing data. With that in mind, let’s look at the first step.
State your objectives
A policy should start by stating its objectives. This sets the tone and expectations for the policy. It also acts as guidance in instances where a future unknown may emerge.
Data security focuses on three main objectives:
- Confidentiality: only individuals with authorization can access data.
- Integrity: data must stay intact, accurate, and complete.
- Availability: users should be able to access information or systems when needed.
This security model (CIA), can serve to answer questions, as well as guide future decisions. If you’re organizing your policy in an internal knowledge base, this is a great jumping off point to set the tone of your organization’s data security efforts.
Create your data taxonomy
Data taxonomy is the classification of data into categories and sub-categories. Classifying the data you process aims to:
- Protect important data, and avoid needless security measures for unimportant data.
- Ensure sensitive data cannot be accessed by anyone.
Classification methods vary from one company to another according to the type of data they process and the regulations they are subject to. You can use the following criteria to create your own data categories:
- Data type. Describe the nature of data being processed (e.g., personal or health data).
- Data subject. Describe the individual whose data is being processed (e.g., customer or employee data)
- Access. Describe the level of accessibility (e.g., Public, Internal or Restricted).
- Risk level. Describe the risk level in line with your risk register (see below).
For instance:
Knowing the type of data and the data subject can make it much easier to determine the risk level and access rights. For example, sensitive data like PHI will certainly have a higher risk level than more generalized data.
To incorporate this taxonomy into your policy, create examples of common data types, your organization’s subjects, and the scale you use to assess risk. This enables anyone to easily map the taxonomy when new data processing happens.
Create your risk register
Risk registers help you create an inventory of potential risk events so you can identify the appropriate mitigation measures.
Your risk register should include:
- Risk description. Describe the measured risk and how it threatens the organization.
- Cause. The event or trigger that causes the risk to happen.
- Likelihood. How probable the risk is to happen to your company
- Impact. The impact your organization faces if the risk occurs.
For instance:
We recommend creating a table or database to house your risk register. This can be as simple as a table in Notion, Airtable, or even a standard spreadsheet.
Define security controls
Using the information you’ve gathered in the previous sections, you can now define the specifics. Security controls are mitigation measures included in your data taxonomy and risk register that describe the actions the security team must carry out to mitigate the risks you identified.
For instance:
Security controls should be specific and clearly define mitigation techniques for all potential risks. In addition to improving your preparedness and security posture, thorough controls are a requirement of many security frameworks and regulations.
Define roles and responsibilities
Finally, ensure that someone is responsible for ownership and upkeep. Define owners, their scope, and the tasks they must carry out. A good practice is to appoint Product Managers and / or Lead Developers to the scope of applications that they are building.
Their responsibilities should include:
- Identifying and documenting the processing of sensitive data (following your data taxonomy).
- Making sure that business purpose is in line with the legal framework (with Legal support).
- Making sure that data security controls are implemented (with Security support).
Product Managers are responsible for these it at the design phase, before Lead Developers take over at the development phase.
Review and iteration
We’ve discussed the basics of establishing a data security policy. State the objectives, create a data taxonomy, create a risk register, define the security controls, and assign roles and responsibilities. It’s important to remember that this isn’t a set-and-forget policy. As your company changes, regulations update, new vulnerabilities are discovered, and new data is collected, you should make sure to revisit and amend the data security policy as necessary.
It’s a lot to keep track of, but that’s where Bearer can help. Our platform helps your team identify risks and detect when policies haven’t been met—or worse, are missing entirely. Book a demo to learn more about how we can help improve your data security efforts.
