Certyfikacja ISO 27001 w chmurze - jak przygotować AWS, Azure i GCP do audytu

„Potrzebujemy ISO 27001” - to zdanie słyszymy coraz częściej od polskich firm IT, które rosną na tyle, że ich klienci zaczynają wymagać formalnych gwarancji bezpieczeństwa. Problem polega na tym, że większość materiałów o ISO 27001 opisuje środowiska on-premises: szafy serwerowe, kontrola dostępu fizycznego, polityki haseł na lokalnym Active Directory.

Jeśli Twoja infrastruktura jest w chmurze, musisz przeinterpretować wymagania standardu. AWS, Azure i GCP mają własne certyfikaty ISO 27001 - ale to certyfikacja ich infrastruktury, nie Twojej aplikacji. Model odpowiedzialności dzielonej (Shared Responsibility) oznacza, że dostawca odpowiada za „bezpieczeństwo chmury” (fizyczne centra danych, hypervisor, sieć), a Ty za „bezpieczeństwo w chmurze” (konfiguracja, dostępy, dane, aplikacja).

Ten artykuł jest mapą: od wymagań ISO 27001:2022 przez konkretne kontrolki techniczne na AWS, Azure i GCP, po automatyzację dowodów audytowych.

Co to jest ISO 27001 i dlaczego firmy cloud-native go potrzebują

ISO/IEC 27001:2022 to standard definiujący wymagania dla Systemu Zarządzania Bezpieczeństwem Informacji (ISMS - Information Security Management System). Nie jest to checklist techniczny - to framework zarządczy, który wymaga:

1. Kontekstu organizacji - zrozumienie, jakie informacje chronisz i dla kogo
2. Analizy ryzyka - identyfikacja zagrożeń i podatności specyficznych dla Twojego środowiska
3. Zabezpieczeń (controls) - wdrożenie odpowiednich środków ochrony (Annex A)
4. Ciągłego doskonalenia - monitoring, przeglądy, audyty wewnętrzne, działania korygujące

Wersja 2022 vs 2013

ISO 27001:2022 zastąpiło wersję z 2013 roku. Kluczowe zmiany:

• Annex A zredukowany ze 114 do 93 kontrolek (pogrupowanych w 4 kategorie zamiast 14)
• Nowe kontrolki specyficzne dla chmury: A.5.23 (bezpieczeństwo usług chmurowych), A.8.11 (maskowanie danych), A.8.23 (filtrowanie treści web)
• Większy nacisk na threat intelligence (A.5.7) i bezpieczeństwo ICT supply chain (A.5.21)
• Atrybuty kontrolek (prewencyjne, detekcyjne, korekcyjne) - ułatwiają mapowanie na narzędzia chmurowe

Kiedy ISO 27001 jest potrzebne

Model odpowiedzialności dzielonej a ISO 27001

Zanim przejdziesz do wdrażania kontrolek, musisz precyzyjnie zdefiniować granicę odpowiedzialności między Tobą a dostawcą chmury. Audytor ISO 27001 zapyta: „Jakie zabezpieczenia wdrożyliście?” - musisz wiedzieć, które kontrolki realizuje dostawca (i mieć na to dowód), a które realizujesz samodzielnie.

Co dostawca pokrywa za Ciebie

Wszyscy trzej główni dostawcy (AWS, Azure, GCP) posiadają certyfikat ISO 27001 dla swojej infrastruktury. To oznacza, że poniższe kontrolki Annex A są pokryte przez dostawcę:

• A.7 (Physical controls) - bezpieczeństwo fizyczne centrów danych, ochrona przed zagrożeniami środowiskowymi
• A.8.12 (Data leakage prevention) - na poziomie hypervisora i separacji tenantów
• A.8.14 (Redundancy) - redundancja sprzętowa, zasilanie, chłodzenie

Co musisz zrobić sam

Kontrolki, za które odpowiadasz Ty (konfiguracja, polityki, procesy):

• A.5 (Organizational controls) - polityki bezpieczeństwa, role, odpowiedzialności
• A.6 (People controls) - szkolenia, weryfikacja pracowników, warunki zatrudnienia
• A.8.1-A.8.11, A.8.13, A.8.15-A.8.34 - większość kontrolek technologicznych: IAM, szyfrowanie, logowanie, backup, monitoring

