Audytor prosi o jedną fakturę albo umowę i zadaje proste pytanie: kiedy dokument wpłynął, skąd się wziął, kto go widział, kto zmieniał dane, kto zatwierdził i co dokładnie zostało zarchiwizowane? W dobrze przygotowanym DMS odpowiedź powinna zająć kilkanaście minut. W źle skonfigurowanym systemie po godzinie nadal mamy trzy ekrany, dwa pliki CSV i brak pewności, czy pokazują tę samą historię.
Przyjmijmy więc konkretny cel: 15 minut na odtworzenie ścieżki jednego wcześniej wybranego dokumentu. Nie jest to wymóg prawny ani gwarantowany czas odpowiedzi systemu. To test operacyjny: czy organizacja potrafi szybko przedstawić spójny materiał dowodowy bez ręcznego rekonstruowania zdarzeń z poczty, Excela i pamięci pracowników.
Dla CFO, compliance i działu jakości najważniejsze nie jest samo posiadanie DMS. Liczy się to, czy system pozwala połączyć w jedną historię wpływ dokumentu, identyfikację oryginału, wersje, zmiany metadanych, dostęp użytkowników, decyzje workflow, delegacje, komentarze oraz archiwizację. I czy wiadomo, czego ta historia nie pokazuje.
Zacznij od tożsamości dokumentu, a nie od ekranu „Historia”
Najczęstszy błąd podczas próbnego audytu zaczyna się przed pierwszym logiem. Osoba prezentująca dokument wyszukuje po numerze faktury, nazwie kontrahenta albo numerze umowy i od razu przechodzi do historii. Tymczasem pierwsze pytanie powinno brzmieć: czy mamy pewność, że patrzymy na właściwy obiekt i właściwy plik?
Dla przykładowej faktury 48/09/2026 o wartości 184 500 zł netto dobry punkt startowy powinien zawierać przynajmniej:
- wewnętrzny Document ID lub inny trwały identyfikator obiektu,
- datę i godzinę wpływu,
- kanał wpływu, np. skrzynka AP, integracja z ERP, import API, skan albo ręczny upload,
- nazwę lub identyfikator źródła,
- nazwę oryginalnego pliku,
- informację o formacie,
- identyfikator procesu lub instancji workflow,
- jeśli system lub procedura to zapewnia — sumę kontrolną pliku, np. SHA-256,
- informację, czy po wpływie przechowywany jest pierwotny plik, czy tylko jego późniejsza reprezentacja.
To rozróżnienie ma znaczenie. Jeśli wiadomość z fakturą wpłynęła 14 września o 08:17, a operator o 08:24 poprawił pole „NIP dostawcy”, nie oznacza to jeszcze zmiany samego PDF. Metadane dokumentu i zawartość pliku są dwiema różnymi warstwami historii. Audyt powinien pokazać obie.
W praktyce przydatny jest hash oryginału. Nie trzeba jednak robić z niego magicznego dowodu wszystkiego. Suma kontrolna pozwala sprawdzić, czy dwa pliki mają identyczną zawartość binarną. Nie wyjaśnia natomiast, kto zatwierdził fakturę ani dlaczego zmieniono termin płatności.
Przykładowo dokumentacja DocuWare opisuje kontrolę integralności plików za pomocą hashy SHA-256, a w nowszych wersjach również SHA-512. Ten przykład dobrze pokazuje mechanizm, ale nie należy zakładać, że każdy DMS przechowuje lub udostępnia hash w taki sam sposób. Trzeba sprawdzić konkretną konfigurację i wersję produktu.
Pierwsze 2 minuty próbnego audytu warto więc przeznaczyć wyłącznie na identyfikację próbki:
- odszukać dokument,
- zapisać jego trwały ID,
- wskazać źródło wpływu,
- pokazać datę wpływu,
- ustalić, która wersja lub plik jest oryginałem.
Jeżeli już tutaj nie można jednoznacznie połączyć pliku z obiektem DMS, dalsze piękne raporty niewiele pomogą.
Kiedy hash ma szczególny sens? Gdy trzeba wykazać, że archiwizowany plik jest tym samym plikiem, który wszedł do procesu, albo gdy dokument jest eksportowany poza DMS. Ma również znaczenie przy przekazywaniu paczek dowodowych między zespołami.
Kiedy sam hash nie wystarczy? Przy audycie procesu akceptacji. Identyczna suma kontrolna dokumentu nie mówi, czy zatwierdzenia dokonała właściwa osoba, czy działała delegacja ani jakie metadane obowiązywały w chwili decyzji.
Jest jeszcze jedno ograniczenie. Nie każdy system zachowuje pierwotny plik w niezmienionej formie. Import może obejmować konwersję, OCR, łączenie załączników albo utworzenie reprezentacji PDF. W takim przypadku trzeba wskazać, czego dokładnie dotyczy suma kontrolna: pliku źródłowego, pliku po konwersji czy aktualnej wersji przechowywanej w repozytorium.
Oś zdarzeń musi pokazywać kto, co i kiedy — również gdy działał system
Kiedy tożsamość dokumentu jest ustalona, zaczyna się właściwy ślad audytowy. Dla przykładowej faktury oś może wyglądać tak:
- 08:17:03 — wiadomość odebrana przez skrzynkę fakturową,
- 08:17:11 — dokument zapisany w repozytorium,
- 08:17:13 — automatycznie odczytano numer faktury i kontrahenta,
- 08:24:42 — Anna Kowalska zmieniła pole „NIP dostawcy” z wartości A na B,
- 08:31:09 — Jan Nowak wyświetlił dokument,
- 09:05:22 — kierownik działu zaakceptował koszt,
- 09:05:23 — workflow przekazał zadanie do CFO,
- 10:14:08 — zadanie przekazano zastępcy na podstawie aktywnej delegacji,
- 10:21:55 — zastępca zatwierdził płatność,
- 10:22:02 — status dokumentu zmieniono na „zatwierdzony”,
- 10:23:17 — dokument przekazano do dalszego procesu lub archiwizacji.
Taka lista jest przydatna tylko wtedy, gdy można odpowiedzieć na cztery pytania: jaka była czynność, kto ją wykonał, którego obiektu dotyczyła i według jakiego czasu ją zapisano.
To ostatnie jest często bagatelizowane. Jeżeli DMS, system tożsamości, serwer integracyjny i ERP mają różne zegary, kolejność zdarzeń może być pozornie nielogiczna. W środowiskach objętych DORA wymagania dotyczące logowania obejmują m.in. synchronizację zegarów systemów ICT z udokumentowanym, wiarygodnym źródłem czasu. To dobra praktyka również poza sektorem finansowym.
W materiale audytowym sensowne jest przechowywanie technicznego czasu w sposób jednoznaczny, np. UTC, a przy prezentacji pokazanie również lokalnej strefy i offsetu. Dla Polski ma to praktyczne znaczenie przy zmianie czasu letniego i zimowego. Zapis „02:18” bez strefy bywa dwuznaczny; zapis zawierający UTC albo jednoznaczny offset już nie.
Drugi problem to tożsamość wykonawcy. Samo pole „User: workflow_service” nie odpowiada na pytanie, kto podjął decyzję. Trzeba odróżnić:
- użytkownika biznesowego,
- konto administratora,
- konto techniczne,
- integrację API,
- automat workflow,
- działanie wykonane w ramach delegacji.
Jeżeli CFO był nieobecny, a jego zastępca zatwierdził fakturę, audyt powinien pokazać nie tylko nazwisko zastępcy. Potrzebne są również: podstawa uprawnienia, okres obowiązywania delegacji i rola, w której wykonano akcję. Inaczej po pół roku zostaje jedynie wpis „zaakceptował Piotr Wiśniewski”, bez odpowiedzi, dlaczego miał do tego prawo.
Tu pojawia się też często nadużywany zapis „document viewed”. Wyświetlenie dokumentu albo jego pobranie oznacza zdarzenie techniczne. Nie dowodzi faktycznego przeczytania treści. Użytkownik mógł otworzyć podgląd na dwie sekundy, aplikacja mogła pobrać dokument automatycznie albo plik mógł zostać zapisany lokalnie bez dalszego otwierania.
Dlatego w raporcie nie należy pisać „Jan Nowak przeczytał umowę”, jeśli system rejestruje wyłącznie otwarcie. Prawidłowe stwierdzenie brzmi: „konto Jana Nowaka wyświetliło dokument o 11:42”.
Na odtworzenie takiej osi warto przeznaczyć około 5 minut. Najpierw filtr po trwałym ID dokumentu lub instancji procesu, dopiero później zawężanie po osobie czy dacie. Filtrowanie wyłącznie po nazwie pliku jest ryzykowne — nazwa może się powtórzyć.
Dobrze skonfigurowany DMS może rejestrować zmianę indeksu wraz ze starą i nową wartością, wyświetlenie, wydruk czy adnotację. DocuWare jest przykładem systemu, którego raport audytowy dokumentu obejmuje takie zdarzenia. Jednocześnie dokumentacja pokazuje ważne ograniczenie: część zdarzeń, np. logowanie użytkowników, może zależeć od konfiguracji. To dokładnie ten typ szczegółu, który trzeba sprawdzić przed audytem, a nie w jego trakcie.
W organizacjach publicznych dodatkowym punktem odniesienia są Krajowe Ramy Interoperacyjności. Obowiązujące rozporządzenie wymaga m.in. uwzględnienia integralności, autentyczności, rozliczalności i niezaprzeczalności informacji oraz odpowiedniego zarządzania uprawnieniami. Nie należy jednak przedstawiać KRI jako ogólnego obowiązku dla każdej prywatnej spółki — zakres regulacji dotyczy podmiotów realizujących zadania publiczne.
Wersje i eksport decydują, czy ślad audytowy da się obronić poza DMS
Najtrudniejszy moment pojawia się wtedy, gdy audytor pyta: „Co dokładnie zatwierdzono?”.
Aktualna wersja pliku nie zawsze daje odpowiedź.
Załóżmy, że projekt umowy trafił do DMS jako wersja 1.0. Dział prawny poprawił klauzulę odpowiedzialności i zapisał 1.1. Procurement zmienił załącznik cenowy, tworząc 1.2. CFO zaakceptował dokument o 14:20. Następnego dnia ktoś dopisał techniczną korektę do metadanych.
Audyt powinien umożliwić odpowiedź:
Która wersja dokumentu była związana z decyzją CFO o 14:20?
Historia wersji w SharePoint pozwala przykładowo ustalić, kiedy plik zmieniono i kto dokonał zmiany, a także obejrzeć lub przywrócić starszą wersję. To jednak nadal nie oznacza automatycznie, że każda organizacja ma kompletny ślad procesu akceptacji. Historia wersji i historia workflow odpowiadają na różne pytania.
Przy kontroli wersji trzeba sprawdzić trzy rzeczy:
- czy DMS zachowuje poprzednie wersje zawartości dokumentu,
- czy pokazuje autora i czas utworzenia wersji,
- czy decyzja workflow jest jednoznacznie powiązana z konkretną wersją.
Na ten etap w ćwiczeniu można przeznaczyć 3 minuty.
Jeśli system zapisuje tylko aktualny dokument i informację „zmieniono 15 września”, bez poprzedniej treści, nie wolno tworzyć rekonstrukcji i przedstawiać jej jako faktu. Uczciwy zapis brzmi: „system potwierdza zmianę w tym czasie, ale nie zachował pełnej treści poprzedniej wersji”. Brak danych jest słabością procesu, lecz nadal jest lepszy niż dowód stworzony po fakcie.
Podobnie z komentarzami. Komentarz „OK, można płacić” ma inną wagę, gdy jest elementem kontrolowanej decyzji workflow, a inną, gdy został wpisany jako luźna adnotacja przez użytkownika bez właściwego uprawnienia. Audyt powinien pokazać kontekst decyzji, rolę osoby i obowiązujące w danym momencie uprawnienia.
Następnie przychodzi eksport. Tu wiele organizacji kończy demonstrację zrzutem ekranu. To za mało.
Dobra paczka audytowa dla pojedynczego dokumentu powinna zawierać, zależnie od możliwości systemu:
- oryginalny dokument albo kontrolowaną kopię,
- identyfikator dokumentu,
- dostępne wersje,
- oś zdarzeń,
- historię zmian metadanych,
- historię akceptacji i delegacji,
- komentarze należące do procesu,
- informację o archiwizacji,
- raport uprawnień lub role istotne dla decyzji,
- eksport logów w formacie czytelnym dla człowieka,
- dane w formacie maszynowym, np. CSV lub JSON,
- opis zakresu eksportu: daty, filtry, identyfikatory i system źródłowy.
Przy większej wadze materiału warto dodać manifest paczki z listą plików i ich hashami. Pozwala to później wykazać, że zestaw przekazany audytorowi nie został przypadkowo podmieniony między eksportem a analizą.
Osobnym testem powinna być integralność samych logów. Jeśli ten sam administrator może zmienić dokument, usunąć lub edytować jego historię i jeszcze zmienić politykę retencji, ślad audytowy ma słabszą wartość dowodową. Dostęp do modyfikacji i kasowania logów powinien być ograniczony, a zmiany konfiguracji audytu, retencji i uprawnień administracyjnych również rejestrowane. Przy procesach o podwyższonym ryzyku sens ma wysyłanie zdarzeń do niezależnego repozytorium lub SIEM, z osobnymi uprawnieniami i odpowiednio dobraną retencją. Chodzi o rozdzielenie kontroli tak, aby jedna osoba nie mogła jednocześnie zmienić dokumentu i wyczyścić jego historii. Trzeba też uważać na częsty skrót myślowy: hash wyeksportowanej paczki potwierdza jej integralność od momentu utworzenia, ale nie dowodzi, że zdarzenia zapisane w logach były prawdziwe i niezmienione przed eksportem.
Na przygotowanie takiego eksportu w próbnym ćwiczeniu przeznacz 3 minuty.
Nie należy przy tym dawać audytorowi stałego pełnego dostępu administracyjnego tylko po to, by mógł samodzielnie szukać dowodów. Lepsza jest zasada najmniejszych uprawnień: czasowy dostęp tylko do potrzebnego zakresu albo kontrolowany eksport wykonany przez uprawnioną osobę. Raport audytowy sam może zawierać dane osobowe pracowników, identyfikatory kont, adresy IP czy informacje o aktywności. Ślad audytowy również podlega zasadom ochrony danych.
RODO wymaga m.in. minimalizacji danych, integralności i poufności oraz rozliczalności administratora. To przemawia przeciwko podejściu „logujmy wszystko bez końca, bo kiedyś może się przydać”. Retencja logów powinna wynikać z celu, ryzyka, obowiązków prawnych i polityki organizacji.
Co ważne, retencja dokumentu i retencja logu to dwie różne rzeczy. Dokument może być przechowywany dziesięć lat, a jego dziennik audytowy znacznie krócej. W aktualnej dokumentacji Microsoft Purview Audit (Standard) podstawowy okres retencji rekordów audytowych wynosi 180 dni. W Audit Premium określone rekordy dla użytkowników z właściwymi licencjami są domyślnie przechowywane rok, a dłuższa retencja wymaga odpowiednich polityk i licencji. To konkretny przykład, dlaczego ustawienia produktu trzeba znać przed rozpoczęciem audytu.
Tak samo licencja może decydować o dostępności funkcji workflow, historii czy raportowania. Nie należy wpisywać do procedury „DMS przechowuje historię przez siedem lat”, dopóki nie zostanie to potwierdzone w konfiguracji tenantów, umowie, dokumentacji produktu i faktycznym teście eksportu.
Ostatnie 2 minuty ćwiczenia powinny być przeznaczone na test kompletności. Nie na poprawianie prezentacji.
Sprawdź sześć pytań:
- Czy znamy źródło i dokładny moment wpływu?
- Czy potrafimy jednoznacznie wskazać oryginał lub wyjaśnić proces jego przekształcenia?
- Czy wiadomo, kto zmienił metadane i jakie były wartości przed i po zmianie?
- Czy decyzje można przypisać do osób, ról, delegacji oraz konkretnej wersji dokumentu?
- Czy log pokazuje również działania kont technicznych i automatów tam, gdzie ma to znaczenie?
- Czy eksport da się później zweryfikować bez dostępu do produkcyjnego DMS?
To daje pełne 15 minut: 2 minuty na wybór i identyfikację dokumentu, 5 minut na oś zdarzeń, 3 minuty na wersje, 3 minuty na eksport i 2 minuty na kontrolę kompletności.
Jeśli ćwiczenie nie mieści się w tym czasie, nie trzeba od razu kupować nowego DMS. Najpierw ustal, gdzie tracone są minuty. Najczęściej problemem jest brak jednego identyfikatora łączącego dokument, workflow i logi, zbyt krótka retencja albo historia rozbita między kilka modułów.
FAQ
Czy sam log z DMS wystarczy podczas audytu?
Nie zawsze. Log może pokazywać dostęp i zmiany, ale osobno mogą istnieć historia wersji, historia workflow, uprawnienia, delegacje i logi systemu tożsamości. Materiał trzeba zestawić tak, aby wszystkie elementy dotyczyły tego samego dokumentu i procesu.
Czy zapis „użytkownik otworzył dokument” potwierdza, że go przeczytał?
Nie. Potwierdza zdarzenie techniczne zarejestrowane przez system. Nie dowodzi zapoznania się z całą treścią ani zrozumienia dokumentu.
Jak długo trzeba przechowywać logi DMS?
Nie istnieje jeden uniwersalny okres właściwy dla każdej organizacji i każdego dokumentu. Termin wynika z celu przetwarzania, przepisów sektorowych, wymogów dowodowych, ryzyka i przyjętej polityki. Trzeba dodatkowo sprawdzić techniczne oraz licencyjne limity konkretnego systemu, bo retencja dokumentów i retencja audytu mogą być różne.
Co zrobić, jeżeli dla starego dokumentu brakuje części historii?
Oznaczyć brak wprost i ustalić jego przyczynę: retencję, wyłączone logowanie, zmianę systemu, migrację albo ograniczenie produktu. Nie należy tworzyć brakujących zdarzeń na podstawie pamięci użytkowników i prezentować ich jako udowodnione logi.
Przygotowania zacznij więc nie od tworzenia prezentacji dla audytora, lecz od jednej prawdziwej faktury lub umowy. Uruchom stoper i spróbuj w 15 minut pokazać jej źródło, ID, oryginał, chronologię, wersje, zmiany metadanych, dostęp, decyzje, delegacje i eksport. Jeżeli czegoś nie da się wykazać, pierwszym zadaniem nie jest poprawienie raportu — jest nim usunięcie luki w rejestrowaniu lub retencji danych, zanim podobna luka pojawi się w próbce wybranej przez audytora.
