Audyt, historia zmian i rozliczalność w rejestrze umów

Wdrożenie CRU JSFP to nie tylko publikacja informacji o umowach. To również konieczność utrzymania kontroli nad tym, kto przygotował dane, kto je zmienił, kto je zatwierdził, kto opublikował informacje, kto dokonał aktualizacji i na jakiej podstawie.

Jeżeli lokalny rejestr umów nie pokazuje historii zmian, jednostka może mieć problem z wyjaśnieniem błędów, korekt, opóźnień, ograniczeń jawności albo różnic między danymi lokalnymi a informacjami opublikowanymi w CRU JSFP.

W praktyce rejestr umów bez audytu jest tylko tabelą. Może zawierać aktualny stan danych, ale nie odpowiada na najważniejsze pytania kontrolne:

kto zmienił dane, kiedy to zrobił, co dokładnie zmienił i dlaczego?

Najkrótsza odpowiedź

Lokalny rejestr umów powinien przechowywać nie tylko aktualne dane o umowie, ale również historię operacji.

Jednostka powinna móc wykazać co najmniej:

• kto utworzył wpis umowy,
• kiedy wpis został utworzony,
• kto zmienił dane,
• jaka była wartość pola przed zmianą i po zmianie,
• dlaczego dokonano zmiany,
• jaki dokument był podstawą zmiany,
• kto zatwierdził zmianę,
• czy zmiana została opublikowana w CRU JSFP,
• czy zastosowano ograniczenie jawności,
• kto zdecydował o ograniczeniu jawności,
• jaki był status publikacji albo aktualizacji,
• czy wystąpił błąd przy przekazaniu danych do CRU JSFP.

Bez takiego śladu jednostka może opublikować dane, ale będzie miała słabą kontrolę nad późniejszym wyjaśnianiem decyzji, błędów i zmian.

Dlaczego audyt jest częścią zgodności z CRU JSFP?

CRU JSFP wymaga udostępniania i aktualizowania informacji o umowach. To oznacza, że jednostka musi zarządzać nie tylko pierwszą publikacją, ale również całym cyklem życia informacji o umowie.

Umowa może zostać aneksowana, wypowiedziana, rozwiązana, skorygowana, może zmienić status albo wartość. Może też pojawić się konieczność ograniczenia jawności określonych informacji.

Każda taka sytuacja wymaga odpowiedzi na pytania:

• co się zmieniło,
• kiedy powstała przyczyna zmiany,
• kto ją zgłosił,
• kto ją zweryfikował,
• kto zatwierdził aktualizację,
• kto przekazał dane do CRU JSFP,
• czy aktualizacja została wykonana w terminie,
• czy można odtworzyć podstawę decyzji.

Dlatego audyt, historia zmian i rozliczalność nie są dodatkiem technicznym. Są elementem kontroli procesu.

Rozliczalność oznacza więcej niż login użytkownika

Samo zapisanie, że użytkownik był zalogowany do systemu, nie wystarczy.

Rozliczalność oznacza możliwość odtworzenia konkretnego działania użytkownika w kontekście konkretnej umowy i konkretnej decyzji.

Dobry rejestr powinien pokazywać:

• kto wykonał operację,
• kiedy ją wykonał,
• czego dotyczyła operacja,
• jaka była poprzednia wartość danych,
• jaka jest nowa wartość danych,
• czy zmiana była robocza, zatwierdzona czy opublikowana,
• jaka była przyczyna zmiany,
• jaki dokument był podstawą,
• czy operacja dotyczyła publikacji, aktualizacji, wycofania, korekty albo ograniczenia jawności.

Dopiero taki zestaw informacji pozwala mówić o realnym śladzie audytowym.

Role użytkowników a odpowiedzialność

Rozporządzenie przewiduje role użytkowników konta jednostki, w tym administratora, wprowadzającego informacje o umowie oraz publikującego informacje o umowie.

To rozróżnienie ma praktyczne znaczenie. Jednostka nie powinna przyznawać wszystkim użytkownikom pełnych uprawnień tylko dlatego, że jest to wygodne organizacyjnie.

W procesie powinny być rozdzielone co najmniej trzy poziomy działania.

1. Przygotowanie danych

