CRU to nie tylko projekt integracyjny. Jak bezpiecznie połączyć uczelnię z rejestrem? [OPINIA]

Od 1 lipca 2026 r. jednostki sektora finansów publicznych, w tym uczelnie, realizują obowiązek udostępniania informacji o zawieranych umowach w Centralnym Rejestrze Umów (CRU). Dane powinny być przekazywane bez zbędnej zwłoki, co do zasady nie później niż w ciągu 30 dni od zawarcia umowy lub wystąpienia zmiany wymagającej aktualizacji.

W praktyce oznacza to konieczność zbudowania powtarzalnego mechanizmu kwalifikowania umów, pozyskiwania informacji, ich zatwierdzania, publikacji i późniejszych korekt. Warto przy tym spojrzeć na CRU szerzej niż tylko jak na formularz lub kolejną integrację systemową.

Każdy automatyczny przepływ danych tworzy nowe zależności i wymaga odpowiedniego zarządzania dostępem. Dlatego wdrożenie CRU dobrze jest analizować również jako projekt z obszaru bezpieczeństwa informacji.

Najpierw mapa danych, dopiero potem integracja

Informacja o umowie rzadko powstaje w jednym miejscu. Część danych znajduje się w systemie obiegu dokumentów, część w systemie finansowo-księgowym, inne elementy w korespondencji, arkuszach lub lokalnych rejestrach jednostek organizacyjnych.

Zanim uczelnia połączy którykolwiek z tych zasobów z CRU, powinna ustalić, gdzie znajduje się źródło referencyjne dla każdego pola oraz kto odpowiada za jego poprawność. To zadanie ma wymiar nie tylko organizacyjny. Przy rozbudowanej strukturze uczelni te same informacje mogą występować w kilku systemach, dlatego potrzebne są jasne zasady rozstrzygania, które źródło jest referencyjne.

Automatyzacja ma największą wartość wtedy, gdy opiera się na danych już uporządkowanych i zweryfikowanych.

Mapa danych powinna obejmować lokalizację informacji, jej właściciela, sposób zatwierdzenia, historię zmian i zasady dostępu. Pozwala to zdecydować, które dane mogą być pobierane automatycznie, a które wymagają weryfikacji człowieka.

API wymaga osobnej warstwy zabezpieczeń

Ministerstwo Finansów przewidziało możliwość komunikacji z CRU za pośrednictwem API, m.in. w celu publikowania i aktualizowania umów, pobierania danych oraz wycofywania informacji z publikacji. Dla dużej uczelni integracja może znacząco ograniczyć ręczne przepisywanie danych. Jednocześnie uruchamia kanał, za pomocą którego system uczelni może wykonywać operacje w zewnętrznym rejestrze.

Z punktu widzenia cyberbezpieczeństwa ważne są poświadczenia wykorzystywane przez integrację: miejsce ich przechowywania, zasady dostępu i cykl zmiany. Konto techniczne powinno otrzymywać tylko niezbędne uprawnienia, a operacje wykonywane automatycznie – pozostawiać ślad pozwalający odtworzyć ich przebieg.

Warto również przewidzieć zachowanie systemu w sytuacjach nietypowych: czasowej niedostępności CRU, ponowienia operacji czy większej liczby aktualizacji. Odpowiednie alerty pomagają szybko wychwycić zarówno błąd techniczny, jak i niezamierzone działanie.

Najmniejsze uprawnienia i rozdzielenie ról

Obsługa umowy angażuje zwykle kilka ról: jednostkę merytoryczną, dział prawny, finanse, kancelarię, administratorów systemów i osobę odpowiedzialną za publikację. W tak złożonym procesie szczególnego znaczenia nabiera precyzyjne przypisanie zakresów dostępu.

Dobrym punktem odniesienia jest zasada najmniejszych uprawnień i rozdzielenie obowiązków. Inna osoba może przygotowywać dane, inna je zatwierdzać, a jeszcze inna zarządzać techniczną konfiguracją integracji.

