On August 11, 2023, Cisco announced that Cisco SecureX will go end-of-life on July 31, 2024. The content in this Github repository will not be actively maintained following this announcement.


Response workflows are a powerful tool that allows you to customize the actions available in Threat Response and SecureX pivot menus.

Response Workflows

User Experience

Here’s what workflows look like in the pivot menu after pivoting on a domain:

When you select a workflow to execute, you’ll see a small success message at the bottom right of the page. Note that this success message only indicates that the workflow was started successfully; it does not mean the workflow completed successfully. To view the workflow’s status and result, you’ll need to go into SecureX orchestration and view its runs.


In order for a workflow to appear in pivot menus, it must:

  1. Have a category of response.
  2. Have a String input named observable_type.
  3. Have a String input named observable_value.
  4. Be in a Validated state.

Valid Observable Types

Observables come in a wide variety and it’s up to your workflow to decide which observables to support. Your workflow can choose to support a single type of observable or multiple. We provide a sample workflow for each of these scenarios below. Some examples of observable types include:


For a full list of valid observable types, see the vocabularies schema in the CTIM specification.

Triggering via the Threat Response API

Response workflows can be triggered via the Threat Response API. This is useful if you want to be able to trigger a workflow from outside of SecureX. For more information about how to do this, see this page.

Sample Workflows

The following sample workflows are available in our repository’s workflows folder to help you get familiar with this concept. These can be imported using the instructions here or you can view the workflow in GitHub by clicking on it.