At Tandem, we regularly receive the question, "What's the difference between policies, standards, controls, and procedures?" This question is foundational to being able to understand how to best write an information security policy. By defining what each of these elements are (and are not), communication can happen more clearly, which is why you try to have these things in the first place.
Let's start to answer this question by laying the groundwork: setting definitions, looking at guidance, and providing some examples. At the end, we'll connect all the dots and help you answer this question.
Policies are a series of statements, rules, and assertions which define the organization's structure. They do this by defining expected behaviors, required actions, and prohibited activities. The FFIEC's Architecture, Infrastructure, and Operations (AIO) Booklet gives us this definition of a policy in the context of AIO.
"[Policies] provide the guiding principles by which an organization designs, builds, and operates its information and technology assets and set the foundation for meeting the entity's objectives. For example, an entity may have policies outlining the types of hardware or software it will or will not use (e.g., "We will not use any unapproved software.")."
Looking at another example of this in action, you might have a policy that says:
"We will secure sensitive data by encrypting it."
While simple, a policy communicates an ideal state. Policies are typically approved by a Board or higher authority and set a direction, provide boundaries, and give a point which can be used to guide future decision-making.
A standard is the answer to the question: "How are you going to implement your policy?" Standards can be published by an external entity or authority for a given domain, or they can be developed specific to your organization. Either way, standards take the guidelines set by the policy and put them into actionable language.
Continuing with the example from the FFIEC AIO Booklet:
"[Standards] build on the policies and provide more granular information for AIO activities. For example, standards may explain the types of data that are allowed to reside in the cloud or the types of controls to be implemented to mitigate the risks of data residing in the cloud."
Looking at this from the encryption example, your standards might mention something like:
"Secure sensitive data by requiring whole disk encryption for data at rest and a virtual private network (VPN) for data in transit."
In short, the implementation standards take a policy's ideals and make it real.
Simply put, a control is an outcome of a standard.
It is a mechanism put in place to mitigate the risks identified by the organization. For example, if our policy says, "we will secure sensitive data by encrypting it," we have identified there is a risk of having unencrypted sensitive data.
As a result, our standard establishes specific things which need to be done to "control" the risk. For example, whole disk encryption or a virtual private network (VPN).
The FFIEC AIO Booklet supports this directly by saying that an AIO standard could be "the types of controls to be implemented to mitigate the risks of data residing in the cloud." For additional information about controls, see the Information Security Booklet, Section II.C.3 Control Types.
Think of a procedure like a step-by-step instruction manual. It is a list of actions which must be taken to achieve the standards and implement the controls.
According to the FFIEC's AIO Booklet:
"[Procedures] describe the specific ways for personnel to perform AIO activities. For example, AIO-related procedures may cover topics including how to harden new systems or perform architecture reviews with the necessary steps for personnel to follow."
What this shows is that procedures are very specific in nature and would be based on how you do things in your environment. For example, with the encryption standard, our procedures could look like this:
Procedures exist to teach people how to do what the standards say. Procedures ensure consistency, accuracy, security, and all around, they make the world a better place to be.
Policies, standards (controls), and procedures go together like peas and carrots. (And green beans, I guess.) If policies are the dream vacation, then standards are the map, and procedures are the travel itinerary. If policies are a dessert, then standards are the ingredients, and procedures are the recipe.
If analogies aren't your thing, it might be helpful to think of it like a pyramid.
Together, these three sections of the pyramid have dedicated their lives to fighting crime and the forces of evil. (Or at least, they can help make your business a better place to be.)
If you're looking to take your policies, standards, controls, and procedures to the next level, check out Tandem Policies. Our enterprise-wide policy management software exists to help you create, document, manage, and export your policies with ease. Each of our policies features fields to help you document these areas, including:
Learn more about how Tandem structures our policies in our blog: Key Sections of an Information Security Policy. For additional information or to see the product in action, check out Tandem.App/Policies-Management-Software.
