Zum Hauptinhalt springen

Assign hazards to a requirement – remove the assignment again

How to assign one or more hazards to a requirement in the audit catalog and remove the assignment again when needed — so the audit shows what a requirement actually protects against.

Last updated:

A requirement in the audit catalog only answers the most important follow-up question — what does it actually protect against? — once hazards are assigned to it. That link is the basis of a risk-oriented audit assessment: if the requirement is assessed as “not fulfilled” in the audit, the assigned hazards are exactly the risk sources you transfer into risk management.

Prerequisites

  • You have access to the parent audit catalog.
  • You have permission to edit the audit catalog.
  • Hazards already exist in the “Hazards” section of the audit catalog.

Step by step

  1. Open the detail view of the audit catalog.
  2. Click the desired checklist to open it.
  3. In the “Requirements” table, click the desired requirement to open it.
  4. In the detail window, scroll to the “Hazards” section and click the “Add hazards” button. The “Add hazards” sidebar opens with a table of all hazards available in the audit catalog.
  5. Use the selection boxes at the beginning of each row to mark the hazards to be assigned.
  6. Click “Add” to apply the selection, or “Cancel”. The assigned hazards then appear in the “Hazards” section of the requirement.

Remove the assignment again

  1. Open the detail view of the requirement as described above.
  2. In the “Hazards” section, use the selection boxes at the beginning of each row to mark the hazards whose assignment you want to remove.
  3. Click “Actions” in the top right and select the bulk action for removing the assignment. Confirm the security prompt.

The hazards remain in the audit catalog and continue to be available for other requirements — only the link to the selected requirement is removed.

What happens next

  • Assigning a hazard and removing an assignment are logged in the activity history of the parent audit catalog.
  • Observers and assigned users receive an email notification as well as a notification in the application.
  • If the audit catalog is in “Published” status, a security prompt appears before every change, because changing a methodological basis affects all ongoing audits against this catalog.

A tip from practice: assign at least one hazard to every requirement — requirements without a hazard are a warning sign in the later audit report, because their protective purpose is not documented. For IT baseline protection requirements, several “Elementary Hazards” from the BSI IT Baseline Protection Compendium (G 0.1 to G 0.47) are usually relevant; for overarching organizational requirements, a single higher-level hazard is often sufficient.

Changes and errors may occur. The information in this article has been carefully compiled, but does not claim to be complete or correct.

Related glossary terms