How to Draft a Useful Data Security Policy

Data security plans are hardly a one size fits all proposition – but they do follow these three broad guidelines and cover a list of considerations. A consultant colleague recently reached out with some questions on how to craft a good organizational information security policy. I’ve got experience with this, as a graduate-level legal instructor, a lawyer, and someone who frequently talks to communications technology practitioners. I can offer guidance on how to plan for, implement and manage organizational information security policies. But note that I am not offering a guarantee. That’s not an accident. I am, after all, a lawyer.

Cybersecurity plans are hardly a one size fits all proposition. In fact, most entities should consider, at the most basic level, three different but loosely connected plans that can be implemented as soon as a circumstance presents itself. At a minimum, these would include a cyber security plan, an incident management plan and a disaster recovery plan. Each serves its own distinct purpose, and each must be the result of careful planning and deployment and implementation. But given the risks associated with getting it wrong, all should have some at least loose connections. Stopping the bleeding is always the first step, but a step-by-step plan for recovery is next. Not surprisingly, many enterprises are requiring various flavors of data/internet security, incident recovery and disaster recovery plans to be in place before even considering working with other enterprise partners. Given the vast quantities of data that most enterprises use and retain, and given the increasing sophistication of those who are trying to gain unauthorized access to such data, having these policies in place is simply a requirement of doing business these days.

Let’s start with the fundamentals:

At the most basic level, it is critical to recognize that definitions matter. It’s tough to know when a breach occurs if and when you don’t know specifically how an enterprise entity constitutes a breach. As an example, here are nine examples of what could—and probably should—constitute a data breach, recognizing that there could be others:

1. Denial of service
2. Changes to system software or firmware
3. Ransomware
4. Exfiltration of data
5. Theft or loss of equipment
6. Exposure of private data
7. Misuse of private data (or use of data for unintended purposes)
8. Accidental exposure of private data
9. Successful hacking, social engineering, phishing, or other scenarios where PII is exposed.

Your enterprise may have other specific categories of data and/or potential vulnerabilities that should be added to this list. Further, “breach” is only one key cyber issue to be defined before—rather than after it’s too late—a problem occurs. Another key consideration in any enterprise partnership either as peers or vendors/customers must be careful evaluation of the policies and actual practices of outside vendors who have access to inside information is another absolute requirement. 

In order to be most effective, careful definition of these breach elements, along with the definitions of other key concerns should involve multiple players from inside (and outside) the enterprise. When you have conversations to identify and address vulnerabilities, be sure to include IT personnel, and knowledgeable participants from risk management and legal departments, among others as circumstances and enterprise obligations warrant.

It is also imperative to consider the nature of the enterprise that the security, incident management and disaster recovery plans are designed to address. Be aware that rigorous requirements around storing and accessing personally identifiable information (PII) may also apply to any backup and recovery plans. FINRA and HIPAA are two examples of well-known laws that mandate compliance. 

Once plans are drafted, approved, adopted and implemented, they must be tested. Not just on Day #1, but throughout the lifespan of the policies. Testing should be routine, systematic, and occasionally random, just to make sure that the policies hold up under controlled circumstances—as well as those that are less-controlled. Think fire drill.

Then there’s the tabletop exercise. This was a new buzzword for me, but what it means—at least in this context—is a walk-through of a realistic cyber-incident and the response from each team affected by the incident. Tabletops should be standard procedure. These exercises just keep everyone involved not only aware of the ongoing challenges, but paying attention as well. And “aware” and “paying attention” are not the same thing.

In addition, policies must be living, breathing documents that can be modified to reflect changes in circumstance. Those trying to access data and systems and processes for those which they have no authority have become increasingly creative, aggressive and brazen as they seek to infiltrate enterprise data and processes. As such, the game of cybersecurity “Whack-a-Mole” absolutely requires that all existing policies related to data security, incident response and disaster recovery be adaptable quickly as circumstances change. The right people still need to be involved from different segments of the enterprise, and they need to have the knowledge and be sufficiently nimble to react quickly as circumstances warrant.

Effective policies designed to protect organizations must be sufficiently flexible and accommodating to respond when unanticipated challenges to data security and policy and practice implementation warrant. Ongoing preparation, system testing and outcome validation, followed by post-game analysis are essential in order to minimize risk at all levels of the enterprise.

As one industry expert said to me, “it’s not if a breach happens, it’s when.”

Originally published on February 14, 2024 in No Jitter