Data Handling Policy

In Stage 1, you were instructed to audit your organization’s data and classify it according to sensitivity. That was the first step of a two step process that involves classifying organizational data and developing a policy for how said data should be handled. This documentation will outline the second part of that equation.

A Data Handling Policy should be a simple, straightforward guide on how different types of data present in your organization should be handled, stored, and transmitted. It should define who exactly should be able to do these things, as well as what security controls should be applied to different pieces and categories of data.

As opposed to other organizational cybersecurity policies, the Data Handling Policy should not be shared publicly. Instead, you should distribute it only to the appropriate employees and generally keep it as an “internal” piece of data. This is because a good Data Handling Policy will include details on the storage and processing of organizational data. Airing this information publicly could give attackers a blueprint for targeting your organization.

Major components of a Data Handling Policy include:

Data Storage Requirements: different classifications of data will likely require different storage. For example, your organization’s QuickBooks files contain detailed financial information about your company. It would be risky to allow your finance employees to store these files locally. Therefore you could state in your Data Handling Policy that all QuickBooks files will be stored on encrypted network drives and are only to be accessed by approved employees as defined in applied access controls.

User & Device Permissions: there is never a scenario where every employee should be able to access every category of data. However without clearly defined privileges, it is likely that privilege creep will occur and employees will find themselves with access to data that they shouldn’t have. By clearly stating what users, groups, and devices should have access to what data, you can reduce the chances of this happening. This is why Role Based Access Control (RBAC) is the recommended form of access control in today’s organizations; it is easy to clearly define roles and associated privileges based on their function in the organization. However it is likely that you will use different forms of access control for different data. In that case, you will need to tailor access restrictions to that access control’s formatting.

Encryption Requirements: encrypting data at all stages of its lifecycle is recommended in today’s digital landscape. Luckily more and more methods and services are being implemented into everyday technologies to aid with encryption. The Data Handling Policy is an opportunity to define which pieces of data must undergo which forms of encryption. For example, the policy may specify that all restricted data must be stored on encrypted network drives with encrypted backups stored offline. It could also specify requirements for encrypting certain pieces of data with Windows Encrypting File System, as well as email encryption standards.

Consequences of Non-Compliance: the Data Handling Policy should constantly reinforce the necessity of adhering to the data governance requirements. Each section whether it be on storage regulations, encryption requirements, or access controls must clearly define why it is necessary for organizational security. TO further drive this home, it is important to highlight the consequences of non-compliance, both accidental and intentional. It is important to not come across as threatening to your employees, while at the same time driving home the necessity of complying with the policy.

---

Example Policy