policy-procedure-street

Look at the following terms.  Aren’t these basically the same thing?

  • Information Policies
  • Information Procedure
  • Information Standard
  • Information Guideline

No, they are not and here’s why.

Differentiating Between Policies, Standards, Procedures, and GuidelinesPolicies

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

Standards are mandatory actions 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

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 example of procedures.

Guidelines

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.

So, 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 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. That’s where most of the issues come up. Building your program is not just up to the IT department, everyone needs to be onboard. 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 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.

Have you recently built an information security program for your business? Tell us all about it in the comments section.

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.

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

    Reply
    • 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.

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

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

    Reply
  4. Matt
    Matt says:

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

    Reply
  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

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

    Reply
    • 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 FISASCORE®? 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.

      Reply

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 *