Policies, Standards And Procedures

Nothing bothers me more than asking for an organization’s firewall policy (or any policy actually) and getting my own personal version of ‘War and Peace’. The document is a mix of policies, standards and procedures all in a vain attempt to get as many topics covered as possible in a single document. And then the writers of these tomes wonder why no one actually reads them and therefore they have little or no compliance.

As that as our backdrop, here is my take on how to properly write policies, standards and procedures.


Webster’s dictionary defines a policy as:

“a high-level overall plan embracing the general goals and acceptable procedures”

The key phrase here is “high level” not details like I encounter in most policies I read.

At a minimum, a policy needs to cover the following topics.

  • Problem statement. This section defines the problem or issue that the policy addresses. This should be no more than two paragraphs and should be devoid of technical terms or legalese if at all possible. If you are taking more than two paragraphs, then you either need to figure out how to be more concise or maybe you are covering too much ground with just one policy. Do not be surprised when you write your problem statement that you figure out ways to consolidate topics or better define topics. For example, why write separate electronic mail, letter writing, facsimile and texting policies when they are all forms of business communications and then just write a communication policy.
  • A bullet point or numbered list of the objectives of the policy. Are you protecting the assets of the organization? Are you minimizing the potential for fraud? Are you informing employees of their rights? Document the objectives you are trying to achieve with this policy.
  • Policy statement. Define the organization’s position and solution(s) regarding the problem documented from the problem statement.
  • Define who is responsible for what. Explain the responsibilities of boards, committees, all personnel, corporate officers of the organization and anyone else that is affected by this policy such as contractors or temporary help.
  • Policy management information. This is a block of information such as the date of issue, the last date of review, board approval date and other information that might be required to prove that policies are updated and reviewed.

The Guru’s rule of thumb is that a policy should be no longer than two to three pages in length. Actually the shorter the policy the better. Anything longer than that and it is not a policy.

As an example, here is that Communication Policy.

Problem Statement:

The organization provides employees with a variety of communication capabilities. As with any form of communication, care must be taken to ensure that the organization is represented appropriately and intellectual property is appropriately protected.


  1. Ensure the appropriate use of organization assets.
  2. Ensure the protection of the organization’s intellectual property and sensitive information.
  3. Notify employees of their rights when using organization-provided communication systems.

Policy Statement:

The organization provides a variety of communication systems including, but not limited to, written, pager, telephone, cellular telephone, facsimile, voice mail, electronic mail and instant messenger systems. These communication systems are for employee use in conducting organization business. The personal privacy of these communication systems is not guaranteed by the organization, as the organization may, from time to time, find it necessary to monitor communication systems and traffic to protect its intellectual property, sensitive information and other critical assets.

As with any method of communication, employees are to conduct such communication in a dignified and business-like manner. Failure of an employee to communicate with other persons in a dignified and business-like manner will result in disciplinary action and possibly termination.

While the use of the communication systems are specifically for conducting the business of the organization, management recognizes that personal use of the communication systems will occur. Employees are to minimize personal usage of the organization’s communication systems. Should personal usage become a problem, the organization will take steps to restrict personal communication that include, but are not limited to, disciplinary action and technical measures to limit or restrict personal communication.


The Corporate Security Officer (CSO) is responsible for development, implementation, dissemination, and monitoring of appropriate communication policies, standards and procedures. The CSO is also responsible for the development and implementation of an internal training program to educate personnel on the communication policies, standards and procedures.

Employees, contractors and temporary personnel will be required to attend a policy training course as well as sign an acknowledgement statement that refers to the organization’s policies regarding the use of the organization’s communication systems at time of on-boarding and annually thereafter. Failure to sign this statement will be grounds for termination of employment/contract.

Information systems management is responsible for implementing, maintaining and monitoring appropriate methods for securing and monitoring automated communication systems.

Internal Audit is responsible for periodic audits of the organization’s automated communication systems capabilities to ensure compliance with the communication policies, standards and procedures.

The head of Human Resources is responsible for the management oversight of this policy.

There are a number of other policies, standards and procedures that support this simple policy. All of those support and facilitate this document. But hopefully this provides you an example of what a policy should look like.


To continue with definitions, Webster’s defines a standard as:

“something established by authority, custom, or general consent as a model”

The key word with this definition is “model”. Standards define for example how device names will be formed, how IP address ranges will be defined and where those addresses will be used, how to properly code in various programming environments, network architecture for where and how to use firewalls and other security devices and the obvious how devices will be configured.

It is allowable to put hyperlinks to Internet documents or other reference documents so that you do not have to constantly update those documents. Where I encounter this the most is with device configuration standards. An organization that for example has Cisco equipment can provide hyperlinks to the relevant Cisco configuration and security standards for the various versions of IOS or Nexus standards on Cisco’s Web site so that the organization can leverage Cisco’s documentation.

Standards can be long or short, but the key is that a standard needs to address the model you are trying to establish.


Webster’s defines a procedure as:

“a series of steps followed in a regular definite order”

A proper procedure is a checklist or a numbered list that tells anyone how to complete some process. Examples of procedures are:

  • Checklists for configuring a device that proves that the standard(s) involved were followed.
  • Daily operations checklists to document that all daily procedures were performed.
  • Monitoring procedures for ensuring that all devices are properly monitored.
  • Incident response procedures documenting how to respond correctly to particular alerts that could be an incident.

