In the last Back to the Basics post, we discussed starting the writing process for security policies and procedures. Once you have the initial draft completed and upper management has signed off on it, what do you do next?

Many organizations will consider it final at that point and push it to the repository where documentation goes to be stored and largely unread. Ensuring that your employees are engaged in the process or at least interested enough to open the documents is another challenge.

Announcing Policies and Procedures

Throughout our careers, we have seen some good and some not-so-good examples of how to announce policy changes to employees. The following are a few things to keep in mind when sending the official announcement of the new policy, procedure, or standard:

• Avoid Email Blasts. While writing and finalizing documentation, you should ideally be considering who the targeted audience is or at least the people side of the scope of the document. If you wrote high-level policies that are applicable to the entire company, it makes sense to send a communication to everyone. But if you want to ensure that your developers read the new SDLC policy and procedures, you should consider writing an email that is directed specifically for them.
• Give the “Why”. In some memorable cases, we have seen HR departments send out emails essentially stating new policies have been created, you have to read them, and either attach the document or give a link to where they are stored. The chances of employees actually reading the documents using this strategy are low and you should consider giving them reasons why they should take time to read these new documents. It takes a little more time on the sender’s part, but we’ve seen it result in more people reading certain documents.
• Write like you normally do. Another odd thing we have occasionally seen is personnel deciding that the policy communication email is the time to use jargon they don’t usually use or brush the dust off that Word of the Day calendar. Both tactics will result in your audience being turned off on the announcement and decrease the likelihood of them reading your documents.
• Ask for feedback. By soliciting feedback-and having an established pattern of showing your listening to that feedback-you greatly increase the likelihood that employees will read your procedural and standards documents.

Provide Training (When Necessary)

It is inevitable that when we recommend providing employees with training on new policies that people will imagine long, droll meetings where they essentially read the policy or a refresher link to the computer-based training system they’re using. While those are two options that are available, they aren’t the only methods to consider when we say training.

In order to avoid your security staff from being in back-to-back meetings or having to awkwardly present new policies to all employees alongside HR, consider having smaller, more frequent information sharing sessions. Some companies have called them lunch and learns or similar, but the general idea is that you send an open invitation to employees to bring their lunch to learn or discuss a topic. Granted, if you tell someone to spend their lunch discussing Acceptable Use attendance will probably be very low. Instead you might consider sending an email to your employees saying you’ll be discussing how to protect themselves online and use relevant policies as additional reading material.

Another way to ensure your staff is trained on the new material is to make updating your security training as part of the documentation process. For organizations that have updated their documentation, make sure that the slides, newsletters, posters, etc. that you use for security training and awareness are communicating the same thing that is in your new documentation. For organizations that are writing the policies, procedures, and standards for the first time, take time once your documents are published to create training materials that align with them.

Up Next…

The advice in this post isn’t meant to serve as a one-size-fits-all solutions, but we have seen varying degrees of success when organizations take the time to figure out which of the above tactics will work for them and then implement it. In our next “Back to the Basics” post, we will be moving away from documentation and focus on asset management.