Jak dokumentować kontrole IT, aby były audytowalne?

Dobra kontrola wewnętrzna to nie wszystko. Dlaczego audyt wymaga dowodów?

W praktyce biznesowej przeprowadzające samodzielnie audyty wewnętrzne przedsiębiorstwa często koncentrują się przede wszystkim na sprawnym wykonaniu kontroli i zapewnieniu ciągłości procesów, ograniczając dokumentowanie wykonanych czynności do minimum. Takie podejście może być efektywne krótkoterminowo, jednak w dłuższej perspektywie rodzi istotne ryzyka. Rotacja pracowników, zmiany zakresów odpowiedzialności czy brak możliwości odtworzenia sposobu wykonania kontroli mogą prowadzić do utraty wiedzy oraz stopniowego odejścia od przyjętych zasad. Odpowiednia dokumentacja procedur i efektów podjętych działań pełni zatem nie tylko funkcję dowodową na potrzeby audytu, lecz także wspiera ciągłość i powtarzalność procesu.

Z perspektywy audytorskiej samo stwierdzenie, że kontrola wewnętrzna jest przez organizację wykonywana, nie jest wystarczające. Aby należycie ją ocenić i potwierdzić jej skuteczność audytor, kierując się zawodowym sceptycyzmem, powinien bowiem dokładnie zrozumieć obowiązujące procedury i ustalić, czy zaprojektowane zasady oraz mechanizmy kontrolne są adekwatne do charakteru działalności jednostki i związanych z nią ryzyk.

Kolejnym etapem jest ocena tego, czy przyjęte zasady rzeczywiście funkcjonują w praktyce. W tym celu audytor wewnętrzny analizuje dowody wykonania kontroli i konfrontuje je z wymaganiami określonymi w procedurach. Dokumentacja powinna zatem umożliwiać ustalenie m.in.: 

• kto i kiedy wykonał kontrolę, 
• jaki był zakres kontroli, 
• jaki rezultat przyniosła kontrola,
• w jaki sposób ustosunkowano się do ewentualnych nieprawidłowości.

Dobrze zaprojektowana kontrola wewnętrzna powinna więc nie tylko ograniczać określone ryzyko, ale także pozostawiać spójny i możliwy do zweryfikowania ślad jej wykonania.

Co oznacza, że kontrola IT jest audytowalna?

Audytowalność kontroli oznacza możliwość odtworzenia jej przebiegu na podstawie dostępnej dokumentacji, bez konieczności opierania się wyłącznie na wyjaśnieniach osób odpowiedzialnych za proces. Oznacza to, że, aby można było mówić o audytowalności kontroli, osoba niezależna powinna być w stanie samodzielnie zrozumieć to, czego dokładnie ona dotyczyła oraz w jaki sposób została wykonana oraz jaki był jej rezultat.

Istotna jest przy tym spójność pomiędzy procedurą a rzeczywistym sposobem działania. Jeżeli organizacja określa, że dana kontrola wykonywana jest przez właściciela procesu co miesiąc, na podstawie konkretnego raportu, to pozostawiony po tym działaniu ślad powinien umożliwiać potwierdzenie właśnie takiego przebiegu kontroli.

Audytowalność nie powinna przy tym oznaczać tworzenia nadmiernej dokumentacji. Celem jest przede wszystkim pozostawienie adekwatnego i wiarygodnego śladu, który pozwala potwierdzić wykonanie kontroli i zweryfikować jej zgodność z przyjętymi wewnętrznie zasadami. Szczegółowość dokumentacji powinna być dostosowana do charakteru kontroli, związanego z nią ryzyka oraz stopnia jej automatyzacji.

Dokumentacja kontroli IT – co powinien zawierać dobry ślad audytowy?

Dobry ślad audytowy powinien pozwalać na odtworzenie przebiegu kontroli bez konieczności uzupełniania dokumentacji ustnymi wyjaśnieniami. Nie chodzi przy tym o liczbę zgromadzonych plików czy zrzutów ekranu, ale o ich jakość, kompletność i powiązanie z wykonywaną kontrolą.

Dokumentacja kontroli IT powinna umożliwiać ustalenie przede wszystkim:

• kto wykonał (i – jeśli wymaga tego procedura – kto zatwierdził kontrolę),
• kiedy kontrola została wykonana,
• jaki był zakres kontroli (w tym jaka populacja lub okres podlegały weryfikacji),
• na podstawie jakich danych przeprowadzono kontrolę,
• jakie czynności weryfikacyjne wykonano,
• jaki był wynik kontroli oraz czy zidentyfikowano wyjątki,
• jak postąpiono wobec stwierdzonych nieprawidłowości.

Istotna do oceny jakości kontroli IT jest również możliwość potwierdzenia kompletności i wiarygodności danych wykorzystanych do wykonania kontroli. Przykładowo, w przypadku wykonania przeglądu uprawnień i dostępów użytkowników dokumentacja obejmująca samą zaakceptowaną listę użytkowników może nie być wystarczająca, jeżeli nie można ustalić, z jakiego systemu pochodziła, kiedy została wygenerowana i czy obejmowała pełną populację użytkowników.

Warto więc pamiętać, że więcej dokumentacji nie zawsze oznacza lepszy ślad audytowy. Znacznie większą wartość ma kilka spójnych dowodów pozwalających zrozumieć cały przebieg kontroli niż rozbudowany zbiór plików bez jasnego wskazania, czego dotyczą i co potwierdzają.

Kto powinien odpowiadać za dokumentację kontroli IT?

Za wykonanie i udokumentowanie kontroli wewnętrznej powinien odpowiadać przede wszystkim właściciel kontroli lub wyznaczona osoba posiadająca odpowiednią wiedzę i kompetencje do jej przeprowadzenia. Nie zawsze musi to być pracownik działu IT. Przykładowo, przegląd uprawnień może wymagać oceny właściciela procesu biznesowego, ponieważ to on najlepiej potrafi określić, czy dany użytkownik rzeczywiście potrzebuje określonego dostępu.

W przypadku bardziej istotnych kontroli dobrą praktyką jest zastosowanie dodatkowego poziomu weryfikacji. Osobą zatwierdzającą może być przełożony właściciela kontroli lub inna osoba posiadająca odpowiednie doświadczenie i poziom odpowiedzialności. Taki podział pozwala ograniczyć ryzyko sytuacji, w której ta sama osoba wykonuje czynność, ocenia jej poprawność i ostatecznie ją zatwierdza. Podejście to wpisuje się w szerszą koncepcję środowiska kontroli, w którym działania kontrolne i monitorujące powinny funkcjonować jako element całego systemu kontroli wewnętrznej. 

Kluczowe jest, aby role te nie funkcjonowały wyłącznie zwyczajowo. Procedura kontroli wewnętrznej powinna jasno określać: 

• kto odpowiada za wykonanie kontroli, 
• kto dokumentuje kontrolę,
• kto dokonuje przeglądu lub zatwierdzenia kontroli (jeżeli taki etap jest przewidziany). 

Odpowiedzialność za poszczególne aspekty kontroli najlepiej przypisywać do stanowiska lub funkcji, a nie konkretnej osoby, dzięki czemu proces pozostanie aktualny również w przypadku zmian kadrowych.

Ważne jest również rozróżnienie właściciela kontroli od funkcji audytu. Rolą audytu jest niezależna ocena funkcjonowania kontroli, a nie jej regularne wykonywanie czy tworzenie dowodów w imieniu właściciela procesu.

Kontrole manualne i automatyczne: jak różni się ich dokumentowanie?

Sposób dokumentowania kontroli IT powinien być dostosowany do sposobu jej wykonywania. 

Kontrole manualne wymagają zazwyczaj wyraźnego udokumentowania: 

• czynności wykonanych przez pracownika,
• daty kontroli, 
• zakresu przeprowadzonej weryfikacji, 
• wyniku kontroli, 
• zatwierdzenia kontroli (jeśli jest wymagane). 

Spełniającym warunek audytowalności dowodem kontroli manualnej może być przykładowo uzupełniona lista kontrolna, odpowiednio opisana korespondencja, zaakceptowany raport czy zapis wykonanej weryfikacji w systemie.

W przypadku kontroli automatycznych sytuacja wygląda inaczej. Jeżeli określony mechanizm działa bez ingerencji pracownika, to istotne jest przede wszystkim potwierdzenie, że został prawidłowo skonfigurowany, działał w analizowanym okresie oraz nie został zmieniony bez odpowiedniej autoryzacji. Dowodem potwierdzającym wykonanie i jakość takiej kontroli wewnętrznej może być więc: 

• konfiguracja systemowa, 
• plik logów, 
• historia zmian, 
• raport potwierdzający działanie mechanizmu.

W praktyce często występują również kontrole hybrydowe. W ich ramach system automatycznie generuje raporty lub wskazuje wyjątki, których ocena wymaga jednak następnie działania człowieka. Dokumentacja takiego procesu powinna obejmować zarówno pliki pozwalające ocenić wiarygodność danych wygenerowanych przez system, jak i ślad wykonanej przez pracownika analizy, podjęte decyzje oraz sposób obsługi zidentyfikowanych wyjątków.

Kluczowe nie jest zatem stworzenie jak największej liczby dowodów, lecz takie ich dobranie, aby odpowiadały rzeczywistemu przebiegowi kontroli IT i pozwalały potwierdzić jej skuteczne działanie.

Najczęstsze błędy popełniane przy dokumentowaniu kontroli IT

Nawet regularnie wykonywana kontrola IT może okazać się trudna do zweryfikowania, jeśli pozostawiony ślad nie pozwala jednoznacznie odtworzyć jej przebiegu. Problemy często wynikają jednak nie z braku samej kontroli, lecz ze sposobu jej dokumentowania.

Do najczęściej spotykanych błędów należą:

• brak daty lub wskazania osoby wykonującej kontrolę – przez co nie można potwierdzić, kiedy i przez kogo procedura została przeprowadzona,
• brak informacji o zakresie kontroli – uniemożliwiający określenie np. które systemy, konta lub zmiany objęto weryfikacją,
• zrzuty ekranu bez odpowiedniego kontekstu – które nie pozwalają określić źródła danych, daty ich pozyskania czy celu wykonanej czynności,
• zatwierdzenia danych które nie dokumentują faktycznej ich weryfikacji –  przykładem takiego działania może być przesłana przez księgową wiadomość „OK” lub „approved”, bez wskazania, co zostało sprawdzone,
• brak udokumentowania wyjątków i sposobu ich rozwiązania – co jest kluczowe, jeśli kontrola wykazała nieprawidłowości,
• odtwarzanie dokumentacji dopiero na potrzeby audytu – uzupełniane danych kilka miesięcy po faktycznym wykonaniu kontroli może prowadzić do licznych błędów.

Szczególnie istotny jest ostatni punkt. Dokumentacja przygotowana na bieżąco jest co do zasady bardziej wiarygodna niż dowód odtwarzany po czasie, kiedy część informacji może być już niedostępna, a osoby odpowiedzialne za proces mogą nie pamiętać szczegółów wykonanej kontroli.

Nie tylko wykonanie kontroli – jak dokumentować wyjątki i działania naprawcze?

Nawet dobrze zaprojektowana procedura nie jest w stanie przewidzieć każdej sytuacji biznesowej. Może pojawić się potrzeba pilnego utworzenia konta użytkownika, nadania dodatkowych uprawnień czy wdrożenia zmiany poza standardową ścieżką akceptacji. Samo wystąpienie takiego wyjątku nie musi oznaczać słabości środowiska kontroli – jednak pod warunkiem, że organizacja posiada jasne zasady postępowania w takich sytuacjach.

Jeżeli standardowy proces zostaje pominięty, to szczególnego znaczenia nabiera pozostawienie odpowiedniego śladu. Dokumentacja powinna wskazywać: 

• przyczynę zastosowania wyjątku, 
• osobę podejmującą decyzję o utworzeniu wyjątku, 
• zakres odstępstwa w ramach procedury, 
• akceptację odstępstwa. 

Przykładowo, jeśli w środowisku IT zostało pilnie utworzone na podstawie rozmowy telefonicznej nowe konto, to dotyczące tego faktu ustalenia powinny zostać później formalnie potwierdzone, najlepiej wraz z uzasadnieniem zastosowania trybu wyjątkowego.

Warto również określić w procedurach to, kto może zatwierdzić odstępstwo od standardowego procesu i czy wymaga ono późniejszej kontroli lub uzupełnienia brakujących kroków. Dzięki temu wyjątek pozostaje świadomą i kontrolowaną decyzją biznesową, a nie nieudokumentowanym obejściem obowiązujących zasad.

Jak określić czy procedury kontroli IT są gotowe na audyt?

Dobrze udokumentowane kontrole IT przede wszystkim nie powinny wymagać odtwarzania dowodów dopiero w momencie rozpoczęcia audytu lub oceny zewnętrznej audytu wewnętrznego. Jeżeli odpowiedzialności są jasno określone, dokumentacja powstaje wraz z wykonaniem kontroli, a sytuacje wyjątkowe są odpowiednio rejestrowane, organizacja może sprawnie wykazać, jak kontrola funkcjonowała i czy była realizowana zgodnie z przyjętymi zasadami.

W praktyce ocena własnego środowiska kontroli nie zawsze jest jednak prosta. Proces, który funkcjonuje w organizacji od lat, może zawierać luki niewidoczne z perspektywy jego właściciela. Niezależny przegląd kontroli IT pozwala tymczasem spojrzeć na funkcjonujące rozwiązania z perspektywy audytora, skutecznie zidentyfikować obszary wymagające poprawy oraz ocenić jakość pozostawianego śladu audytowego jeszcze przed właściwym audytem.

Wsparcie doradcze z zakresu audytu wewnętrznego może obejmować zarówno przegląd istniejących kontroli i procedur, jak i ocenę ich projektu oraz sposobu dokumentowania, a także pomoc w zaprojektowaniu lub usprawnieniu mechanizmów kontrolnych. Celem takiego działania nie powinien być przy tym rozrost biurokracji, lecz wypracowanie rozwiązań, które są proporcjonalne do ryzyka i możliwe do stosowania w codziennej działalności.

Dobrze przygotowane środowisko kontroli IT to nie tylko sprawniejszy audyt, to przede wszystkim większa przejrzystość procesów, jasno określona odpowiedzialność i mniejsze ryzyko, że wiedza o funkcjonowaniu kluczowych kontroli pozostanie wyłącznie w głowach pracowników. W razie potrzeby wdrożenia w jego ramach niezbędnych zmian w organizacji zachęcamy więc do kontaktu – nasz zespół audytorski chętnie odpowie na wszelkie pytania i zaproponuje odpowiednie, dostosowane do indywidualnych potrzeb jednostki rozwiązania.