---
title: "Incident einstufen"
description: "Setzt die NIS-2-Kategorie eines Incident-Management-Incidents (Verfügbarkeit, Sicherheit, Sonstiges) und markiert ihn als Beinahevorfall."
---

`POST /api/im/incidents/:id/classification`

Stuft einen Incident für die NIS-2-Meldung ein (Durchführungsverordnung (EU) 2024/2690, Anhang 3.1): seine `category` und ob er ein Beinahevorfall war (`isNearMiss`, ein Ereignis, das Verfügbarkeit, Integrität oder Vertraulichkeit hätte beeinträchtigen können, es aber nicht tat). Neue Incidents beginnen mit `category: null` (noch nicht eingestuft) und `isNearMiss: false`; nichts setzt die Felder automatisch. Erlaubt in jedem Status, auch nach dem Lösen.

Weggelassene Felder bleiben unverändert. Die Änderung steht als Ereignis `classification_changed` in der Zeitachse des Incidents (mit `from` und `to` je geändertem Feld) und im Audit-Protokoll der Organisation. Sie alarmiert niemanden und geht weder an Statusseiten noch an ausgehende Integrationen. Eine Anfrage, die nichts ändert, schreibt nichts und gibt den Incident unverändert zurück.

Ist NIS-2 eingeschaltet, braucht ein gelöster Incident mit Kategorie `security` immer ein [Postmortem](/de/api/incident-management/postmortems), unabhängig vom Schweregrad, und ein damit verknüpfter [Meldefall](/de/api/incident-management/report-cases) schlägt das Kriterium `malicious_unauthorized_access` vor.

## Authentifizierung

Jede IM-berechtigte Rolle (`admin`, `editor`, `responder`) oder ein organisationsweiter API-Token, siehe [Authentifizierung](/de/api/incident-management#authentifizierung). Incident Management muss für die Organisation aktiviert sein. Sie müssen Mitglied im Team des Incidents sein oder Organisations-`admin`.

## Anfrage (Request Body)

| Feld | Typ | Erforderlich | Beschreibung |
|-------|------|----------|--------------|
| `category` | string oder null | Nein* | Einer von `availability`, `security`, `other`. `null` leert sie (nicht eingestuft). |
| `isNearMiss` | boolean | Nein* | `true` markiert den Incident als Beinahevorfall. |

\* Mindestens eines der beiden. Jeder andere Schlüssel wird abgewiesen.

## Beispiel (cURL)

```bash
curl -X POST "$BASE_URL/api/im/incidents/42/classification" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "category": "security", "isNearMiss": false }'
```

## Antwort (Response)

`200 OK`: die aktualisierte Incident-Zeile (dieselbe Form wie die `items` von [Incidents auflisten](/de/api/incident-management/list-incidents), ohne die Anreicherungsfelder).

```json
{
  "id": 42,
  "teamId": 3,
  "title": "Verdächtige Anmeldungen im Admin-Bereich",
  "severity": "sev3",
  "status": "resolved",
  "category": "security",
  "isNearMiss": false
}
```

(Gekürzt; die vollständige Zeile wird zurückgegeben.)

## Häufige Fehler

- `401 Unauthorized`, wenn nicht authentifiziert
- `403 Forbidden` (`customerScopedTokenForbidden`) bei einem kundengebundenen Token
- `403 Forbidden` (`imAccessDenied`), wenn der Sitzungsnutzer keine IM-berechtigte Rolle hat
- `403 Forbidden` (`imTeamMembershipRequired`), wenn Sie weder Mitglied im Team des Incidents noch Organisations-`admin` sind
- `403 Forbidden` (`imNotEnabled`), wenn Incident Management für die Organisation nicht aktiviert ist
- `400 Bad Request` (`invalidRequestBody`), wenn `:id` keine positive Ganzzahl ist, der Body weder `category` noch `isNearMiss` enthält, `category` keiner der drei Werte oder `null` ist, `isNearMiss` kein Boolean ist oder der Body einen unbekannten Schlüssel enthält
- `404 Not Found` (`imIncidentNotFound`), wenn der Incident nicht existiert oder zu einer anderen Organisation gehört