Security Standards, Guidelines, Policies, and Procedures

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 vs Standards vs Procedures vs Guidelines


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.


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.

Final Thoughts

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

incident response

Chad Spoden on Linkedin
Chad Spoden
Senior Security Analyst (Team Lead) at FRSecure LLC
Chad Spoden is a passionate Information Security expert with over 20 years experience who has served businesses of all sizes. Chad's experience in architecting, implementing, and supporting network infrastructures gives him a deep level of understanding of Information Security. Prior to joining FRSecure, Chad was a Vice President of Information Technology and a Network Administrator. At FRSecure, Chad enjoys being able to use his technical expertise and passion for helping people.

16 replies
  1. ala'a
    ala'a says:

    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?

    • Chad Spoden
      Chad Spoden says:

      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.

  2. Nicholas Wade
    Nicholas Wade says:

    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.

  3. Fred Krimmelbein
    Fred Krimmelbein says:

    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.

  4. Matt
    Matt says:

    These are great clarifications. What about frameworks though? Where would they sit or are frameworks just a collection of standards?

  5. Banana Barbara Mudanga
    Banana Barbara Mudanga says:

    Thanks for clarity but would like to hear more on difference of programme strategy and programme police operational guidelines

  6. Linda Smith
    Linda Smith says:

    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.

    • Chad Spoden
      Chad Spoden says:

      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?
      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.

    • Chris
      Chris says:

      Good Question? What was the outcome? I would define the procedure: Read, Comprehend, Follow, Practice, When in doubt Inquire.

  7. Colin Macguire
    Colin Macguire says:

    Thanks for the great post, Chad. Much appreciated. What role do you see principles playing in the development of policies, standards, procedures and guidelines?

  8. Anis
    Anis says:

    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.

  9. Bryony
    Bryony says:

    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.


Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *