Developing your Data Security Policy

Data security is a philosophy. To protect against breaches, you have to make data security part of your core values and live those values every day. And for that, you require a Data Security Policy (DSP) that everyone can access. Data security policies help to balance the three main elements of security:

• Confidentiality: Sensitive information must be safe from prying eyes.
• Integrity: Data must be free from corruption or loss.
• Availability: Data must always be available for legitimate business purposes

These elements, known as the CIA triad, are sometimes in competition with each other, but a strong DSP will help you find balance.

How to Write a Data Security Policy

Data security policy (or DSP) documents are often written in dense legal language, usually in the hope that they might help limit the organization’s liability in the event of a breach. However, ignorance or a lack of understanding of your company’s data security policy doesn’t constitute a legal defense in the event of a breach.

Instead, it’s usually better to write a DSP in plain language that most people can understand. Doing so means that the DSP document acts as a useful guide for employees, customers and partners, helping them understand how to keep data safe.

Your DSP document will generally include the following sections:

• Purpose: Your main goals, which helps readers understand the spirit of the law. Examples of such goals are: protect customer confidentiality; safeguard business reputation; comply with relevant laws; proactively work to minimize the risk of breaches.
• Scope: What does the DSP cover? The section will explicitly scope in sensitive data such as PII and classified information. It’s also useful to scope out certain things, such as publicly available information and non-sensitive data.
• Data classification: An overview of how you classify data, ranging from Public to Highly Sensitive. We’ll look at this in more depth in chapter 4.
• Physical security policy: Standards for keeping physical devices safe, which includes entry to the office building as well as transportation of electronic devices.
• Access Control Policy: Rules about who may access data and how.
• Cloud adoption policy: Guidelines on implementing cloud-based systems, including data warehouses and ETL.
• Remote access policy: Outline the requirements for external access to local systems.
• Change management policy: The process for deploying new systems or procedures, such as minimum documentation requirements.
• Business continuity and disaster response plans: A plan for what happens in the event of a disaster or catastrophic failure.
• Technical guidelines: The DSP may outline specific technical standards for the organization. This can include things such as:
  • Confidentiality: Sensitive information must be safe from prying eyes.
  • Integrity: Data must be free from corruption or loss.
  • Availability: Data must always be available for legitimate business purposes
• Reporting and oversight: The DSP will outline an internal audit process to ensure that all systems meet the agreed requirements. Any issues will go back to a specified authority, such as the data governance team.
• Update procedure: A Data Security Policy is a living document that grows with the organization. You’ll need an established process to review and update the DSP to keep up with new technology and stay abreast of new threats.

Data Security Policy checklist

A data security policy can’t cover every eventuality. Instead, the goal is to create a framework that offers guidance when someone needs to make a decision about your organization’s data. Here is a checklist of questions to help establish if your document meets standards.

Have you clarified the DSP with all major stakeholders, including your executive team, I.T., H.R. and compliance?	Have you clarified the DSP with all major stakeholders, including your executive team, I.T., H.R. and compliance?
Is the document written in clear language?	Is the document written in clear language?
Have you outlined your primary data security goals?	Have you outlined your primary data security goals?
Do your policies accord with all compliance requirements? (see chapter 3)	Do your policies accord with all compliance requirements? (see chapter 3)
Have you categorized data according to sensitivity? (see chapter 4)	Have you categorized data according to sensitivity? (see chapter 4)

Once you have answered these questions, you’re ready to publish your security policy. It’s good practice to try to engage people in conversation about the policy, using channels such as eLearning tools or discussion seminars.