Nie chodzi o mnożenie akceptacji, lecz o czytelny podział odpowiedzialności. Uprawnienia powinny być również regularnie aktualizowane, m.in. po zmianie stanowiska, zakończeniu zastępstwa lub odejściu pracownika. Dzięki temu model dostępu pozostaje zgodny z rzeczywistym zakresem obowiązków.

Nie publikować więcej, niż trzeba

Fakt, że dane są przetwarzane w systemie uczelni, nie oznacza jeszcze, że cały ich zakres powinien zostać przekazany do CRU. Systemy źródłowe mogą zawierać opisy robocze, dane kontaktowe, załączniki lub informacje wewnętrzne, które nie należą do wymaganego zestawu danych.

Bezpieczny przepływ powinien działać odwrotnie: przekazywać wyłącznie zdefiniowane i zweryfikowane pola, zgodnie z przyjętymi regułami kwalifikacji. Każde pole warto opisać pod względem źródła, formatu, walidacji oraz osoby odpowiedzialnej.

Szczególnej ostrożności wymagają pola tekstowe, do których użytkownicy mogą wpisywać dowolne informacje, bo to właśnie tam najłatwiej o umieszczenie treści nieprzeznaczonej do publikacji.

Minimalizacja danych nie jest więc wyłącznie kwestią zgodności. Ogranicza skutki błędu, upraszcza kontrolę i ułatwia wykazanie, dlaczego konkretna informacja znalazła się w rejestrze.

Ślad audytowy musi odpowiadać na pytanie: kto, co i kiedy

W razie potrzeby wyjaśnienia publikacji uczelnia powinna móc ustalić, z jakiego źródła pochodziła dana wartość, kto ją wprowadził lub zmienił, kto zatwierdził publikację, kiedy wykonano operację oraz jaką odpowiedź zwrócił CRU. Logi powinny być chronione przed nieautoryzowaną zmianą, przechowywane przez ustalony okres i dostępne osobom odpowiedzialnym za analizę zdarzeń.

Warto też określić sytuacje wymagające alertu, np. wielokrotne nieudane próby, masowe zmiany lub nietypową liczbę publikacji. Taki ślad pomaga nie tylko reagować na zdarzenia, lecz także oceniać jakość procesu i identyfikować miejsca, w których automatyzacja może jeszcze lepiej wspierać pracowników.

Plan reakcji jest częścią wdrożenia

Nawet dobrze zaprojektowany proces powinien uwzględniać sytuacje nietypowe. Przed uruchomieniem integracji warto ustalić, jak uczelnia zareaguje na publikację błędnych danych, niedostępność usługi lub podejrzenie nieautoryzowanej operacji.

Potrzebna jest jasna ścieżka eskalacji: kto może wstrzymać wysyłkę, kto ocenia zdarzenie i kto podejmuje decyzję o korekcie albo wycofaniu informacji. Testy powinny obejmować nie tylko prawidłową transmisję, ale też błędne formaty, przerwanie połączenia, ponowienie operacji i możliwość kontrolowanego zatrzymania integracji.

Wspólny projekt administracji i IT

Uczelnie są organizacjami o rozbudowanej strukturze, w których dane o umowach powstają w wielu jednostkach i systemach. To naturalnie zwiększa złożoność wdrożenia, ale jednocześnie sprawia, że wspólne ustalenie zasad może przynieść korzyści wykraczające poza sam CRU.

Nie chodzi o wdrożenie najbardziej rozbudowanego narzędzia, lecz o odpowiedź na praktyczne pytania: skąd pochodzi dana informacja, kto może ją zmienić, kto zatwierdza publikację, jakie zdarzenia są rejestrowane i jak organizacja reaguje w sytuacji nietypowej.

Po uporządkowaniu tych kwestii API może stać się realnym ułatwieniem. Wdrożenie CRU warto więc potraktować jako wspólny projekt administracji, zespołów merytorycznych i IT, w którym bezpieczeństwo jest jednym z założeń procesu od samego początku.