ISMS Copilot Docs

Dostarczanie Kontekstu Organizacyjnego

Ogólne porady dotyczące zgodności rzadko sprawdzają się w rzeczywistej implementacji. Startup zatrudniający 10 osób i przedsiębiorstwo liczące 500 pracowników mają zupełnie różne zasoby, ryzyka i zakresy audytów – nawet gdy dążą do uzyskania tej samej certyfikacji ISO 27001 lub SOC 2.

Dlaczego Kontekst Ma Znaczenie

Ogólne porady dotyczące zgodności rzadko sprawdzają się w rzeczywistej implementacji. Startup zatrudniający 10 osób i przedsiębiorstwo liczące 500 pracowników mają zupełnie różne zasoby, ryzyka i zakresy audytów – nawet gdy dążą do uzyskania tej samej certyfikacji ISO 27001 lub SOC 2.

ISMS Copilot dostosowuje rekomendacje, gdy dostarczysz kontekst organizacyjny. To przekształca teoretyczne kontrole w praktyczne kroki dopasowane do Twojej branży, stosu technologicznego, wielkości zespołu i poziomu dojrzałości.

Kluczowe Elementy Kontekstu

1. Wielkość i Struktura Firmy

Liczba pracowników i struktura organizacyjna wpływają na złożoność kontroli i alokację zasobów.

Przykład: "Jesteśmy 25-osobowym startupem z 5-osobowym zespołem inżynieryjnym, bez dedykowanego personelu ds. bezpieczeństwa i ograniczonym budżetem."

Dlaczego to ma znaczenie: Małe zespoły potrzebują usprawnionych, zautomatyzowanych kontroli, a nie procesów na skalę przedsiębiorstwa. ISMS Copilot rekomenduje narzędzia SaaS zamiast niestandardowych rozwiązań oraz łączenie ról zamiast specjalizowanych stanowisk.

2. Branża i Środowisko Regulacyjne

Twój sektor określa obowiązujące przepisy i priorytety ryzyka.

Przykłady:

  • "SaaS dla służby zdrowia przetwarzający PHI zgodnie z HIPAA"
  • "Fintech obsługujący dane płatnicze, podlegający PCI DSS i RODO"
  • "B2B SaaS sprzedający do klientów korporacyjnych wymagających SOC 2"

Dlaczego to ma znaczenie: Opieka zdrowotna priorytetowo traktuje poufność danych pacjentów; fintech kładzie nacisk na integralność transakcji; B2B SaaS skupia się na izolacji danych klientów. Kontrole i dowody dostosowują się odpowiednio.

3. Stos Technologiczny

Wymień swoją podstawową infrastrukturę, aplikacje i narzędzia bezpieczeństwa.

Przykład: "Używamy AWS (EC2, RDS, S3), GitHub do kodu, Google Workspace do współpracy, Okta do SSO i Datadog do monitoringu."

Dlaczego to ma znaczenie: Wskazówki specyficzne dla narzędzi są lepsze niż ogólne rekomendacje. Zamiast "wdrożenie logowania", otrzymujesz "skonfiguruj AWS CloudTrail z przechowywaniem w S3 i alertami w Datadog dla ISO 27001 A.8.15."

4. Aktualny Poziom Dojrzałości i Cele

Opisz, gdzie jesteś i dokąd zmierzasz.

Przykłady:

  • "Rozpoczynamy wdrażanie ISO 27001 od zera, audyt za 12 miesięcy"
  • "Utrzymujemy SOC 2 Type II, trzeci audyt roczny za 6 miesięcy"
  • "Rozszerzamy zakres z ISO 27001 o SOC 2 dla klientów w USA"

Dlaczego to ma znaczenie: Pierwsze wdrożenia potrzebują podstawowych kontroli i szybkich zwycięstw. Dojrzałe programy wymagają optymalizacji i udoskonalania dowodów. Scenariusze wieloramkowe korzystają z mapowania kontroli, aby zmniejszyć duplikację.

5. Konkretne Wyzwania lub Ograniczenia

Wspomnij o ograniczeniach, wcześniejszych ustaleniach audytowych lub wyjątkowych sytuacjach.

Przykłady:

  • "Poprzedni audytor wskazał słabe polityki haseł i brak MFA"
  • "Zespół rozproszony w 15 krajach, brak fizycznego biura"
  • "Monolityczna aplikacja legacy migrowana do mikrousług na Kubernetesie"
  • "Ograniczenie budżetowe: 10 tys. USD na narzędzia compliance"

Dlaczego to ma znaczenie: Ograniczenia kształtują wykonalne rozwiązania. Praca zdalna zmienia kontrole bezpieczeństwa fizycznego; budżet wpływa na wybór narzędzi; ustalenia audytowe priorytetyzują naprawę.

Kontekst w Praktyce: Przed i Po

Przykład 1: Polityka Kontroli Dostępu

❌ Bez kontekstu: "Stwórz politykę kontroli dostępu dla SOC 2"

Rezultat: Ogólny szablon polityki wymagający znacznego dostosowania do ról, narzędzi i procesów.

✅ Z kontekstem: "Stwórz politykę kontroli dostępu dla SOC 2 CC6 dla 50-osobowej firmy SaaS używającej Okta SSO, GitHub, AWS i Salesforce. Uwzględnij kwartalne przeglądy dostępu przez menedżerów oraz dostęp oparty na rolach dla zespołów inżynieryjnych, sprzedaży i wsparcia."

Rezultat: Szkic polityki z nazwami narzędzi, konkretnymi rolami, określoną częstotliwością przeglądów i procedurami gotowymi do audytu.

Przykład 2: Ocena Ryzyka

❌ Bez kontekstu: "Jak przeprowadzić ocenę ryzyka dla ISO 27001?"

Rezultat: Ogólny przegląd metodologii bez szczegółów dotyczących aktywów lub priorytetów.

✅ Z kontekstem: "Stwórz szablon oceny ryzyka dla ISO 27001 A.5.7 dla SaaS w służbie zdrowia z 100 tys. rekordów pacjentów w AWS RDS, używającego Stripe do płatności i Intercom do wsparcia. Priorytetyzuj zagrożenia związane z HIPAA."

Rezultat: Szablon identyfikujący krytyczne aktywa (baza danych pacjentów, procesor płatności), istotne zagrożenia (wyciek danych, ransomware) i kontrole specyficzne dla służby zdrowia.

Przykład 3: Plan Wdrożenia

❌ Bez kontekstu: "Podaj mi plan wdrożenia SOC 2"

Rezultat: Wysokopoziomowe fazy bez harmonogramu lub dostosowania zasobów.

✅ Z kontekstem: "Stwórz 9-miesięczny plan wdrożenia SOC 2 Type I dla 30-osobowego startupu z jednym półetatowym liderem ds. bezpieczeństwa, celując w Kryteria Usług Zaufania dla Bezpieczeństwa i Dostępności. Używamy Google Workspace, GitHub, AWS i mamy podstawowe MFA, ale brak formalnych polityk."

Rezultat: Plan fazowy z szybkimi zwycięstwami (sformalizowanie istniejącego MFA), kamieniami milowymi dostosowanymi do zasobów oraz zadaniami specyficznymi dla narzędzi, dopasowanymi do harmonogramu i możliwości zespołu.

Użyj Niestandardowych Instrukcji w Przestrzeniach Roboczych, aby ustawić kontekst raz dla wszystkich zapytań w projekcie. Pozwala to uniknąć powtarzania "Jesteśmy 50-osobowym SaaS w służbie zdrowia używającym AWS..." w każdej wiadomości.

Organizowanie Kontekstu za Pomocą Przestrzeni Roboczych

W przypadku pracy dla klientów lub scenariuszy wieloprojektowych, utwórz oddzielne przestrzenie robocze z niestandardowymi instrukcjami zawierającymi:

  • Nazwę klienta i branżę
  • Wielkość i strukturę firmy
  • Stos technologiczny
  • Ramy i harmonogramy audytów
  • Konkretne priorytety lub ograniczenia

Przykładowa instrukcja:

