Faculty Advisor: Concept of Operations and Why It Should Be In Your Toolkit

Return to Demonstrating Value
Q. We have a hard time getting understanding for some of our initiatives. Any thoughts on how to get the attention of senior management?

Risk-responsive security management involves a multitude of periodic initiatives that require a more in-depth, documented approach, justification and communication to key stakeholders. It’s your vision, the blueprint you draw so that you and others can more accurately fulfill the need and deliver the desired results. One way to achieve clarity and buy-in is to create a concept of operations (ConOps) document. As you can see from the following original definition, it has been used extensively in technology and government systems planning. We have used the same concept successfully in our field of operations.

A Concept of Operations (CONOPS) is a document that "describes system characteristics for a proposed system from a user's perspective. A CONOPS also describes the user organization, mission, and objectives from an integrated systems point of view and is used to communicate overall quantitative and qualitative program or system characteristics to stakeholders."[1]

Why build a ConOps? We are in competition for resources with all the other managers in our company. We also are frequently confronted with the need for a new, state-of-the-art GSOC, a risk-responsive addition of significance that will add headcount, or other initiatives that require a well-documented business case. A ConOps clearly identifies the need, crafts the over-arching methodology to be applied and specifies the who, what, when, how and why of the program. If you are in the midst of an initiative that has not been effectively specified in a business case, the ConOps provides the detail that helps drive the team to desired results.

What is in a ConOps? Let’s assume your company is moving into a new country and is building a major facility with a large ex-pat and local workforce. You have a solid risk assessment and a good set of requirements for how you are going to address the site’s operational security   mission. A wish list does not pass muster for a project of this importance or cost. A ConOps will provide your plan and the table of contents might look something like this:

  1. A statement of vision, mission and anticipated value of the security program or service.
  2. A description of the threats and risks as well as the service needs confronting the business here and how the program will generally address them.
  3. The specific objectives of the proposed program with measurable results identified.
  4. Identification of applicable standards, policies or other requirements that will apply to the program’s implementation at this location.
  5. A description of the current state to identify what local dependencies, project constraints or limitations may impact the mission or program objectives.
  6. Documentation of the critical processes and dependencies that will reside here - these are the targets of identified threats, objects of special protection and/or special operational requirements.
  7. Identified stakeholder requirements for the security program.
  8. A description of the anticipated future state requirements:
    1. A summary description of the overall site protection strategy and cost considerations.
    2. Proposed reporting requirements for security staff.
    3. Approach to staffing and projected headcount.
    4. A training plan.
    5. The physical security strategy and system architecture to maximize asset protection and cost-effectiveness:
      • Anticipated local operational requirements
      • GSOC considerations
      • In-country and resident implementation and support strategy
      • Projected IT support for implementation
    6. Projected local business operations requiring specific security support.
    7. Projected support to Cyber, EH&S, Business Continuity and Supply Chain.
    8. Required external (in-country) dependencies and relationships.
  9. A work breakdown structure and associated program schedule.
  10. Anticipated project related program risks and mitigation strategy.
  11. Stakeholder and user requirements.
  12. Program success measures and reporting metrics.
  13. Test and acceptance of initial operational capability.

Summary. A ConOps is uniquely tailored to the needs and practices of your organization. The term “concept” drives the notion of a summary of details. This list of contents may appear to be long but it is a relatively straight-forward example of a large project that will have high-level implications and visibility. Each program will bring its own requirements for conceptual detail but it should be sufficient for stakeholders to understand program purpose, scope, framework of requirements and provide approval.

Response provided by George Campbell, Emeritus Faculty, Security Executive Council.


[1] IEEE Std. 1362-1998 Guide for Information Technology- System Definition- Concept of Operations (ConOps) Document


Return to Demonstrating Value