# Lokale Ausführungsprotokolle stützen SOC 2 CC7-Nachweise

Lokale, nachweislich gegen unbemerkte Änderungen geschützte Ausführungsprotokolle können SOC 2 CC7-Nachweise stützen, aber CC7.1 oder CC7.2 nicht allein abdecken. Sie können zeigen, welcher lokale Agentenprozess eine Sitzung begann, welche Aufrufe mit Zugangsdaten er versuchte, wie diese endeten und ob sich die gespeicherte Historie änderte. Sie zeigen nicht, dass jede zum Prüfungsumfang gehörende Komponente auf Schwachstellen überwacht wurde oder jemand Anomalien planmäßig untersuchte.

Diese Grenze ist wichtig. Ich habe Teams erlebt, die einem Prüfer einen sauber signierten Protokollexport vorlegten und ihn als Überwachungskontrolle bezeichneten. Der Export bewies, dass Ereignisse existierten. Er bewies weder Abdeckung noch Erkennungslogik, Prüfung, Eskalation oder Behebung. Das lokale Protokoll ist als eine Nachweisquelle in einem Kontrollsystem nützlich. Wird es mit der gesamten Kontrolle verwechselt, treten die Lücken bei der Stichprobe zutage.

Der Praxistest ist einfach: Verbinden Sie jede Behauptung mit einem Feld, einem Verfahren, einem Verantwortlichen und einem bestätigenden Beleg. Fehlt ein Element, dokumentieren Sie die Einschränkung, bevor der Prüfer es tut.

## CC7.1 und CC7.2 stellen verschiedene Fragen

CC7.1 fragt, ob die Organisation Erkennungs- und Überwachungsverfahren einsetzt, um Konfigurationsänderungen zu finden, die neue Schwachstellen verursachen, sowie die Anfälligkeit gegenüber neu entdeckten Schwachstellen. CC7.2 fragt, ob sie Systemkomponenten und deren Betrieb auf Anomalien im Zusammenhang mit böswilligen Handlungen, Naturereignissen oder Fehlern überwacht und anschließend entscheidet, ob diese Anomalien Sicherheitsereignisse sind. Das Protokoll einer API- oder SSH-Aktion eines Agenten kann zu beiden Kriterien beitragen, aber auf unterschiedliche Weise.

Für CC7.1 ist ein Ausführungsprotokoll meist ein Änderungsnachweis. Es kann zeigen, dass ein Agent eine Firewallregel änderte, ein Paket installierte, eine Identitätseinstellung anpasste oder einen Befehl auf einem Host ausführte. Damit lässt sich eine erkannte Konfigurationsabweichung oder neue Angriffsfläche mit dem verursachenden Prozess verbinden. Eine neu veröffentlichte Schwachstelle erkennt das Protokoll nicht. Dafür muss ein Scanner, Hinweis-Feed, Inventardienst oder Prüfverfahren installierte Komponenten mit neuen Schwachstelleninformationen vergleichen.

Für CC7.2 sind dieselben Daten betriebliche Telemetrie. Ein abgelehnter Aufruf, ein unerwartetes Ziel, wiederholte Anmeldefehler, ein ungewöhnlicher Befehl oder eine Aktion außerhalb einer genehmigten Sitzung können Anomaliehinweise sein. Ein gespeichertes Ereignis ist dennoch keine Überwachung. Die Organisation braucht ein festgelegtes Verfahren, um Ereignisse auszuwählen, verdächtige Muster zu erkennen, sie an Prüfer weiterzugeben und Entscheidungen festzuhalten.

Diese Unterscheidung verhindert einen häufigen Zuordnungsfehler: Protokollierung wird mit Erkennung gleichgesetzt. Eine Protokollquelle zeichnet Beobachtungen auf. Eine Erkennungskontrolle wendet Logik oder menschliches Urteil auf sie an. Ein Prüfer testet häufig Gestaltung und Betrieb, daher beantwortet ein reiner Sammelnachweis nur die halbe Frage.

Die Trust Services Criteria der AICPA enthalten Schwerpunkte statt einer universellen Werkzeugliste. Ein Unternehmen kann Kontrollen passend zu seinen Risiken entwerfen, doch es gibt weder eine magische Aufbewahrungsfrist noch eine vorgeschriebene Produktkategorie. Systembeschreibung, Risikobewertung, Kontrollformulierung und tatsächliches Verfahren bestimmen, ob lokale Ausführungsdaten relevant sind.

