Policies have life cycles associated with them just like everything else we talk about. Some policies are going to be around for a long, long time, and they're going to be revised over time, they are living documents that we will use. Others will be around for a very narrowly defined period of time and then ultimately will disappear or be replaced by something else. One of the things we often miss, and as an SSCP you should be aware of, is that policies have to be constantly reviewed and refreshed against the technology that we are using today and against the technology that we may be deploying tomorrow. What I mean by that is if you're a company today, hypothetically, that really does not do much in the cloud right now, doesn't do much with virtualization, really doesn't do anything with containerization or any of the convergence technologies that we often talk about and think about today, then you may not have policies that govern that kind of use in those kinds of systems and the behavior expected from users with that. But if you start moving into those areas over time, you will need to develop policies that speak to those things. If you don't have those policies but you deploy the technology, you have a gap in your management strategy, and SSCPs have to be able to step up and understand how to address that because that can lead to risk and those risks can become very, very problematic for the system and for the company overall if we're not careful. So we want to make sure that we're, every so often, maybe every six months, once a year, it will vary depending on the nature of the business and how big the organization is, but at least once a year, if not twice or more, you want to review the current policies you have in place, look at them and kind of hold them up against the current systems you're managing, the current services you're offering, and make sure that they are mapped in some way so you can see clear alignment that you have one or more policies that address all the systems and services that are in play. If you have services that are going to come online, make sure you have policies that are prepared to deal with them. If you are updating systems and services to reflect new offerings, make sure policies get a refresh and are updated as well. So it's very important and you want to make sure you're aware of that and thinking about that. When we define and talk about standards and guidelines, we're going to start to narrow that focus a little bit as we talked about, you know, policies, very broad strategic overview of the intent that we want to address, shaping the general thought process of the user. Standards are formal document requirements, as you can see, that give us a kind of a specified way of doing things for some sort of technology or method that we're going to use. Hey, this is what we're going to do and this is the specification that we're going to follow in order to do it. That's what a standard is. Guidelines are recommended practices to be followed. They're not mandatory, they usually are a compilation of best practices or internal offerings and ideas that we've come up with that kind of make sense, but they're not mandatory, they don't have to be followed. They're just recommendations that may or may not prove to be valuable. Standards, on the other hand, may be implemented from some sort of regulatory standpoint. In other words, we may be told this is the way you need to do it, and this is the reason why and this is the law or the regulation you are following in order to achieve this end result. So, standards typically have to be implemented. There usually is some sort of regulatory push behind them or at least a industry specificity that we are addressing that is behind them, whereas guidelines will typically not fall into that category. They may certainly be recommendations but they may or may not need to be implemented. They are optional as opposed to required. I want to make sure we understand the difference there between the two. And then finally, as we talk about procedures, these are the very tactical, specified, individual step-by-step documents or step-by-step solutions that we lay out that are going to tell end users and managers and operators and whoever exactly what needs to happen so that we can go from point A to point D and all the stops along the way in order to make that journey and to do so according to whatever the specific issue is or concern is that we're addressing. So, we want to make sure we're aware of that procedure, step- -by-step instructions, right? Go here, do this, then do this. When you're done, put this back and then go and report in over here. That's a procedure. So, if you think about a cookbook and a step-by-step recipe to make something, that's effectively what a procedure is and that's what we're talking about. As we think about the different elements here, with controls, technical, operational, managerial, when we think about the policies, standards, guidelines and procedures that we use and use to frame and interact with around our management of how not only controls can be seen to be implemented but how actions can be governed how they can be documented, how they can be tracked, how we can have visibility into them within the organization, the SSCP needs to be aware of these terms, these elements that we use as building blocks to be able to shape behavior and give direction to people at various levels and in various ways within the organization and we have to bring in controls as well as policy, guidelines, standards and procedures to bear in order to be able to fully document and fully help the users and the people within our systems to understand what the expectations are for usage of the system but always with an eye towards confidentiality, integrity, and availability. It's very important for us to be able to give people guidance. It's really one of the key things that SSCPs are looked to to be able to do: provide direction, provide guidance, help us to understand exactly what it is you expect of us, give us the rules, shake the playing field for us, constrain it, control it, understand through our eyes what we will see and we will expect and we will need to know, and then help us through documentation and policies and procedures and controls to operate that way by explaining to us what the expectations are. If the SSCPs can do these and do them well, we're going to be successful. Please make sure you take time to review our conversations in this area. Make sure you are successful. Make sure you set yourself up to be successful as you study and prepare for these questions on the exam, and equally importantly and even more so, in the real world, as you look to work with existing policies, existing procedures, make sure you refresh them, make sure you document them, make sure that they are aligned with the business requirements as we discussed and make sure every so often you check in to make sure they're still relevant. Nothing worse than trotting out a group of policies and procedures for a brand new hire, and they ask you why you still have a procedure that talks about how to disable your modem on the mobile devices that you're using when you don't have modems in laptops anymore. Doesn't give that new hire a lot of confidence and the technical integrity and the technical prowess of the organization, and it is going to just effectively be embarrassing because you're talking about things you no longer do. Get rid of all that stuff that's distracting, focus on the things that are relevant, and you will ensure the success and security through confidentiality, integrity, and availability of the systems you're being asked to manage.