"Klient: Acme Corp, 120-osobowy fintech, z siedzibą w UE. Technologia: Azure, GitHub, Salesforce, Okta. Wdrażamy ISO 27001:2022 i przygotowujemy się do audytu RODO. Priorytet: szybkie zwycięstwa dla certyfikacji w ciągu 6 miesięcy, nacisk na rezydencję danych i szyfrowanie. Budżet: 25 tys. USD na narzędzia."

Wszystkie zapytania w tej przestrzeni roboczej automatycznie stosują ten kontekst bez powtórzeń.

Dowiedz się więcej o Przestrzeniach Roboczych

Kontekst dla Różnych Typów Zapytań

Generowanie Polityk

Podaj: role, narzędzia, częstotliwości przeglądów, przepływy zatwierdzania

Przykład: "Sporządź politykę reagowania na incydenty dla ISO 27001 A.5.24. Role: Lider ds. Bezpieczeństwa (Jane), CTO (zatwierdzanie), Zespół Inżynieryjny (reakcja). Narzędzia: PagerDuty do alertów, Jira do śledzenia, Slack do komunikacji. Przeglądy poincydentowe w ciągu 48 godzin."

Analiza Luk

Podaj: aktualny stan, docelowe ramy, znane słabości

Przykład: "Przeanalizuj naszą obecną postawę bezpieczeństwa w odniesieniu do SOC 2 CC6-CC8. Mamy MFA przez Okta, kwartalne przeglądy dostępu, ochronę gałęzi w GitHub i AWS CloudTrail. Brakuje: formalnej dokumentacji zarządzania zmianami, oceny ryzyka dostawców i testów DRP."

Przygotowanie Dowodów

Podaj: zakres audytu, możliwości zbierania dowodów, narzędzia z logowaniem

Przykład: "Jakie dowody są potrzebne dla ISO 27001 A.8.15 (logowanie i monitorowanie)? Mamy AWS CloudTrail, Datadog APM i logi systemowe Okta. Zakres audytu: środowisko produkcyjne AWS i korporacyjne SSO."

Wskazówki Dotyczące Wdrożenia

Podaj: umiejętności zespołu, harmonogram, istniejące narzędzia

Przykład: "Jak wdrożyć szyfrowanie danych w spoczynku dla ISO 27001 A.8.24? Nasz inżynier DevOps ma doświadczenie z AWS, używamy RDS PostgreSQL i S3 do przechowywania plików, a implementacja musi być zakończona w ciągu 4 tygodni."

Unikaj umieszczania rzeczywistych wrażliwych danych (nazw klientów, prawdziwych haseł, danych osobowych) w zapytaniach. Używaj zastępczych określeń jak "[baza danych klientów]" lub "[procesor płatności]" i włącz redukcję PII, jeśli omawiasz scenariusze obsługi danych.

Kiedy Aktualizować Kontekst

Odświeżaj kontekst, gdy Twoja organizacja ulega zmianom:

  • Znaczący wzrost lub redukcja zatrudnienia
  • Wdrożenie nowych technologii (np. migracja do Kubernetes)
  • Zmiany regulacyjne (np. nowe wymogi RODO)
  • Ustalenia poaudytowe wymagające naprawy
  • Przejście z fazy wdrażania do fazy utrzymania

Aktualizuj niestandardowe instrukcje w przestrzeniach roboczych, zamiast edytować przeszłe zapytania.

Testowanie Twojego Kontekstu

Przed wysłaniem zapytania, sprawdź, czy uwzględniłeś:

  1. Wielkość firmy i strukturę zespołu
  2. Branżę i odpowiednie regulacje
  3. Kluczowe technologie i narzędzia
  4. Aktualny stan i cele
  5. Wszelkie ograniczenia lub priorytety

Jeśli dana kategoria dotyczy Twojego zapytania, uwzględnij ją.

Dobrze sformułowane zapytania z kontekstem generują wyniki gotowe do audytu za pierwszym razem. Ogólne zapytania wymagają wielu rund poprawek, zużywając limit wiadomości i czas.

Następne Kroki

Dodaj kontekst organizacyjny do swojego następnego zapytania. Porównaj jakość i specyfikę odpowiedzi z poprzednimi, ogólnymi próbami.

Powrót do Przeglądu Inżynierii Promptów

On this page