TechKnowSurge
ISC2 CISSP 1.6 CompTIA Security+ 5.1 NIST 800-53 PM-1 NIST CSF GV.PO-01 NIST 800-53 PL-2 NIST CSF GV.PO-02
TechKnowSurge Catalog Videos Policies, Standards, Procedures, Guidelines
VideoSecurityFree

Policies, Standards, Procedures, Guidelines

Policies, standards, procedures, guidelines, and controls form a structured hierarchy that governs how organizations build and manage a cybersecurity program. Understanding how these components relate to each other—and how to document them appropriately—is essential for designing a program that is both effective and scalable.

⚑ Complete this video to capture a CTF flag worth 1 point.

About this video

A well-functioning cybersecurity program depends on a structured governance hierarchy in which policies, standards, procedures, guidelines, and controls each play a distinct and complementary role. Policies sit at the top of this hierarchy as broad, high-level statements of organizational intent—directional in nature rather than prescriptive. From each policy, organizations derive standards that define specific, measurable requirements. Procedures then translate those standards into step-by-step operational instructions, while guidelines provide optional recommendations that practitioners may follow to improve efficiency or reduce risk without being formally required to do so. Controls add a layer of accountability by establishing measurable outcomes and the evidence needed to prove those outcomes were achieved. In practice, this hierarchy is often divided into two distinct documentation sets. The Written Information Security Policy—sometimes called a WISP or ISP—captures the policies, standards, and controls that define what the organization is committed to achieving. This document typically requires executive approval and is treated as a formal organizational commitment. A separate operational playbook covers procedures and guidelines, representing how those commitments are actually carried out. Keeping these two layers separate allows the playbook to evolve through continuous improvement without triggering a full approval cycle every time a process is refined. The scale and structure of this framework should be rightsized to fit the organization. Smaller companies or those with fewer regulatory obligations may need only a handful of top-level policies and a lean set of standards, while larger or more heavily regulated organizations may require a more extensive hierarchy. Decisions about where specific requirements live—at the policy level, the standard level, or within procedures—have real consequences for governance and flexibility, and those decisions should reflect both the organization's operational needs and the degree of control it wants to maintain over how and when changes are approved.

What you'll learn

What's covered

Security Program Documentation

Aligned to

ISC2 CISSP
1.6 Develop, document, and implement security policy, standards, procedures, and guidelines
CompTIA Security+
5.1 Summarize elements of effective security governance.
NIST 800-53
PM-1 Information Security Program Plan
PL-2 System Security and Privacy Plans
NIST CSF
GV.PO-01 Policy for managing cybersecurity risks is established based on organizational context, cybersecurity strategy, and priorities and is communicated and enforced.
GV.PO-02 Policy for managing cybersecurity risks is reviewed, updated, communicated, and enforced to reflect changes in requirements, threats, technology, and organizational mission.

Key terms

Security Policy
A formal document that defines an organization's security goals, rules, and responsibilities.
Standard
A mandatory, specific requirement derived from a policy that defines how the policy is to be implemented.
Procedure
A detailed, step-by-step set of instructions for carrying out a specific task in alignment with policies and standards.
Guideline
A recommended, non-mandatory suggestion that provides flexible guidance for implementing policies and standards.
Control
A measurable outcome or requirement used to verify that an organization is meeting its cybersecurity standards and can provide evidence of compliance.
Baseline
A documented set of minimum security standards or performance metrics used as a reference point.

Topics

Security Governance Security Policies Security Standards Security Controls Cybersecurity Program Management Risk Management

Transcript

Policies, standards, procedures and guidelines all work together to secure the organization that we work for, and so we set these up to manage our security program.

The order we develop them in

When we're creating a cybersecurity program, we're going to start developing things in a certain order. There are certain high-level policies that we will create first, and from those high-level policies, that blueprint of how we're going to operate, then we develop the standards. So we'll create the standards, and there will be lots of standards for each one of those policies that we have. Then from those standards we'll develop procedures that help fulfill those standards, which help fulfill the policies. So that's kind of how this plays out when we're creating a cybersecurity program.

A baking example

Let's go ahead and go through a baking example just so we have an understanding of what the differences are between these.

Let's say I want to give my kids some sort of treat, and so we're going to bake a delicious dessert on a regular basis. That's going to be our policy. It's very kind of up in the sky, not really well defined here, but that's what we're going to do. It sounds good to me, I think the kids are going to enjoy it.

So now we need to create some standards on it. We're going to bake a delicious cake on a monthly basis that the whole family is going to enjoy. What type of dessert? Well, a cake might be one of them, and maybe I have many different standards. Maybe I'm going to do brownies, or maybe I'm going to do donuts, or I'm going to do pie. So I'm going to bake these different desserts, but one of them is going to be cake. So this is one of my lines here, and that's the standard, that all the family is going to enjoy.

So now I've got the standard for that. The procedure would be like the recipe, the recipe that I'm going to follow to bake this cake.