Dowód pokrycia przez dostawcę

Na audycie musisz wykazać, że dostawca pokrywa swoje kontrolki. Każdy provider udostępnia:

• AWS: AWS Artifact - portal z raportami ISO 27001, SOC 2, PCI DSS (dostępny w konsoli AWS)
• Azure: Service Trust Portal (servicetrust.microsoft.com) - certyfikaty i raporty audytowe
• GCP: Compliance Reports Manager w Google Cloud Console + strona compliance.google.com

Pobierz certyfikat ISO 27001 dostawcy i dołącz do dokumentacji ISMS jako dowód pokrycia kontrolek fizycznych.

Annex A w chmurze - mapowanie kontrolek na usługi AWS, Azure i GCP

Poniżej mapowanie najważniejszych kontrolek Annex A (ISO 27001:2022) na konkretne usługi i konfiguracje u trzech dostawców. Skupiam się na kontrolkach technologicznych (A.8), bo to one wymagają najwięcej pracy w środowisku chmurowym.

A.8.2 - Uprzywilejowane prawa dostępu (Privileged access rights)

Wymaganie: ograniczenie i kontrola przydziału uprzywilejowanego dostępu.

A.8.5 - Bezpieczne uwierzytelnianie (Secure authentication)

Wymaganie: mechanizmy uwierzytelniania proporcjonalne do klasyfikacji informacji.

Rekomendowana architektura uwierzytelniania (multi-cloud):

┌─────────────────────────────────────────────────┐
│  Identity Provider (IdP)                        │
│  (Entra ID / Okta / Google Workspace)           │
│                                                 │
│  - SSO (SAML 2.0 / OIDC)                        │
│  - MFA (hardware key + biometrics)              │
│  - Conditional Access (lokalizacja, urządzenie) │
│  - Session timeout: 8h (regular), 1h (admin)    │
└─────────────┬───────────────────────────────────┘
              │ Federation
              ├──────────────── AWS IAM Identity Center
              ├──────────────── Azure (native Entra ID)
              └──────────────── GCP Workforce Identity Federation

Kluczowe zasady:

• Jeden IdP jako źródło prawdy (Single Source of Truth) - nie twórz lokalnych użytkowników w konsoli chmury
• MFA obowiązkowe dla wszystkich użytkowników (nie tylko adminów) - ISO 27001:2022 A.8.5 nie rozróżnia poziomów
• Session timeout: max 8 godzin dla zwykłych użytkowników, max 1 godzina dla kont administracyjnych
• Monitoruj nieudane logowania i blokuj po 5 próbach

A.8.9 - Zarządzanie konfiguracją (Configuration management)

Wymaganie: konfiguracje systemów ustalone, udokumentowane, wdrożone, monitorowane i przeglądane.

To jest kontrolka, która w chmurze realizowana jest przez Infrastructure as Code (IaC). Audytor oczekuje:

• Udokumentowanej konfiguracji bazowej (baseline)
• Mechanizmu wykrywania odchyleń (drift detection)
• Procesu zatwierdzania zmian (change management)

Przykład: AWS Config Rule sprawdzająca, czy wszystkie buckety S3 mają włączone szyfrowanie:

{
  "ConfigRuleName": "s3-bucket-server-side-encryption-enabled",
  "Source": {
    "Owner": "AWS",
    "SourceIdentifier": "S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED"
  },
  "Scope": {
    "ComplianceResourceTypes": ["AWS::S3::Bucket"]
  }
}

Na Azure odpowiednik to Policy Definition:

{
  "if": {
    "allOf": [
      { "field": "type", "equals": "Microsoft.Storage/storageAccounts" },
      { "field": "Microsoft.Storage/storageAccounts/minimumTlsVersion", "notEquals": "TLS1_2" }
    ]
  },
  "then": { "effect": "deny" }
}

A.8.15 - Logowanie (Logging)

Wymaganie: logi rejestrujące aktywności, wyjątki, błędy i inne istotne zdarzenia muszą być generowane, przechowywane, chronione i analizowane.

To jest kontrolka krytyczna dla audytu. Audytor poprosi o dowód, że przez ostatnie 12 miesięcy logowanie było aktywne i logi nie były modyfikowane.

Konfiguracja niemodyfikowalnego przechowywania logów na AWS:

# Bucket z Object Lock dla logów CloudTrail
aws s3api create-bucket \
  --bucket company-audit-logs-2026 \
  --region eu-central-1 \
  --create-bucket-configuration LocationConstraint=eu-central-1 \
  --object-lock-enabled-for-bucket

# Domyślna retencja 365 dni (COMPLIANCE mode - nie można skrócić)
aws s3api put-object-lock-configuration \
  --bucket company-audit-logs-2026 \
  --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {
      "DefaultRetention": {
        "Mode": "COMPLIANCE",
        "Days": 365
      }
    }
  }'

A.8.24 - Kryptografia (Use of cryptography)

Wymaganie: zasady stosowania kryptografii, w tym zarządzanie kluczami, muszą być zdefiniowane i wdrożone.

W chmurze szyfrowanie at-rest jest domyślnie włączone u wszystkich dostawców. Ale ISO 27001 wymaga czegoś więcej: udokumentowanej polityki kryptograficznej, zarządzania kluczami i świadomej decyzji o typie szyfrowania.

Dla ISO 27001 minimalne wymaganie to:

• Dokumentacja polityki kryptograficznej (jaki typ szyfrowania, dla jakich danych)
• CMEK dla danych wrażliwych (dane osobowe, dane finansowe, sekrety)
• Automatyczna rotacja kluczy (audytor sprawdzi, czy rotacja faktycznie działa)
• Logi dostępu do kluczy (kto użył klucza do odszyfrowania i kiedy)

A.8.25 - Bezpieczny cykl życia oprogramowania (Secure development lifecycle)

Wymaganie: zasady bezpiecznego wytwarzania oprogramowania muszą być ustalone i stosowane.

W kontekście chmury to kontrolka realizowana przez pipeline CI/CD z wbudowanymi bramkami bezpieczeństwa:

Developer → Commit → Pipeline CI/CD
                         │
                         ├── SAST (statyczna analiza kodu)
                         ├── SCA (skanowanie zależności)
                         ├── Container scan (podatności w obrazach)
                         ├── IaC scan (Terraform/CloudFormation - misconfigurations)
                         ├── Testy jednostkowe i integracyjne
                         ├── Code Review (wymagany 1 approver)
                         │
                         └── Deploy → Production
                                      │
                                      └── DAST (dynamiczna analiza po deploy)

Narzędzia per provider:

• AWS: CodeGuru Reviewer (SAST), ECR Image Scanning, Inspector (runtime)
• Azure: Microsoft Defender for DevOps, GitHub Advanced Security (GHAS), Container Registry scanning
• GCP: Artifact Analysis, Binary Authorization, Cloud Build + integracja z Snyk/SonarQube

A.5.23 - Bezpieczeństwo usług chmurowych (nowa kontrolka w 2022)

To jest kontrolka dodana specjalnie w wersji 2022 standardu. Wymaga:

1. Zdefiniowania wymagań bezpieczeństwa dla usług chmurowych
2. Kryteriów wyboru dostawcy chmury
3. Monitorowania zgodności dostawcy
4. Zarządzania zmianami w usługach chmurowych (np. deprecation, zmiana regionów)

Czego audytor oczekuje

• Polityka korzystania z usług chmurowych - dokument opisujący: jakich dostawców używacie, jakie dane przetwarzacie w chmurze, jakie wymagania bezpieczeństwa nakładacie na dostawcę
• Ocena dostawcy - dowód, że zweryfikowaliście certyfikaty dostawcy (ISO 27001, SOC 2) przed wyborem
• Umowa / DPA - Data Processing Agreement z dostawcą (AWS/Azure/GCP mają standardowe DPA)
• Monitoring SLA - jak monitorujecie, czy dostawca dotrzymuje zobowiązań

Praktyczna realizacja

Stwórz dokument „Cloud Security Policy” zawierający:

