- Donald E. Hester
Policy, Procedure, or Plan
Some standards like PCI and NIST require policies that cover specific topics. Sometimes you will see a requirement for a policy and procedure around a given topic, and other times you will see a requirement that says “policy and procedures.” People often get hung up on the terms “policy” and “procedure,” and confuse the two. Here are some of the top questions I get about policies, procedures, and plans. Do I have to use the specific terms policy, procedure, or plan? No. I have found organizations that call policies “administrative directives” and procedures “SOPs.” I even once had a client that called them “Da Rulez.” In fact our firm, following accounting guidelines, calls our collective policies our Quality Assurance Manual. Call them whatever you want. Just make sure people know they need to follow them and where to find them.
Do we have to have policies, procedures, and plans? Yes. Each type of document serves a different purpose. You may remember from a previous post that policies are overall a broad requirement statement. Procedures cover how to apply a policy statement to a given situation. Finally, plans are like procedures, only they cover a larger spectrum of possible issues. For example, you may have procedures for running backups and even for recovery. On the other hand, a business continuity plan will need to be less specific because it needs to address a multitude of possible scenarios that will be impossible to document into a vast multitude of individual procedures. Think of plans as a strategy for recovery and not so much as procedures. You will have some procedures that will support the plan.
Do I need an incident response policy and plan? Yes. You need a policy statement that says that the organization will have an incident response capability and outline high-level requirements and assign responsibilities. Unlike a policy, a plan is an action document, something to be executed when an incident happens. This is not the time to be reading the policy; it is time to execute the plan.
Do you have to have a procedure for everything? No. Frankly, that is impossible. So what procedures should you have? That should be based on risk. Procedures are prone to error and if the error leads to a security incident, it should be documented. The reason for establishing procedures is to ensure consistency in process and for improvement over time. Admins often think they know what they are doing. That is, until steps are missed. The more complex the process, the more likely the process will not be consistently carried out, and the more likely a step will be missed. If you don’t want to do the work of determining the risk processes, you can start with COBIT, NIST, and PCI standards. Then add any procedures based upon an evaluation of incidents or as the need arises.
Can you have policy and procedures in the same document? You can, but I do not advise it. Policies should be approved by your board, executive team, council, or governing body. Any changes to policies need to go back to the approving authority that made them. Procedures change often, and you don’t want to have to take them back for review and approval every time there is any change. Policies should last roughly five or more years. Procedures should change as needed, which could be a few times a year.
You can, however, add standards, guidelines, how-to’s, and other supporting documents directly into procedures. For policies, I recommend you reference standards by saying the “latest version of PCI DSS” or “latest version of NIST SP 800-53.” A good example of a guideline in a procedure might be an instruction on selecting a complex password in the access control procedures or terms of use (rules of behavior/acceptable use) document.
Should we have one big policy or a multitude of smaller policies? You can do either and it doesn’t matter if you post them online. If you post policies on an intranet site, you can have an overall index that links to individual parts. If you have an overall policy that covers all the necessary items, you can save paper by covering topics each individual policy should have once (e.g. violations of policy) instead of referencing it multiple times across multiple policy documents.
What should I include in my policies? That is a bigger answer and deserves its own post.
What items should we have a policy for? That, too, is a bigger answer that also deserves its own post.
What do you mean by supporting documents? Supporting documents are things that we need to put on record aside from policies, procedures, or plans. For example:
Rules of Behavior, (The NIST term for a Terms of Use, Acceptable Use, Limitations on Use Policy)
How-to’s
Information Sheets
Training Materials
Reference Materials
Inventories
Lists
Manuals
Guidelines
Standards
Contracts
Service Level Agreements
Licenses
MOU/MOA
Legal Code (referenced)
Logs
Maintenance Records
Configuration Files, Settings, Images
System Security Plan
Do policies, procedures, and plans have to documented?
Yes. This is a matter of a maturity scale. If you don’t have policies, it is likely that you are not doing what you need to do. Some firms claim they are doing what they need to do and I, as an auditor, will say, “OK, you have an ad hoc approach, and I have a finding and recommendation that you implement the appropriate documentation.”
There is a maturity matrix called the Capability Maturity Model Integration (CMMI) that is generally used in the industry to gauge the maturity of an organization. The term "maturity" relates to the degree of formality and optimization of processes—from ad hoc practices to formally defined steps, to managed result metrics, to active optimization of the processes. There are five levels of maturity (six, if you count the 0):
0: Non-existent – there are no controls or processes 1: Initial (chaotic, ad hoc, individual heroics) – the starting point for use of a new or undocumented repeat process 2: Repeatable – the process is documented sufficiently such that repeating the same steps may be attempted 3: Defined – the process is defined/confirmed as a standard business process 4: Capable – the process is quantitatively managed in accordance with agreed-upon metrics
5: Efficient - process management includes deliberate process optimization/improvement
In order for your organization to meet level 3, you will need to have things documented. This is where policies, procedures, plans, and supporting documentation come into play.