And then the guidelines. Guidelines is not something I have to follow, but it might be nice to follow. So in this example, maybe I preheat the oven before mixing the ingredients, so that way it's ready, so once all the ingredients are mixed I can put it directly into the oven. This is going to save me time. So it's a little tip, a guideline that I can follow, but I don't have to follow it. Worst case scenario, I just turn on the oven after I mix the ingredients and put it in 10 minutes later.

Controls

And then there's a control. I mentioned that there's kind of three definitions of a control. It could be the same as a standard. It could be just anything that you implement, so really kind of top level there. Or when it comes to our different compliance, I find that it's very specific and there's some sort of outcome that's measurable, that we can prove that we've done this.

So what does a control look like? The cake will be baked on a monthly basis, and the whole family would rate it at least a seven out of 10 on a deliciousness scale. So what would you do? Let's create some sort of survey. After we bake the cake, the family will eat the cake, they'll rate the cake, and so we'll be able to see at the end of the month. We'll take a look and say, did we accomplish this? We've got all of the surveys from the family members, and let's take a look. Well, maybe we rated it mostly at an 8 out of 10, and we've accomplished this, that's good to go. Or maybe everybody rated a six out of 10; well, we have not accomplished it. Now there's some sort of proof of whether I followed through with this or not.

A technical example

The policy might be: we will perform maintenance on hardware and software. The standard is: machines will be patched on a monthly basis. Once again, I'll have lots of standards for this one policy, but in this case right here it's that machines will be patched on a monthly basis.

Procedures: what I'm going to do is I'm going to log on to patching software, I'm going to research the updates, the patches, and approve those patches, and then commit it so that way it sends all the patches out to the different machines. So those are the procedures I'm going to roll out.

The guidelines for this is, maybe sometimes you have to make a little bit of a judgment decision, based off of a patch might present a little bit of risk in itself in pushing it out, but at the same time if you don't patch it might be a risk. So I might need some guidance to determine whether I'm going to push out a certain patch or not.

And then what is a control? Well, a control gets much more specific here: 95% of machines will be patched on a monthly basis, and any machine that's not patched within 60 days must be removed from the network. Did I do it? Let's take a look at our patching reports. I take a look at the patching reports and I see that 96% of the machines are patched right now and there are no machines past 60 days, so we're good to go. Or I see, oh well, no, I'm at 94% and there's a machine out there that's been 65 days. Well, that's problematic, and now I need to take corrective action. So this is a more technical example of how we use policies, standards, procedures, guidelines and controls.

Two sets of documentation

One thing that I like to do is break this into two sets of documentation. I have the first set of documentation, which is our policies, standards and controls, and this is part of our WISP or ISP, our information security policy or written information security policy. And then down here we have our playbook, or our functional documentation. So this is what we're actually doing to carry out our procedures and our guidelines and all of that, what we're going to follow to actually implement things.

One reason why I do this is because I like to get exact approval over this. So I would create these upper level policies right here inside of our written information security policy, get the approval from the execs and from the higher up that this is acceptable, and then that allows this down here, our playbooks, to be much more dynamic. That way we can adjust things and improve things and do continuous improvement with this without the need to get approval every time we make a change.

Right-sizing

Now just realize there's a lot of different ways we could roll this out, and really there's a lot of flexibility in how we roll this out. What we want to do is we want to right-size this. That means that we want to adjust how many policies and standards and procedures and guidelines we have according to the size and the need of the company, the industry it's in, the requirements that we have. So we're going to make adjustments to how this is. For instance, I may have a lot of top high-level policies, or maybe I have just a few. Perhaps I have a lot of standards, or maybe I have just a few. I'm going to adjust it accordingly.

One of the examples of this is also where I put things. For instance, maybe I wanted to create, as part of the way we do business, that I want to follow up with users who haven't accepted the patches. So we're going to push out patches to user systems, they have to accept it so that way it installs on the system, and then maybe we are going to follow up if they have not done that process. But where does that live? Maybe I'm going to say we're going to do that at the 45-day mark, if they haven't rolled out a patch within 45 days.

What I could do is I could set this as a requirement as part of my information security policy, and then this becomes something that we are going to achieve. This is our policy and we're going to achieve this, and so it becomes something that's very high-level, what we're going to strive for, and then we work it into our procedures to make sure that happens. So that is one way we could do it.

Or maybe I say, this is something that I want to make sure we do, but it's not necessarily going to be at the policy level. I'm going to put it down here in the procedure level, and this allows us to be a little more flexible with it, because now if I need to change this, and maybe I'm going to say 30 days instead, or maybe I'm going to say 60 days, I don't necessarily have to get approval for that like I would our information security policy. So where you put things is going to vary a little bit depending on what you're trying to achieve and the size of your company.

About TechKnowSurge

TechKnowSurge builds IT and cybersecurity professionals through hands-on, concept-first training built around real understanding — not memorization. Free interactive tools, structured programs, and 25+ years of real-world experience, all in one place.

Explore free tools and programs →