View source for Policy Procedure Standards Guidelines

== Overview ==
I often find myself defining (directly or indirectly) rules that ultimately become a policy, procedure, standard, or guideline. I sometimes find it difficult to label these rules, I found an article that was useful and am reproducing it here so its easier to find.

'''DISCLAIMER:''' This is not original work, all credit goes to Chad Spoden author of the article located in the reference section of this page. This is not an endorsement nor am I affiliated with FRSecure.


               /\
              /  \   Guidelines
             /    \
            /------\
           /        \
          /  (HOW)   \   Procedure
         /            \
        /--------------\
       /                \
      /      (WHAT)      \   Standards
     /                    \
    /----------------------\
   /                        \
  /           (WHY)          \   Policies
 /____________________________\
 


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


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


== 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!)


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


== Reference ==
https://frsecure.com/blog/differentiating-between-policies-standards-procedures-and-guidelines/


[[Category:Tech_Notes]]