ISMS Audits and BSI Catalogs

Ready-to-use audit catalogs are available for BSI IT-Grundschutz, CISIS12 and VdA ISA; each is an optional, paid add-on. Beyond these, you define any audits of your own and build custom audit catalogs from requirements, applicability and threats, for example for your organization’s internal rules. Compliance with ISO/IEC 27001 or SiKoSH is managed in parallel through requirement catalogs in the ISMS Cockpit.

An audit catalog provides the checklists for a specific audit: you create audit objects, assign checklists to them and document the implementation status, the people interviewed and notes for each requirement. A requirement catalog such as ISO/IEC 27001, by contrast, represents ongoing compliance with the standard. It is activated per organization, evaluated in the ISMS Cockpit and holds evidence, links to measures and the Statement of Applicability.

You create the audit objects hierarchically, with audit object type and applicability, and link them to existing assets. You then assign the checklists from the audit catalog to the audit objects. For each requirement, you record the implementation status, the people interviewed and implementation notes, and assign tasks. Progress is displayed graphically and aggregated onto parent audit objects; you can download the current status as PDF or DOCX.

“Not applicable” is an implementation status in its own right, which you justify on the requirement; exclusions therefore flow straight into the Statement of Applicability (SoA). From this, a document is generated as PDF and DOCX with a summary, all requirements with their source, evidence and implementation status, and an appendix of the modelled assets. Using “Archive version”, you freeze the current state as an immutable version with date and author.

You store evidence as a file, as a document in the application or as a link – or request it from other people; external parties can also respond with a file or link. Evidence only counts once the person responsible for the requirement has confirmed it; they are asked to do so by email. Expiring evidence automatically triggers a review, and the “Evidence” worklist in the cockpit shows outdated evidence and outstanding evidence requests.

Yes. For catalogs based on BSI IT-Grundschutz, you choose the target protection level – basic protection, standard protection or high protection requirement; only the requirements of that level and the levels below are created. You model modules on the asset, plan implementation with open measures, responsible persons and deadlines, and generate the audit documents structure analysis, modeling and IT-Grundschutz check result, each row showing the protection requirement.

For requirements you deliberately do not implement, you document an exception for the accepted residual risk. The requirement is then excluded from the compliance level but remains visible with its justification: in the cockpit, the distribution across all implementation statuses shows justified exceptions separately. Follow-ups let you schedule a regular review of such decisions.