1. Dozwoleni dostawcy: AWS, Azure, GCP (z uzasadnieniem wyboru)
2. Dozwolone regiony: eu-central-1, eu-west-1, europe-west1 (uzasadnienie: RODO, rezydencja danych)
3. Klasyfikacja danych w chmurze:
   - Publiczne → dowolna usługa, dowolny region
   - Wewnętrzne → managed services z szyfrowaniem, region EU
   - Poufne → CMEK, VPC/VNet isolation, region EU, audit logging
   - Ściśle poufne → HSM, dedykowany VPC, zero-trust access
4. Wymagania wobec dostawcy: ISO 27001, SOC 2 Type II, DPA podpisane
5. Przegląd roczny: weryfikacja aktualności certyfikatów dostawcy

Budowanie ISMS - podejście pragmatyczne dla firmy chmurowej

ISO 27001 wymaga Systemu Zarządzania Bezpieczeństwem Informacji (ISMS). Brzmi biurokratycznie, ale w praktyce to zestaw dokumentów + procesów + narzędzi. Dla firmy 20-100 osób operującej w chmurze, ISMS może być lekki i zautomatyzowany.

Minimalna dokumentacja ISMS

Rejestr ryzyk specyficznych dla chmury

Typowe ryzyka, które audytor oczekuje zobaczyć w rejestrze firmy cloud-native:

1. Nieautoryzowany dostęp do konsoli chmury - prawdopodobieństwo: średnie, wpływ: wysoki → zabezpieczenie: MFA + SSO + session timeout
2. Wyciek danych z błędnie skonfigurowanego storage - prawdopodobieństwo: średnie, wpływ: wysoki → zabezpieczenie: Block Public Access (default) + AWS Config/Azure Policy
3. Vendor lock-in / niedostępność dostawcy - prawdopodobieństwo: niskie, wpływ: wysoki → zabezpieczenie: multi-region, backup off-cloud, IaC
4. Eskalacja uprawnień przez nadmiarowe role IAM - prawdopodobieństwo: średnie, wpływ: średni → zabezpieczenie: least privilege + IAM Access Analyzer
5. Utrata danych (brak backup lub uszkodzony backup) - prawdopodobieństwo: niskie, wpływ: krytyczny → zabezpieczenie: automatyczny backup + testy odtwarzania

Automatyzacja zbierania dowodów audytowych

Największy koszt certyfikacji ISO 27001 to nie wdrożenie kontrolek - to ciągłe zbieranie dowodów, że kontrolki działają. Audytor nadzoru (co rok) poprosi o dowody z ostatnich 12 miesięcy. Ręczne screenshotowanie konsoli to strata czasu. Automatyzacja jest kluczowa.

AWS - zestaw narzędzi do compliance

AWS Audit Manager
├── Framework: ISO 27001:2022 (gotowy, wbudowany)
├── Automatyczne zbieranie dowodów:
│   ├── CloudTrail events → kontrolki A.8.15 (Logging)
│   ├── Config compliance → kontrolki A.8.9 (Configuration management)
│   ├── Security Hub findings → kontrolki A.8.8 (Vulnerability management)
│   └── IAM Access Analyzer → kontrolki A.8.2 (Privileged access)
└── Generowanie raportów per kontrolka

AWS Audit Manager automatycznie mapuje usługi AWS na kontrolki ISO 27001. Wystarczy włączyć assessment i co miesiąc eksportować raport. Koszt: $1.25/assessment/miesiąc (za jeden framework).

Azure - Microsoft Defender for Cloud + Compliance Manager

Azure oferuje dwa narzędzia:

1. Defender for Cloud - ciągły monitoring compliance z wbudowanym benchmarkiem ISO 27001
2. Microsoft Purview Compliance Manager - zarządzanie dowodami, akcjami naprawczymi, scoring

Konfiguracja w Defender for Cloud:

# Przypisanie inicjatywy ISO 27001:2022 do subskrypcji
az policy assignment create \
  --name 'ISO27001-2022' \
  --display-name 'ISO 27001:2022 Compliance' \
  --scope "/subscriptions/${SUBSCRIPTION_ID}" \
  --policy-set-definition '/providers/Microsoft.Authorization/policySetDefinitions/ISO27001-2022'

Po przypisaniu inicjatywy, Defender for Cloud generuje compliance score i listę niezgodności z mapowaniem na kontrolki Annex A.