The key though with procedures is that they must be complete so that anyone can perform them. And when I say anyone, I mean anyone. If you have never been through procedure writing, the best example I can give you is to write down instructions for tying a pair of shoes and then give them to a co-worker and have them follow those instructions. You should find that it is not as easy as you might think and will take many revisions to get a set of working instructions.

When I was a CIO, the way I tested procedures was to perform them myself. What started this practice was an extended power outage one night and our UPS systems required us to shut down the data center. When the power came back on around 4AM, the night operator was not able to get the systems back up and running because he had no procedures to follow. As a result, when I got in at 6AM systems were still powered down and the day operator was waiting for some key people to get everything back up. I gave the IT staff three days to prepare start up and shut down procedures for all systems and then came in on a Sunday and tried them out myself. Needless to say, that Sunday did not go as well as people expected and a lot of updates and changes to those procedures were made. However, once those procedures were complete, I could have gotten the Chairman of the Board to restart the data center.

Hopefully this gives you the guidance you need to properly write policies, standards and procedures. I think you will find as I have that properly written, such documentation can be very useful in clearly communicating with everyone involved in your organization.


8 Responses to “Policies, Standards And Procedures”

  1. 1 gabbyndu
    September 5, 2018 at 2:33 AM

    Please i will need a clarification on PCI DSS standard as regards policies and procedures. At the end of each requirement on PCI standard, it mentions “Ensure that security policies and operational procedures for ……..”. e.g “Ensure that security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties”.
    Does it mean i will create 12 policies and 12 procedures? If yes, does it cover all the policies and procedures needed as stated in the requirement of the standard?

    • September 7, 2018 at 7:01 AM

      NO! What those last requirements mean is that your existing policies, standards and procedures cover the individual 12 sections of requirements. For example, section 10 is all about logging and time, so somewhere in your policies, standards and procedures should cover the logging and time PCI requirements in section 10.

  2. July 13, 2016 at 11:27 AM

    Here’s a quick 2 part question re: policies.
    Firstly, thanks for the clarification of policies versus standards etc.

    Ok. The first part of my question pertains to policies required as they relate to what SAQ level you’re obligated to report with – that is, If I only fill out an SAQ A, my policies only need to reflect the requirements of THAT SAQ …correct? (I am, however, in a somewhat different camp on this, seeing IT Security more holistically etc.) – or should they be comprehensive so as to cover the entire spec?

    AND is it enough, for those who tire easily when writing policies (not me), to simply say that the ‘policy’ is to adhere to the PCI-DSS (and maybe supply a link to that famous website)?

    I am somewhat old school and see either as a short-cut. But, that’s just me.

    • July 14, 2016 at 2:22 PM

      The PCI SAQs are pretty consistent on policies in section 12, give or take a few. Yes, they are not all required depending on the SAQ, but information security and privacy are more than just PCI. As such, I would lean towards your holistic approach and say that all policies are necessary to have information security and privacy covered and that those will just happen to provide compliance with the PCI DSS.

      As to your second question, 12.3.10 is the only place I allow my clients to generically reference the PCI DSS as a whole. Otherwise, I prefer policies, standards and procedures to state explicitly what they need to state. Not that they need to use the exact wording from the PCI DSS, just that they provide enough definition/concepts/etc. that one can apply that to compliance with the PCI DSS or other security/privacy standards.

  3. 5 Jake
    July 6, 2015 at 3:08 AM

    Hi – great article! How do you understand “processes”? Example from PCIDSSv3.1: “3.1.a Examine the data retention and disposal *policies*, *procedures* and *processes* to verify they include…”

    Policies and procedures are crystal clear but then they mention *processes*? How do you understand the difference between a procedure and a process?

    • July 6, 2015 at 5:39 AM

      Unfortunately, some organizations use the terms ‘process’ and ‘procedure’ interchangeably. Not sure why, but you encounter it a lot even though the organizations swear they are two different things. Near as I can tell with some of these instances, procedures are a numbered list and processes are a checklist or vice versa.

      • 7 Jake
        July 6, 2015 at 5:45 AM

        I agree; they are interchangeable; however the problem is in the way the SSC worded these reqs. using the ‘AND’ rather than the ‘OR’, which implies any compliant company should present 3x different documents to the QSA: policy, procedure AND process. Confusing…

      • July 6, 2015 at 5:51 AM

        God knows the Council has not always been the clearest on some things and this is a prime example. I am sure that someone involved in the standard writing process decided that in order to cover the spectrum of documentation needed for an assessment added in the term ‘processes’ and then forgot to use ‘or’ instead of ‘and’. Points to all those people trying to lawyer their way out of compliance does it not? LOL!

        Organizations should be providing policies, standards and procedures as documentation. If the organization wants to use the term ‘processes’ as well, just include them in the procedures bucket and move on. If that is a bone of contention, then put them in a separate folder but consider them a procedure. AT the end of the day, it really does not matter because documentation is documentation and that is all the PCI DSS requires is a document that states what a QSA/ISA should be looking for to confirm compliance.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

July 2015

%d bloggers like this: