Information Security Policies are a big part of a comprehensive cybersecurity program. This blog has its share security policy content as this is something I was heavily involved with 4 years ago. But this topic is so important to review, especially if you are just now getting started with information security policies.
I still like the 9-step IT Security creation process I wrote about, but what if we approach it as a 3-step process – before, during, and after? Does this approach work or does it leave the sections too long? I think it would be a good review of what I learned about in the process, but let's find out.
1. Before Publishing
- START WITH WHY (Rutgers has a great example).
- Don’t just copy existing official policies.
- Indicate whether a policy supersedes a previous policy.
- Make a plan to make security part of your organization culture. Have ways to enforce policy. Add security awareness activities. A policy itself isn’t enough.
- Get support from the top down, especially if you don’t have any policies. Leadership and some level of direction and enforcement are crucial. Otherwise you can waste a lot of time writing a document that no one cares about.
- Make a policy diagram to get a visual view of what you're working towards. This will help when presenting to leadership and other stakeholders.
- Identify stakeholders. Who will this policy affect? End users, IT support personnel, vendors, etc.
- Identify authorities, subject matter experts, specialists, focus groups, etc. Build rapport with these people. Chances are, you the policy writer, will lack the technical skills or specialist knowledge that goes into writing a high level document that will guide your IT efforts.
- Look for examples of good policies, even templates. Don’t just grab a template and insert your company name. [insert company name] policies are so easy to spot and will mean very little to your employees. Many protected data policies require you to have policies specific to your company and proof that not only employees have read but also a document that is being followed. Research best practices.
- Read and save copies of official policies. Referring to official regulation. Use a PDF editor or print out the official policy and highlight every “shall” word. Link to RFC for official words.
- Researching tips, Special Publications (800 Series), Googling tips, Smartbriefs, websites, example documentation, for trending topics.
- Don’t make something a requirement that you have no way of monitoring or automatically preventing.
- The most secure option isn't always the best. Meet business requirements.
2. During Drafting
- Decide on one big document or multiple documents. Meet business requirements. If there are no requirements, don't spend more than 30 minutes deciding.
- Use bullets and use proper layout and formatting.
- Write in easy to read sentences. The easier it is to write, the easier it is for everyone to read. A GISO at security conference I attended one time said his 70+document was a bear to read.
- Doing this you'll realize you can point to specific things such as license counts, network diagrams, backup reports, audits, logs, and more. Specific information shouldn't be in the policy itself, but you can point to company stance on staying abreast on these types of things.
- Establish authority by using active voice.
- Require a team effort and coordination with:
- IT staff
- Hardware and software vendor support
- Administration and IT governance
- Continual training and professional development
- Trends and best practices
- Rules and regulations
3. After Publishing
- Do the policies make sense?. Are you using the same words over and over? How's the flow and consistency?
- Are they easily accessible?
- Do the policies have legs? Have they be accepted and endorsed.
- Have a minimum annual review plan. Revision action.
- Test to see if policy is meeting expectations.
- Have a process to enforce the policy. Use walkthroughs, audits, tests, and other security health checkup techniques.
- Charter, setup, and run a security awareness program to help educate users.
- Practice scenarios and see if policy and general security program is adequate.
A Few Reminders
Security needs to be at the top of the list. Information security pros have been saying this since the 90s (it's crazy looking back at how “modern” this information security policy presentation was). However, because it's so new, many leaders may not even remember to keep security at the top of the list. You're going to need to push to make it a priority.
Everyone, from the top to the bottom of your organization, needs to understand the importance of information security. Attackers and overall risk don't go away if you ignore it.
Share your knowledge with the whole organization. Convince people to care and create materials for all employees to reference so that you can help boost a culture. Once people start getting on the program, you'll have a better time managing security threats.
The more people in your corner the better. Educate people on how they can contribute. This helps reduce the burden of work and will make overall enforcement easier and more efficient.
Finally, as you began to create momentum, don't forget to look for ways to collect metrics you can show the higher-ups. This effort has to be worth it, at least in their eyes. Report regularly on your progress and don't wait until something is complete or perfect before you present it to people. I know this little tidbit the hard way. Show leadership and everyone involved that this is important and is worth keeping up with.
So what do you think about getting started with information security policies guide? Did this work as a 3-step process? Have you had to create an information security program from nothing as I have? What did you learn?