Eine enge, belastbare Formulierung könnte lauten: „Das Sicherheitsteam prüft an jedem Arbeitstag agentenvermittelte Produktionsaktionen auf abgelehnte und fehlgeschlagene Aufrufe, neue Ziele und privilegierte SSH-Befehle; der Prüfer dokumentiert die Einordnung und eskaliert verdächtige Ereignisse nach dem Vorfallverfahren.“ Diese Aussage nennt Datenmenge, Signale, Rhythmus, Verantwortung und Folgemaßnahmen. „Wir speichern manipulationsgeschützte Protokolle“ beschreibt nur eine Speichereigenschaft.

## Eine Sitzungsidentität bezeichnet den Prozess, nicht die Person

Ein nützlicher Sitzungsdatensatz identifiziert den Agentenprozess genau genug, um zwei Läufe zu unterscheiden. Erfassen Sie mindestens eine eindeutige Sitzungs-ID, Start und Ende, Pfad der ausführbaren Datei, Signaturidentität oder Binär-Hash, Elternprozess, Host-ID, lokales Konto, Autorisierungsentscheidung, genehmigende Person und Widerrufsstatus. Halten Sie fest, wie jedes Feld ermittelt wurde. Ein vom Agenten gemeldeter Wert ist weniger vertrauenswürdig als eine Beobachtung des Gateways oder Betriebssystems.

Machen Sie aus einer Prozessidentität nicht stillschweigend eine Personenidentität. Eine Signaturstelle kann sagen, wer eine Binärdatei signierte. Ein lokales Konto nennt den Betriebssystemkontext des Starts. Beides beweist nicht, welcher Mitarbeiter den Prompt schrieb, jede Aktion genehmigte oder einen bestimmten Befehl beabsichtigte. Erfordert die Kontrolle eine persönliche Zuordnung, verbinden Sie die Sitzung mit Anmeldedaten des Identitätsanbieters, Geräteverwaltung, Genehmigungen, Ticketverantwortung oder einer kontrollierten Arbeitsplatzzuweisung.

Dieselbe Vorsicht gilt für Prozessbeziehungen. Eine Shell kann einen Agenten starten, der einen Helfer startet, der eine SSH-Aktion anfordert. Zeichnen Sie die beobachtete Kette auf, aber legen Sie den kontrollierten Prozess fest. Sonst gruppiert ein Team nach dem Hauptagenten, ein anderes nach dem Helfer und die Stichprobenmenge ändert sich mitten in der Prüfung.

Ein kompaktes Sitzungsobjekt macht den Nachweisvertrag deutlich:

```json
{"session_id":"ses_01JX...","host_id":"mac-042","started_at":"2026-07-21T14:03:18Z","ended_at":"2026-07-21T14:48:02Z","executable":"/usr/local/bin/agent","signing_authority":"Developer ID Application: Example","parent_pid":8821,"local_account":"builder","authorization":{"decision":"approved","method":"local_user_action","at":"2026-07-21T14:03:22Z"},"revoked_at":null}
```

Die Auslassungspunkte kennzeichnen ein gekürztes Beispiel, keine zulässige Produktions-ID. Der echte Nachweis braucht den vollständigen Wert und eine dokumentierte Eindeutigkeitsregel. Außerdem ist ein Nachweis der Zeitsynchronisierung nötig. Wenn Zeitstempel von Endgerät, Gateway, Identitätssystem und Ticket auseinanderlaufen, kann der Prüfer die Abfolge trotz interner Konsistenz der Quellen nicht zuverlässig rekonstruieren.

Bei Sallyport zeichnet das Sessions-Journal Agentenläufe auf, während die Genehmigung des ersten Aufrufs zuerst die Signaturstelle des Prozesses zeigt und bis zu dessen Ende gilt. Das ist ein guter lokaler Sitzungsnachweis, aber bei Aussagen über einen bestimmten Mitarbeiter, ein verwaltetes Gerät, eine genehmigte Änderung oder eine Unternehmensanmeldung sind externe Daten nötig.

## Aufrufergebnisse brauchen entscheidungsfähigen Kontext

