1. Home
  2. Training Library
  3. CISSP: Domain 1 - Security and Risk Management - Module 2

Develop and Implement Documented Security Policy, Standards, Procedures, and Guidelines

Develop and Implement Documented Security Policy, Standards, Procedures, and Guidelines

This course is the 2nd of four modules of Domain 1 of the CISSP, covering security and risk management. 

Learning Objectives

The objectives of this course are to provide you with and understanding of:

  • Professional Ethics
  • How to develop and implement documented security policies, standards, procedures, and guidelines and the differences between them
  • The fundamentals of business continuity requirements
  • How to contribute to personnel security policies

Intended Audience

This course is designed for those looking to take the most in-demand information security professional certification currently available, the CISSP.


Any experience relating to information security would be advantageous, but not essential.  All topics discussed are thoroughly explained and presented in a way allowing the information to be absorbed by everyone, regardless of experience within the security field.


If you have thoughts or suggestions for this course, please contact Cloud Academy at support@cloudacademy.com.


So let's move on to our next section. Here, we're going to develop, implement documented security policy, standards, procedures, and guidelines. 

So with all of this governance documentation, it usually begins with a policy of some sort. Policies are necessary because they communicate management's expectations which are fulfilled through the execution of procedures, the how-to instructions we would say. Adherence to standards, baselines, and guidelines. And these will exist at various levels in any organization. The policies, you could say, are the laws of our organization, and as such they need to be followed with diligence. 

So the approach to security management involves different levels, different types of interaction. The top-down approach is security practices that are directed downward, have been drafted at the management level. Now these are oftentimes driven by laws external to the organization. They reflect various concepts, various goals that the organization is expected, or that management wants the organization to achieve. So these are drafted into policies. Typically, they're reviewed by all management, signed off on by management and by legal, and then they're pushed downwards through middle management for implementation amongst the staff, to the various levels. 

A complement to that is the bottom-up approach. This particular approach means that those working in the trenches find issues, come across various kinds of situations for which they have no adequate guidance, no description, no sort of direction of any sort of consistent way of addressing whatever the situation might be. So it gets pushed up through middle management, eventually being escalated to senior management. And the essential question to be answered is, could you please, senior management, devise a policy that tells us what you want done. Otherwise, we're just going to continue to do what we think is best or, worse yet, flounder until somebody says something. But rather than wait until that and have to undo all kinds of things, how about we get a policy to place a consistent way in place now. 

Now these two approaches, top-down and bottom-up, are complements to each other and they create the cycle through which policy is created and pushed down through the organization from issues that have been brought up through the organization to the hightest levels. And they provide the entire feedback cycle: action, reaction, action, reaction. So once the policy documents have been created, we have the basis for ensuring that compliance is established. But this is not going to be sufficient in and of itself. We need additional things that will help us implement the policy. 

Frequently, like laws, the policies are written in such a way that a direct implementation from a policy could be very difficult as a practical matter. So we need more direction. We need more flesh on the bone, so to speak, so that we know exactly how to do it and achieve the objectives stated in the policy. These documents are what we have. Standards define compulsory requirements. These could be system specifications that have to be established, various kinds of devices, various kinds of benchmarks that have to be achieved. 

We have Baselines that define the minimum level of performance or security. We have Guidelines that offer recommendations on how standards and baselines are implemented. Guidelines serve another useful purpose and that is, in situations where policies in their black and white sort of approach, are not sufficient or would provide perhaps a primary effect that is wanted but might produce a secondary or tertiary effect that is not wanted or possibly even intolerable. When we have various areas of execution in these documents that provide us some latitude of a solution, a Guideline can provide us the flexibility to approach it creatively, even while keeping us focused on achieving the compliance objective that is necessary. And then ultimately of course we have our Procedures which provide the detailed, step-by-step instructions that direct us to proper implementation and make sure that it aligns, again, with the business objectives for this particular policy.

About the Author
Learning Paths

Mr. Leo has been in Information System for 38 years, and an Information Security professional for over 36 years.  He has worked internationally as a Systems Analyst/Engineer, and as a Security and Privacy Consultant.  His past employers include IBM, St. Luke’s Episcopal Hospital, Computer Sciences Corporation, and Rockwell International.  A NASA contractor for 22 years, from 1998 to 2002 he was Director of Security Engineering and Chief Security Architect for Mission Control at the Johnson Space Center.  From 2002 to 2006 Mr. Leo was the Director of Information Systems, and Chief Information Security Officer for the Managed Care Division of the University of Texas Medical Branch in Galveston, Texas.


Upon attaining his CISSP license in 1997, Mr. Leo joined ISC2 (a professional role) as Chairman of the Curriculum Development Committee, and served in this role until 2004.   During this time, he formulated and directed the effort that produced what became and remains the standard curriculum used to train CISSP candidates worldwide.  He has maintained his professional standards as a professional educator and has since trained and certified nearly 8500 CISSP candidates since 1998, and nearly 2500 in HIPAA compliance certification since 2004.  Mr. leo is an ISC2 Certified Instructor.

Covered Topics