W dokumencie tym powinny się znaleźć zapisy o systematycznym tworzeniu kopii rezerwowych danych i ksiąg rachunkowych. Jeśli przyjęty system ochrony danych na komputerowych nośnikach nie zapewniałby trwałości zapisu informacji przez czas nie krótszy od wymaganego ustawą o rachunkowości (czyli co najmniej przez pięć lat), wówczas księgi rachunkowe należy wydrukować nie później niż na koniec roku obrotowego.
W praktyce jednostka powinna prowadzić także inną dokumentację związaną z eksploatacją systemu informatycznego rachunkowości. Dokumentacja powinna obejmować opis procedur związanych np. z:
- tworzeniem bieżących rezerwowych kopii danych,
- organizacją fizycznego transportu nośników danych (spedycją),
- postępowaniem w sytuacjach awaryjnych.
W poniższym wzorze zawarto przykładową instrukcję archiwizacji i przechowywania zbiorów danych księgowych dla jedno- lub kilkustanowiskowego informatycznego systemu rachunkowości.
Wzór
Kliknij aby zobaczyć ilustrację.
Kliknij aby zobaczyć ilustrację.
Systemy informatyczne rachunkowości obsługiwane na stanowiskach niewłączonych do sieci zawierają najczęściej wbudowane mechanizmy umożliwiające wykonywanie rezerwowych kopii danych. Kopie rezerwowe wykonuje się przy użyciu specjalnych programów zakupionych zwykle wraz z oprogramowaniem finansowo-księgowym (np. programu PKZIP czy ARJ).
Ponadto SIR może również posiadać wbudowaną funkcję informowania użytkownika o konieczności archiwizacji danych. W praktyce spotyka się dwa rozwiązania. W pierwszym przypadku system zawsze przypomina o archiwizacji danych przy zakończeniu pracy z programem. Drugie rozwiązanie polega na tym, że system posiada funkcję, w której użytkownik systemu sam ustala częstotliwość archiwizacji danych (np. co dwa dni), a system przypomina o obowiązku w odpowiednich terminach.
Instrukcja odnosząca się do fizycznego transportu nośników danych dotyczy zarówno dokumentów papierowych, jak i danych umieszczonych na nośnikach komputerowych. Powinna ona określać środki zabezpieczenia związane z transportem wewnętrznym i zewnętrznym (np. do zewnętrznego ośrodka obliczeniowego). Powinna w szczególności regulować zagadnienia dotyczące:
- właściwości opakowań nośników,
- wykazu i zasad sporządzania dokumentów towarzyszących transportowi,
- sprawdzania tożsamości odbiorcy nośników i potwierdzenia odbioru na dokumentach towarzyszących,
- zasady obsługi transportu,
- harmonogramów transportu,
- niezawodności środków transportu.
Szczególne znaczenie z punktu widzenia kompletności danych mają dokumenty towarzyszące spedycji. Powinny one zawierać następujące informacje:
- nazwę przedsiębiorstwa (komórki organizacyjnej) odpowiedzialnego za przygotowanie nośników,
- nazwę lub symbol systemu informatycznego, z którego dane pochodzą,
- rodzaje nośników,
- liczbę egzemplarzy nośników i sumy kontrolne,
- datę przekazania nośników,
- określenie osoby przekazującej i odbierającej nośniki, przy czym w momencie przejmowania nośników osoba odbierająca powinna zbadać prawdziwość danych zawartych w dokumencie towarzyszącym, dokonując kontroli formalnej nośników i potwierdzając to podpisem.
Dokument polityki bezpieczeństwa informacji
Większe podmioty opracowują dokument politykibezpieczeństwa informacji. W normach zaleca się, aby zawierał on co najmniej:
- definicję bezpieczeństwa informacji, jego ogólne cele i zakres oraz znaczenie,
- oświadczenie o intencjach kierownictwa, potwierdzające cele i zasady bezpieczeństwa informacji,
- krótkie wyjaśnienie polityki bezpieczeństwa, zasad, standardów i wymagań zgodności mających szczególne znaczenie dla instytucji,
- definicje ogólnych i szczególnych obowiązków w odniesieniu do zarządzania bezpieczeństwem informacji, w tym zgłaszania przypadków naruszenia bezpieczeństwa,
- odsyłacze do dokumentacji mogącej uzupełniać politykę, np. bardziej szczegółowych polityk bezpieczeństwa (polityki bezpieczeństwa poszczególnych systemów) i procedur oraz instrukcji dotyczących poszczególnych systemów informatycznych lub zasad bezpieczeństwa zalecanych do przestrzegania przez użytkowników.
Integralnym elementem każdej polityki są procedury, czyli sposoby postępowania, wykonywane w odstępach czasu, mające na celu minimalizowanie czynników ryzyka, które zostały określone w polityce. Instrukcje zawierają opis sposobów postępowania (np. wykonania kopii rezerwowej danych oraz raportów oceny, protokołów przeglądów i pomiarów). Procedura i instrukcja nie będą użyteczne, jeżeli będą wykonywane mechanicznie, bez skoncentrowania się na warunkach, na które nakierowana jest polityka.
Zalecane uzupełniające elementy dokumentacji polityki bezpieczeństwa to:
- wymagania bezpieczeństwa systemów informatycznych (np. pod względem poufności, integralności, dostępności, rozliczalności i niezawodności systemów)
- infrastruktura organizacyjna i określenie zakresu odpowiedzialności
- zintegrowanie bezpieczeństwa z rozwojem i nabywaniem systemów
- wytyczne i procedury
- zdefiniowanie klas na potrzeby klasyfikacji informacji
- strategia zarządzania ryzykiem
- planowanie awaryjne
- administrowanie personelem (zaleca się zwrócenie szczególnej uwagi na personel na stanowiskach wymagających zaufania, taki jak administratorzy systemu i personel informatyczny)
- uświadamianie i szkolenie
- obowiązki prawne i regulacyjne
- zarządzanie outsourcingiem (usługami świadczonymi przez podmioty zewnętrzne)
- obsługa incydentów bezpieczeństwa
Dokument polityki powinien zostać zatwierdzony przez kierownictwo, opublikowany i udostępniony w odpowiedni sposób wszystkim pracownikom.
W wielu dużych firmach dla niektórych systemów wymaga się przygotowania oddzielnych polityk bezpieczeństwa, które powinny opierać się na przeglądach analizy ryzyka. Polityka bezpieczeństwa systemu informatycznego powinna być zgodna z polityką bezpieczeństwa instytucji w zakresie systemów informatycznych. Powinna być jednak bardziej szczegółowa niż polityka bezpieczeństwa instytucji. Powinna zawierać szczegóły dotyczące wymaganych zabezpieczeń oraz uzasadniać konieczność ich wprowadzenia.
Polityka bezpieczeństwa systemu informatycznego i związane z nią dokumenty powinny zawierać:
- definicję danego systemu informatycznego, opis jego komponentów i zakresu (opis ten powinien obejmować wszelki sprzęt, oprogramowanie, aktywa ludzkie, środowisko i działania, które składają się na ten system)
- definicję celów biznesowych dla systemu - może to mieć następstwa dla polityki bezpieczeństwa dla tego systemu, wybraną metodę analizy ryzyka oraz wybór i priorytety wdrażania zabezpieczeń
- identyfikację celów bezpieczeństwa systemu
- ogólny stopień uzależnienia od systemu informatycznego określony na podstawie tego, jak bardzo działalność instytucji byłaby narażona w wyniku utraty lub poważnego incydentu związanego z bezpieczeństwem tego systemu, zadań, które ma on wypełniać, oraz przetwarzanych informacji
- poziom nakładów na informatykę na podstawie kosztu opracowania, utrzymania i wymiany systemu informatycznego, wraz z kosztami kapitału, eksploatacji i wykorzystywanych pomieszczeń
- metodę analizy ryzyka wybraną dla tego systemu
- aktywa systemu informatycznego, które instytucja zamierza chronić
- wycenę tych aktywów, wyrażoną w kategoriach konsekwencji, w przypadku gdyby aktywa te zostały poważnie naruszone (wartość informacji powinna zostać opisana jako potencjalne negatywne skutki dla działalności biznesowej wynikające z jej ujawnienia, modyfikacji, braku dostępności i zniszczenia)
- zagrożenia dla systemu informatycznego i przetwarzanych informacji, w tym związek między aktywami i zagrożeniami oraz prawdopodobieństwo wystąpienia tych zagrożeń,
- podatność systemu, w tym opis właściwych mu słabości, które mogą być wykorzystane przez zagrożenia
- ryzyko dla bezpieczeństwa tego systemu, wynikające z potencjalnego negatywnego wpływu na działalność instytucji, prawdopodobieństwo wystąpienia zagrożenia
- listę zabezpieczeń wybranych do ochrony tego systemu oraz przybliżone koszty zabezpieczeń informatycznych
Dla polityki bezpieczeństwa tworzy się plan bezpieczeństwa dla każdego systemu informatycznego, który opisuje sposób wdrożenia zabezpieczeń. Powinien określać koszty oraz harmonogram wdrażania, według priorytetów ustalonych na podstawie ryzyka dla danego systemu informatycznego, zgodnie z opisem sposobu wdrażania zabezpieczeń i metodą osiągnięcia odpowiedniego poziomu bezpieczeństwa. Powinien zawierać także zestaw procedur po wdrożeniu, umożliwiających utrzymanie założonego poziomu bezpieczeństwa.
Plan bezpieczeństwa powinien obejmować:
l cele bezpieczeństwa w kategoriach poufności, integralności, dostępności, rozliczalności, autentyczności i niezawodności
l wariant analizy ryzyka, wybrany dla tego systemu
l oszacowanie oczekiwanego i akceptowanego ryzyka szczątkowego po wdrożeniu przewidywanych zabezpieczeń
l listę zabezpieczeń wybranych do wdrożenia oraz listę zabezpieczeń istniejących i planowanych, w tym określenie ich efektywności i potrzeb ich uaktualnienia; lista ta powinna zawierać:
- priorytety dla wdrożenia wybranych zabezpieczeń i uaktualnienia zabezpieczeń istniejących
- opis, jak zabezpieczenia te powinny działać w praktyce
- przybliżone koszty instalacji i eksploatacji zabezpieczeń
- przybliżone oszacowanie zasobów ludzkich koniecznych do wdrożenia zabezpieczeń i prowadzenia czynności po wdrożeniu
l szczegółowy plan wdrażania zabezpieczeń zawierający:
- priorytety
- harmonogram wdrażania uwzględniający priorytety
- niezbędny budżet
- zakresy odpowiedzialności
- procedury uświadamiania bezpieczeństwa i szkoleń dla personelu informatycznego i użytkowników końcowych, niezbędne dla zapewnienia efektywności zabezpieczeń
- harmonogram procesów uzyskiwania aprobaty, jeśli zachodzi taka potrzeba
- harmonogram procedur po wdrożeniu
l środki kontroli procesu prawidłowego wdrażania zabezpieczeń, takie jak:
- zdefiniowanie procedur relacjonowania postępów
- procedury identyfikujące możliwe trudności
l procedury zatwierdzania każdego z wymienionych wyżej punktów, w tym procedury związane z możliwymi modyfikacjami części lub całości samego planu, jeśli zachodzi taka potrzeba
Niezależnie od wielkości podmiotu należy przewidzieć możliwość wystąpienia sytuacji awaryjnej (awaria sprzętu, oprogramowania lub zdarzenia losowe) oraz opracować politykę utrzymania ciągłości działania systemów lub plan ciągłości działania (ang. Business Continuity Plan). Plan ciągłości działania powinien być zaakceptowany przez najwyższe kierownictwo, powinien być zgodny z planami biznesowymi, aktualny, testowany i rozpowszechniony w firmie.
Sytuacje awaryjne stanowią istotne zagrożenie dla SIR. Mogą przynieść także katastrofalne skutki dla podmiotu gospodarczego. Aby zmniejszyć to zagrożenie oraz uniknąć skutków takich zdarzeń, jednostka powinna opracować, przetestować, a w razie konieczności zrealizować następujące plany postępowania w sytuacjach awaryjnych:
l plan postępowania pracowników w przypadkach awarii, wypadkach losowych i stanach zagrożenia,
l plan określający tryb przetwarzania danych w trybie awaryjnym w stanie zagrożenia lub po wypadku losowym - plan obejmujący procedury przetwarzania alternatywnego, stosowanego przejściowo do usunięcia przyczyn lub skutków, po wypadku losowym lub w stanie zagrożenia,
l plan działań niezbędnych po awarii dla powrotu do stanu normalnego przetwarzania - plan powinien zawierać m.in. procedury odtworzenia zbiorów danych lub programów z kopii rezerwowych.
dr Elżbieta Izabela Szczepankiewicz
audytor wewnętrzny, wykładowca WSHiR w Poznaniu