Ein einzelner Aufrufdatensatz sollte beantworten, was der Prozess wo versuchte, welche Zugangsdatenreferenz oder Schlüsselklasse das Gateway nutzte, ob eine Genehmigung nötig war, welche Entscheidung fiel, ob die Ausführung begann und wie sie endete. Erfassen Sie Zeit, Dauer, Kanal, normalisiertes Ziel, Aktionstyp, Ergebnis- und Fehlerklasse sowie eine stabile Korrelations-ID. Speichern Sie genug Befehls- oder Anfragedetails für Untersuchungen, ohne Geheimnisse oder sensible Antwortkörper in den Audit-Trail zu kopieren.

Die Ergebnisbegriffe müssen streng sein. „Abgelehnt“ bedeutet, dass eine Kontrolle die Ausführung vor der externen Aktion stoppte. „Fehlgeschlagen“ bedeutet, dass sie begann, aber einen Fehler zurückgab, auslief oder die Verbindung verlor. „Erfolgreich“ bedeutet, dass die entfernte Schnittstelle nach einer dokumentierten Regel Erfolg meldete. „Unbekannt“ deckt den Fall ab, dass der Client nach dem Senden keine Bestätigung erhielt. Ablehnung und Fehlschlag in einer Fehlerklasse zu mischen zerstört den Nachweis, dass die Prävention wirkte.

Ein HTTP-Status erzählt selten die ganze Geschichte. Eine `200`-Antwort kann einen Anwendungsfehler enthalten. `202` kann nur eine Warteschlange bestätigen. SSH-Exitcode null besagt, dass die entfernte Shell Erfolg meldete, nicht dass sich der gewünschte Zustand änderte. Definieren Sie die Normalisierung je Aktionstyp und bewahren Sie den Rohstatus daneben auf.

Ein praktischer Datensatz sieht so aus:

```json
{"call_id":"call_01JX...","session_id":"ses_01JX...","occurred_at":"2026-07-21T14:17:09Z","channel":"ssh","destination":"prod-web-03","action":"systemctl restart api","credential_ref":"ssh-prod-ops","approval":{"required":true,"decision":"approved","method":"touch_id"},"execution":{"started":true,"result":"failed","exit_code":1,"error_class":"remote_command_error","duration_ms":842},"ticket_ref":"CHG-1842"}
```

Protokollieren Sie kein bearer token, keinen privaten Schlüssel, vollständigen Autorisierungsheader oder Rohantwort nur für scheinbare Vollständigkeit. Ein Auditprotokoll, das Geheimnisse preisgibt, erzeugt einen neuen Kontrollfehler. Verwenden Sie eine stabile Referenz und dokumentieren Sie die Einfügungsmethode, während das Geheimnis außerhalb des Agenten und Exports bleibt.

Für CC7.1 lassen sich änderungsfähige Aufrufe mit Abweichungen, Deployments und Schwachstellenfunden verbinden. Für CC7.2 können abgelehnte, fehlgeschlagene, unbekannte, ungewöhnliche oder riskante Aktionen ausgewählt werden. Der Datensatz unterstützt diese Verfahren nur, wenn die Organisation die vollständige Grundgesamtheit bestimmen kann. Ein Bild von fünf Ereignissen beweist fünf Ereignisse, nicht die Prüfung aller relevanten.

## Integritätsprüfungen beweisen Konsistenz, nicht Wahrheit

Eine Hash-Kette kann Löschung, Einfügung, Umordnung oder Änderung nach Aufnahme der Datensätze erkennen, wenn der Prüfer von einem vertrauenswürdigen Format und Anker ausgeht. Sie beweist nicht, dass die Quelle jede Aktion erfasste, jedes Feld beim Schreiben richtig war oder ein Angreifer den Logger nie umging. Die scharfe Grenze lautet: Datensatzintegrität ist nicht Erfassungsvollständigkeit.

Verschlüsselter Speicher ohne Rückschreibemöglichkeit verringert das Risiko, dass ein Leser oder kompromittierter Analyseweg alte Einträge ändert. Verschlüsselung schützt Vertraulichkeit. Verkettung schützt überprüfbare Kontinuität. Hardwaregestützte Schlüssel können Zugriff stärken. Diese Mechanismen beantworten verschiedene Fragen und sollten getrennt dokumentiert werden, statt das Gesamtdesign „unveränderlich“ zu nennen.

Ein Integritätsverfahren braucht wiederholbare Eingaben und aufbewahrte Ergebnisse. Mit Sallyport kann ein Prüfer die verschlüsselte Kette offline ohne Schlüssel prüfen:

