IT w audycie finansowym: dowody KSB 315

Systemy IT jako źródło danych finansowych

KSB 315 (Zmieniony w 2022 r.) dotyczy identyfikacji i oszacowania ryzyk istotnego zniekształcenia sprawozdania finansowego. Zgodnie z publikacją PIBR ma zastosowanie do okresów rozpoczynających się 1 stycznia 2023 r. lub później, z możliwością wcześniejszego stosowania. Ocena systemów i kontroli IT dostarcza materiałów do badania; nie zastępuje osądu biegłego ani opinii z badania.

Jak IT pomaga biegłemu rewidentowi szybciej ocenić ryzyko

Dobrze przygotowane IT nie zastępuje pracy audytora, ale skraca drogę do sprawdzalnych dowodów. Najważniejsze jest powiązanie systemów finansowych, właścicieli danych, przeglądów dostępu, logów zmian i testów backupu z konkretnymi procesami sprawozdawczymi. Dzięki temu audyt finansowy opiera się na faktach, a nie na ręcznym szukaniu informacji w wielu zespołach.

Dlaczego IT jest częścią audytu finansowego

KSB 315 to polski standard badania dotyczący identyfikacji i oszacowania ryzyk istotnego zniekształcenia. Biegły rewident określa znaczenie aplikacji, ryzyk wynikających z IT i powiązanych kontroli dla konkretnego badania. Nie jest to wymóg jednakowego audytu wszystkich narzędzi informatycznych.

• Sprawdzane są źródła danych, przepływy między systemami, uprawnienia i ręczne obejścia procesu.
• Znaczenie mają kontrole zmian, kopie zapasowe, logi administracyjne, separacja ról i historia uzgodnień.
• Słabe kontrole IT mogą wymagać innych lub dodatkowych procedur; brak wystarczających dowodów może wpłynąć na opinię z badania. Ocenia to biegły rewident.

Nowe wyzwania audytu finansowego

Nowe wyzwania audytu finansowego wynikają z automatyzacji, pracy w chmurze, integracji e-commerce, rozproszonych arkuszy, dostępu zdalnego i zewnętrznych dostawców IT. Jednocześnie dobrze uporządkowane systemy dają audytorowi lepsze dowody: historię zmian, ślady akceptacji, logi, raporty backupu i spójne źródła danych.

Co najczęściej interesuje biegłego rewidenta

Audytor nie potrzebuje katalogu wszystkich narzędzi. Potrzebuje jasnej odpowiedzi, skąd pochodzą dane finansowe, kto może je zmienić, jak działa kontrola i czy istnieją dowody jej wykonania.

Pakiet dowodów dla audytu finansowego

Pakiet dowodów powinien wskazywać okres, źródło, zakres i właściciela każdej kontroli oraz stwierdzone braki. Ułatwia ocenę materiału; nie gwarantuje skrócenia badania ani określonej opinii.

• Mapa systemów źródłowych: księgowość, ERP, sprzedaż, magazyn, kadry, bankowość, e-commerce i integracje.
• Macierz ról i uprawnień z właścicielem biznesowym, datą przeglądu oraz listą kont uprzywilejowanych.
• Rejestr zmian w konfiguracji istotnych aplikacji wraz z akceptacją właściciela procesu.
• Dowody backupu i odtworzenia danych istotnych dla sprawozdawczości, w tym RTO, RPO i wynik testu.
• Opis ręcznych obejść: eksporty do arkuszy, importy, korekty, uzgodnienia i kontrola wersji.
• Plan dostosowania do wymagań dla luk, których nie da się zamknąć przed rozpoczęciem badania.

Decyzje, których nie warto odkładać do końca badania

Najtrudniejsze pytania audytowe pojawiają się wtedy, gdy nie wiadomo, kto odpowiada za dane, uprawnienia albo zmianę w systemie. Warto rozstrzygnąć je przed przekazaniem paczki dowodów.

• Właściciel danych: kto potwierdza, że system jest źródłem danych dla konkretnego procesu finansowego.
• Właściciel dostępu: kto akceptuje role, konta uprzywilejowane, wyjątki i separację obowiązków.
• Właściciel zmiany: kto zatwierdza konfigurację, integrację, poprawkę lub ręczne obejście procesu.
• Właściciel backupu: kto potwierdza, że odtworzenie obejmuje dane potrzebne do sprawozdawczości.
• Właściciel planu: kto zamyka rekomendacje po audycie i raportuje postęp do zarządu.

Kiedy warto włączyć zewnętrznego partnera IT

Partner IT pomaga uzgodnić pojęcia, zakres techniczny i źródła dowodów z finansami oraz audytorem. Właściciele procesów nadal potwierdzają dane i decyzje; wsparcie nie usuwa ich udziału w badaniu.

Jak zaczynamy

Zaczynamy od krótkiego ustalenia zakresu: jakie systemy generują dane finansowe, kto jest właścicielem procesu, jakie pytania zadał audytor i jakie dowody już istnieją. Następnie przygotowujemy listę braków, priorytety, właścicieli oraz plan zebrania lub poprawy materiałów.

Mapa ryzyk IT pod KSB 315

