Standards are the what when creating policy documents. It details what should be configured or done on a particular IT resource. They are also meant to back up what was stated in the policy and help drive what goes into a procedure.
What goes into standards
Standards are meant to back up policies. As a policy drives the why, the standard establishes what to configure. As an example, a policy may state that the organization intends to encrypt hard drives or securely delete data from external devices. The standard states what knobs must be turned, but not how to turn the knobs. It should state what types of encryption should be used, or the type of program intended to encrypt the hard drive.
Another example could be the intended use of DBan when erasing files from a hard drive or thumb drive. The standard would state how many times you should securely wipe the drive. Maybe you write a section on shredding optical media such as CDs or DVD’s.
Standards documents should not be shared with anyone without a non-disclosure agreement (NDA) in place. Standards are documents that are sensitive in nature as they state what is to be configured. In 2014, the news of Heartbleed was released which took advantage of older versions of SSL and TLS. Standards should state appropriate encryption levels to be used and more importantly, what should not be used. If you intend to only use TLS v. 1.2 or higher, the standard should state that in the document.
How they drive procedures
Standards drive procedures. In the previous examples we discussed using certain technology to drive encryption. Once we establish that we want to use BitLocker for hard drive encryption, or disable older versions of TLS, those drive the procedure documents. We could have multiple procedures used to configure TLS on a web server or how to configure an API.
In the next section, we discuss the how or what goes into a procedure.