```text
$ sp audit verify /evidence/agent-audit-2026-07.splog
verified: 18432 records
first: 2026-07-01T00:01:44Z
last: 2026-07-31T23:58:10Z
chain: valid
```

Die genaue Ausgabe muss aus der installierten Version stammen. Das Muster zeigt den Inhalt des Nachweispakets: Befehl, Version, Datei-ID oder Hash, Anzahl, Zeitgrenzen, Ergebnis, Ausführungszeit und Bediener. Gibt der echte Befehl andere Bezeichnungen aus, bewahren Sie das Original auf, statt es umzuschreiben.

Führen Sie vor dem Einsatz einen Negativtest durch. Kopieren Sie einen Nichtproduktions-Export, ändern oder entfernen Sie mit einer von der Entwicklung unterstützten Testvorrichtung einen Datensatz und bestätigen Sie den Fehler. Bewahren Sie Methode, erwarteten Fehler, Ausgabe, Version und Freigabe auf. Eine erfolgreiche Prüfung zeigt, dass eine Datei bestand; ein kontrollierter Negativtest zeigt, dass die behauptete Änderung erkannt wird.

Stimmen Sie auch Grenzen ab. Vergleichen Sie letzte Anzahl und Anker eines Exports mit dem erwarteten Anfang des nächsten. Untersuchen Sie Lücken, Rücksetzungen, Neuinstallationen, Zeitsprünge und Hostwechsel. Kann ein lokaler Administrator Protokoll und Anker löschen, bestätigt die Kette möglicherweise nur die Ersatzhistorie. Senden Sie Anker, Hashes oder signierte Quittungen in risikogerechten Abständen an einen getrennt kontrollierten Ort.

NIST Special Publication 800-92 empfiehlt, die Integrität archivierter Protokolle zu schützen und übertragene Protokolle häufig durch Hash-Vergleich zu prüfen. Das bleibt sinnvoll, ersetzt aber keine Überwachung der Quellenabdeckung. Nutzen Sie es, um Übertragungs- und Aufbewahrungsfehler sichtbar zu machen, und testen Sie dann die Meldung aller Quellen im Umfang.

## Aufbewahrung beginnt bei Zeitraum und Untersuchung

SOC 2 nennt keine universelle Tageszahl für CC7.1- oder CC7.2-Nachweise. Bestimmen Sie die Dauer aus Prüfungszeitraum, Verträgen, Recht, Untersuchungsbedarf, Erkennungsverzug, Sensibilität und Zeit für Stichproben. Die Richtlinie nennt Ereignisklassen, Ort, Verantwortliche, Zugriff, Löschung und Ausnahmen.

Bei einer Type 2-Prüfung testet der Prüfer den Betrieb über einen Zeitraum. Behält das Team nur die jüngste lokale Historie, fehlen möglicherweise frühe Stichproben und Kontinuität. Decken Sie Zeitraum, Vorbereitung, Feldarbeit und einen angemessenen Nachlauf ab. Längere Pflichten klären Recht oder Compliance, statt die Dauer eines fremden Berichts zu kopieren.

Nur lokale Aufbewahrung hat einen vorhersehbaren Fehler. Ein Laptop wird im April ersetzt, sein Journal verschwindet und die Oktoberstichprobe betrifft Februar. Das Team hat eine perfekte Kette für das Ersatzgerät, aber keine Daten für das Datum. Exportieren Sie Datensätze und Anker planmäßig in Organisationsspeicher und bewahren Sie Ausführungsnachweise auf.

Testen Sie Abruf, nicht nur Einstellungen. Wählen Sie ein frühes Datum, finden Sie Sitzungen, holen Sie Aufrufe, prüfen Sie Integrität und verbinden Sie ein Ereignis mit seiner Bewertung. Erfassen Sie Dauer und Fehler. Ein Einstellungsbild zeigt Design; erfolgreicher Abruf eines alten Zeitraums zeigt Betrieb.

Datenschutz und Sicherheit gelten weiter. Befehle, Ziele, Konten und Fehler können personenbezogene oder sensible Details enthalten. Begrenzen Sie Zugriff, schwärzen Sie Kopien nach dokumentierter Regel und bewahren Sie ungekürzte Quellen nur mit Erlaubnis auf. Schwärzung darf Reihenfolge oder Prüfung nicht ändern, ohne ein separat prüfbares Original zu erhalten.