Krótka mapa ryzyk powinna łączyć każdy proces finansowy z aplikacją, właścicielem, kontrolą i dowodem jej działania. Dzięki temu rozmowa z audytorem jest oparta na weryfikowalnym materiale, a nie na samych deklaracjach.

• Brak separacji ról w księgowości, sprzedaży lub magazynie.
• Zmiany konfiguracji bez akceptacji właściciela procesu.
• Eksporty do arkuszy bez kontroli wersji i właściciela danych.
• Konta byłych pracowników lub współdzielone konta administracyjne.
• Backup bez testu odtworzenia danych krytycznych dla sprawozdawczości.

Jak przygotować środowisko przed audytem

Zabezpiecz istniejące dowody za badany okres. Opisz braki, daty wdrożenia nowych kontroli i działania naprawcze. Nowej dokumentacji nie przedstawiaj jako dowodu historycznego działania kontroli. Pilne ryzyka zabezpiecz od razu.

• Zidentyfikuj aplikacje i bazy, z których powstają istotne dane finansowe.
• Przygotuj listę administratorów, właścicieli biznesowych i kont uprzywilejowanych.
• Wyeksportuj przeglądy dostępów, logi zmian, harmonogramy kopii i wyniki testów odtworzenia.
• Opisz ręczne korekty, integracje i miejsca, w których dane są przenoszone między systemami.
• Ustal właściciela każdego ryzyka oraz termin zamknięcia rekomendacji.

Gdzie pomagają ISO 27001 i TrustGuard

Dokumentacja systemu zarządzania bezpieczeństwem informacji i programu TrustGuard może dostarczyć materiału pomocniczego, jeśli jej zakres i okres odpowiadają badaniu. Certyfikat nie zastępuje dowodów działania konkretnych kontroli ani osądu biegłego rewidenta.

Jak wygląda wsparcie Virtline

Wchodzimy w rolę technicznego partnera dla audytora, zarządu i działu finansowego. Tłumaczymy ryzyka IT na język kontroli, kompletujemy dowody i wskazujemy działania, które realnie zmniejszają ryzyko błędu w danych. Opieramy się na doświadczeniu z audytów, utrzymania środowisk IT i własnym systemie zarządzania bezpieczeństwem informacji PN-EN ISO/IEC 27001:2023-08 certyfikowanym przez TÜV NORD. Łączymy wiedzę o utrzymaniu systemów, cyberbezpieczeństwie, backupie, ISO 27001, KSB 315 i praktycznych dowodach, dzięki czemu zespół finansowy nie musi samodzielnie tłumaczyć technicznych ustawień na język kontroli.

• Zakres własnej certyfikacji Virtline można zweryfikować w dokumencie źródłowym wraz z numerem i datą ważności.
• Ocena techniczna rozdziela braki krytyczne dla danych finansowych od działań, które można bezpiecznie zaplanować i zamknąć w ustalonych terminach.
• Doświadczenie audytowe i praktyka testów penetracyjnych dają praktyczne spojrzenie na systemy, dostęp, backup i ryzyka techniczne.
• Program TrustGuard wspiera rozmowę o zaufaniu i uporządkowaniu kontroli w organizacjach obsługujących wymagających klientów.
• Po audycie możemy utrzymywać kontrole w modelu outsourcingu IT, zamiast zostawiać klienta z jednorazową listą zaleceń.

Co klient dostaje po pracy

Przekazujemy mapę systemów, ryzyk, kontroli i braków dowodowych z właścicielami działań. Pilne luki w dostępie, kopiach i reagowaniu wymagają szybkiej reakcji. Przeglądy po 30/60/90 dniach śledzą postęp; nie odraczają podstawowej ochrony.

• Spis systemów istotnych dla danych finansowych wraz z właścicielami i zależnościami.
• Tabela ryzyk dotyczących ogólnych kontroli IT (ITGC) oraz kontroli aplikacyjnych powiązanych z procesami księgowymi.
• Lista brakujących lub słabych dowodów: logi, akceptacje, testy backupu, zmiany, przeglądy dostępów.
• Rekomendacje priorytetowe z rozróżnieniem na szybkie działania, zmiany procesowe i prace projektowe.
• Materiały dla biegłego rewidenta: odpowiedzi techniczne, zakres dowodów i właściciele decyzji.

Kiedy warto zacząć

Najlepiej przed rozpoczęciem właściwego badania albo przed wdrożeniem nowego ERP, księgowości, hurtowni danych lub integracji e-commerce. Wtedy można zaprojektować kontrolę zanim audyt wykaże brak dowodów.

• Firma zmienia system finansowo-księgowy albo integruje kilka źródeł danych.
• Audytor pyta o ITGC, kontrole aplikacyjne, logi lub uprawnienia.
• Dane finansowe są przygotowywane w wielu arkuszach poza systemem źródłowym.
• Brakuje testów backupu lub historii przeglądów dostępów.
• Klienci pytają o ISO 27001, TrustGuard lub dojrzałość bezpieczeństwa.

Powiązane usługi

Jeżeli audyt finansowy ujawni luki techniczne, warto potraktować je jako plan poprawy bezpieczeństwa i wiarygodności danych, a nie jednorazową odpowiedź do audytora.

Kontakt

Ustalmy zakres technicznego wsparcia badania i dostępne dowody.

Źródła i dalsza lektura