Organisatorischen Kontext bereitstellen

Warum Kontext wichtig ist

Generische Compliance-Empfehlungen überleben selten die reale Umsetzung. Ein 10-Personen-Startup und ein 500-Personen-Unternehmen verfügen über völlig unterschiedliche Ressourcen, Risiken und Prüfungsumfänge – selbst wenn sie dieselbe ISO 27001- oder SOC-2-Zertifizierung anstreben.

ISMS Copilot passt Empfehlungen an, wenn Sie organisatorischen Kontext bereitstellen. Dies verwandelt theoretische Kontrollen in praktische Schritte, die auf Ihre Branche, Ihren Technologie-Stack, die Teamgröße und den Reifegrad abgestimmt sind.

Wesentliche Kontextelemente

1. Unternehmensgröße und -struktur

Die Anzahl der Mitarbeiter und die Organisationsstruktur beeinflussen die Komplexität der Kontrollen und die Ressourcenverteilung.

Beispiel: "Wir sind ein 25-Personen-Startup mit einem 5-köpfigen Engineering-Team, keinem dedizierten Sicherheitspersonal und einem schlanken Budget."

Warum es wichtig ist: Kleine Teams benötigen optimierte, automatisierte Kontrollen statt unternehmensweiter Prozesse. ISMS Copilot empfiehlt SaaS-Tools statt maßgeschneiderter Lösungen und kombinierte Rollen statt spezialisierter Positionen.

2. Branche und regulatorisches Umfeld

Ihr Sektor bestimmt geltende Vorschriften und Risikoprioritäten.

Beispiele:

• "Healthcare-SaaS, das PHI unter HIPAA verarbeitet"
• "Fintech, das Zahlungsdaten verarbeitet und PCI DSS sowie GDPR unterliegt"
• "B2B-SaaS, das an Unternehmenskunden verkauft und SOC 2 benötigt"

Warum es wichtig ist: Das Gesundheitswesen priorisiert die Vertraulichkeit von Patientendaten; Fintech legt Wert auf die Integrität von Transaktionen; B2B-SaaS konzentriert sich auf die Isolation von Kundendaten. Kontrollen und Nachweise passen sich entsprechend an.

3. Technologie-Stack

Listen Sie Ihre Kerninfrastruktur, Anwendungen und Sicherheitstools auf.

Beispiel: "Wir nutzen AWS (EC2, RDS, S3), GitHub für Code, Google Workspace für die Zusammenarbeit, Okta für SSO und Datadog für das Monitoring."

Warum es wichtig ist: Toolspezifische Anleitungen sind besser als generische Empfehlungen. Statt "Logging implementieren" erhalten Sie "AWS CloudTrail mit S3-Aufbewahrung und Datadog-Alarmierung für ISO 27001 A.8.15 konfigurieren."

4. Aktueller Reifegrad und Ziele

Beschreiben Sie, wo Sie stehen und wohin Sie wollen.

Beispiele:

• "Beginn der ISO-27001-Umsetzung von Grund auf, Audit in 12 Monaten"
• "Aufrechterhaltung von SOC 2 Type II, drittes jährliches Audit in 6 Monaten"
• "Erweiterung von ISO 27001 um SOC 2 für US-Kunden"

Warum es wichtig ist: Erstimplementierungen benötigen grundlegende Kontrollen und schnelle Erfolge. Ausgereifte Programme erfordern Optimierung und Verfeinerung der Nachweise. Szenarien mit mehreren Frameworks profitieren von der Kontrolle-Zuordnung, um Dopplungen zu vermeiden.

5. Spezifische Herausforderungen oder Einschränkungen

Nennen Sie Beschränkungen, frühere Audit-Feststellungen oder besondere Situationen.

Beispiele:

• "Vorheriger Prüfer bemängelte schwache Passwortrichtlinien und fehlende MFA"
• "Remote-first-Team in 15 Ländern, kein physisches Büro"
• "Legacy-Monolith wird auf Microservices unter Kubernetes migriert"
• "Budgetbeschränkung: 10.000 $ insgesamt für Compliance-Tools"

Warum es wichtig ist: Einschränkungen prägen machbare Lösungen. Remote-first verändert physische Sicherheitskontrollen; Budgetgrenzen beeinflussen die Tool-Auswahl; Audit-Feststellungen priorisieren die Behebung.

Kontext in Aktion: Vorher und Nachher

Beispiel 1: Zugriffskontrollrichtlinie

❌ Ohne Kontext: "Erstelle eine Zugriffskontrollrichtlinie für SOC 2"

Ergebnis: Generische Richtlinienvorlage, die erhebliche Anpassungen für Rollen, Tools und Prozesse erfordert.

✅ Mit Kontext: "Erstelle eine Zugriffskontrollrichtlinie für SOC 2 CC6 für ein 50-Personen-SaaS-Unternehmen, das Okta SSO, GitHub, AWS und Salesforce nutzt. Enthalte vierteljährliche Zugriffsprüfungen durch Manager und rollenbasierten Zugriff für Engineering-, Vertriebs- und Support-Teams."

Ergebnis: Richtlinienentwurf mit benannten Tools, spezifischen Rollen, definierter Prüfhäufigkeit und auditfähigen Verfahren.

Beispiel 2: Risikobewertung

❌ Ohne Kontext: "Wie führe ich eine Risikobewertung für ISO 27001 durch?"

Ergebnis: Allgemeiner Methodik-Überblick ohne spezifische Assets oder Priorisierung.

