Okay, so let's move on and talk about the policy life cycle, which, ideally is, of course, covering the policy from its creation all the way through its retirement or revisions. So the idea is that once you come into a kn organization as a scissor
chances a really good they already have some policies and standards in place, right?
Rarely are you gonna be walking in the door and they go, You know, we never had a policy before.
It's not gonna happen. So most of the time, what you're looking at is you're being brought in and you're gonna be asked to evaluate the policies that are in place and make modifications, or at least recommendations. So we want to talk about the life cycle here
when the policies are already in place. Of course, the first thing you're gonna do is you're gonna look at them, you're gonna review them
and take into consideration. Um, you know what your ultimate goals are and what you want to accomplish, and whether or not those policies air satisfying those needs many contract to consolidate policies, policies convey very much be, you know, traditionally,
policies are very poorly written and not very well organized.
They're not really phones, any sort of standard for how there's policy should be developed. So you're probably gonna have to come in and evaluate them, man, to consolidate that, have to do some rewriting. And then you're gonna also make sure that the policies that you write or a valid way they reviewed on a
Usually you want to review these policies at least once a year
or in the event of a major change, new risks come up or, um,
uh, modification to your organization, like, uh
ah. Merger or something of that nature.
Okay, so we've got the policy that's already been written and were brought in. We're gonna evaluate this. So what we're looking to do is we're looking to conduct the gap analysis. Uh, we look at current state versus Desired state is we've talked about earlier. So where are we? Where do we need to be?
So we're gonna conduct an assessment of our policies. We're gonna look at him and figure out the gaps, and ideally, we're gonna be able to close those gas and get closer to our desire to ST.
So our first piece here. We're gonna look at the policies and see what's missing, because many kinds their policies don't cover certain areas. And we're going to get a very high level level list
off what we need. You know what policies need to be created where we need enhancements to policies and we're gonna have to work on prioritization. So we're gonna have to put those most significant gaps first and develop and spend. Our resource is in our attention there.
A What we're looking to do is to create a prioritized enhancement list. Here, the enhancements we need Thio implement based on priority. And this is something that will work with the auditor on because the auditor's gonna be the most cognizant of,
uh, with the desired state should
be what we have to do to get into compliance. So this is going to be something that the scissors gonna work very closely hand in hand with the odds. All right. Ah, and we have to have reviewers and approve Ear's a policy in place. That's our next piece is we want to make sure that we know
who's gonna review the policy and who's going to sign.
so we talked about reviewing the policy. Depending on the type of policy, we may have different reviewers. Our security team, our subject matter experts legal may have to sign off whoever that may be. Whoever is
delegated with the responsibility of signing off on policy,
we have to make sure that that is established and documented. Now, ultimately, the system owner is gonna be the one to sign off on the policy. They're gonna be the ones to approve it, but we want to document those that are gonna review it. And you know what? Each step of the way we're gonna get that sign off.
Um, make sure your viewers know that this is something that you expect of them. Nothing worse than showing up with stack of folders and putting it on somebody's desk. So reviewers should know what their role is in relation to this gap analysis. Okay, what we're looking at here, what we should
provide when we're done is a list of reviewers
Who is going to review this policy for logic? Who is going to approve it with a perspective of functionality? Who's gonna prove it with function of security? You know, all these folks how they're gonna work together, and ultimately, we're gonna have that document.
All right, so now we take that, we're gonna create our policy where there were missing policies. Of course, we're gonna create new ones. Were their existing policies were gonna bridge the gap between what we need? What's there?
So we've gotten the feedback from those people that we delegated to be reviewers, like our subject matter expert auditors, all the different, uh, people that we brought into our team.
And ultimately, we're gonna have them go through and help us review the policy piece by piece by piece. And ultimately, they're gonna be following that enhancement list. And ultimately, through this process, we're going to create new documents, were gonna update the existing documents. So,
uh, we're gonna take those people that we identified,
and we're gonna use their knowledge, their skill and expertise, and we're gonna create the new policies and modify the existing ones. Now, of course, those policies have to be reviewed. So we're gonna bring this to senior management to the system owner, and we're gonna ask them, you know, does this meet the needs
off the system business, meet the business units needs
whatever we want to make sure that
the policies not just cover security issue. We want to make sure that they're well written that they're easy to understand that they're complete in nature.
you know, this third bullet points kind of interesting don't basin approval decision on whether or not the company is currently in compliance or currently performs what's documented.
Matter of fact, the whole policies help us is supposed to help us get to the desired state
with the understanding that current state isn't there. So putting policy in place or modifying policy just cause you're not compliant, Obviously that's not how we do business, right? We put the policy in place, even if we're not compliant. And ideally, we're gonna develop procedures to get into compliance.
Ultimately, we get are completed. Review. Now we're gonna have this policy and we're always gonna get pushback. People do not like change. Many people feel like any change. Guard, Lis. What it is is gonna make their load heavier. So
be prepared for push back. You know, when we look at Oh, we can't do this.
Well, we don't have the technology. Maybe it's time for an upgrade.
Well, our people aren't trained, we train our people. And I'm not saying that there are instances where the answer really is. This isn't feasible. Well, that might mean that we need to document an exception to the policy wherever that may be. But as a general rule, expect push backs and prepare your case.
You know, this is what we have to do. Move in four.
Here's why. Here is the lost potential here, the benefits and let's make a good decision moving forward,
all right, And then we take the feedback that were given from the review. We're going to send this to the author's bring them all in, and we're gonna look at the reviews and the comments on the policies on these documents, and we're gonna make changes that's legitimate,
that are changes that are legitimate or from legitimate suggestions
and making sure that we evaluate those changes with other members of the reviewers team.
Um, make sure that we're clear and communicating the issues off policy, and you see how very much this is a team procedure. This isn't just Mia's. The CSO san mark. This word out at this world word we really do make sure that our policies were gonna be effective
and we're gonna satisfy the need.
And the way that we do that is we bring a team together.
Um, now we've implemented the feedback and we've documented and he showed it changes were controlling the version ing of our policy. Now we believe that our policies well written and inclusive, we obtained approval
again. It's the system owners. Whether that system is an individual computer, it's division or team working together. We regardless of what that system is, we go to the system owners for approval. Also, you know, if we're talking about a company wide policy or individual entities that were
looking to create policy for
we go to the senior officers and we get there. Sign off
now, making sure again that we don't just take a stack of folders and sitting on somebody's desk. You know, this is gonna be something that ultimately we're really looking to gain approval. You know, this is our project that we've managed, and we feel like we've designed these policies to bring us into compliance.
We want to do our best to make these
easy to understand for senior management, not overwhelmed them. So maybe scheduling a time once a week, a couple of times a week to meet with them and go over policies for specific security risks or security functions, but making sure that we break it down and make it
And ultimately what we are looking for is to get approval from the senior executives. These air the policies we want
now. At that point in time, we're really we've really completed the life cycle off the policy revision process.