Writing policies can be hard, writing good policies can be even harder. Though writing policies, standards, and procedures are often last on people’s minds, they are however a necessity. When building a cybersecurity program, not only are technical controls important but policies, standards, and procedures (PSP) are required documents for any information technology assessment. Whether it is for ISO 27000, NIST, SOX, or any other type of certification or framework, auditors will want review your documentation.

Auditors want to ensure that your PSP’s back up your IT program. They will evaluate how the technology is configured and implemented. The auditor will review your PSP’s to ensure that IT governance has been established for the organization. The following describes what policies, standards, and procedures are and how to craft a document.

Policies

Policies are overarching documents which provide an overview of the control objective. They are high level documents which establish IT governance and intent of applying administrative and technical controls. Policies are high level, allowing anyone to view the document without giving away specific technologies or how they are implemented.

“Policy” is often confused for any written document, which include standards and procedures. Policies do not go into detail of how a particular technology is configured or the process of how to do it. The document is used to show intent that these are put in place.

Standards

Standards are medium to low-level documents which depict how a device is configured or acceptable technologies to use. A standard must detail the levels of adequate encryption or what SPF, DKIM, or DMARC settings must be configured for email. Standards are used to backup what was previously stated in the policy.

A standards document what is going to be done without going into detail of how to do it. That is the responsibility of a procedure document. A standard would go into details of acceptable encryption. A procedure would then detail how to configure it for a piece of software. Standards state that guest accounts should be disabled, the procedure would depict how to disable it.

Procedures

Would your co-workers know how to perform your job if you were to win the lottery? Procedures must be written so that anyone can follow and understand. It should be simple enough that a new hire, or a junior admin could perform a function without much trouble. Procedures focus on how a job function is performed without getting into details of what is acceptable. They can be in the form of swim lanes or procedural, however the document must state who is responsible for what job function.

Policies, Standards, and Procedures Documentation Layout Framework

All too often I encounter an organization that has combined their PSP’s into a 30 – 100 page document. This makes searching what you are looking for extremely difficult, especially when you need to locate a document for a control. This is where breaking up documents is helpful. When you follow the methodology that procedures are written to back up standards, and standards are written to back up policies then you are on the right track. The Open Policy Framework provides a way to accomplish this.

When looking at the framework layout, the policy is on the left hand side with its subsequent standards and procedures falling beneath it. An example would be, document 100.00 is the Information Security Policy with each standard and procedure below. Acceptable Use is 100.01, Encryption 100.03, and so on. Procedures would follow the same numbering scheme with 100.03.01 being a procedure of how to configure an Apache server for instance. This numbering scheme allows one to easily locate the information needed.

Writing policies, standards, and procedures may be the non-sexy side of information technology or security but it is a necessity. When scoring a maturity level for an organization, not only will an organization need to have appropriate technical safeguards in place but also documentation to back it up.