✅ Mit Kontext: "Erstelle eine Risikobewertungsvorlage für ISO 27001 A.5.7 für ein Healthcare-SaaS mit 100.000 Patientendatensätzen in AWS RDS, das Stripe für Zahlungen und Intercom für Support nutzt. Priorisiere HIPAA-relevante Bedrohungen."

Ergebnis: Vorlage, die kritische Assets (Patientendatenbank, Zahlungsabwickler), relevante Bedrohungen (Datenpanne, Ransomware) und branchenspezifische Kontrollen identifiziert.

Beispiel 3: Implementierungsfahrplan

❌ Ohne Kontext: "Gib mir einen SOC-2-Implementierungsplan"

Ergebnis: Hochrangige Phasen ohne Zeitplan oder Ressourcenabstimmung.

✅ Mit Kontext: "Erstelle einen 9-monatigen SOC-2-Type-I-Implementierungsfahrplan für ein 30-Personen-Startup mit einem teilzeitbeschäftigten Sicherheitsverantwortlichen, das die Trust Services Criteria für Security und Availability anstrebt. Wir nutzen Google Workspace, GitHub, AWS und haben grundlegende MFA, aber keine formalen Richtlinien."

Ergebnis: Phasenplan mit schnellen Erfolgen (Formalisierung der bestehenden MFA), ressourcenangepassten Meilensteinen und toolspezifischen Aufgaben, die auf Zeitplan und Teamkapazität abgestimmt sind.

Kontext mit Workspaces organisieren

Für Kundenprojekte oder Szenarien mit mehreren Projekten erstellen Sie separate Workspaces mit benutzerdefinierten Anweisungen, die Folgendes enthalten:

• Kundenname und Branche
• Unternehmensgröße und -struktur
• Technologie-Stack
• Frameworks und Audit-Zeitpläne
• Spezifische Prioritäten oder Einschränkungen

Beispielanweisung:

"Kunde: Acme Corp, 120-Personen-Fintech, EU-ansässig. Technologie: Azure, GitHub, Salesforce, Okta. Umsetzung von ISO 27001:2022 und Vorbereitung auf GDPR-Audit. Priorität: schnelle Erfolge für die Zertifizierung in 6 Monaten, Schwerpunkt auf Datenresidenz und Verschlüsselung. Budget: 25.000 $ für Tools."

Alle Abfragen in diesem Workspace wenden diesen Kontext automatisch an, ohne Wiederholungen.

Erfahren Sie mehr über Workspaces

Kontext für verschiedene Abfragetypen

Richtlinienerstellung

Geben Sie an: Rollen, Tools, Prüfhäufigkeiten, Genehmigungsworkflows

Beispiel: "Entwirf eine Incident-Response-Richtlinie für ISO 27001 A.5.24. Rollen: Sicherheitsverantwortliche (Jane), CTO (Genehmigung), Engineering-Team (Reaktion). Tools: PagerDuty für Alarmierung, Jira für Tracking, Slack für Kommunikation. Post-Incident-Reviews innerhalb von 48 Stunden."

Gap-Analyse

Geben Sie an: aktueller Stand, Ziel-Framework, bekannte Schwächen

Beispiel: "Analysiere unsere aktuelle Sicherheitslage im Vergleich zu SOC 2 CC6-CC8. Wir haben MFA über Okta, vierteljährliche Zugriffsprüfungen, GitHub-Branch-Schutz und AWS CloudTrail. Fehlend: formale Change-Management-Dokumente, Lieferantenrisikobewertungen und DRP-Tests."

Nachweiserstellung

Geben Sie an: Audit-Umfang, Möglichkeiten zur Nachweiserhebung, Tools mit Protokollierung

Beispiel: "Welche Nachweise benötige ich für ISO 27001 A.8.15 (Protokollierung und Überwachung)? Wir haben AWS CloudTrail, Datadog APM und Okta-Systemprotokolle. Audit-Umfang: AWS-Produktionsumgebung und Unternehmens-SSO."

Implementierungsleitfaden

Geben Sie an: Teamfähigkeiten, Zeitplan, vorhandene Tools

Beispiel: "Wie implementiere ich Verschlüsselung im Ruhezustand für ISO 27001 A.8.24? Unser DevOps-Ingenieur hat AWS-Erfahrung, wir nutzen RDS PostgreSQL und S3 für die Dateispeicherung und benötigen die Implementierung in 4 Wochen."

Wann der Kontext aktualisiert werden sollte

Aktualisieren Sie den Kontext, wenn sich Ihre Organisation ändert:

• Signifikantes Wachstum oder Reduzierung der Mitarbeiterzahl
• Einführung neuer Technologien (z. B. Migration zu Kubernetes)
• Regulatorische Änderungen (z. B. neue GDPR-Anforderungen)
• Audit-Feststellungen, die eine Behebung erfordern
• Wechsel von der Implementierungs- zur Wartungsphase

Aktualisieren Sie die benutzerdefinierten Anweisungen in Workspaces, anstatt vergangene Abfragen zu bearbeiten.

Ihren Kontext testen

Bevor Sie eine Abfrage senden, überprüfen Sie, ob Sie Folgendes enthalten haben:

1. Unternehmensgröße und Teamstruktur
2. Branche und relevante Vorschriften
3. Wichtige Technologien und Tools
4. Aktueller Stand und Ziele
5. Alle Einschränkungen oder Prioritäten

Fügen Sie eine Kategorie hinzu, wenn sie auf Ihre Abfrage zutrifft.

Nächste Schritte

Fügen Sie Ihrer nächsten Abfrage organisatorischen Kontext hinzu. Vergleichen Sie die Qualität und Spezifität der Antwort mit früheren generischen Versuchen.

Zurück zur Übersicht über Prompt Engineering