This is part of an ongoing series on documentation development. Please be sure to read the previous posts in this series.
Part 1 , Part 2 , Part 3 , Part 4 , Part 5
Knowing Your Audience
A natural human behavior is assuming that the majority of the world’s people are similar to us; similar in thoughts, assumptions, knowledge, opinions etc. Psychologists may see this as the consensus effect, a form of cognitive bias. If you love ballet, you likely assume that far more people also like it than actually do.
What does this have to do with documentation?
When creating the various types of documentation, it is important to know your audience and understand their comprehension of the topic. In many cases, things that are second nature to you will be completely foreign to the majority of the world. If you are reading this, chances are you know what https means, but there are many people who only know that it sometimes goes in front of a web address, if they even know that.
For general distribution documentation, including companywide policies, you generally want to stay around a fifth grade reading level. (If you want to know why, fire up your favorite search engine and enter “reading comprehension levels of college graduates.”) Of course, nothing is ever that easy, because on the other side of the coin you want to make sure that you aren’t talking down to certain audiences. If you are creating a highly technical specification to be used solely by engineers, you can leave out the explanations of basic math.
Also keep in mind that the same word or abbreviation can have multiple meaning to multiple audiences. DC? To tech folks, that is the datacenter. If you work in a warehouse, it is the distribution center. Electricians will take it as Direct Current. To generation Y, DC is a shoe company, and to their parents it is a comic book company. DC is also shorthand for the District of Columbia. The list could go on and on, and that is just one example. So be certain to explain any abbreviations or acronyms the first time you use them within each document.
We must also consider not just denotation, but also connotation, especially in view of the vast range of connotations a general audience may have. The right amount of detail is essential. This becomes even more important when users may not be native speakers of English.
Writing to the correct audience is one of the most important elements of creating effective documentation. If the documentation is too technical for the audience, they will not understand it and likely not read it. Conversely, if the documentation is too simple for the audience, they may skim over important points.
In the next installment, we will discuss some of the intricacies of language. Should you read it, or must you read it?
Read more!
Showing posts with label Policies. Show all posts
Showing posts with label Policies. Show all posts
Tuesday, September 7, 2010
Monday, August 30, 2010
Information Security Policies and Procedures, Part 5
This is part of an ongoing series on documentation development. Please be sure to read the previous posts in this series.
Part 1 , Part 2 , Part 3 , Part 4 , Part 6
In this installment, we will discuss fonts, and then move on to additional structural elements necessary in documentation, starting with policies.
Does the font matter? Certainly. As I mentioned in a previous post, if your organization has a corporate style guide, the font and document layout is likely already determined. However, if you are blazing a trail through the documentation, you will need to choose a font. If you are planning on distributing hard copies of your documents, a Serif font is easiest on the eyes. For documentation meant to be viewed on a monitor, a Sans Serif font is best. Of course, rare is the document that is viewed in one format only. Lucky for us, Microsoft has come up with a font designed to be easy to read both on screen and when printed; this font is Calibri.
Side Note: Serif? Sans Serif? Seriously? For those of you who are not familiar with typography, serif fonts are those with serifs, the little embellishments on the letters. Think Times New Roman. Sans Serif, as students of French will note, are fonts without serifs. Perhaps the best known example, at least to a generation raised with computers, is Arial. If you have any confusion, type a few letters in Arial and Times New Roman and compare them side by side. (In case you don’t think typography is cool, read Steve Jobs’ 1995 commencement address to Stanford “I decided to take a calligraphy class to learn how to do this. I learned about serif and san serif typefaces, about varying the amount of space between different letter combinations, about what makes great typography great. It was beautiful, historical, artistically subtle in a way that science can’t capture, and I found it fascinating.”) So when you refer to your documentation as a work of art, Mr. Jobs may concur.
Before we get too far down the road into typography (kerning anyone?), let’s move on to some additional structural elements necessary in documentation, starting with policies. In addition to the elements discussed in previous posts, policies need a few standard sections.
These sections include purpose, scope, policy details, and enforcement. You may also wish to include a section with definitions or relevant standards/laws.
The purpose section should include information about why the policy is necessary. You may also wish to add some information about how the issue was dealt with historically. It is also a great place to reiterate some company values. An example is “To ensure compliance with (regulation) and create a more secure environment, this company has implemented this policy…“ Some policies will require a paragraph to get the point across, while others may only need a line or two.
The scope is generally fairly straightforward. To whom does the policy apply? Employees? Contractors? Visitors? To what facilities does this policy apply? To what systems? And so on and so forth.
The policy details section is one into which we will take a much deeper dive in a future post. For now, just know that this section enumerates the rules of the policy. It may also refer to related procedures.
The Enforcement section is where you outline the consequences for non compliance. Is it up to and including termination? A written warning? Be sure to involve HR and Legal in this part.
As we continue in this series, we will expound on each of these areas. Hopefully by now you are feeling more comfortable with documentation development. Please feel free to email me any questions or ask them in the comments section below.
In the next installment, we will discuss knowing your audience.
Read more!
Part 1 , Part 2 , Part 3 , Part 4 , Part 6
In this installment, we will discuss fonts, and then move on to additional structural elements necessary in documentation, starting with policies.
Does the font matter? Certainly. As I mentioned in a previous post, if your organization has a corporate style guide, the font and document layout is likely already determined. However, if you are blazing a trail through the documentation, you will need to choose a font. If you are planning on distributing hard copies of your documents, a Serif font is easiest on the eyes. For documentation meant to be viewed on a monitor, a Sans Serif font is best. Of course, rare is the document that is viewed in one format only. Lucky for us, Microsoft has come up with a font designed to be easy to read both on screen and when printed; this font is Calibri.
Side Note: Serif? Sans Serif? Seriously? For those of you who are not familiar with typography, serif fonts are those with serifs, the little embellishments on the letters. Think Times New Roman. Sans Serif, as students of French will note, are fonts without serifs. Perhaps the best known example, at least to a generation raised with computers, is Arial. If you have any confusion, type a few letters in Arial and Times New Roman and compare them side by side. (In case you don’t think typography is cool, read Steve Jobs’ 1995 commencement address to Stanford “I decided to take a calligraphy class to learn how to do this. I learned about serif and san serif typefaces, about varying the amount of space between different letter combinations, about what makes great typography great. It was beautiful, historical, artistically subtle in a way that science can’t capture, and I found it fascinating.”) So when you refer to your documentation as a work of art, Mr. Jobs may concur.
Before we get too far down the road into typography (kerning anyone?), let’s move on to some additional structural elements necessary in documentation, starting with policies. In addition to the elements discussed in previous posts, policies need a few standard sections.
These sections include purpose, scope, policy details, and enforcement. You may also wish to include a section with definitions or relevant standards/laws.
The purpose section should include information about why the policy is necessary. You may also wish to add some information about how the issue was dealt with historically. It is also a great place to reiterate some company values. An example is “To ensure compliance with (regulation) and create a more secure environment, this company has implemented this policy…“ Some policies will require a paragraph to get the point across, while others may only need a line or two.
The scope is generally fairly straightforward. To whom does the policy apply? Employees? Contractors? Visitors? To what facilities does this policy apply? To what systems? And so on and so forth.
The policy details section is one into which we will take a much deeper dive in a future post. For now, just know that this section enumerates the rules of the policy. It may also refer to related procedures.
The Enforcement section is where you outline the consequences for non compliance. Is it up to and including termination? A written warning? Be sure to involve HR and Legal in this part.
As we continue in this series, we will expound on each of these areas. Hopefully by now you are feeling more comfortable with documentation development. Please feel free to email me any questions or ask them in the comments section below.
In the next installment, we will discuss knowing your audience.
Read more!
Tuesday, August 17, 2010
Information Security Policies and Procedures, Part 3
This is part of an ongoing series on documentation development. Please be sure to read the previous posts in this series.
Part 1 , Part 2 , Part 4 , Part 5 , Part 6
While we are still at the beginning stages of preparing to develop policies, procedures, and related documentation, it is important to mention a few things not to do.
Do Not Repurpose/Borrow the Work of Others
Search engines are great, and place a vast body of human knowledge at your fingertips. This vast knowledge often includes the intellectual property of others. Finding policies on the internet and using control H to place your organization’s name in place of another is not only wrong, it is also ineffective. Even if you have policies examples available that are not covered by copyright, they still will not cover everything you need in most situations. Every organization is unique, and as such has unique policy and procedure requirements. By all means, scour the web, libraries, desk drawers, etc. for policies to get ideas for format, structure, and things to include. But be sure to create your own intellectual property.
Do Not Ignore the Input of Others
No doubt you are an expert in your chosen field. However, developing policies and procedures is best done with the input of others. Be sure to speak with the Human Resources department about Acceptable Use, System Access, and other cross functional policies. Talk to your receptionist or security guards to get another perspective for Physical Security and Visitor policies. And certainly, wherever possible seek direction from whoever will be tasked with approving the policies. I am sure you get the idea; I could go on ad infinitum listing people who you should involve in policy creation.
Do Not Overcomplicate Things
I have never been accused of using too few words. However, when writing policies, be sure to be clear and concise. Don’t use two sentences where one will do. (Save that for blogs.) Of course it follows that you need to be thorough enough to make certain that your audience understands what the policy is saying. Finding the perfect balance is never easy, but if you are cognizant of this issue, you will likely be okay. Just remember, there is a reason Hemingway didn’t write policies.
Do not Forget the Audience
There are policies and procedures that will be distributed companywide, and others that will stay within IT. While IT procedures may be filled with the intricacies of required network logging, general policies will need to be geared toward a more general audience.
Do Not Get Stuck in the Weeds
Don’t let small issues derail your documentation project. Keep writing. There will always be debates about minutiae; note these for later resolution and move on. These decisions will need to be made prior to final approval and distribution, but they shouldn’t stop your progress.
Do not Confuse Policies with Procedures
As we discussed in a previous installment, policies and procedures have significant differences. One practical reason to separate policies and procedures involves the approval process. While policies generally go through an approval workflow that includes executive management, many times procedures (especially highly technical IT procedures) can be updated less formally. If procedural steps are embedded in policies, you could find yourself seeking executive approval each time you change software vendors or process minutiae. We will discuss this more in later installments.
In our next installment of this series, we will cover basic document formatting and structure. (Don’t worry; it is not as dry as it sounds.)
Read more!
Part 1 , Part 2 , Part 4 , Part 5 , Part 6
While we are still at the beginning stages of preparing to develop policies, procedures, and related documentation, it is important to mention a few things not to do.
Do Not Repurpose/Borrow the Work of Others
Search engines are great, and place a vast body of human knowledge at your fingertips. This vast knowledge often includes the intellectual property of others. Finding policies on the internet and using control H to place your organization’s name in place of another is not only wrong, it is also ineffective. Even if you have policies examples available that are not covered by copyright, they still will not cover everything you need in most situations. Every organization is unique, and as such has unique policy and procedure requirements. By all means, scour the web, libraries, desk drawers, etc. for policies to get ideas for format, structure, and things to include. But be sure to create your own intellectual property.
Do Not Ignore the Input of Others
No doubt you are an expert in your chosen field. However, developing policies and procedures is best done with the input of others. Be sure to speak with the Human Resources department about Acceptable Use, System Access, and other cross functional policies. Talk to your receptionist or security guards to get another perspective for Physical Security and Visitor policies. And certainly, wherever possible seek direction from whoever will be tasked with approving the policies. I am sure you get the idea; I could go on ad infinitum listing people who you should involve in policy creation.
Do Not Overcomplicate Things
I have never been accused of using too few words. However, when writing policies, be sure to be clear and concise. Don’t use two sentences where one will do. (Save that for blogs.) Of course it follows that you need to be thorough enough to make certain that your audience understands what the policy is saying. Finding the perfect balance is never easy, but if you are cognizant of this issue, you will likely be okay. Just remember, there is a reason Hemingway didn’t write policies.
Do not Forget the Audience
There are policies and procedures that will be distributed companywide, and others that will stay within IT. While IT procedures may be filled with the intricacies of required network logging, general policies will need to be geared toward a more general audience.
Do Not Get Stuck in the Weeds
Don’t let small issues derail your documentation project. Keep writing. There will always be debates about minutiae; note these for later resolution and move on. These decisions will need to be made prior to final approval and distribution, but they shouldn’t stop your progress.
Do not Confuse Policies with Procedures
As we discussed in a previous installment, policies and procedures have significant differences. One practical reason to separate policies and procedures involves the approval process. While policies generally go through an approval workflow that includes executive management, many times procedures (especially highly technical IT procedures) can be updated less formally. If procedural steps are embedded in policies, you could find yourself seeking executive approval each time you change software vendors or process minutiae. We will discuss this more in later installments.
In our next installment of this series, we will cover basic document formatting and structure. (Don’t worry; it is not as dry as it sounds.)
Read more!
Tuesday, August 10, 2010
Information Security Policies and Procedures, Part 2
This is part of an ongoing series on documentation development. Please be sure to read the previous posts in this series.
Part 1 , Part 3 , Part 4 , Part 5 , Part 6
Knowing which policies are necessary in your environment can be a challenge. Most organizations will have at least some formalized policies. Many of these are in response to legal requirements (HR policies) or specific incidents. After someone leaves their laptop in the car trunk for 6 hours on a 100 degree day, a policy on the care of equipment is generally issued.
With policies and procedures, it is essential to be proactive rather than reactive. In the case of the melted laptop, it would be far better to have instituted a policy regarding equipment care prior to the incident. That may be a simplistic scenario where the company is out a thousand dollars for a laptop, but it illustrates a point. This proactive posture becomes far more important when applied to more complex situations. What if, instead of being out a thousand dollars for a laptop, you were instead out tens or hundreds of thousands of dollars in fines after a cardholder data breach? Or worse, in the case of HIPAA, you find yourself with tremendous legal bills or in jail. (I am aware that is an extreme case, but it is illustrative of my point.)
As far as information security, every organization will have a unique set of foundational policies. Although there will be many that are common to all organizations, the unique qualities of each organization call for custom policies. How then, do we determine what basic policies we need? I have found that one of the simplest ways to determine which policies are essential is to look at all applicable regulations, laws, standards, and contracts and perform a gap assessment. For example, if you are subject to the PCI DSS, a good way to start is to take a copy of the standard and identify every place where a policy or procedure is required. PCI requires a policy on visitors to your facilities. As such, part of being compliant with PCI will be developing a visitor policy per the specific requirements of the standard. An important caveat: having a policy in place does not equal compliance.
An auditor will not only look for the policy, they will also look for evidence that the policy is enforced. So, for our example of a visitor policy, the auditor will want to see associated visitor logs and will check to see if they are issued a visitor badge per the policy. Careful readers will note that I slipped in mention of another document, the visitor log. In many cases, documentation leads to more documents. In this case, you will also likely need to develop training and awareness programs. Procedures for the receptionist to follow will help ensure that they are correctly logging visitors. An awareness program allows employees to understand that the policy exists as well as the rationale behind the policy.
As you move through the standard or regulation identifying where documentation is necessary, keep a list of what policies address which sections. At the conclusion of the gap assessment of the applicable regulations and compliances, you will have a firm understanding of what policies and related documentation are necessary. Keep in mind that in addition, it is important to review contractual obligations. These contractual obligations generally exist between you and your clients, vendors, and other service providers. Involving your legal department is always recommended.
In the next part of this series we will cover some of the pitfalls to avoid.
Read more!
Part 1 , Part 3 , Part 4 , Part 5 , Part 6
Knowing which policies are necessary in your environment can be a challenge. Most organizations will have at least some formalized policies. Many of these are in response to legal requirements (HR policies) or specific incidents. After someone leaves their laptop in the car trunk for 6 hours on a 100 degree day, a policy on the care of equipment is generally issued.
With policies and procedures, it is essential to be proactive rather than reactive. In the case of the melted laptop, it would be far better to have instituted a policy regarding equipment care prior to the incident. That may be a simplistic scenario where the company is out a thousand dollars for a laptop, but it illustrates a point. This proactive posture becomes far more important when applied to more complex situations. What if, instead of being out a thousand dollars for a laptop, you were instead out tens or hundreds of thousands of dollars in fines after a cardholder data breach? Or worse, in the case of HIPAA, you find yourself with tremendous legal bills or in jail. (I am aware that is an extreme case, but it is illustrative of my point.)
As far as information security, every organization will have a unique set of foundational policies. Although there will be many that are common to all organizations, the unique qualities of each organization call for custom policies. How then, do we determine what basic policies we need? I have found that one of the simplest ways to determine which policies are essential is to look at all applicable regulations, laws, standards, and contracts and perform a gap assessment. For example, if you are subject to the PCI DSS, a good way to start is to take a copy of the standard and identify every place where a policy or procedure is required. PCI requires a policy on visitors to your facilities. As such, part of being compliant with PCI will be developing a visitor policy per the specific requirements of the standard. An important caveat: having a policy in place does not equal compliance.
An auditor will not only look for the policy, they will also look for evidence that the policy is enforced. So, for our example of a visitor policy, the auditor will want to see associated visitor logs and will check to see if they are issued a visitor badge per the policy. Careful readers will note that I slipped in mention of another document, the visitor log. In many cases, documentation leads to more documents. In this case, you will also likely need to develop training and awareness programs. Procedures for the receptionist to follow will help ensure that they are correctly logging visitors. An awareness program allows employees to understand that the policy exists as well as the rationale behind the policy.
As you move through the standard or regulation identifying where documentation is necessary, keep a list of what policies address which sections. At the conclusion of the gap assessment of the applicable regulations and compliances, you will have a firm understanding of what policies and related documentation are necessary. Keep in mind that in addition, it is important to review contractual obligations. These contractual obligations generally exist between you and your clients, vendors, and other service providers. Involving your legal department is always recommended.
In the next part of this series we will cover some of the pitfalls to avoid.
Read more!
Tuesday, August 3, 2010
Information Security Policies and Procedures, Part 1
Note: This is part of an ongoing series on documentation development. Please be sure to read the previous posts in this series.
Part 2 , Part 3 , Part 4 , Part 5 , Part 6
Policy writing can be a daunting task, and one for which many are not overly enthused. However, Policies and Procedures are an integral part of any information security program. Not only do they provide direction and accountability, many specific policy elements are a requirement of specific laws, regulations, and/or standards. In this multipart series, I will work to help you become comfortable writing policies and their associated procedures.
Before we get started, there are a few things that are important to know.
Policy sets are different in each environment. With information security, the number of policies as well as the breadth of each policy will vary depending on the complexity of the environment as well as the sensitivity and criticality of the information. There are other factors that will affect information security policy development as well. For example, it is common that some of the elements of an Acceptable Use Policy will already be covered in basic HR policies and employee handbooks. It is essential that different departments work together to ensure that policies work in concert and do not contradict each other.
It is also essential to determine the audience for any given policy. For most users, the Acceptable Use Policy will determine the rules for their access. Network Security Policies, Access Control Policies, and System Access Logging and Maintenance Policies will have IT departments as their audience. It is also important to note that certain policies may be confidential according to an asset classification program. A Network Security Policy delineating requirements for protections such as connection restrictions or intrusion protection and detection may be valuable for an attacker. It is vital to consider business need to know when distributing policies.
The Differences Between Policies, Procedures, and Standards
It is important to understand the differences between a policy, procedure, and standard, and the functions of each. Policies delineate the laws for an organization. Procedures and standards describe how to implement policies. A simple analogy is that of a red light. The policy, or law, requires that drivers come to a complete stop at any and all red lights. The procedure, however, will describe how to depress the brake, operate the clutch, etc. The standard would describe what types of brakes and tires are appropriate. An exception process would describe the circumstances under which the policy may be violated--in this example, an emergency vehicle.
In the next part of this series, we will discuss how to determine which policies are necessary for your environment.
Part 2 , Part 3 , Part 4
Read more!
Part 2 , Part 3 , Part 4 , Part 5 , Part 6
Policy writing can be a daunting task, and one for which many are not overly enthused. However, Policies and Procedures are an integral part of any information security program. Not only do they provide direction and accountability, many specific policy elements are a requirement of specific laws, regulations, and/or standards. In this multipart series, I will work to help you become comfortable writing policies and their associated procedures.
Before we get started, there are a few things that are important to know.
Policy sets are different in each environment. With information security, the number of policies as well as the breadth of each policy will vary depending on the complexity of the environment as well as the sensitivity and criticality of the information. There are other factors that will affect information security policy development as well. For example, it is common that some of the elements of an Acceptable Use Policy will already be covered in basic HR policies and employee handbooks. It is essential that different departments work together to ensure that policies work in concert and do not contradict each other.
It is also essential to determine the audience for any given policy. For most users, the Acceptable Use Policy will determine the rules for their access. Network Security Policies, Access Control Policies, and System Access Logging and Maintenance Policies will have IT departments as their audience. It is also important to note that certain policies may be confidential according to an asset classification program. A Network Security Policy delineating requirements for protections such as connection restrictions or intrusion protection and detection may be valuable for an attacker. It is vital to consider business need to know when distributing policies.
The Differences Between Policies, Procedures, and Standards
It is important to understand the differences between a policy, procedure, and standard, and the functions of each. Policies delineate the laws for an organization. Procedures and standards describe how to implement policies. A simple analogy is that of a red light. The policy, or law, requires that drivers come to a complete stop at any and all red lights. The procedure, however, will describe how to depress the brake, operate the clutch, etc. The standard would describe what types of brakes and tires are appropriate. An exception process would describe the circumstances under which the policy may be violated--in this example, an emergency vehicle.
In the next part of this series, we will discuss how to determine which policies are necessary for your environment.
Part 2 , Part 3 , Part 4
Read more!
Subscribe to:
Posts (Atom)
Posts