GCP - Security Command Center + Assured Workloads

Podejście GCP:

1. Security Command Center Premium - compliance dashboard z CIS Benchmarks (mapowalne na ISO 27001)
2. Assured Workloads - wymuszanie kontrolek compliance na poziomie folderu/projektu
3. Cloud Asset Inventory - historia konfiguracji zasobów (dowód na A.8.9)

# Eksport compliance findings z SCC do BigQuery (automatyczny raport miesięczny)
gcloud scc findings list organizations/${ORG_ID} \
  --filter="category=\"COMPLIANCE_VIOLATION\"" \
  --format=json > monthly-compliance-report.json

Harmonogram zbierania dowodów

Proces certyfikacji - etapy i timeline

Etap 1: Gap analysis (2-4 tygodnie)

Ocena aktualnego stanu bezpieczeństwa wobec wymagań ISO 27001:2022. Wynik: lista luk do uzupełnienia.

Co sprawdzamy:

• Czy istnieją podstawowe polityki (kontrola dostępu, kryptografia, incydenty)?
• Czy logowanie jest włączone i logi przechowywane minimum 1 rok?
• Czy IAM jest skonfigurowany zgodnie z zasadą least privilege?
• Czy backup istnieje i jest testowany?
• Czy pipeline CI/CD ma bramki bezpieczeństwa?

Etap 2: Wdrożenie ISMS (6-12 tygodni)

Uzupełnienie luk zidentyfikowanych w gap analysis:

• Opracowanie brakujących polityk i procedur
• Konfiguracja zabezpieczeń technicznych (IAM hardening, szyfrowanie CMEK, logowanie)
• Wdrożenie narzędzi compliance (Audit Manager / Defender / SCC)
• Szkolenie pracowników (awareness training)
• Przeprowadzenie oceny ryzyka

Etap 3: Okres działania ISMS (minimum 3 miesiące)

Audytor certyfikujący wymaga dowodów, że ISMS działa. Minimum 3 miesiące operacji przed audytem certyfikującym. W tym czasie:

• Zbierasz dowody (automatycznie)
• Przeprowadzasz co najmniej 1 audyt wewnętrzny
• Przeprowadzasz przegląd zarządzania (Management Review)
• Reagujesz na incydenty zgodnie z procedurą (jeśli wystąpią)
• Przeglądasz i aktualizujesz rejestr ryzyk

Etap 4: Audyt certyfikujący (Stage 1 + Stage 2)

• Stage 1 (1-2 dni) - audytor przegląda dokumentację ISMS, polityki, rejestr ryzyk, SoA. Identyfikuje ewentualne braki przed Stage 2.
• Stage 2 (2-5 dni, zależy od wielkości firmy) - audytor weryfikuje, czy kontrolki faktycznie działają. Rozmowy z pracownikami, przegląd dowodów, testy konfiguracji.

Timeline dla firmy 30-50 osób operującej w chmurze

Tydzień 1-4:    Gap analysis + plan naprawczy
Tydzień 5-16:   Wdrożenie ISMS (polityki + kontrolki techniczne)
Tydzień 17-28:  Okres działania ISMS (zbieranie dowodów)
Tydzień 20:     Audyt wewnętrzny
Tydzień 24:     Przegląd zarządzania (Management Review)
Tydzień 29:     Stage 1 audytu certyfikującego
Tydzień 31-32:  Stage 2 audytu certyfikującego
Tydzień 33:     Decyzja o certyfikacji

Realny timeline: 8-9 miesięcy od decyzji do certyfikatu. Można skrócić do 6 miesięcy, jeśli firma ma już dojrzałe procesy bezpieczeństwa (np. przeszła SOC 2).

Koszty certyfikacji ISO 27001 w chmurze

Koszty jednorazowe (przygotowanie + audyt)

Koszty roczne (utrzymanie certyfikacji)

Optymalizacja kosztów: natywne narzędzia vs platformy GRC

Możesz realizować zbieranie dowodów dwoma sposobami:

1. Platformy GRC (Vanta, Drata, Secureframe) - automatyzacja cross-cloud, gotowe mapowania, dashboard compliance. Koszt: $10,000-25,000/rok. Zaleta: szybsze wdrożenie, mniej pracy manualnej.

2. Natywne narzędzia chmury (Audit Manager, Defender, SCC) - tańsze ($2,000-8,000/rok), ale wymagają więcej konfiguracji i integracji. Zaleta: brak dodatkowego dostawcy, dane zostają w Twojej chmurze.

Dla firmy operującej na jednym dostawcy: natywne narzędzia wystarczą. Dla multi-cloud: platforma GRC oszczędza czas.

Najczęstsze błędy przy certyfikacji ISO 27001 w chmurze

1. Kopiowanie polityk z szablonów bez dostosowania do chmury

Audytor natychmiast zobaczy, że polityka kontroli dostępu mówi o „kartach dostępu do serwerowni”, a firma nie ma serwerowni. Polityki muszą odzwierciedlać rzeczywistość - opisywać IAM Roles, SSO, Conditional Access, nie fizyczne zamki.

2. Brak dowodów na działanie kontrolek

Mieć włączony CloudTrail to za mało. Audytor zapyta: „Pokaż mi, że analizujecie te logi”. Potrzebujesz:

• Alertów na podejrzane aktywności (dowód na monitoring)
• Procesów reagowania na alerty (dowód na incident response)
• Historii zamkniętych incydentów (dowód na działanie procedury)

3. Zbyt szeroki zakres ISMS

Nie musisz certyfikować całej firmy. Zakres może obejmować np. „Usługę X dostarczaną klientom, wraz z infrastrukturą chmurową na AWS i zespołem development”. Im węższy zakres, tym mniej kontrolek do wdrożenia, mniej dowodów do zebrania i niższy koszt audytu.

4. Ignorowanie kontrolek ludzkich (A.6)

ISO 27001 to nie tylko technologia. Kontrolki A.6 (People controls) wymagają:

• Weryfikacji pracowników przed zatrudnieniem (background check)
• Szkolenia z bezpieczeństwa informacji (awareness training)
• Zobowiązania do poufności (NDA / klauzula w umowie)
• Procesu odejścia pracownika (deprovisioning dostępów)

W firmie chmurowej deprovisioning musi obejmować: usunięcie z IdP (co automatycznie odcina dostęp do AWS/Azure/GCP), cofnięcie dostępu do repozytoriów, rotacja sekretów, do których miał dostęp.

5. Brak testów backup/restore

Kontrolka A.8.13 (Information backup) wymaga nie tylko posiadania backup - ale dowodu, że backup działa. Audytor zapyta: „Kiedy ostatnio testowaliście odtwarzanie z backup? Jaki był wynik?”. Planuj testy restore co kwartał i dokumentuj wyniki.

Podsumowanie - checklist przygotowania do ISO 27001 w chmurze

Faza 1: Fundament organizacyjny (tydzień 1-4)

• Decyzja o zakresie ISMS (jakie systemy, jakie dane, jaki zespół)
• Powołanie osoby odpowiedzialnej za ISMS (Information Security Officer)
• Opracowanie polityki bezpieczeństwa informacji
• Przeprowadzenie gap analysis

Faza 2: Kontrolki techniczne (tydzień 5-12)

• IAM hardening (SSO, MFA, least privilege, przeglądy uprawnień)
• Logowanie i monitoring (CloudTrail/Activity Log/Audit Logs + centralizacja + WORM)
• Szyfrowanie (CMEK dla danych wrażliwych, rotacja kluczy)
• Backup + testy restore
• Pipeline CI/CD z bramkami bezpieczeństwa (SAST, SCA, container scan)
• Network security (security groups / NSG, WAF, VPC isolation)

Faza 3: Dokumentacja i procesy (tydzień 8-16)

• Ocena ryzyka (rejestr ryzyk + plan postępowania)
• Statement of Applicability (SoA)
• Procedura incydentów bezpieczeństwa
• Plan ciągłości działania (BCP/DR)
• Polityka kryptograficzna
• Polityka usług chmurowych (A.5.23)

Faza 4: Operacja ISMS (tydzień 17-28)

• Automatyczne zbieranie dowodów (Audit Manager / Defender / SCC)
• Szkolenia pracowników
• Audyt wewnętrzny
• Przegląd zarządzania
• Reakcja na findings i działania korygujące