## Der Prüfungsrhythmus muss Nachweise hinterlassen

Eine Kontrolle funktioniert, wenn eine benannte Rolle eine definierte Grundgesamtheit in festem Rhythmus nach schriftlichen Kriterien prüft und die Entscheidung erfasst. „Protokolle werden regelmäßig geprüft“ lässt sich nicht zuverlässig testen. Arbeitstägliche Prüfung kann für Produktion passen, Einzelgenehmigung für wenige mächtige Schlüssel, wöchentliche Trendprüfung für risikoärmere Entwicklung. Die Risikobewertung erklärt die Wahl.

Trennen Sie präventive Genehmigung von detektiver Prüfung. Genehmigung entscheidet über Fortsetzung. Prüfung fragt, ob erlaubte, abgelehnte, fehlgeschlagene und umgangene Aktionen auf eine Anomalie hindeuten. Die Genehmigung eines riskanten Aufrufs beweist keine spätere Ergebnisprüfung, Korrelation oder Erkennung einer kompromittierten Sitzung.

Definieren Sie Auswahlregeln vor dem Werkzeug. Ein Verfahren kann alle `result` mit `failed` oder `unknown`, abgelehnte Genehmigungen, neue Ziele, bestimmte Produktionszugänge, Sitzungen mit unbekannter Signatur und Integritätsfehler wählen. Der Prüfer ordnet jedes Element als erwartet, Betriebsfehler, Richtlinienabweichung oder mögliches Sicherheitsereignis ein. Verdachtsfälle erhalten ID und Eskalationszeit.

Bewahren Sie Nullergebnisse auf. An einem ruhigen Tag beweisen gespeicherte Abfrage, Zeitfenster, Ausführungszeit, Prüferidentität und Nullzahl den Lauf. Ein Monat nur mit positiven Tickets wirft Fragen zu den anderen Tagen auf. Prüfer ziehen Stichproben aus dem Kontrollbetrieb, nicht nur aus interessanten Fällen.

Der Prüfungsnachweis umfasst:

- Grundgesamtheitsabfrage oder Exportkriterien und Version.
- Beginn, Ende, Zeitzone und Datensatzanzahl.
- Prüferidentität, Abschlusszeit und Erklärung von Verspätungen.
- Jede gewählte Anomalie, Entscheidung und Begründung.
- Vorfall-, Änderungs- oder Problemtickets bei Eskalation.

Lassen Sie den Ereigniserzeuger nicht allein seine Historie prüfen. Kleine Teams können eine kompensierende Prüfung durch eine andere Person, regelmäßige Leitungsprüfung und getrennt kontrollierte Exporte nutzen. Beschreiben Sie die Realität. Erfundenes Vier-Augen-Prinzip ist schlechter als eine ehrliche Grenze mit sinnvoller Kompensation.

Der Rhythmus gilt auch für die Gesundheit der Kontrolle. Bestätigen Sie, dass erwartete Hosts Daten erzeugten, Exporte endeten, Uhren synchron blieben, Integritätsprüfungen bestanden, Auswahlregeln noch zum Schema passen und Warteschlangen geschlossen wurden. Eine Schemaänderung kann eine scheinbar gesunde Abfrage still brechen. Fügen Sie ein bekanntes Testereignis oder eine Mengengrenze hinzu, um Stille zu bemerken.

CC7.2 verlangt die Entscheidung, ob eine Anomalie ein Sicherheitsereignis ist. Ein Ticket ohne Begründung als „Fehlalarm“ zu schließen beweist keine Analyse. Der Datensatz beschreibt Vorgang, Auswirkung auf Ziele, Belege, Entscheider und Änderungen am Detektor oder Verfahren.

## Bauen Sie das Paket um Aussagen und Stichproben

Ein Prüfer fordert meist zuerst Designnachweise, dann Betriebsnachweise ausgewählter Daten oder Ereignisse. Ordnen Sie lokale Datensätze so, dass jedes Artefakt eine Aussage beantwortet. Übergeben Sie kein Roharchiv in der Hoffnung, der Prüfer finde die Kontrolle darin.

Nutzen Sie diese Zuordnung als Index:

| Prüferanfrage | Hilfreicher lokaler Nachweis | Übliche Bestätigung |
| --- | --- | --- |
| Initiator zeigen | Sitzungs-ID, Datei, Signatur, Host und Konto | Identitätsanmeldung, Geräteinventar, Personalzuweisung |
| Änderung zeigen | Ziel, Befehl, Zugangsdatenreferenz, Zeit und Ergebnis | Ticket, Repository-Historie, entfernter Zustand |
| Überwachung zeigen | Vollständige Menge, Auswahlregeln, Ablehnungen und Fehler | Erkennungseinstellung, Alert-Routing, Prüfungen und Vorfälle |
| Unverändertheit zeigen | Prüfausgabe, Version, Hash, Anker und Negativtest | Exporteinstellungen, separater Zugriff, Abdeckungstest |
| Aufbewahrung zeigen | Älteste und neueste abrufbare Daten, Exporthistorie | Richtlinie, Speicher, Löschung und Ausnahmen |
| Analyse zeigen | Prüfbogen, Entscheidung, Grund und Eskalationsreferenz | Vorfallverfahren, Reaktion und Korrektur |

Pflegen Sie je Kontrolle eine einseitige Definition mit Wortlaut, Eigentümer, Frequenz, Grundgesamtheiten, Verfahren, Artefakten, Ort und Ausnahmen. Ergänzen Sie ein Feldwörterbuch. Der Prüfer darf nicht raten, ob `actor` Mitarbeiter, Konto, Prozess oder Signaturstelle meint.

Bereiten Sie zwei Stichprobenwege vor. Der erste beginnt mit einem zufälligen Datum und beweist die rechtzeitige vollständige Prüfung. Der zweite beginnt mit einem riskanten Aufruf, geht zur Genehmigung zurück und weiter zu entferntem Ergebnis, Bewertung und Tickets. Das Datum testet Wiederholung, das Ereignis Nachverfolgbarkeit.

Stimmen Sie Summen bei jeder Übergabe ab. Die Sessions-Anzahl muss unter dokumentierten Filtern zum Export passen. Aufrufzahlen müssen vor und nach Übertragung übereinstimmen. Prüfeingaben teilen sich in gewählt, ausgeschlossen und offen. Erklären Sie Testumgebungen, genehmigte Ausnahmen, Wiederholungen und Daten außerhalb des Fensters.

Ein Type 1-Bericht bewertet Design zu einem Zeitpunkt. Type 2 bewertet zusätzlich den Betrieb im Zeitraum. Ein aktuelles Bild, eine neue Integritätsprüfung oder neue Anweisung kann Type 1 stützen, aber keine fehlenden Type 2-Monate erzeugen. Fehlt Historie, legen Sie die Lücke offen und verschieben Sie die Bereitschaft, statt rückwirkende Freigaben zu erfinden.

Fragen Sie vor der Feldarbeit, wie verschlüsselte oder sensible Daten geliefert werden sollen, welche Attribute erwartet werden und ob der Prüfer Daten, Sitzungen, Aufrufe oder Alerts wählt. Das ändert die Verpackung, nicht die Kontrolle. Sie muss schon vorher konsistent arbeiten.

## Sammeln Sie Abdeckung und Reaktion aus anderen Systemen

Lokale Protokolle decken nur Aktionen im lokalen Pfad ab. Sie beweisen nicht, dass alle Produktionsänderungen diesen Pfad nutzen. Administratoren können Cloud-Konsole, direktes SSH, CI/CD-Zugänge, Supportkanäle, Notfallkonten, geplante Jobs oder andere Rechner verwenden. Inventarisieren Sie die Wege und bringen Sie sie in die Kontrolle oder sammeln Sie deren Protokolle getrennt.

CC7.1 braucht außerdem:

- Aktuelles Inventar von Anlagen und Software im Umfang.
- Konfigurationsstandards und genehmigte Basisversionen.
- Scan-Konfiguration, Abdeckung, Ergebnisse und Funktionsnachweis.
- Verfahren für neue Hinweise und betroffene Komponenten.
- Behebungstickets, Risikoakzeptanzen, Fristen, Nachtests und Ausnahmen.

Ein Aufruf, der Version X installiert, ist ein nützlicher Änderungsnachweis. Er sagt nicht, dass X drei Wochen später verwundbar wurde. Schwachstellenmanagement, Hinweiserfassung, Inventar und Behebung müssen diese Geschichte liefern.

