Countermeasure statuses

The Countermeasure status is the project status for a requirement or control. SD Elements includes three main statuses:

  • Complete

  • Incomplete

  • Not Applicable

When you click the icon associated with a Countermeasure status, a drop-down list appears to let you select which status you want for that Countermeasure. If you create a custom Countermeasure status, it will also appear in this list.

When you click a Countermeasure status that is currently set to Complete, it will automatically change to Incomplete while it displays the drop-down list. Similarly, when you click a Countermeasure status that is currently set to Incomplete, it will automatically change to Complete while it displays the drop-down list.

Custom Countermeasure statuses can be created based on any of these three. Organizations may want to use a unique Countermeasure status to better match their team’s processes and workflow.

For example, teams may not complete all Countermeasures in a project, and often prefer to accept the risk or defer the work. An SD Elements super user can create Countermeasure statuses, such as “Risk Accepted” or “Deferred”, and map them to one of the three main statuses using the "meaning" attribute.

We recommend only using built-in Countermeasure statuses whenever possible, because the user experience and integrations are specifically designed around them.

Details

A Countermeasure status has the following fields:

  • Slug: A unique name for the status.

  • Icon: An image representing the status.

  • Name: The name of the status.

  • Meaning: A mapping to one of the three main statuses.

  • Default: An indicator whether or not Countermeasures added to a project should be set to this status by default.

    • Only one Countermeasure status can be set to "default" at any given time.

  • Requires comment: An indicator whether a user must enter a comment before setting a Countermeasure to this status.

Create a custom Countermeasure status

Create a new Countermeasure status by following the steps below.

Prerequisites:
  • The user has the system Super User permission.

Steps:
  1. From the gear icon menu, select Countermeasure Status.

  2. Click Add Status.

  3. Fill in the required fields.

  4. Click Add Status.

The new Countermeasure status is now available in all projects.

Delete a custom Countermeasure status

Delete a custom Countermeasure status by following the steps below.

Prerequisites:
  • The user has the system Super User permission.

Steps:
  1. From the gear icon menu, select Countermeasure Status.

  2. Select the desired Countermeasure status.

  3. Click Delete Status.

  4. Acknowledge the warning.

  5. Click Confirm.

The selected Countermeasure status is permanently deleted. All instances of the status is replaced with its underlying built-in Countermeasure status.

When to create a custom Countermeasure status

You may encounter situations where a custom Countermeasure status is important for enterprise adoption. For example, if there is already a process for adopting software security requirements, you may need to reflect the existing process statuses.

Another reason for adding a custom Countermeasure status is when organizations want to reflect a difference between a Countermeasure that is incomplete versus a Countermeasure that will never be worked on. In this case, you may want to create a custom Countermeasure status for “Risk Accepted”. You can determine this by interviewing key stakeholders when you plan for an SD Elements deployment. In particular, ask if the current status conveys enough information for reporting purposes.

It is highly recommended that you make this kind of change early on, ideally before you model any projects in SD Elements. While there is no defined hard limit for the number of custom Countermeasure statuses, adding more than two will likely significantly degrade the user experience. Additionally, Countermeasure status names should be short because certain views may cut off any that are too long.

Key Questions
  • Are there any pre-existing security requirements with different statuses that are not accurately reflected in SD Elements?

  • Do the three built-in statutes provide sufficient data for key stakeholders?

results matching ""

    No results matching ""