Zum Hauptinhalt springen

Maintain requirements in an audit catalog

Requirements are the questions answered during the audit. Learn how to create a requirement in a checklist, phrase it so it can be rated clearly, assign the right applicability and keep the order in your catalog clean.

Last updated:

Requirements are the concrete questions to be answered during an audit. In this article you create a requirement in a checklist of your audit catalog, phrase it so that it can be rated unambiguously, and assign it via “Applicability” to the protection requirements logic known from ISO 27001, BSI IT baseline protection or CISIS12.

Prerequisites

  • You have access to the parent audit catalog.
  • You have permission to edit the audit catalog.
  • At least one “Applicability” is maintained in the audit catalog (for example Basic, Standard, High).
  • The checklist the requirement belongs to already exists.

Create a new requirement

  1. Open the detail view of the audit catalog and click the relevant row in the “Checklists” section. The checklist opens in a sidebar.
  2. In the “Requirements” section, click the “New” button. The “New requirement” input window opens.
  3. Enter the name of the requirement under “Designation” (mandatory field, 1–191 characters). Phrase it as a short, clear requirement question.
  4. Use “Description” for the detailed explanation: concrete rating criteria, interpretation notes and cross-references to normative texts.
  5. In the “Applicability” selection menu, choose the level from which the requirement applies. If the level you need does not exist yet, click “Edit” to the right of the selection menu and create it in the “Applicabilities” sidebar.
  6. Click “Create” to create the requirement, or “Cancel” to discard the entry.

If the audit catalog has the status “Released”, a security prompt appears before the change, because the methodology affects all ongoing audits against this catalog.

Phrase requirements so they can be rated

  • A requirement should be answerable in the audit with “Fulfilled / Partially fulfilled / Not fulfilled”. If a question is too complex, split it into several requirements.
  • Keep the “Designation” compact and move the interpretation into the “Description” — that way the auditor has the rating logic directly at hand.
  • In the detail view of a requirement, use the “Hazards” section to link the hazards it protects against. If the requirement is rated as not fulfilled in the audit, those hazards can be transferred directly into a risk analysis.

Edit or delete a requirement

  1. In the “Requirements” table, click the row to open the detail view in the sidebar.
  2. Click “Edit” at the top right, or choose “Edit” in the “Actions” selection menu, to adjust designation, description and applicability.
  3. Use “Delete” to remove the requirement after a security prompt.

Control the order within the catalog

The order of the requirements follows their “Designation” — there is no free manual re-sorting. Use a consistent nomenclature from the start, following the pattern {Area}.{Number}: {Title} as used by CISIS12 and the BSI IT baseline protection compendium. Leave gaps when numbering (for example 10, 20, 30) so that requirements added later slot into the right place without renaming the entire catalog.

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