zgodność regulacyjna

Zgodność regulacyjna (ang. compliance) to stan, w którym organizacja spełnia wymagania prawa, umów, norm i regulacji wewnętrznych i potrafi to wykazać dowodami. Sama zgodność nie jest tożsama z bezpieczeństwem: dokument może istnieć, a opisany w nim mechanizm nie działać. W polskich tekstach branżowych obok zwrotu „zapewnienie zgodności” funkcjonuje angielskie „compliance”, na przykład w zestawieniu „od compliance aż po twarde rozwiązania techniczne” ^[4]. Ramy NIST ujmują to samo jako wynik, w którym prawne, regulacyjne i umowne wymagania dotyczące cyberbezpieczeństwa, w tym obowiązki w zakresie prywatności, są zrozumiane i zarządzane ^[3].

Składniki

Zgodność ma trzy warstwy. Pierwsza to wymagania: przepisy, umowy z klientami i dostawcami, normy branżowe oraz polityki wewnętrzne. Druga to środki, którymi organizacja je realizuje. Trzecia to dowody, które pokazują, że środki działają.

Warstwę dowodów RODO nazywa rozliczalnością: administrator odpowiada za przestrzeganie zasad przetwarzania i musi być w stanie wykazać ich przestrzeganie ^[1]. Art. 24 dodaje, że administrator wdraża odpowiednie środki techniczne i organizacyjne, aby przetwarzanie odbywało się zgodnie z rozporządzeniem i aby móc to wykazać, a środki te w razie potrzeby poddaje przeglądom i aktualizuje ^[1]. Zatwierdzony kodeks postępowania albo mechanizm certyfikacji może być jednym z elementów takiego wykazania ^[1].

Jak działa

Zarządzanie zgodnością to proces ciągły. NIST CSF 2.0 umieszcza go w funkcji GOVERN, w kategorii kontekstu organizacji, obok misji, oczekiwań interesariuszy i zależności ^[3]. Ramy nie przesądzają, jak osiągnąć opisane wyniki; wskazują je, a sposób realizacji pozostawiają organizacji ^[3]. Cykl pokazuje schemat poniżej.

RYS. 1Cykl zarządzania zgodnością

W praktyce łączy się to z szacowaniem ryzyka, bo większość współczesnych regulacji nie podaje zamkniętej listy zabezpieczeń, tylko każe dobrać je do ryzyka. Podejście łączące ład, ryzyko i zgodność bywa nazywane GRC, a formalną ramą dla niego jest system zarządzania bezpieczeństwem informacji.

Wymagania NIS2 jako przykład

Dyrektywa NIS2 dobrze pokazuje, czym zgodność różni się od posiadania dokumentów. Art. 21 wymaga od podmiotów kluczowych i ważnych odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych, uwzględniających najnowszy stan wiedzy ^[2]. Minimalna lista obejmuje m.in. politykę analizy ryzyka, obsługę incydentów, ciągłość działania z zarządzaniem kopiami zapasowymi (backup), bezpieczeństwo łańcucha dostaw, postępowanie z podatnościami, ocenę skuteczności środków, kryptografię oraz, w stosownych przypadkach, uwierzytelnianie wieloskładnikowe (MFA) ^[2].

Art. 20 przenosi odpowiedzialność na kierownictwo: organy zarządzające zatwierdzają środki zarządzania ryzykiem, nadzorują ich wdrażanie i mogą ponosić odpowiedzialność za naruszenia, a ich członkowie mają obowiązek regularnych szkoleń ^[2]. Za naruszenie art. 21 lub 23 podmiotom kluczowym grożą kary o maksymalnej wysokości co najmniej 10 000 000 EUR lub co najmniej 2% rocznego światowego obrotu, przy czym stosuje się kwotę wyższą ^[2]. Art. 23 dotyczy obowiązku zgłaszania incydentów.

W WordPressie

Strona na WordPressie podlega kilku reżimom naraz, zależnie od tego, co robi.

• Dane osobowe. Formularze, komentarze, konta i zamówienia oznaczają obowiązki z RODO. Narzędzia prywatności w rdzeniu pomagają przy części z nich, ale dokumentacja wprost stwierdza, że nie są same w sobie procesem zapewniania zgodności ^[7]. Zapisuje też, że ochrona prywatności nie jest obowiązkiem jednorazowym, tylko procesem ciągłym ^[7].
• Płatności kartą. Według dokumentacji WooCommerce za zgodność z PCI DSS ostatecznie odpowiada właściciel sklepu ^[6]. Bramka płatności przyjmująca dane karty poza stroną może znacznie zmniejszyć zakres wymagań, ale PCI DSS nadal ma zastosowanie ^[6]. Operator płatności może zażądać kwestionariusza samooceny (SAQ) albo skanów przez zatwierdzonego dostawcę (ASV) ^[6].
• Wtyczki z katalogu. Wytyczne WordPress.org wymagają m.in. zgodności kodu z licencją GNU GPL oraz zakazują śledzenia użytkowników bez ich zgody; wtyczka nie może kontaktować się z zewnętrznymi serwerami bez wyraźnej i autoryzowanej zgody ^[5]. To przykład zgodności z regulaminem platformy, który przy okazji chroni prywatność użytkowników.

Dla właściciela strony oznacza to potrzebę rejestru: jakie dane zbiera strona, jakie wtyczki i usługi zewnętrzne je przetwarzają, z kim zawarto umowę powierzenia, gdzie są kopie zapasowe i kto ma dostęp do panelu.

Zgodność a bezpieczeństwo

Zgodność i bezpieczeństwo pokrywają się, ale nie są tym samym. Wymagania bywają minimum, a nie pełną odpowiedzią na zagrożenia danej organizacji. Z drugiej strony dobrze wdrożone zabezpieczenia bez dokumentacji nie wystarczą, gdy trzeba je wykazać przed organem lub kontrahentem. RODO wymaga środków odpowiednich do ryzyka i poddawanych przeglądom ^[1], a NIS2 dodatkowo polityk i procedur oceny skuteczności środków zarządzania ryzykiem ^[2]. Obie regulacje sprawdzają więc działanie zabezpieczeń, a nie tylko ich opis.

Dobre praktyki

• Prowadzić listę wymagań z podaniem źródła: przepis, umowa, norma, polityka.
• Każde wymaganie przypisać do właściciela i do dowodu, na przykład raportu z audytu bezpieczeństwa, dziennika testu odtwarzania kopii, rejestru szkoleń.
• Przy zmianie systemu, na przykład nowej wtyczce, sprawdzić, czy nie zmienia zakresu wymagań; zob. ocena skutków dla ochrony danych.
• Włączyć dostawców do procesu przez zarządzanie ryzykiem dostawców (third-party risk management, TPRM).
• Traktować NIST Cybersecurity Framework i podobne ramy jako wspólny język dla wymagań z różnych źródeł ^[3].