Osoba wprowadzająca dane uzupełnia informacje o umowie, przygotowuje dane do publikacji, poprawia braki i obsługuje wersję roboczą.

2. Weryfikacja i zatwierdzenie

Osoba odpowiedzialna za weryfikację sprawdza poprawność danych, wartość umowy, podstawę kwalifikacji, status oraz ewentualne ograniczenia jawności.

3. Publikacja albo aktualizacja

Osoba publikująca udostępnia informacje w CRU JSFP albo dokonuje aktualizacji danych.

Taki podział zmniejsza ryzyko, że jedna osoba bez kontroli przygotuje, zatwierdzi i opublikuje błędne dane.

Co lokalny rejestr powinien zapisywać?

Lokalny rejestr umów powinien przechowywać historię operacji dotyczącą całego cyklu życia umowy.

Minimalny zakres historii powinien obejmować:

• utworzenie wpisu umowy,
• zmianę danych podstawowych,
• zmianę wartości umowy,
• zmianę okresu obowiązywania,
• zmianę statusu umowy,
• dodanie aneksu,
• wypowiedzenie umowy,
• rozwiązanie umowy,
• odstąpienie od umowy,
• cesję praw,
• korektę błędu,
• decyzję o ograniczeniu jawności,
• zatwierdzenie danych do publikacji,
• publikację w CRU JSFP,
• aktualizację danych w CRU JSFP,
• wycofanie danych,
• błąd publikacji albo integracji,
• ponowienie wysyłki,
• zmianę uprawnień użytkownika.

W każdej z tych operacji warto zapisywać użytkownika, datę, czas, zakres zmiany, przyczynę oraz powiązanie z dokumentem źródłowym.

Historia zmian danych: stan przed i po zmianie

Dobra historia zmian nie powinna ograniczać się do komunikatu:

„zmieniono dane umowy”.

To za mało.

System powinien pozwalać sprawdzić, które pole zostało zmienione i jak wyglądała jego poprzednia oraz nowa wartość.

Przykładowo:

• wartość umowy przed zmianą: 120 000,00 PLN,
• wartość umowy po zmianie: 145 000,00 PLN,
• przyczyna: aneks nr 1 zwiększający zakres usług,
• data przyczyny: 15 września 2026 r.,
• użytkownik zgłaszający zmianę,
• użytkownik zatwierdzający zmianę,
• data publikacji aktualizacji w CRU JSFP.

Taka historia pozwala szybko wyjaśnić, czy zmiana była wynikiem aneksu, korekty błędu, aktualizacji statusu, czy nieuprawnionej ingerencji w dane.

Powiązanie zmian z dokumentami źródłowymi

W rejestrze umów sama informacja o zmianie nie wystarcza. Ważne jest również powiązanie zmiany z dokumentem, z którego wynika.

Dokumentem źródłowym może być między innymi:

• umowa,
• aneks,
• wypowiedzenie,
• porozumienie rozwiązujące,
• odstąpienie od umowy,
• cesja praw,
• notatka służbowa,
• decyzja o ograniczeniu jawności,
• opinia prawna,
• informacja od komórki merytorycznej,
• dokument potwierdzający korektę błędu,
• komunikat o błędzie integracji,
• potwierdzenie publikacji w CRU JSFP.

Dzięki temu audyt nie kończy się na stwierdzeniu, że dane zostały zmienione. Można od razu ustalić, z czego zmiana wynikała.

Statusy pracy z danymi

Rozliczalność wymaga rozróżnienia etapów pracy z danymi. W przeciwnym razie trudno ustalić, czy dane były robocze, zatwierdzone, wysłane do CRU JSFP, opublikowane czy tylko przygotowane lokalnie.

Praktyczny model statusów może obejmować:

• wersja robocza,
• dane wymagają uzupełnienia,
• dane gotowe do weryfikacji,
• dane zweryfikowane,
• dane zatwierdzone do publikacji,
• oczekuje na publikację,
• opublikowano w CRU JSFP,
• wymaga aktualizacji,
• aktualizacja przygotowana,
• aktualizacja zatwierdzona,
• aktualizacja opublikowana,
• błąd publikacji,
• błąd integracji,
• wycofano informację,
• zamknięto sprawę.

