Take a look at the terms “information policies,” “information procedures,” “information standards,” and “information guidelines.” Aren’t these basically the same thing?
No, they are not and here’s why.
Policies are formal statements produced and supported by senior management.
They can be organization-wide, issue-specific, or system-specific. Your organization’s policies should reflect your objectives for your information security program—protecting information, risk management, and infrastructure security. Your policies should be like a building foundation; built to last and resistant to change or erosion.
- Driven by business objectives and convey the amount of risk senior management is willing to accept.
- Easily accessible and understood by the intended reader
- Created with the intent to be in place for several years and regularly reviewed with approved changes made as needed.
Standards are mandatory courses of action or rules that give formal policies support and direction.
One of the more difficult parts of writing standards for an information security program is getting a company-wide consensus on what standards need to be in place. This can be a time-consuming process but is vital to the success of your information security program.
- Used to indicate expected user behavior. For example, a consistent company email signature.
- Might specify what hardware and software solutions are available and supported.
- Compulsory and must be enforced to be effective (this also applies to policies).
Procedures are detailed step-by-step instructions to achieve a given goal or mandate.
They are typically intended for internal departments and should adhere to strict change control processes. Procedures can be developed as you go. If this is the route your organization chooses to take it’s necessary to have comprehensive and consistent documentation of the procedures that you are developing.
- Often act as the “cookbook” for staff to consult to accomplish a repeatable process.
- Detailed enough and yet not too difficult that only a small group (or a single person) will understand.
- Installing operating systems, performing a system backup, granting access rights to a system, and setting up new user accounts are all examples of procedures.
Guidelines are recommendations to users when specific standards do not apply.
Guidelines are designed to streamline certain processes according to what the best practices are. Guidelines, by nature, should open to interpretation and do not need to be followed to the letter.
- Are more general vs. specific rules.
- Provide flexibility for unforeseen circumstances.
- Should NOT be confused with formal policy statements.
As you can see, there is a difference between policies, procedures, standards, and guidelines. Each has their place and fills a specific need.
Policies are the data security anchor—use the others to build upon that foundation.
Keep in mind that building an information security program doesn’t happen overnight. It is a conscious, organization-wide, process that requires input from all levels. Building your program is not just up to the IT department; that’s where most of the issues come up.
Everyone needs to be on board.
Getting organization-wide agreement on policies, standards, procedures, and guidelines is further complicated by the day-to-day activities that need to go in order to run your business.
In the end, all of the time and effort that goes into developing your security measures within your program is worth it. Building a comprehensive information security program forces alignment between your business objectives and your security objectives and builds in controls to ensure that these objectives, which can sometimes be viewed as hindrances to one another, grow and succeed as one.
If you need help building your information security program—regardless of if it’s from square one or just to make top-end improvements—reach out to us at frsecure.com.
When do we need to have a standard in place? shouldn’t we go for some policies and then procedures to support the implementations of those policies
Are guidelines only produced when we don’t have procedures?
Great question, thanks for asking!
Policies will be the base foundation which your security program will be built on. As the pyramid shows once you have the baseline you can start to develop your standards.
Standards can be drafted as you work on different aspects of IT. For example, if you’re doing a hardware refresh you might update the standards to reflect what is now being implemented.
Policies are formal and need to be approved and supported by executive management. Standards, procedures, and guidelines are more departmental in nature and can be handled by your change control process.
Try not to mix policy with actual procedure steps which is what we often see. This adds complexity and the intent of the policy can get lost in the details.
Your policy might reference a standard that could change more frequently. Policies might not change much from year to year however they still need to be reviewed and tracked on a regular basis.
Finally, use Guidelines to address any unforeseen situations that do not need to be formally addressed by policy. A best practices document would be considered a guideline, the statements are suggestions and not required.
Contact FRSecure anytime, we’d love to help with your information security needs.
Thank you both for this Q&A. I have been asking the same question, and the answer is very helpful!
Excellent clarifications here! Thank you so much.
Easy, except that Standards consist of control objectives which are defined for goals…all gets a bit confusing when you’re trying to formulate the wording.
The opinions expressed here are my own and may not specifically reflect the opinions of Vidant Health. (This actually comes from our policy when posting to public sites.)
Standards can include things like classifications, in our case data classifications setting out which types of data are considered confidential, company use and for public consumption. The procedure would state that we have a standard or classification. This is so that it doesn’t have to be changed every time we have to update the standard to reflect new attributes being added. Less cumbersome change process when you think about it as the standard does not have to meet the same rigor for change as the policy.
These are great clarifications. What about frameworks though? Where would they sit or are frameworks just a collection of standards?
Thanks for clarity but would like to hear more on difference of programme strategy and programme police operational guidelines
I am having a bit of a disagreement with a co-worker. Can you answer this question? Does every policy have to have a corresponding procedure? This colleague is trying to have every department use the same template for policies, but there are only three sections: Purpose, Policy, and Procedure. My policies do not fall clearly into this template because I have some that do no have corresponding procedures. For example, the computer acceptable user policy which outlines acceptable use – i.e., do not use corporate resources for hacking purposes, do not install unapproved equipment etc. These do not have procedures. They are simply policy statements. I could be wrong, but I am struggling with every policy needing a corresponding procedure. Thanks.
The bottom line is there’s no “correct” answer, sorry. I always ask “Why”.
Why are you creating the procedure? Is it to support the day to day activities to ensure things are done consistently? If we fail to follow the correct procedure what is the risk, what’s at stake? Failure to apply proper controls on a public-facing vs. nonpublic server could have grave consequences depending on the purpose of the server.
I would first start with good policies and then create the supporting procedure documents as the need arises or as I stated above based on the risk. Procedures often are created for someone to follow specific steps to implant technical & physical controls. It’s creating the “recipe” to ensure the policy can be successfully followed.
What’s your organization’s risk score? https://securitystudio.com
If you’re coming in at 400 then you have other things to worry about. If you’re 790 then go for it and come up with detailed procedures for everything you do.
Keep it simple, complexity is the enemy of security.
Good Question? What was the outcome? I would define the procedure: Read, Comprehend, Follow, Practice, When in doubt Inquire.
Thanks for the great post, Chad. Much appreciated. What role do you see principles playing in the development of policies, standards, procedures and guidelines?
Hello Chad, Can you please give an example/examples to clarify all terms, Policy, standard, procedures, baseline and guideline? Usually they are very mixed concepts, thanks for the article though.
Hi Chad. Great article.
I would like to add ‘specification’ into the mix.
Would I be right in saying that a procedure is a document for internal use and a specification is a document issued to third parties indicating the requirements but not specifying how these requirements are to be met? In other words, the WHAT but not the HOW.
Are Policy Statements and Policies one and the same thing?
Thanks, in anticipation!
Are guidelines only produced when we don’t have procedures?