Welcome to Cash in the Cyber Sheets. I'm your host, James Bowers, and together we'll work with business leaders and industry experts to dive into the misunderstood business of cybersecurity and compliance to learn how to start making money from being secure and compliant. Welcome to Cash in the Cyber Sheets.
Hey everybody, welcome back to Cash in the Cyber Sheets. I'm your host, James Bowers, Chief Security and Compliance Architect here with Input Output. Very happy to have you back here with us today. And today, we are actually going to jump into an information security policy document example.
We actually have set up, getting a lot more set up on the website. And one of the things is actually are a part of the entire WISP that we have, the Written Information Security Program, and it's the entire first part of that with the table of contents, the core structure, really some of the biggest goodies with that, all completely for free. So that way you can dive in, really understand how to set up your own information security policy, the different components you need, and hopefully, if that's really all that you needed to get you over the hump, then you don't need to pay anything for it.
That way, you get what you need, you get your policies all put together, the organization a little bit more secure, and hopefully down the road, you thought it was so cool that we did that, that you'll come to us for audits and other things. But what I thought we should do today is actually just dive right into that entire document that we're giving away, the very first part, the governance domain. We'll get in a little bit to that.
But really today, I'm just going to go straight through that document. I'm just going to kind of write it up here, and we'll have a link in the description for this podcast, which will actually take you right to where you can download that completely free of charge. And what's cool is even over a little bit, we'll even send out some other emails with some other goodies that go with it, all completely for free.
So really just hoping we can help get you a little bit more secure, a little bit more compliant, and really just make it a lot easier, because the way we put these together is pretty easy. So before we get started, please click that like, click that subscribe, and as always, if there's things you want to hear about, if you have any comments, suggestions, things you're having trouble with, or even some success you've had in your security program, go ahead and drop those in. We'd love to hear about them and be able to better support you and also help celebrate some of your wins.
So with all of that said, let's dive right into it. Now, when we get into the actual document, the WISP, this is really the entire WISP document, just not all of the pages. So it's the exact same document, exact same structure, all the way up through basically page 25.
So it's not missing anything there except the other domains, that's the other meat and potatoes. But we're not cutting other things out, it's not an email. So what you'll see when you first start going through, really kind of page three, what is it, triple I, but it's the document inversion control.
This is something that when we're doing audits, that is missed so many times with so many companies, is their policies, their procedures, their forms, they don't have appropriate document inversion control. And it doesn't need to be complicated. When you think about it and kind of start from scratch, it might seem a little daunting. It doesn't need to be. On our document here, it just has the form number right there at top. There it is.
You can't see me mark that, but I did. The form type, we designate between global policies, procedures, yada, yada. That's not so important, but something we do to help make putting them in different folders, keeping track of things a little easier.
Obviously, the name of the document and then the scope. Now, we'll have a scoping statement a little bit later, but to make it easy, we point our scope to the scope of the information security program. That is typically what all of your policies are going to be.
It may be a little bit different if you have, say, department procedures or certain policies that only apply to certain areas of the organization. Or if you have, say, a separate ISMS aside from a quality management system, maybe you have like a clinical laboratory and you have the tech side and you've split those up to make compliance and certification a little bit easier, then your scope statement here may point differently. Otherwise, it's typically the entire security program and not the whole organization, but the whole security program.
We'll have a version number. That's normally going to be like a version A, version B. That could be a version numbering system like a 1.0, 1.1, so that way you can designate big changes and small changes. Some organizations, some businesses we work with, like to set it up to where if it's a whole number change, then that is something that needs training.
If it's a fraction, so if it's going from 1.1 to 1.2, that's just a minor change that doesn't require training. No right or wrong there. However you want to set it up.
What's very important on here is our ownership. Basically, the document approver, the document owner, this is the head on the chopping block. If things go sideways, if this doesn't get done, if this doesn't get executed, this is the person that is going to get executed.
They're the ones whose butt's on the line. Ultimately, signing off and taking responsibility that everything is accurate and executed. On top of the owner, we also want to have, it could be a custodian, it could be a reviewer, it could be a preparer, it could be somebody else other than that owner, other than that ultimate approver that is reviewing this, helping to put it together.
That way, it's two sets of eyes on it, and that helps with your segregation of duties. Not going to dive deep into that today, but you do want to make sure it's documented on your document. We also have on ours where version management and authorization management is managed.
It can easily be right on the document itself, so that could be wet signatures right on it, and you just feed that right into a notebook or with the policy or scan it in. You could use DocuSign, PandaDoc. I'm not giving any particular kudos to any of those, just any e-sign solution you want to use, or if you have a GRC or document management platform, you could even point to that.
That's where we're doing our approval, just to let an auditor know, let your team know, you're not going to see the signature here, it's going to be in whatever platform that is. Same with the version management. Again, you can manage that right in the document, you could manage that in a platform.
It is good to document where you're doing that right in the document itself though. And then finally at the bottom you'll notice the actual change record. So that's where it shows each version, what was changed, who prepared, who the reviewer was, is training required, yes or no, and the date that this was executed.
And you want to make sure that every time there's a change that you're listing all the changes that you did. Now, different companies do this different ways, some do it in this document version control, others will point somewhere else and have the changes. I think it's just easy enough to point here and you could list the pages that you changed, you could make notes of what you changed, but it is good to document that in here.
And whenever you're making a change, make sure you retain the old copy. Typically that's for about six and a half to seven years, that's typically under HIPAA. Other regulatory controls have other requirements, but a good rule of thumb is typically seven years to keep those older versions.
So continuing, it would not be a true policy if we didn't have some of those page intentionally left blank pages, and we've got those on here. That way you know it's actually serious, a real document. Then we get into our table of contents.
Now, depending on how your word refreshes, how your system refreshes, this may look a little bit messier, just because after page 25, all of those pages aren't there. They're still in the table of contents, but there's nothing to reference. So it may just start popping a lot of errors saying it's not defined, but even without that, we can see that we've got the initial, all of the document version, table of contents, leadership commitment statement, implementation clause, policy overview.
We're going to quickly go through all of those, and then we have our whole governance section. After that, we also have all of our other domains, our risk management, our data classification and handling, human resource security and management, yada, yada, yada, and it has each of the different controls. So here's what's really cool about that.
If you downloaded the sample document, if you downloaded this and you're using it, and you're going through the governance section, you're getting that all completed, now what you can do is just look at this table of contents and say, okay, now I need to do a risk management domain, and I need to do risk management and planning. I'll write my language for that, and I'm basically going to do it in the same structure that was in the governance side. Now I'm going to do ISP objectives and KPIs, and you can go right down this table of contents to make sure you're getting all of the different controls, all of the different policy sections that you need to really be compliant.
Obviously, if you want to make it even easier, you can download our entire WISP, which has all this filled out, all the policies and procedures, everything, even online access to us to where you can jump into different webinars, different group sessions, and we can help you through the whole thing. But if you're doing this on a budget or you just needed that little oomph, that little push, this is going to give you all of those controls right there, and you can really use this table of contents in this sample document as your checklist for all the controls. So kind of a really cool way that you can use this.
I'm going to skip forward here a little bit, and being respectful of our time, I'm going to try to move through this a little bit quicker. Now the leadership commitment statement, you want to make sure you have one of these. This just shows that leadership is involved, that they are standing behind this, that they authorize it, and in some way there's going to be some hell to pay if you're not following this, however you want to explain that.
But you want to make sure to have some sort of leadership commitment statement. You really don't need to change this around. Input your company information there, your senior management that's signing off on it, and you should be good.
You're welcome to change it as much as you want, but again, you don't need to make things harder on yourself. Your implementation clause. You want to have one of these, whether it's in your policy, whether it's somewhere else, I figure just keep it all together, keep it in the policy, but this is where you're actually signing off and saying, this is the date that this policy, that this security program is active and enforceable, and this is the information security program execution, and this is the principal, the owner, or the very senior management position, and also you want to have the ISP director.
That could be the same person. That's perfectly okay, but if they're separate, you want to make sure to have those, and it is good to have, if you can, have it separate to where, again, it's top management dictating and providing the resources to the team to manage the information security program. It just helps show that separation between audit and execution, directive and execution, and also leadership's involvement.
This you will not sign until typically you have the entire policy done, so put a little flag on that, and you'll come back to that one. We've got another intentionally blank page. That way you know it's super serious.
We've got a lot of those, and here we have our policy overview section. This is really the boilerplates. You want to have your purpose.
Your purpose should state the reason for the policy, and it really, if you can, should tie to the different standards that you're looking to comply with. If there's any particular stakeholder requirements, say you're a startup and you've got a lot of seed money and they require a security program, you'd want to put that in here. For the case of our document, it's really geared towards a lot of financial companies and firms that are under the FTC safeguards rule, so you see that right there, and right under it, Graham-Leach-Bliley Act, as well as FTC financial privacy requirements, and since so many CPAs and financial firms use this, the IRS Publication 4557.
Again, if you've got to be PCI, any of those, just put those there. Don't overthink this, though. You're not really going to get your hand slapped if you don't get the language exactly right, so rough is enough.
Scope and applicability. You want to put guidelines around your security program. Now, a lot of companies, especially smaller ones, this is going to be the entire organization.
As you get larger, however, this is where you're going to want to segment things, and this is very important, especially if you go for, like, an ISO 27001 or a SOC 2 or other certification. You want to narrow the scope as much as you realistically can, so that way you're spending less money, it's less headache, it's less to manage, and less oversight. That's something we've had some discussions about before, and I think we'll set up even some more about it, because it's real important.
There's a lot to go over there. Violations. You're going to get your hand slapped or fired if you don't follow this.
Exceptions. I would identify how you manage exceptions within ours. They're addressed by the ISP board and documented within the risk register.
That's part of the full WISP. And then terms and definitions. Now, one thing we do, if you notice at the bottom in the footnotes, is we actually reference NIST IR 7298.
That just has tons of common security terms, so that way we're not listing all of them here. And the same with the NIST Computer Security Resource Center glossary. But some of the things we have in here, like the CIAPS, the IOGRCF, the Input Output Governance Risk and Compliance Framework, some of the other things we have documented right in here, just for easy reference.
Continuing on, we've got our roles and responsibilities. This is where we're identifying the different role within the organization and the responsibility that role has to the information security program. Just a few here, We've got the ISP director, a ISP board member, IT, the director of IT, human resources, so on and so forth.
And then getting into the actual policy language, I'm not going to go through the policy language. That's not the point of this, but more of the structure. You can see at the top we've got our domain, where we talk about what that domain means. And within our document here, within our IOGRCF, our whole framework, the domains are just logical groupings. So all of the governance controls are just things related to the governance of the information security program.
All of the HRS, human resource security management, it's all human resource security training, HR management style of controls. So not too difficult to understand there. We then have all of the, each of the different sections broken up by kind of the general control.
And then those are footnoted that actually reference the IOGRCF control and then the different regulatory standards and frameworks that section addresses. So here for 1.1, ISP security, privacy, and organizational governance, that's taking care of FTC safeguards rule 314.4a, E2, taking care of HIPAA, taking care of some ISO controls, some NIST, some PCI, all kinds of things in there. I spoke too soon. I didn't list PCI on this one just yet.
But then as you continue through, you can see the policy language just continues to reference all of those controls. So it makes it very easy to, one, as you're doing an audit, to look, reference that control requirement and see, does this language actually do it? Is there anything missing? Is there anything that we need to change? And if you ever have an auditor or you ever have a client asking about certain controls, it's very easy to search within this policy document to see where that's at.
So that way you don't need to remember everything. It just makes it very, very handy to do a quick control F, search for the control they're looking for, and bam, they'll take you right to it. It was a loud snap.
That really came through. All right. Let's just scope here to the end real quick.
And one of the ways that we've put together the document you'll see here with this one is in the appendices of each of the domains is really the meat and potatoes. All of that policy language that we went through, most of that doesn't really need to change. That's high-level policy.
That's core requirements that are meeting the regulatory requirements. But for the most part, you're not going to need to tweak that too much. What you will need to do, though, is fill out the information in the appendices.
So here for this first one, we're going to identify who our information security program director is, if we're using an outside company, all the questions for that, and because senior management always has to be involved, we're also going to identify who it is in senior management that's going to oversee this person or that external affiliate. The next appendices in this sample document is going to be the roles and responsibilities, but here we're going to actually identify the responsible party. So we're just going to go down this list and start identifying.
Who's our senior management member that's going to oversee this? Well, that's Bob. And what about the ISP director? Well, we've got a small organization, so that's Bob too. And our data privacy officer? Well, that's Lucy.
She is actually kind of legal. IT director? Well, that's our outside company, Acme Tech, so on and so forth. You get the idea.
It just makes it very easy, though, to go down and answer those questions of who's doing what, and once you've done that, you've gotten a very big part of your roles and responsibilities requirements taken care of. Don't overlook the simplicity of it.
Next part, ISP stakeholder and communication matrix. Not typically too much here to update, but again, in the appendices, this is where you want to look to make sure, is this correct? Is there a different way that we would want to do this? One thing I will say here is if you're really starting to get into it, especially if you're a high S, high C on the disk profile, you're probably thinking of all kinds of other things you need to identify, and that's good, but don't drive yourself nuts here. Especially on your first go through, rough is enough. Let's get you to 85%, 90% of the core structure there.
Make notes of the things that you would want to improve, that you think that you could be better, things that you'd want to flesh out even more, and then once you've gotten everything implemented, come back and do those improvements. If what you do is you try and get it all right, right from the beginning, or perfect in the beginning, you're going to end up spinning your wheels. The projects are not going to continue.
You're not going to see the progress. You're going to lose the involvement and the support of leadership because they're not going to see the progress, and ultimately, you're going to get frustrated. It's going to stagnate everything, and with what we see a lot is it's going to get put up on the shelf, and now six, seven, eight months later, even with basically a compliance paint by numbers, it's still just sitting there.
So please heed this advice. Rough is enough. You can't steer a parked car.
Get done what you can get done now, and come back and improve. It's much better to have a security program in place that you're working to improve than nothing at all that you're trying to get perfect before implementing it.
Our next one, mission objectives, obligations, and organizational context. We've definitely talked about this before. We'll talk about this again in other episodes, but this is very important. You want to identify the purpose of the organization, your industry context, how you fit in, are you a big player, are you a small niche player, the mission of the organization, and then your objectives, ultimately how you make money and your obligations, all the things you have to do, all the non-negotiables.
We have to meet these contract requirements. We have these regulations, so on and so forth. This is very important to not skip.
This is very important to not go too light on, because this whole section is going to tie in when you start doing your risk planning, when you start doing your risk analysis, it's going to tie directly to this. This is how you start marrying those things to the business. We also have primary inputs and outputs there at the bottom.
A lot of times, especially on first go through, companies will leave that blank. Perfectly okay, but you can start identifying those, which will help with your risk assessment process. The final one here is just a core audit structure, different things you need to do and at what times.
You're welcome to update that. You don't really need to, but easy reference right there. The appendices, as I said, are typically where you'll really do the bulk of the updating, and you can also pull those out to where it would be easy reference.
I don't necessarily need to reference all the policy language all the time, but I do need to see when we're going to be performing our audits. I could have that even just on a cork board and check it off as I'm doing them, however you want to do it. For those of you that still use cork boards, probably showing my age.
In any case, that takes us to the end, our very last intentionally left blank page, and that is our entire sample document. It is the entire first domain. It provides all of the controls and the entire structure there that you're going to need for the rest of your information security program.
And of course, we can make it so much easier. If you're diving in with this, you like what you saw, this made it super easy. The entire WISP has all of the domains, has all of the structure, has all of the forms and the procedures, the risk register, everything that you need to meet those compliance requirements and to quickly get through it.
We are also always here with any questions. More than happy to connect to help you get through it, help you be secure and compliant in your business. With all of that said, I will finish up today with thank you very much for listening today.
Go ahead, and if you haven't already downloaded it, click that link in the description to get your copy of the template. Thank you very much, and until next time.
Thanks for joining us today. Don't forget, click that subscribe button, leave us a review, and share it with your network. Remember, security and compliance aren't just about avoiding risk. They're about unlocking your business's full potential. So stay secure, stay compliant, and we'll catch you next week on Cash in the Cyber Sheets. Goodbye for now.