Takie statusy pozwalają sprawdzić, na którym etapie powstał problem. Bez nich łatwo o spór, czy błąd powstał przy przygotowaniu danych, zatwierdzeniu, publikacji, aktualizacji czy integracji.

Aktualizacja musi mieć przyczynę

Przy aktualizacji informacji o umowie nie wystarczy zmienić wartości pola. Trzeba wiedzieć, dlaczego aktualizacja została dokonana.

Przyczyną aktualizacji może być między innymi:

• zmiana umowy,
• aneks,
• wypowiedzenie,
• cesja praw,
• korekta błędu,
• zmiana statusu umowy,
• rozwiązanie umowy,
• odstąpienie od umowy,
• zmiana podstawy ograniczenia jawności,
• uzupełnienie brakujących danych.

Dla każdej aktualizacji warto zapisać:

• przyczynę aktualizacji,
• zwięzły opis,
• datę, od której przyczyna zaistniała,
• dokument źródłowy,
• osobę zgłaszającą,
• osobę zatwierdzającą,
• datę przekazania aktualizacji do CRU JSFP.

To szczególnie ważne przy późniejszym wyjaśnianiu, dlaczego dane w rejestrze zmieniły się po pierwszej publikacji.

Ograniczenia jawności też muszą zostawiać ślad

Jeżeli jednostka ogranicza jawność określonej informacji, taka decyzja musi być możliwa do odtworzenia.

W lokalnym rejestrze warto zapisać:

• która informacja została wyłączona z jawności,
• jaka była podstawa prawna nieudostępnienia,
• jaki organ albo jakie stanowisko osoby dokonało wyłączenia,
• kiedy podjęto decyzję,
• kto przygotował ocenę,
• kto zatwierdził decyzję,
• czy decyzja była konsultowana z działem prawnym, IOD albo komórką bezpieczeństwa,
• czy ograniczenie dotyczyło całej informacji, czy tylko jej części.

Bez tego jednostka może mieć trudność z wykazaniem, że ograniczenie jawności było świadome, uzasadnione i zgodne z procedurą.

Ślad publikacji w CRU JSFP

Lokalny rejestr powinien rozróżniać samo przygotowanie danych od faktycznej publikacji w CRU JSFP.

Warto zapisywać:

• datę zatwierdzenia danych do publikacji,
• osobę zatwierdzającą,
• osobę publikującą,
• datę publikacji,
• zakres opublikowanych danych,
• identyfikator publikacji albo operacji, jeżeli jest dostępny,
• status publikacji,
• informację o ewentualnym błędzie,
• datę ponowienia publikacji,
• potwierdzenie skutecznej publikacji.

To pozwala uniknąć sytuacji, w której lokalnie wszyscy uznają, że dane zostały opublikowane, ale w rzeczywistości publikacja nie doszła do skutku albo zakończyła się błędem.

Ślad techniczny integracji przez API

Jeżeli jednostka korzysta z integracji przez API, historia techniczna jest równie ważna jak historia merytoryczna.

Lokalny system powinien zapisywać co najmniej:

• datę i godzinę wysłania danych,
• zakres wysłanych danych,
• identyfikator operacji,
• użytkownika albo proces techniczny uruchamiający wysyłkę,
• status odpowiedzi systemu centralnego,
• komunikat błędu,
• treść odpowiedzi technicznej,
• datę ponowienia wysyłki,
• informację, czy błąd był techniczny, walidacyjny czy merytoryczny,
• powiązanie z wersją danych wysłaną do CRU JSFP.

Bez takiego śladu trudno będzie ustalić, czy problem wynikał z jakości danych, błędu użytkownika, błędu integracji, niedostępności systemu centralnego czy zmiany dokumentacji API.

Uprawnienia użytkowników i okresowy przegląd dostępów

Rozliczalność wymaga nie tylko zapisywania operacji, ale również kontroli uprawnień.

Jednostka powinna wiedzieć:

• kto ma dostęp do rejestru umów,
• jakie role posiada,
• kto nadał uprawnienia,
• kiedy uprawnienia zostały nadane,
• kto zatwierdził dostęp,
• kiedy uprawnienia zostały odebrane,
• czy użytkownik nadal potrzebuje dostępu,
• czy były wykonywane okresowe przeglądy uprawnień.

