Participating in and Understanding Change Management Processes
Start course

This course is the 2nd of 4 modules of Domain 7 of the CISSP, covering Security Operations.

Learning Objectives

The objectives of this course are to provide you with the ability to:

  • Employ resource protection techniques
  • Conduct incident response
  • Operate and maintain preventative measures
  • Implement and support patch and vulnerability management
  • Participate in and understand change management processes

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


So, we're going to continue the discussion by talking about participation in and understanding the change management process. Now, the change management process is looked at as management's structure for recognizing changes that are necessary and then building a process by which they can be absorbed by the organization. There have to, therefore, be procedures for the operational aspects of how the change will be recognized, disassembled into its various pieces, and then through a controlled process implementing these into the organization.

There are, therefore, subsections of the change management process. This will include a process of intake where we receive requests upon which we will do an impact assessment, both of what will happen if we do the change and what happens if we don't do the change. Once this is understood then the necessity of doing the change will be discussed and decided and that will lead ultimately to approval or disapproval of making the change. Assuming approval, we will then disassemble the change further into its component parts, we will do whatever the build might require, we will test it to make sure that we know exactly what it will do and what it won't do.

Then when it's been decided the schedule for when it's going to be implemented, we will do notification of the affected parties. Then we will do first a test implementation so we can see what in the real world it will actually cause to happen and then once we're satisfied that it will do what and only what we expect or want, then we proceed with the implementation in the real production environment. When this is done, we do verification and validation that the changes that were made were those that were expected and only those that were expected, and that we verify that everything that we did, we've done completely, and that the process is in fact 100% complete.

All of this gets documented by the issuance of a new version and a new baseline in the systems configuration. Now, the documentation, of course, has to be done. As the old saying goes, the job isn't done until the paperwork is complete, and that's very true here. So the outcome is going to be recorded in the appropriate records, it's going to be committed to the corporate memory, it is including any system modifications that might have been made anywhere along the way, and it will include anything in the way of lessons learned from the process all the way through the operationalization of whatever the change was. That brings us to the close of our second module of Domain 7: Security Operations. We're going to continue with our next module beginning on slide 92 with the implementation of recovery strategies. Please be sure to join us for that, thank you.

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.