Security policies form the foundation of any security program, serving as the high-level governing principles that define what an organization is trying to achieve and how it will operate. Understanding the distinction between policies, standards, procedures, and guidelines is essential for building and managing an effective security program.
Security Policies
To a certain degree, your policies are the core of your security program. They set the foundation for everything else and how it's going to operate.
Policies, along with standards, procedures, guidelines and controls, help define what our security program is and how it functions. But a lot of this other material — standards, procedures, guidelines and controls — is really built off of policies. Policies are governing principles. It's kind of like setting the targets from a very high level. We can think of them as the blueprints, what we're trying to achieve. It's not the achievement in itself, but what it is that we're aiming for.
One of the things that these policies do is set expectations. They may come from upper management, like maybe the execs within the company, or maybe it comes from a security department. So it sets the expectations of how people are going to operate within the company.
One of the great things about starting out with policies is you can start creating agreements — that is, your security department is probably working with the execs to come up with these policies. The reason why that's important is because the security department is going to make lots of changes, and that's going to affect the users of the company, all of the different operators of the company, all the employees within this company. Since you're affecting what they're doing and how they're going about doing things, you're going to have some people that are going to complain about that. But as long as you and the execs are on the same page with what it is that you're trying to set out to accomplish, then you have some backing from the execs as you're trying to implement changes with the employees.
So what are some examples of policies? One of them is an information security policy, which I'll actually tackle in another lesson. Or we could get into a business continuity policy, or a disaster recovery policy, in case things go terribly awry and we need to be able to fix things. We could have a software development life cycle policy, an SDLC, so as we develop software for a company we make sure that it falls under certain guidelines. We can have a change management policy, so how we implement changes within our network, within our infrastructure. We could have an acceptable use policy, an AUP — we should definitely have an AUP. We should probably have a password policy.
There are different levels to policies, and I kind of break this up into two categories. You have the high-level security policies that really set the overall tone for how the security program is going to operate. Examples of that might be the business continuity plan, disaster recovery plan, incident response plan, the SDLC. But you also have a system specific or an issue specific policy, so this would be things like email policy, acceptable use policy, password policy, payroll system policy, social media policy.
The high-level policy really is that foundation for the security program and how the security program is going to operate — what it is that you're trying to achieve, that blueprint for the whole security program and how it's going to operate. So once again, you've got the business continuity or the access control policy, risk management policy; these are all examples of those high-level policies, and we'd wrap these up into an information security policy.
But there are policies that operate more in the weeds of things. What I mean by that is that there are policies that we create to help give guidance, a blueprint, for how people are going to operate, and it may be around a specific system or a specific issue. Some examples of that might be social media, how they're supposed to respond on social media; it might be around payroll systems, if we have a payroll system and how we operate with that; email and how we utilise email; an acceptable use policy; how we create secure passwords; a work from home policy; how to use different systems like a CRM system.
These are some examples of policies that we may even go to the extent of having our users sign. For instance, the acceptable use policy is definitely one that I would have, and I would make my users sign that. If we made any changes to that acceptable use policy, we would make them sign those changes as we update things. Same thing with things like the password policy.
Policies are usually separate from an actual plan. The policy is the blueprint of what we need to build. So we've got our policies and standards over here — those governing principles — and then we have the actual plans or procedures or guidelines, things that we're going to use. So we have some sort of operational procedures that people are actually going to carry out.
Let's say an example is a disaster recovery policy. We're going to set the tone for how we're going to prepare for a disaster if a disaster were to ever hit: what kind of plan, what is it going to look like, what are some of the details like an RPO and RTO for that, and how often will it be tested. Whereas on the more procedural or plan side of this, we may have a disaster recovery plan as well, and that disaster recovery plan helps identify when we're going to have a DR scenario, when we're actually going to implement this, what are the actual steps that we're going to follow to fail over to a DR site, and steps to test this plan out. So much more detail for the end users who are actually carrying out these functions, versus the policies.
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 →