Cybersecurity Policies Are Not Procedures, Systems, or Training

During an executive client briefing, I showed the CEO his organization’s written cybersecurity policy, which stated that all data must be stored on servers and was prohibited from being stored on local computers. Then I showed him their written policy that all data protected by regulations must be encrypted. Finally, I showed him reports from our “under the skin” network scans identifying protected data on unencrypted local PCs.

The CEO asked (with more than a little frustration), “Why aren’t our people following our policies?” I replied that I was about to ask him the same question.

It’s an important question to ask, given that three recent HIPAA penalties, each for more than $1 million, cited the failure to IMPLEMENT policies and procedures. And new Department of Defense requirements for defense contractors require proof that cybersecurity controls are being IMPLEMENTED OVER TIME.

Everyone just assumes that if they have a policy, people are properly trained and are following it. They usually find out the hard way—when something bad happens and their implementation is questioned by regulators or lawyers suing them—that they are wrong.

I’ve worked in my own business where I could implement a policy immediately. I’ve also worked for organizations where I needed multiple layers of approvals from executives and the boards, meaning that I needed to write policies that didn’t need to be revised and reapproved whenever something changed.

An easy way to understand how policies and procedures should be implemented is to understand what they are not.

•    Cybersecurity policies aren’t procedures
•    Procedures aren’t systems
•    Systems aren’t training

What Is a Policy?

A policy is a brief, simple statement defining a rule that something is either required or prohibited.

If you must comply with multiple regulations, you can increase your chances of surviving an audit or investigation, or winning a lawsuit, by having separate policy manuals for the various regulations. This extra work pays off if you are audited for compliance, investigated after a data breach or other incident, or sued based on your alleged noncompliance with a regulation. By making it easy for an auditor to quickly see that your policies use the wording, and even the sequence, on which they base their audit, you increase your chances of success. Trying to combine multiple requirements into a single policy may seem easier, but will slow down and frustrate auditors, lowering your chances of success.

Policies should be vague, and not include details like procedures and systems, which are likely to change over time. For example, “We will protect our devices against malicious software. Our chief security officer will identify the procedures and systems to be utilized and will ensure all applicable workforce members have received the proper training.”