Maintain responsibilities and vulnerabilities – asset owner and CVE references

For every asset in your system landscape you document two sublists that an ISMS audit asks about first: “Responsibilities” — who is responsible for the system — and “Known vulnerabilities / CVE references” — which security vulnerabilities are known and how far their remediation has progressed.

Prerequisites

• Your team has a license for information security (ISMS).
• You have access to the asset and permission to edit it.
• Both sublists are maintained from the Edit form: open the asset in the detail view and click “Edit” at the top right.

Create a responsibility

The “Responsibilities” section records the parties responsible for the system. Technical and administrative management, the information security officer (ISO) and the emergency contact are maintained in the “Administration and management” area instead — a note in the section points this out.

1. Open the edit form of the asset.
2. In the “Responsibilities” section, click the “New” button. A slide-in panel opens, displaying the name of the asset as the title.
3. Under “Role / Responsibilities”, select from the dropdown menu: “Asset Owner / Technical Responsibility”, “Deputy Head of Department” or “Human supervision (AI)”.
4. Fill in the contact details: “Name of the company”, “First name”, “Surname”, “Position”, “Street”, “House number”, “Postcode”, “Town/City”, “Country”, “Telephone”, “Fax” and “Email”.
5. Click “Apply” to save the responsibility, or “Cancel” to discard the entry.

Designate at least the “Asset Owner / Technical Responsibility” for every productive asset — this is the party to involve first in the event of a security incident or a change. For assets with AI components, add “Human supervision (AI)”.

Create a vulnerability

As long as nothing has been recorded in the “Known vulnerabilities / CVE references” section, the note “No vulnerabilities found.” appears there.

1. In the “Known vulnerabilities / CVE references” section, click the “New” button.
2. Under “Designation”, enter the name or identifier of the vulnerability, for example a CVE number such as CVE-2024-12345 or an internal designation.
3. Under “URL”, add a reference to the source — the CVE entry, a vendor advisory or internal documentation.
4. In the “Description” field, explain the vulnerability, its effects and the planned or implemented countermeasures.
5. Under “Status”, select the processing status: “Open”, “In progress”, “Resolved”, “Risk accepted” or “Not affected”.
6. Click “Apply” or “Cancel”.

What happens next

• Creating, changing and removing entries is applied when you save the asset and logged in the activity history.
• Full-text search is rebuilt so that the asset remains searchable with its current details.
• A documented vulnerability is a typical starting point for a system-related risk analysis — especially with status “Open” or “Risk accepted”. To track remediation, create a task or follow-up directly on the asset.

Maintain the “Status” consistently: the most common audit finding is not an open vulnerability, but an open vulnerability without a recognisable processing status. A deliberately set “Risk accepted” status with a brief justification in the “Description” is far more robust than an entry that remains at “Open” for months.