Najważniejsze na dziś: CRU JSFP nie jest wyłącznie publikacją danych o umowach. Aktualne przepisy budują także mechanizmy rozliczalności: kto przygotował dane, kto je zmienił, kto opublikował informacje, kto dokonał aktualizacji oraz na jakiej podstawie.
Dlaczego audyt i historia zmian są częścią zgodności
CRU JSFP nie jest wyłącznie publikacją danych o umowach. Aktualne przepisy budują również mechanizmy rozliczalności: kto przygotował dane, kto je zmienił, kto opublikował informacje, kto dokonał aktualizacji oraz na jakiej podstawie. Widać to zarówno w ustawie o finansach publicznych, jak i w rozporządzeniu wykonawczym.
Aktualizacja musi mieć powód, opis i datę
Art. 34a ust. 7 pkt 10 ustawy o finansach publicznych wymaga, aby przy aktualizacji informacji o umowie wskazać podstawę dokonania aktualizacji. Rozporządzenie doprecyzowuje, że chodzi w szczególności o zmianę umowy, wypowiedzenie umowy, cesję praw albo korektę błędu, wraz ze zwięzłym opisem aktualizacji oraz datą, od której ta przyczyna zaistniała.
To oznacza, że każda aktualizacja powinna mieć nie tylko nową wartość pola, ale również powód, opis i moment powstania przyczyny zmiany.
Role użytkowników to element rozliczalności
System CRU JSFP rozdziela role użytkowników. Rozporządzenie przewiduje uprawnienia administratora, wprowadzającego informacje o umowie oraz publikującego informacje o umowie. To rozróżnienie nie jest przypadkowe. Pozwala oddzielić przygotowanie danych od ich publikacji i lepiej przypisać odpowiedzialność za operacje wykonywane w systemie.
Administrator
Zarządza kontem jednostki i uprawnieniami użytkowników.
Wprowadzający
Może wprowadzać dane i dokonywać ich zmian.
Publikujący
Udostępnia i aktualizuje informacje w CRU JSFP, wycofuje udostępnione informacje oraz może zasilać system centralny danymi przez API.
W praktyce oznacza to, że jednostka powinna świadomie rozdzielić role, a nie przyznawać wszystkim użytkownikom pełne uprawnienia „dla wygody”.
Rozliczalność użytkownika nie jest dodatkiem technicznym
Rozporządzenie wymaga, aby konto osoby fizycznej było udostępniane w systemie przez okres niezbędny do wykonywania uprawnień, nie krócej jednak niż do dnia usunięcia z systemu wszystkich informacji niezbędnych do zapewnienia rozliczalności systemu, które zostały wprowadzone przez tego użytkownika.
To bardzo mocny sygnał prawny: rozliczalność działań użytkownika nie jest „miłym dodatkiem”, ale elementem modelu zgodności.
Pięcioletni horyzont wyjaśniania historii
Ustawa przewiduje pięcioletni okres utrzymywania informacji o umowie w CRU JSFP. Informacje o umowie są usuwane z rejestru po upływie pięciu lat, licząc od końca roku, w którym umowa przestała obowiązywać.
To oznacza, że proces lokalny również powinien być przygotowany na długoterminowe wyjaśnianie historii publikacji, aktualizacji i decyzji dotyczących jawności.
Co lokalny rejestr powinien przechowywać
- kto utworzył wpis,
- kiedy wpis został utworzony,
- kto zmienił dane,
- kiedy zmiana nastąpiła,
- jaka była treść przed zmianą i po zmianie,
- z jakiego powodu dokonano zmiany,
- czy zmiana wynikała z aneksu, wypowiedzenia, cesji, korekty błędu albo innej przyczyny,
- czy zmiana została zatwierdzona,
- kto zatwierdził zmianę,
- czy zmiana została już opublikowana albo zaktualizowana w CRU JSFP,
- czy zastosowano ograniczenie jawności,
- jaka była podstawa prawna ograniczenia jawności,
- kto podjął decyzję o ograniczeniu jawności.
Powiązanie z dokumentami źródłowymi
W dużej jednostce warto pójść krok dalej i powiązać historię zmian z dokumentem źródłowym: aneksem, wypowiedzeniem, porozumieniem rozwiązującym, cesją, notatką służbową, decyzją o wyłączeniu jawności albo korektą błędu.
Dzięki temu audyt nie kończy się na stwierdzeniu, że „ktoś coś zmienił”, tylko pozwala od razu sprawdzić, dlaczego zmiana została dokonana i z jakiego dokumentu wynikała.
Cztery statusy pracy z danymi
Rozliczalność jest potrzebna także poza samym systemem centralnym. Jeżeli jednostka korzysta z lokalnego rejestru umów, systemu obiegu dokumentów, systemu finansowo-księgowego albo integracji API, musi umieć wykazać, które dane były robocze, które zostały zweryfikowane, które zatwierdzone, które wysłane do CRU JSFP, a które faktycznie opublikowane albo zaktualizowane.
- dane przygotowane lokalnie,
- dane zatwierdzone do publikacji,
- dane przekazane do CRU JSFP,
- dane opublikowane albo zaktualizowane w CRU JSFP.
Jeżeli jednostka nie rozróżnia tych etapów, może mieć problem z ustaleniem, gdzie powstał błąd.
Jawność też musi zostawiać ślad
Historia zmian ma znaczenie również przy ograniczeniach jawności. Jeżeli dana informacja nie została udostępniona, lokalny rejestr powinien wskazywać nie tylko sam fakt ograniczenia, ale także podstawę prawną, organ albo stanowisko osoby dokonującej wyłączenia oraz datę decyzji.
W przeciwnym razie jednostka będzie miała trudność z wykazaniem, że ograniczenie jawności było świadome, uzasadnione i zgodne z procedurą.
Ślad techniczny integracji przez API
Dobrą praktyką jest także przechowywanie technicznego śladu integracji, jeżeli jednostka korzysta z API. Taki ślad powinien obejmować co najmniej:
- datę wysłania danych,
- zakres wysłanych danych,
- identyfikator operacji,
- status odpowiedzi systemu centralnego,
- ewentualny komunikat błędu,
- informację o użytkowniku albo procesie technicznym, który uruchomił wysyłkę.
Bez tego trudno później wyjaśnić, czy problem leżał po stronie danych, integracji, systemu centralnego czy organizacji pracy w jednostce.
Wniosek praktyczny: lokalny rejestr powinien pamiętać więcej niż rejestr centralny. CRU JSFP służy udostępnianiu informacji o umowach, ale to lokalnie jednostka musi umieć wykazać, kto przygotował dane, kto je zatwierdził, kto zdecydował o ograniczeniu jawności, kto dokonał aktualizacji i z jakiego powodu.
Rekomendacja wdrożeniowa
Największym błędem byłoby traktowanie historii zmian jako funkcji „ładnie mieć”. W realnym wdrożeniu CRU JSFP historia zmian, audyt operacji i rozliczalność użytkowników są elementami bezpieczeństwa organizacyjnego.
Lokalny rejestr umów powinien mieć:
- pełną historię zmian,
- rozdzielone role,
- statusy akceptacji,
- ślad publikacji,
- powiązanie z dokumentami źródłowymi,
- możliwość raportowania operacji.
Dopiero wtedy CRU JSFP staje się procesem kontrolowanym, a nie ręcznym wpisywaniem danych do systemu centralnego.
Źródła
- Art. 34a ust. 7 pkt 10 ustawy o finansach publicznych — obowiązek wskazania podstawy aktualizacji informacji o umowie.
- Art. 34b ust. 6 ustawy o finansach publicznych — pięcioletni okres utrzymywania informacji o umowie w CRU JSFP.
- § 3 pkt 8 rozporządzenia Ministra Finansów i Gospodarki z dnia 30 marca 2026 r. — przyczyna aktualizacji, opis i data jej zaistnienia.
- § 9 ust. 4 rozporządzenia Ministra Finansów i Gospodarki z dnia 30 marca 2026 r. — utrzymanie konta osoby fizycznej w związku z rozliczalnością systemu.
- § 10 rozporządzenia Ministra Finansów i Gospodarki z dnia 30 marca 2026 r. — role użytkowników i ich uprawnienia.
- § 12 rozporządzenia Ministra Finansów i Gospodarki z dnia 30 marca 2026 r. — możliwość zasilania CRU JSFP danymi z innych systemów teleinformatycznych przez API.