Wiele osób rozważa możliwość zastosowania norm serii ISO do zarządzania ochroną danych osobowych. W trakcie naszego warsztatu o planach ciągłości działania uznaliśmy, że można, jednak z dużą dozą ostrożności.
Toksyczne słowa
To określenie, którego używam do wskazania fraz, słów, czy określeń w dokumentach systemowych (politykach, procedurach, instrukcjach) oraz zapisach (dokumentują działania np. raporty, zestawienia, notatki), które mają wydźwięk wskazujący na niepoprawne działanie czy rozumienie. W RODO jest tych słów kilka. W obszarze ciągłości już sama ciągłość działania może być negatywnie odbierana, ponieważ to nie jej wymaga przepis, a dostępności i dostępu do danych.
Podobnie jest z jednym z fundamentów czyli RPO – recovery point objective, czyli punkt, do którego przywracamy się po awarii. W co najmniej dwóch aspektach:
- Zakładamy, że w tym punkcie mieliśmy jeszcze dane integralne (poprawne, zgodne z rzeczywistością). To jest jedno z wymagań w RODO, nie dotyczy ono jednak wprost realizacji zapisu z art. 32.1.c – czyli przywrócenia dostępności i dostępu, a spełnia wymaganie przetwarzania danych poprawnych (integralnych).
- Awaria zniszczyła nam część naszej bazy, archiwum. Ale wiemy, gdzie mamy ostatnie nasze zapisane dane.
Dodam jeszcze, że w normach ISO serii 22300 RPO nazywa się również MDL – maximum data loss, a więc maksymalna ilość utraconych danych.
Toksyczność
Jak widać od razu mamy tutaj pewnego rodzaju toksyczność, nawet jeśli poprawnie określimy sobie ten punkt. O poprawności za chwilę. Otóż RODO nie zezwala nam na to, abyśmy w sposób niekontrolowany, właśnie w wyniku awarii utracili jakiekolwiek dane. Jeśli do tego dojdzie, jest to naruszenie ochrony danych.
Poprawność liczenia MDL czy RPO (choć nazwijmy to raczej łagodniej) powinna oznaczać, że:
Tracimy na określony, dopuszczalny, oznaczony przez nas czas dostępność oraz dostęp do danych
Dane nie są utracone, ponieważ mamy je w innym miejscu np. dokumenty na podstawie których wprowadziliśmy dane do systemu. I jesteśmy w stanie je odtworzyć. To jest parametr wpływający na czas przywrócenia dostępności i dostępu.
Porównując dalej do modeli zarządzania ciągłością działania z norm ISO serii 22300, mamy kolejno następne definicje:
MBCO – minimum business continuity objective, mimo, że tłumaczenie dosłowne mówi o tym, że jest to minimalny cel dla ciągłości działania, ja wolę to określenie tłumaczyć jako minimalny poziom świadczonej usługi. Ten cel powinien być zrealizowany w czasie RTO – recovery time objective, czyli czasie, w którym wznowimy nasze działanie do minimalnego poziomu świadczonej usługi. W naszym przypadku zrobiliśmy nieco inaczej, ale o tym za chwilę.
Po czasie RTO następują kolejne działania w ramach odtwarzania np. na podstawie DRP – disaster recovery plan, planu odtwarzania po awarii lub po prostu na podstawie jakiejkolwiek procedury czy polityki zarządzania incydentami. Ich celem jest przywrócenie do stanu sprzed awarii.
Wszystkie te kroki powinny zostać zrealizowane we wcześniej określonej ramie czasowej, która w pełnym BCMS nazywa się różnie. Może to być najbardziej klasyczny MTPD – maxium tolerable period of disruption, czyli maksymalny tolerowany czas zakłócenia, czy jak w firmach z rodowodem z USA są to BIL – business interruption limit. My nazwaliśmy to MCUD – maksymalny czasu utraty dostępności.
Powiązanie wznawiania dostępności z ryzykiem
Audytując naprawdę wiele organizacji na ciągłość działania (tę specjalizację mam od 2012 roku) widziałem w wielu przypadkach, że w ramach zarządzania ciągłością działania pojawiają się „drugie systemy szacowania i oceny ryzyka”. Jest to błąd, ponieważ ryzyko powinno być oszacowane raz, jednym zespołem. W przeciwnym razie skutki są takie, jakie widziałem w tych firmach – dwa odrębne systemy, z dwoma całkowicie różnymi podejściami czy wynikami (o tym jeszcze napiszę, że sam skutek może być różnie oceniony, natomiast po co wykonywać podwójną pracę?).
W przypadku RODO po prostu trzeba wziąć takie ryzyka z ogólnego szacowania, które zmaterializują się w wyniku braku dostępności do danych. Na tej podstawie określamy MCUD (maksymalny czas utraty dostępu do danych), który będzie dla nas nieprzekraczalny i na tej podstawie planujemy wszystkie działania odtworzeniowe. I to są zabezpieczenia, o których mowa w art. 32 RODO.
Czas dostępności i dostępu
RODO w art. 32.1.c po raz kolejny pokazuje, że po pewnym dopracowaniu, jest całkiem niezłym poradnikiem zarządzania bezpieczeństwem. Pod warunkiem, że umiemy czytać akt prawny w pełni i tak jak został napisany, a nie jego interpretacje i teoretyczne wybrażenia.
- Czas przywrócenia dostępności do danych – to czas wznowienia minimalnego poziomu usług. Oznacza to, że dane już są. Jak w naszym warsztatowym przykładzie – dane wróciły na serwer bazodanowy i już są.
- Czas przywrócenia dostępu – to czas przywrócenia interfejsów, nadanie haseł.
W przypadku incydentu fizycznego będzie to np.:
- Przywiezienie dokumentów do archiwum, czy pomieszczeń
- Nadanie dostępów w kontroli dostępu do tych pomieszczeń lub wydanie kluczy.
Podsumowanie
Warto podkreślić, że większość z tych aspektów o których napisałem nie będzie realizowanych przez osobę zajmującą się ochroną danych. Za działania systemów, serwerów, sieci odpowiada IT, w przypadku incydentów fizycznych jest to dział zajmujący się bezpieczeństwem fizycznym.
Zadania managera czy specjalisty ds. ochrony danych osobowych to wskazanie dodatkowych wymagań wobec niektórych procesów w organizacji (np. tych związanych z ciągłością działania – pełną) oraz uruchomienie zasad raportowania i rejestracji działań, aby wykazać ich skuteczność (5.2 RODO czyli rozliczalność, bardziej rozumiana jako zademonstrowanie skuteczności, z angielskiego „to demonstrate”).
Ważne jest też to, że jeśli chcemy stosować normy ISO do naszych systemów, konieczne jest wskazanie w jaki sposób importujemy rozwiązania. Nie musimy stosować nazw dokładnie, bo żaden audytor ISO nie ma prawa wymagać od nas posługiwania się językiem normy. Więc jeśli zmienimy sobie MTPD na MCUD – to będzie ok, ważne aby to zapisać.
Ostatnia porada. Jeśli budujecie jakikolwiek system samodzielnie, to powinien być opisany. Tak, aby można było dokonać poprawnych przeglądów (nie mniej niż raz w roku), dokonać kolejnych analiz, czy korekt. Nie mając bazowego opisu w jaki sposób to jest robione, trudno będzie potem ten proces i jego „otoczkę” (dokumenty, zadania, zapisy) modyfikować.
