Ład IT i zgodność – kiedy papier ma rację, a projekt się sypie

Wyobraź sobie scenę, którą zna prawie każdy senior PM z kilkuletnim stażem. Na stole leży plik dokumentów grubości trzech centymetrów. Na okładce logo firmy, numer wersji 2.3 i napis “Polityka ładu IT i zarządzania zgodnością”. Dokument ma 87 stron, tabelę odpowiedzialności RACI na stronie 34, mapę ryzyk na stronie 51 i podpisy czterech dyrektorów. Nikt z zespołu projektowego nigdy go nie otworzył. Wszyscy o tym wiedzą, nikt tego głośno nie mówi – i projekt idzie dokładnie tak, jak szedł przed wdrożeniem governance.

Ład IT to system, za pomocą którego organizacja podejmuje decyzje o technologii, rozdziela odpowiedzialność i kontroluje, czy IT faktycznie realizuje cele biznesowe. Compliance to potwierdzenie, że te decyzje są zgodne z przepisami, standardami i wewnętrznymi politykami. Razem tworzą coś, co w praktyce okazuje się bardziej polityczne niż techniczne – i co pada nie dlatego, że brakuje frameworku, ale dlatego, że nikt nie zadbał o to, żeby framework komukolwiek rzeczywiście przeszkadzał robić głupoty.

COBIT, ITIL i ISO 27001 – trzy różne problemy

COBIT powstał w 1996 roku jako odpowiedź ISACA na pytanie, jak audytować systemy informatyczne w sposób powtarzalny. Przez trzy dekady ewoluował z listy kontrolnej dla audytorów w pełny framework łączący cele IT z celami biznesowymi, zarządzaniem ryzykiem i strukturami decyzyjnymi. Dziś COBIT 2019 opisuje 40 celów zarządczych i 13 celów governance – brzmi imponująco, dopóki nie zaczniesz wdrożenia w firmie zatrudniającej 200 osób i odkryjesz, że samo mapowanie procesów zajmuje trzy miesiące.

ITIL z kolei dotyczy czegoś innego – zarządzania usługami IT, nie governance jako takim. Mylenie tych dwóch rzeczy to jeden z tych błędów, które popełnia się raz, po czym słyszy się o tym na każdej retrospekcji przez rok. ITIL 4 Foundation zakłada, że wartość usługi IT powstaje wspólnie z biznesem – nie jest dostarczana jednostronnie przez dział IT. Brzmi oczywiscie, ale w firmach, gdzie CIO raportuje do CFO wyłącznie przez arkusz kalkulacyjny, ta zasada jest trochę utopią.

ISO/IEC 27001 to z kolei standard dla systemu zarządzania bezpieczeństwem informacji (ISMS), certyfikowalny i audytowalny. Liczba ważnych certyfikatów na świecie sięga według danych ISO Survey dziesiątek tysięcy organizacji – rośnie konsekwentnie od lat, zwłaszcza po RODO i kolejnych regulacjach sektorowych. Certyfikacja oznacza, że zewnętrzny audytor potwierdza, że twoje procesy spełniają wymagania normy – nie że jesteś bezpieczny, tylko że masz udokumentowane procedury reagowania na incydenty. To subtelna, ale ważna różnica, którą compliance officerowie rozumieją, a zarządy rzadko.

Compliance officer – prawnik czy specjalista IT

Jedno z pytań, które regularnie pojawiają się przy budowaniu funkcji zgodności, dotyczy tego, czy compliance officer musi być prawnikiem. Krótka odpowiedź brzmi: nie musi, ale musi rozumieć prawo tak dobrze, żeby wiedzieć, kiedy zadzwonić do prawnika. W kontekście IT compliance – RODO, NIS2, regulacje sektorowe dla finansów i ochrony zdrowia – rola ta coraz bardziej wymaga rozumienia architektury systemów, przepływów danych i procesów zarządzania incydentami. Czysty prawnik bez znajomości infrastruktury IT często staje się autorem pięknych dokumentów, które nie opisują rzeczywistości.