CC7.2 braucht breitere Quellen. Sammeln Sie je Risiko Telemetrie von Endgeräten, Identität, Netz, Cloud-Steuerung, Anwendungen, Datenbanken und Verfügbarkeit. Bewahren Sie Detektordefinitionen, Quelleninventare, Routingtests, Bereitschaften, Alert-Historie, Entscheidungen, Vorfälle und Folgemaßnahmen auf. Naturereignisse und Betriebsfehler können Verfügbarkeitsalarme und Kontinuitätsverfahren erfordern, die ein Aktionsgateway nicht sieht.

Beweisen Sie Vollständigkeit durch Abgleich. Vergleichen Sie verwaltete mit exportierenden Geräten, Produktionszugänge mit Gateway-Zugängen und Cloud-Änderungen mit Aufrufen und genehmigter Automatisierung. Untersuchen Sie beide Richtungen: Änderung ohne Aufruf kann Umgehung bedeuten; erfolgreicher Aufruf ohne erwartete Änderung kann fehlerhafte Normalisierung oder Rollback zeigen.

Sammeln Sie auch Governance. Die Risikobewertung erklärt die Bedeutung von Agentenaktionen für CC7.1 und CC7.2. Richtlinien verteilen Verantwortung für Protokolle, Schwachstellen, Überwachung, Prüfung, Vorfälle und Aufbewahrung. Schulung umfasst Genehmigende und Prüfende. Zugriffsprüfungen zeigen, wer Nachweise lesen, exportieren, verwalten oder löschen und Erkennungslogik ändern darf.

NIST Special Publication 800-92 behandelt Protokollmanagement als Erzeugung, Übertragung, Speicherung, Analyse und Löschung. Dieser Lebenszyklus prüft ein zu lokales Design. Wenn Erzeugung und Speicherung gelöst sind, aber Übertragung, Analyse und Löschung fehlen, bleibt es trotz guter Kryptografie unfertig.

Führen Sie ein Lückenregister mit unbedecktem System, fehlendem Zeitraum, betroffener Kontrolle, Risiko, Zwischenverfahren, Verantwortlichem und Zieldatum. Prüfer erwarten nicht, dass ein kleines Protokoll das ganze Unternehmen sieht. Sie erwarten, dass die Leitung den Umfang kennt und Aussagen auf vorhandene Belege begrenzt.

## Nutzen Sie lokale Daten als engen, testbaren Baustein

Lokale manipulationsgeschützte Daten sind sinnvoll, wenn die Kontrollaussage zu ihren Beobachtungen passt. Sie liefern detaillierte Sitzungs- und Aufrufdaten, bewahren Ablehnungen auf, die entfernte Systeme nie erhalten, und machen spätere Änderungen erkennbar. Für KI-Agenten sind sie besonders nützlich, weil entfernte APIs oft nur eine gemeinsame Dienstidentität sehen und den lokalen Prozesskontext verlieren.

Sie werden schwach, wenn Teams Identität übertreiben, Umgehungswege ignorieren, nur auf austauschbaren Geräten speichern oder eine gültige Kette mit vollständiger Überwachung verwechseln. Die Lösung ist kein weiteres kryptografisches Adjektiv. Nötig sind eine kleinere Aussage, dokumentierte Grundgesamtheit, wiederkehrende Prüfung, getrennte Prüfergebnisse und Verbindungen zu maßgeblichen Systemen.

Führen Sie vor dem Einsatz einen End-to-End-Test mit einem gesetzten Ereignis durch. Starten Sie eine erkennbare Testsitzung, versuchen Sie eine genehmigte und eine abgelehnte Aktion, bestätigen Sie beide Ergebnisse, exportieren Sie den Zeitraum, prüfen Sie die Kette, führen Sie die Auswahl aus, dokumentieren Sie die Entscheidung und gleichen Sie das entfernte Ereignis ab. Wiederholen Sie den Abruf für einen alten Zeitraum. Jeder Bruch ist eine echte Lücke.

Geben Sie dem Prüfer das Kettenergebnis, aber auch Quelleninventar, Auswahlregel, Prüfbeleg, Ausnahmen und externe Bestätigung. Dieses Paket stützt eine belastbare CC7.1- oder CC7.2-Kontrolle. Die Kette allein stützt nur die bescheidene Aussage, dass die gelieferte lokale Historie noch die vom Prüfwerkzeug erwartete Struktur besitzt.