Warto przyjąć zasadę minimalnych uprawnień. Użytkownik powinien mieć tylko taki zakres dostępu, jaki jest potrzebny do wykonywania jego zadań.

Szczególnej kontroli wymagają osoby z prawem publikacji, administratorzy oraz użytkownicy mogący zmieniać dane po zatwierdzeniu.

Rejestr powinien pamiętać więcej niż system centralny

CRU JSFP służy publicznemu udostępnianiu informacji o umowach. Lokalny rejestr powinien pełnić szerszą rolę.

To lokalnie jednostka powinna przechowywać informacje potrzebne do wyjaśnienia:

• skąd pochodzą dane,
• kto je przygotował,
• kto je sprawdził,
• kto je zatwierdził,
• dlaczego ograniczono jawność,
• dlaczego dokonano aktualizacji,
• jaki dokument był podstawą zmiany,
• czy zachowano termin 30 dni,
• czy wystąpił błąd publikacji,
• kto podjął decyzję w przypadku wątpliwości.

Dlatego lokalny rejestr umów nie powinien być tylko kopią pól z CRU JSFP. Powinien być systemem zarządzania procesem i dowodami działania jednostki.

Pięcioletni horyzont wyjaśniania historii

Informacje o umowie w CRU JSFP są utrzymywane przez określony czas po zakończeniu obowiązywania umowy. To oznacza, że jednostka powinna być przygotowana na długoterminowe wyjaśnianie historii publikacji, aktualizacji i decyzji dotyczących jawności.

W praktyce lokalny rejestr powinien pozwalać odtworzyć historię także po zakończeniu umowy, zmianie pracowników, reorganizacji komórki albo zmianie administratora.

To szczególnie ważne przy:

• kontrolach,
• audytach,
• wnioskach o informację publiczną,
• sporach z wykonawcami,
• analizach kierownictwa,
• wyjaśnianiu błędów publikacji,
• zmianach kadrowych.

Historia zmian nie powinna znikać tylko dlatego, że użytkownik odszedł z pracy albo odebrano mu uprawnienia.

Raporty audytowe

Dobry lokalny rejestr powinien umożliwiać generowanie raportów audytowych. Nie chodzi tylko o raport listy umów. Chodzi o raporty pokazujące przebieg procesu.

Przydatne raporty to między innymi:

• umowy bez pełnej historii zmian,
• umowy zmienione po zatwierdzeniu,
• umowy z korektą błędu,
• umowy oczekujące na aktualizację,
• umowy po terminie 30 dni,
• umowy z błędem publikacji,
• umowy z ograniczeniem jawności,
• umowy bez wskazanej podstawy ograniczenia jawności,
• umowy opublikowane przez danego użytkownika,
• zmiany wykonane przez danego użytkownika,
• zmiany wartości umowy,
• aktualizacje wynikające z aneksów,
• operacje wykonane przez API,
• nieudane wysyłki do CRU JSFP,
• zmiany uprawnień użytkowników.

Takie raporty pozwalają kierownictwu widzieć nie tylko stan rejestru, ale również jakość procesu.

Najczęstsze błędy

Najczęstsze błędy przy audycie i historii zmian w rejestrze umów to:

• brak historii zmian,
• zapisywanie tylko aktualnej wartości pola,
• brak informacji o stanie przed zmianą,
• brak przyczyny aktualizacji,
• brak powiązania z dokumentem źródłowym,
• brak rozróżnienia danych roboczych i zatwierdzonych,
• brak informacji, kto zatwierdził publikację,
• brak śladu faktycznej publikacji w CRU JSFP,
• brak śladu błędów integracji,
• zbyt szerokie uprawnienia użytkowników,
• brak okresowego przeglądu dostępów,
• brak historii decyzji o ograniczeniu jawności,
• brak raportów audytowych,
• nadpisywanie danych bez zachowania poprzedniej wersji,
• traktowanie Excela jako pełnoprawnego rejestru audytowego.

Większość tych błędów ujawnia się dopiero wtedy, gdy trzeba coś wyjaśnić. Wtedy jest już za późno na odtworzenie historii, której system wcześniej nie zapisał.