Widziałem sytuacje, gdzie firma zatrudniała compliance officera z kancelarii, który pisał polityki bezpieczeństwa bez jednej rozmowy z administratorem systemów. Po sześciu miesiącach polityki były gotowe, certyfikacja ISO 27001 w toku, a dział IT nadal nadawał uprawnienia administratora przez maila bez żadnego procesu zatwierdzania. Polityki opisywały procesy, które nie istniały. Audytor zewnętrzny to w końcu wyłapał – tyle że przy okazji audytu klienta, nie wewnętrznego.

Gdzie governance realnie się sypie

Badania nad wdrożeniami frameworków IT governance w różnych organizacjach konsekwentnie wskazują ten sam problem: główną barierą nie jest technologia ani brak dokumentacji, lecz brak akceptacji ze strony ludzi. Struktury decyzyjne opisane na papierze rozmijają się z tym, jak decyzje faktycznie zapadają przy tablicy w sali konferencyjnej albo na Slacku o 17:45.

\p>Wyobraź sobie projekt wdrożenia nowego systemu ERP w firmie produkcyjnej. Komitet sterujący spotyka się co dwa tygodnie, eskalacje idą zgodnie z RACI, raporty statusu mają właściwe RAGi. A równolegle kierownik działu logistyki dogaduje się bezpośrednio z zewnętrznym integratorem, bo “tak jest szybciej”. Governance istnieje, ale obchodzi się je jak drogę ekspresową z wjazdem przez pole. Nikt formalnie nie łamie reguł – po prostu wszyscy wiedzą, gdzie są dziury w płocie.

Prawo Goodharta mówi, że kiedy miara staje się celem, przestaje być dobrą miarą. W kontekście compliance przekłada się to wprost na organizacje, które mierzą zgodność liczbą zamkniętych pozycji na checkliście audytowej, a nie realnym stanem ryzyka. Wskaźnik compliance wynosi 94%, a dane klientów są eksportowane do arkuszy Excel i trzymane na dyskach lokalnych – bo “tak zawsze się robiło” i nikt tego nie sprawdzał.

Co z tym zrobić – i kto to powinien robić

Governance działa wtedy, gdy ludzie z realną władzą decyzyjną czują, że framework im pomaga, a nie tylko przeszkadza. To nie jest kwestia wyboru między COBIT a ITIL ani między certyfikacją ISO 27001 a wewnętrznymi politykami. To kwestia tego, czy CTO i CFO rozmawiają językiem ryzyka biznesowego, czy CIO ma mandat do powiedzenia “nie” biznesowi, gdy projekt narusza polityki bezpieczeństwa, i czy compliance officer siedzi przy stole podczas planowania projektu, a nie pojawia się dopiero przy wdrożeniu produkcyjnym.

Jeśli governance w twojej organizacji oznacza głównie dokumentację tworzoną pod audyty, sprawdź, ile z tych dokumentów ktokolwiek czytał w ciągu ostatnich 12 miesięcy. Jeśli odpowiedź jest bliska zeru, problem nie leży w wyborze frameworku – leży w tym, że nikt nie poczuł realnych konsekwencji jego braku. Jeszcze.

Źródła

1. ISACA, “COBIT 2019 Framework: Governance and Management Objectives”, ISACA, 2018.
2. AXELOS, “ITIL 4 Foundation”, The Stationery Office, 2019.
3. ISO/IEC 27001, “Information security, cybersecurity and privacy protection – Information security management systems – Requirements”, ISO, 2022.
4. Goodhart C., “Problems of Monetary Management: The U.K. Experience”, 1975 (zasada sformulowana w kontekscie ekonomii, szeroko stosowana w teorii zarzadzania).

Zdjęcie: Ivan S / Pexels