Operational Requirements

The course is part of this learning path

Operational Requirements

This course is the third installment of three courses covering Domain 2 of the CSSLP, covering the topic of functional and operational security requirements.

Learning Objectives

  • Explore the functional and operational requirements for building secure software

Intended Audience

This course is designed for those looking to take the Certified Secure Software Lifecycle Professional (CSSLP)​ certification, or for anyone interested in the topics it covers.


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


Now the operational requirements reflect the philosophy of, Secure by Design, Secure by Default, and Secure in Deployment. These reflect that philosophy that has been for many years, the holy grail of secure development programs. It ensures that security is designed in that in doing so, it will operate as a fully integrated member and set of controls that collaborate with the operational program instructions, and that it is not disrupted or disabled when implemented. In other words, it becomes more of a business enabler than the oft-perceived impediment that so many see as the case.

As it works properly, it ensures that the operational environment is properly prepared and ready to receive any form of processing within its capabilities. Part of this will be to capture the operational requirements in a Requirements Traceability Matrix or RTM. During the development cycle, this becomes a tracking mechanism that records and assists development teams in the ability to trace requirements from source to implemented form. And once it becomes operational, it traces back to those for doing troubleshooting and problem resolution.

It gives us the ability to authenticate any of our requirements sources. This is especially important when we're attempting to authenticate and trace a regulatory requirement. It validates our integration success because knowing the requirement, knowing its source, allows us to demonstrate how it works when it works successfully and that the compliance requirement contained therein is achieved. It helps us verify completeness of build and correctness of operation by documenting the requirements and then giving us the vehicle whereby we can verify correct performance and validate that the expected result was achieved. It further enables identification and tracking of any deviation.

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