Checklista audytu i rozliczalności

Przed uruchomieniem procesu CRU JSFP warto sprawdzić, czy lokalny rejestr pozwala odpowiedzieć na poniższe pytania:

• Czy wiadomo, kto utworzył wpis umowy?
• Czy wiadomo, kto zmienił dane?
• Czy system pokazuje datę i godzinę zmiany?
• Czy można zobaczyć wartość pola przed zmianą i po zmianie?
• Czy każda aktualizacja ma przyczynę?
• Czy aktualizacja ma zwięzły opis?
• Czy wskazano datę zaistnienia przyczyny aktualizacji?
• Czy zmiana jest powiązana z dokumentem źródłowym?
• Czy wiadomo, kto zatwierdził dane do publikacji?
• Czy wiadomo, kto opublikował dane w CRU JSFP?
• Czy system przechowuje status publikacji?
• Czy system zapisuje błędy publikacji albo integracji?
• Czy decyzje o ograniczeniu jawności mają podstawę prawną?
• Czy wiadomo, kto dokonał wyłączenia jawności?
• Czy istnieje historia zmian uprawnień użytkowników?
• Czy można wygenerować raport audytowy?
• Czy historia jest zachowywana po odejściu użytkownika z jednostki?
• Czy lokalny rejestr pozwala wyjaśnić różnice między danymi lokalnymi a CRU JSFP?

Jeżeli odpowiedź na kilka z tych pytań brzmi „nie”, jednostka może mieć problem z rozliczalnością procesu publikacji i aktualizacji informacji o umowach.

Rekomendacja wdrożeniowa

Lokalny rejestr umów powinien mieć mechanizmy audytu od początku, a nie dopiero po pierwszym błędzie albo kontroli.

W praktyce warto wdrożyć:

• rozdzielone role użytkowników,
• historię zmian pól,
• statusy pracy z danymi,
• ścieżkę akceptacji,
• powiązanie zmian z dokumentami źródłowymi,
• rejestr decyzji o ograniczeniu jawności,
• ślad publikacji w CRU JSFP,
• ślad techniczny integracji przez API,
• raporty audytowe,
• okresowy przegląd uprawnień,
• zasady zachowania historii po odebraniu dostępu użytkownikowi.

Dopiero wtedy lokalny rejestr umów staje się narzędziem kontroli procesu, a nie tylko miejscem wpisywania danych.

Podsumowanie

Audyt, historia zmian i rozliczalność są jednym z najważniejszych elementów dojrzałego rejestru umów.

Przy CRU JSFP jednostka musi umieć nie tylko opublikować dane, ale również wyjaśnić, skąd te dane pochodzą, kto je przygotował, kto je zatwierdził, kto je zmienił, kto opublikował aktualizację i dlaczego.

Rejestr bez historii zmian może wystarczyć do prostego wykazu umów, ale nie wystarczy do bezpiecznego zarządzania procesem publikacji, aktualizacji, ograniczeń jawności i kontroli terminów.

Najważniejsza zasada jest prosta:

Źródła i podstawy prawne

Materiał został przygotowany na podstawie aktualnie dostępnych informacji publicznych dotyczących Centralnego Rejestru Umów Jednostek Sektora Finansów Publicznych oraz przepisów regulujących publikację, aktualizację, role użytkowników i rozliczalność działań w systemie.

Najważniejsze źródła:

• 1. Ustawa z dnia 27 sierpnia 2009 r. o finansach publicznych — w zakresie przepisów dotyczących Centralnego Rejestru Umów JSFP, odpowiedzialności kierownika jednostki, zakresu informacji o umowie, terminu publikacji i aktualizacji oraz okresu utrzymywania informacji w rejestrze.
• 2. Ustawa z dnia 4 grudnia 2025 r. zmieniająca ustawę o zmianie ustawy – Kodeks karny oraz niektórych innych ustaw oraz o zmianie niektórych innych ustaw, Dz.U. 2025 poz. 1844.
• 3. Ustawa z dnia 6 września 2001 r. o dostępie do informacji publicznej — w zakresie ograniczeń prawa do informacji publicznej, które mogą mieć znaczenie przy nieudostępnianiu określonych informacji o umowie.