- We're making our way through Course 5.
We're in video four where we talk about
where are we now and where do we want to go.
We got to realize where we are.
So that may take a little bit of review
and we want to think where do we want to get to go,
how do we get there?
Okay, so figure out where you are now.
What do we have now?
So what do we have in terms of documents?
And then where do we want to go?
We're planning a document project, we need to know
where we are, what do we have, right?
We got to know what documents we have to know
what documents we need to improve or create.
Then we're planning where we want to go
and how we want to get there.
Okay, do you recognize this painting?
Let's see if you do.
Anybody recognize it?
It is "The Creation of Adam" in the Sistine Chapels
by Michelangelo, 1511 or so.
What you did not know is he was illustrating a policy course
and you have not seen his early sketches,
which I am going to show you right now.
This was his early sketch
as he was creating his policy course
before he did the Sistine Chapels.
Of course, I'm kidding
and I'm kidding about his copyright too.
Copyright actually expires after a certain number of years.
Michelangelo's copyright expired long ago.
In fact, they probably didn't even
have copyright back then, they didn't.
This is my sketch, I am no Michelangelo,
but this is my way of saying you are here
and this cartoon figure is pointing to where to go.
So you got to think where to go.
It'd be easy if we knew where to go.
And there are all these potential
destinations of where to go.
You got to lay out your options, pick your option,
and then plot a course on how to get there.
And of course, we're planning the project
so we don't have all the answers.
Some of those things we're going to figure out
during the policy project.
But we have to scope it out.
So we got to think where do we want to be?
So we can talk about that as the current state
and the desired future state.
Or maybe we call the current state as-is
and the future state to-be.
And then we do a gap analysis
or we figure out what's the delta, the change?
What do we need to do to get us from
where we are to where we want to be?
So as we do that, remember our ethics video
and we want to be honest, we want to be accurate,
we want to be realistic, right?
When we first start to deceive what a tangled web we weave,
if we're honest about where we are and where we want to be,
we can do a better project and improve the organization.
And that's the goal.
All right, where possible, let's try not
to step on too many toes too hard,
or maybe we don't step on any, right?
We want to consider the people
and the culture in the organization.
What will be received well?
What might not be received well?
Sometimes, and hopefully initiative
and innovation are well received, sometimes not.
And we got to remember, we may be thinking
of a great improvement on something that really stinks now,
but maybe someone else built what we think stinks.
So we might want to be careful about that.
Information security, I think it's about people
and the decisions people make.
Yeah, there's a lot of technology involved,
but it's people decisions about technology.
You work for people, you work with people,
so that diplomacy and relationships are important.
Some people are really busy,
some people might feel threatened or second guessed.
So we do want to keep that in our mind as we plot the best way
to propose things and do things.
You know, some organization members have worked on policies.
Diplomacy is always important.
Let's find ways to interact positively, meet people,
gain information, make positive changes,
and try to avoid stomping on their toes,
alienating people if we don't need to,
or giving the impression we're trying
to take over someone's turf.
And we want to be careful how we criticize things
because someone worked on that or wrote it
and there may be existing tensions
and conflicts between departments and people.
That said, to make an omelet,
sometimes you just have to break some eggs.
And I guess the egg is not happy getting broken, right?
You can tell I'm no Michelangelo, but I try, right?
Okay, so where are you now?
What documents do you have now?
And what can you learn about the documents you have?
In theory, that's the easiest thing to figure out.
Inventory what you've got.
And that inventory can include the names,
filenames, dates, et cetera.
Of course, sometimes the names are not accurate,
filenames don't track.
It can sometimes be a little confusing.
But the goal is you do not want
to create duplicate documents.
You don't want to have two information security policies.
I would think you don't want
to have an information security policy
and a cybersecurity policy.
You don't want things to overlap.
You don't want to duplicate language across documents.
So you do want to cross reference appropriately.
We want to think of the levels of the document.
So if your project is this type of document,
you want to know what the higher level documents are.
You might not be touching them,
but your documents have to comply
with the higher level documents.
And you know, mid level, lower level,
you want to know what's there.
You want to know who created them and how,
who approved them, who was involved and who was left out.
Sometimes this is easier said than done, right?
Project one time, it was hard to know
where that earlier thing came from
and ultimately, they got it from the internet,
but they didn't want to admit that right away, right?
You want to try for assess
what are the strengths and weaknesses.
What do various stakeholders think?
Who created, updated, wrote and approved them?
And you know, existing documents,
they're going to have some precedence,
to use a legal term, or inertia.
They're kind of the status quo.
But that doesn't mean they're good and can't be improved
or it doesn't mean they're the best they can be.
So we're thinking what should be updated?
What should be phased out?
I know this is a lot of stuff
and maybe you're not going to go
through an exhaustive review like this,
but just things to think about.
So we're taking stock, we're taking an inventory
to the appropriate level of detail for the time we got.
What approved documents exist?
Are there any approved documents
that are obsolete or no longer enforced
or they're technically enforced but they shouldn't be?
Are there any draft documents you should review?
Did they try to start up this project two years ago
and then they abandoned it and they had a draft
that's good or that got close?
Maybe that's something you need to look at.
Let's do an inventory, a policy, standards, procedures.
You know, the basics would be the official title,
maybe a short title, filename, revision date, approval date.
Think about the content, how is that content?
Is it good, not so good?
Does the name describe the contents?
Is there duplication within the document
or across documents?
Are there contradictions?
What's the quality like?
You got written rules,
think about reading the with a fresh eye.
This might mean you reading it with a new eye,
like, "Hey, how would I,
"if I actually read this word by word, sentence by sentence,
"like, does this make sense?
"Is this what we really do?"
You could test it or have a new person read it,
might be a new employee.
Say, "Here's the rules.
"We'd like you to learn 'em, follow 'em and test 'em,
"and also give us feedback 'cause maybe we're not,
"maybe this is not written as well as they could be."
Or you could cross-train another employee and see
if they work what that other employee thinks, right?
Fresh eyes.
Now I've got a policy review checklist if you need it.
Recognizing at this stage in the planning,
you might want to limit the amount of detail that you cover
because, you know, we want to be efficient with the time
and resources we're putting into this.
But this checklist is available on my site,
the Policy Checklist.
And I'll also have this link
in the References slide towards the end.
And you're looking at your situation.
What is the gap we are closing and why?
How do we get to where we want to be?
What do we need document-wise,
if I can make that word up.
Maybe we have no documents or no documents
in that area and need to create some.
Maybe we have a few, but we need to create more.
Maybe we have some documents, we just need
to update them and improve them, add a couple things.
Or maybe we have some documents but we hate 'em,
want to throw 'em out and never look
at 'em again and start over.
So what do we need?
That's where we want to be.
What documents do we need, what's our end stage?
And can we get project approval to create these documents?
So remember those five components of policy work?
Let's think how can we do this step by step?
Not doing too much, maybe a modular approach.
We want to right size things for our organization,
for our organization size, our risks,
our level of maturity for cybersecurity,
yet we also want to plan for growth and evolution, right?
We want to build a house, build documents
that we can grow with, add to, adapt, increase,
and that's where the modularity helps.
So what do we really need and why?
And then how are we going to need to crosswalk it
or map it to either compliance tools,
frameworks, laws, our audit,
you know, so how is that layer going to happen too?
And of course, we are creating and improving internal rules.
So we got the internal rules platform,
and those rules might be unwritten, verbal, or cultural.
Look, I know this path is about documents,
but we can't ignore the fact that there are verbal
and cultural rules that apply and are important.
And we don't document every single rule or instruction.
Then there's the written rules, or written...
Well, I'll get to that in a sec.
We might call these governance documents
that at the top, we got bylaws
and articles of incorporation, maybe,
articles of organization, whatever you call it,
then policies, standards,
guidelines, I'll get to that in a sec,
Procedures, manuals, handbooks, and more.
And those are all internal rules.
Now let's talk about guidelines a second.
You know, the way I think about it,
a guideline is not a rule, it's a guideline,
but we have to talk about it here in this path
because it's a written document.
And if we're updating our documentation
and we have guidelines, yeah, they're not a rule,
they're internal guidance.
But we want our internal guidance in everything
that we write to be clear, accurate,
and aligned with everything else, make sense?
All right, remember, policies are general,
they're not detailed.
They don't or should not need to be changed frequently,
approved at a high level,
and have a high level of authority.
And standards and procedures comply
with the policies which are above them.
Standards, more detail than a policy,
less detail than a procedure,
are going to need more frequent change than a policy,
but less frequent than a procedure
and a intermediate level of approval.
Guidelines, not a rule,
guidance to help comply with rules.
I'll call 'em internal guidance,
distinguish 'em from external guidance,
and they might have similar level of detail as a standard.
Procedures have more detail than a standard
and much more detail than a policy,
step-by-step instructions to accomplish a task,
need to be updated more frequently.
If you change the tool, change the technology,
change the business needs, you got to update the procedures.
And a lower level of approval.
Let's talk a sec about plan and procedure pitfalls.
Groot and the jailbreak analogy.
Remember, I talked about that in a Course 1 video
when I was talking about the people
who write, read, and approve policies.
And I talked about that scene from "Guardians of the Galaxy"
where they're talking about how to escape from jail
and Groot is a great guy, not guy, he's a humanoid,
but he's not the sharpest tool in the drawer.
And as Rocket, the raccoon, is explaining the procedure,
the plan for breaking out of the jail,
Rocket gives the plan out of order.
And he tells Groot what Groot is going to need to do
but he doesn't tell Groot or anybody until the end
that Groot should not grab that blinky light thing
until after other things have been done.
So Groot acts on the instruction
without knowing when it should take place.
So we want to think about things like that in the plan.
How is it read, how are people going to read it?
I guarantee none of you have a a humanoid on your team,
but still, we think about how clearly things are written
and how people will read 'em.
You know, recipes are another good example, right?
So imagine a recipe that gives 20 steps
and then it never mentions anything about the oven,
and then it says, "Place it into a preheated oven at 475."
And you're like, "You know, I was,
"for 45 minutes I've been doing this recipe
"and I didn't know I had to preheat the oven.
"I wish that was step number one: preheat the oven,
"so when I got to step 20: put it in the preheated oven,
"it would already be preheated."
So just an example, a way a plan
or procedure can lay out what to do when,
depending on who's reading it,
especially if we're busy or stressed,
such as incident response.
You know, ingredients or instructions,
if you say one 16-ounce can of tomatoes
and you read that and you did the numeral one
and numeral one-six, if you read that quickly,
might you think 116-ounce can of tomatoes?
So you know, we're looking at things
from different perspectives on
how someone might read our written word.
And there are other documents too, okay?
Manual handbooks and more,
like that can all be part
of a security document project or any document project.
So whatever you call the documents,
we can apply these project management planning principles
and of course the execution principles.
And remember the goal,
don't forget the big picture for the organization.
We want improved efficiency, accomplishment of the mission,
protecting from cyber crime, and compliance.
Okay, references as always for this course
and the next Policy Project Planning and Execution.
The Policy Checklist on my website too,
it's got a list of things to think about.
How to Write a Paper, I wrote that for my students,
but I think it also helps when we're looking
at documents and writing documents,
it helps us to plan that project.
And Paper Submission project, again,
I did that for my students submitting papers,
but you know, if we're submitting our 10-page policy,
30-page policy, it's got a good checklist
that's helpful there too.
And as always, these resources.
Okay, wrapping this one up,
figure out what you have, figure out where you want to go,
plan to close the gap and how to get there.
See you in the next video, bye-bye.