Jak możemy pomóc

W Devopsity pomagamy polskim firmom IT przygotować infrastrukturę chmurową do certyfikacji ISO 27001. Typowa współpraca:

• Gap analysis (3-5 dni) - ocena aktualnego stanu bezpieczeństwa wobec ISO 27001:2022, raport z listą luk i rekomendacjami
• Wdrożenie kontrolek technicznych (4-8 tygodni) - IAM hardening, centralizacja logów, szyfrowanie CMEK, pipeline CI/CD z bramkami bezpieczeństwa, automatyzacja compliance
• Wsparcie audytu (2-3 tygodnie) - przygotowanie dokumentacji, konfiguracja narzędzi zbierania dowodów, wsparcie podczas Stage 1 i Stage 2
• Utrzymanie (ongoing) - kwartalne przeglądy bezpieczeństwa, aktualizacja ISMS, wsparcie audytów nadzoru

Planujesz certyfikację ISO 27001?

Umów się na bezpłatną konsultację. Ocenimy, ile czasu i pracy potrzeba w Twoim przypadku.

Umów rozmowę

Najczęściej zadawane pytania

Czy certyfikat ISO 27001 dostawcy chmury (AWS/Azure/GCP) wystarczy?

Nie. Certyfikat dostawcy potwierdza bezpieczeństwo jego infrastruktury (centra danych, sieć, hypervisor). Twoja aplikacja, konfiguracja IAM, dane i procesy wymagają osobnej certyfikacji. Model odpowiedzialności dzielonej oznacza, że dostawca pokrywa kontrolki fizyczne (A.7), ale kontrolki organizacyjne (A.5), ludzkie (A.6) i większość technologicznych (A.8) leży po Twojej stronie.

Ile kosztuje certyfikacja ISO 27001 dla firmy 30-50 osób?

Przy infrastrukturze w chmurze i dojrzałych procesach DevOps: 55,000-100,000 PLN jednorazowo (konsultant + audyt + narzędzia). Utrzymanie roczne: 15,000-30,000 PLN (audyt nadzoru + narzędzia + czas zespołu). Firmy bez istniejących polityk bezpieczeństwa mogą spodziewać się wyższych kosztów wdrożenia.

Czy mogę certyfikować się na ISO 27001 bez konsultanta?

Technicznie tak, ale w praktyce to ryzykowne. Standard jest interpretacyjny - audytor oczekuje specyficznego podejścia do dokumentacji i dowodów. Firmy, które przechodzą proces bez doświadczonego wsparcia, typowo tracą więcej czasu (i pieniędzy na powtórne audyty) niż te, które inwestują w konsultanta od początku.

ISO 27001 vs SOC 2 - co wybrać?

Zależy od rynku. ISO 27001 jest preferowany w Europie, administracji publicznej i przetargach. SOC 2 jest standardem w USA i wśród firm SaaS. Jeśli obsługujesz klientów po obu stronach Atlantyku, możesz potrzebować obu. Dobra wiadomość: ~70% kontrolek pokrywa się, więc posiadanie jednego znacząco ułatwia uzyskanie drugiego.

Jak długo ważny jest certyfikat ISO 27001?

Certyfikat jest ważny 3 lata, ale wymaga audytów nadzoru co roku (w rocznicę certyfikacji). Jeśli audyt nadzoru wykaże poważne niezgodności i nie zostaną usunięte w wyznaczonym terminie, certyfikat może zostać zawieszony. Po 3 latach konieczna jest recertyfikacja (pełen audyt ponowny).

Czy ISO 27001 pomoże w zgodności z NIS2?

Tak. Dyrektywa NIS2 (obowiązująca od października 2024, implementacja w Polsce w toku) wymaga od podmiotów kluczowych i ważnych wdrożenia środków zarządzania ryzykiem cyberbezpieczeństwa. ISO 27001 pokrywa większość wymagań NIS2 (zarządzanie ryzykiem, obsługa incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw). Certyfikat ISO 27001 nie gwarantuje zgodności z NIS2 (dyrektywa ma dodatkowe wymagania dot. raportowania incydentów), ale znacząco ułatwia jej wykazanie.