Zintegrowany system zarządzania pozwala uporządkować normy ISO, ale nie prawo, atestacje i wymagania klientów. Zgadzamy się z diagnozą Piotra Fiderkiewicza, że norm jest wiele, a wzorzec jeden, ale nie z lekarstwem w postaci jednej normy rdzeniowej. Integratorem powinna być warstwa GRC (ład, ryzyko, zgodność) ponad normami.
Zintegrowany system zarządzania porządkuje normy, ale nie całe portfolio zgodności. Efekt: te same luki raportowane trzy razy, u trzech właścicieli.
Wstęp: spór o lekarstwo, nie o diagnozę
23 września 2026 r. Piotr Fiderkiewicz opublikował na LinkedIn . Według jego obserwacji ponad 80 norm systemów zarządzania (liczba przywoływana przez autora) opiera się na jednym wzorcu, a firmy utrzymują osobne systemy tam, gdzie wystarczyłby jeden. Autor opisuje audyt, na którym „system zintegrowany” okazał się dwoma systemami w jednym segregatorze, i proponuje jedną normę rdzeniową z modułami: jakość, środowisko, BHP, energia, informacja, ciągłość. Sam wskazuje też kontrargumenty: dokument IAF MD 11, odmienne kompetencje audytorów i ryzyko mega-normy.
Pod wpisem zapowiedzieliśmy rozwinięcie. Nasza teza jest krótka: model „rdzeń plus moduły” już istnieje, ale obejmuje wyłącznie normy ISO, a realne portfolio zgodności jest szersze. Najpierw sprawdzamy, co o integracji mówi sama ISO. Potem pokazujemy, dlaczego to nie wystarcza.
Czy model „rdzeń plus moduły” już istnieje?
W części tak, ale na poziomie norm, nie organizacji. Wspólna struktura (Harmonized Structure) ułatwia integrację wymagań norm, lecz sama nie tworzy zintegrowanego systemu organizacji. Przewodnik ISO zaznacza, że powstała dla autorów norm, a nie jako struktura dokumentowania systemu, choć jest dobrym punktem odniesienia. „Dwa systemy w jednym segregatorze” z wpisu PF nie jest więc błędem architektury norm, lecz błędem wdrożenia.
Co mówi trzecie wydanie przewodnika ISO
W 2026 r. ISO wydało trzecie wydanie przewodnika „Integrated management systems: A practical guide”, które zastępuje wydanie z 2018 r. Punktem wyjścia jest założenie, że każda organizacja ma już system zarządzania, formalny lub nie, a wymagania norm należy wbudować w istniejące praktyki, nie budować obok nich. Przewodnik wymienia pięć podstawowych aspektów zarządzania: ład (z odesłaniem do ISO 37000), ryzyka i szanse (ISO 31000), zarządzanie zgodnością (ISO 37301), procesy operacyjne oraz ocenę i doskonalenie.
Dwa szczegóły mają znaczenie dla naszej polemiki. Po pierwsze, przewodnik mówi o integracji wymagań norm „oraz innych wymagań i zaleceń”, w tym prawnych, w jednym systemie. Po drugie, wymagania norm dotyczące ryzyka mają mieścić się w istniejących ramach zarządzania ryzykiem organizacji, a integracja nie powinna zmieniać struktury systemu. Narzędziem jest macierz zgodności: procesy na jednej osi, wymagania na drugiej, z możliwością dołączenia wymagań zewnętrznych, także prawnych. Przewodnik zastrzega zarazem, że nie narzuca struktury systemu zintegrowanego, nie faworyzuje żadnej normy i nie zawiera wymagań poddających się audytowi. Nasz wniosek: ISO nie proponuje mega-normy, tylko system organizacji jako integrator.
Ile integracja daje w audycie
Wątek IAF MD 11 PF przywołuje słusznie. W wydaniu 2023 (Issue 3) dokument dopuszcza skrócenie czasu audytu zintegrowanego o nie więcej niż 20% względem punktu wyjścia, czyli sumy czasów dla poszczególnych norm. To maksymalny dopuszczalny pułap, a jego uzasadnienie zależy od oceny poziomu integracji i innych czynników wskazanych w dokumencie, m.in. zdolności zespołu audytowego do oceny wielu norm. Wszystkie wymagania każdej normy muszą zostać zaudytowane. Dokument dotyczy audytów zintegrowanych systemów ISO. Nasza interpretacja: 20% to sufit oszczędności czasu audytu, a nie miara wartości integracji. Korzyść z integracji jest głównie operacyjna i leży po stronie organizacji (mniej dublowania, jedno miejsce decyzji), nie po stronie audytora. Materiałem uzupełniającym jest PAS 99, który PF przywołuje jako kontrargument: to ramy wspólnych wymagań dla co najmniej dwóch norm systemów zarządzania opartych na Annex SL (wydanie 2012, pierwsze z 2006 r.).
Gdzie kończy się rdzeń ISO?
Rdzeń ISO kończy się tam, gdzie zaczynają się prawo, atestacje i wymagania klienta. Harmonized Structure integruje wyłącznie rodzinę ISO, a organizacja odpowiada jednocześnie na kilka rodzajów wymagań. Trzy przykłady.
Prawo jako przedmiot normy. EN 18286:2026, zatwierdzona przez CEN w lipcu 2026 r., opisuje system zarządzania jakością dla art. 17 AI Act. Ma strukturę klauzul 4–10 znaną z norm ISO, ale „jakość” rozumie jako zgodność z wymaganiami rozporządzenia. Jej Annex ZA zastrzega, że norma sama nie zapewnia spełnienia wszystkich wymagań, które trzeba badać jedno po drugim. Domniemanie zgodności powstaje dopiero po zacytowaniu w Dzienniku Urzędowym UE. Wstęp dopuszcza rozszerzenie istniejącego systemu zamiast budowy osobnego. Annex B wiąże ją zaś z ISO 9001:2015, nie z wydaniem 2026. Nawet norma o strukturze ISO, której przedmiotem jest prawo, nie staje się modułem rdzenia. Wymaga mapowania.
Prawo krajowe. Podmioty kluczowe i ważne objęte nowelizacją ustawy o krajowym systemie cyberbezpieczeństwa mają obowiązki dotyczące m.in. rejestracji, korzystania z systemu S46 i wdrożenia systemu zarządzania bezpieczeństwem informacji. Obowiązek cyklicznego audytu dotyczy podmiotów kluczowych, a podmioty ważne audytuje się na żądanie organu.
Atestacja. SOC 2 to raport atestacyjny wydawany przez niezależną firmę CPA (amerykański licencjonowany biegły, niekoniecznie tożsamy z polskim biegłym rewidentem) według kryteriów Trust Services Criteria; nie jest certyfikacją. Raport typu 2 ocenia skuteczność działania zabezpieczeń w badanym okresie, a typu 1 ich zaprojektowanie na wskazany dzień.
Terminy w skrócie. AI Act: obowiązki dla systemów wysokiego ryzyka z załącznika III od 2 grudnia 2027 r., z załącznika I od 2 sierpnia 2028 r. (rozporządzenie (UE) 2026/1744). Ustawa o KSC: wpis do wykazu do 3 października 2026 r. (termin minął), rozpoczęcie korzystania z systemu S46 i wdrożenie obowiązków do 3 kwietnia 2027 r., pierwszy audyt do 3 kwietnia 2028 r. dla podmiotów kluczowych, które nie były operatorami usług kluczowych (pozostałe podmioty kluczowe zachowują 3-letni cykl audytów).
Żadna z tych trzech rzeczy nie jest normą ISO, a wszystkie mogą dotyczyć tej samej organizacji.
Czym jest warstwa nad normami i jak działa?
W tym artykule przez warstwę GRC rozumiemy proponowany model organizacyjny, nie gotowy produkt ani powszechnie przyjęty standard: wspólną ewidencję zobowiązań, mapowanie ich na zabezpieczenia, właścicieli i dowody oraz wspólny nadzór kierownictwa. Zabezpieczenie testuje się raz, a każdy audyt jest innym widokiem na te same dowody. GRC to ład, ryzyko i zgodność. OCEG, organizacja, która ukuła ten skrót, definiuje GRC jako zintegrowany zestaw zdolności pozwalających niezawodnie osiągać cele, radzić sobie z niepewnością i działać z integralnością. Jej model (GRC Capability Model, tzw. Red Book, wersja 3.5) jest dostępny publicznie.
Mechanikę pokazuje Cloud Controls Matrix Cloud Security Alliance. Wersja 4 zawiera 197 celów kontrolnych w 17 domenach i mapowania m.in. do ISO/IEC 27001 i 27002, kryteriów AICPA oraz NIST SP 800-53, z analizą równoważności, luk i rozbieżności. Ostatnie jest istotne: mapowanie nie tylko łączy, ale i ujawnia, czego brakuje.
CCM jest ramą chmurową, a ogólniejszą rolę wspólnego zbioru zabezpieczeń pełnią metaramy. Secure Controls Framework (SCF) jest bezpłatny i obejmuje ponad 1400 zabezpieczeń w 33 domenach, mapowanych na ponad 200 aktów prawnych i ram, a Unified Compliance Framework (UCF) to komercyjna baza, która harmonizuje wymagania z setek dokumentów w zbiór wspólnych zabezpieczeń (opisy według wydawców). Od strony ładu i ryzyka wspólnym językiem są COSO ERM (2017), który wiąże zarządzanie ryzykiem ze strategią i wynikami, oraz NIST CSF 2.0 (luty 2024), w którym ład stał się osobną funkcją Govern. Mapowanie nie oznacza równoważności ani automatycznego spełnienia wymagania. Różne systemy, prawo i atestacje mają inne kryteria, zakres, okres badania i sposób wykazania skuteczności.
Normy ISO nie zabraniają takiej warstwy, tylko jej nie definiują. W normie o bezpieczeństwie informacji ISO/IEC 27001:2022, w pkt 6.1.3 (uwaga 1), czytamy: „Organizations can design controls as required, or identify them from any source.” (w tłumaczeniu własnym: organizacje mogą projektować zabezpieczenia według potrzeb albo wskazywać je z dowolnego źródła) Deklaracja Stosowania z tego samego punktu wymaga zarazem uzasadnienia wyboru. W normie dla systemów zarządzania jakością ISO 9001:2026 pkt 4.2 c) każe organizacji zdecydować, które wymagania stron zainteresowanych obejmie system, a pkt 5.1.1 b) wymaga włączenia wymagań systemu w procesy biznesowe. Norma systemu zarządzania zgodnością ISO 37301:2021 w pkt 4.5 wymaga systematycznego rozpoznawania zobowiązań i procesu wykrywania ich zmian. Przewodnik ISO opisuje macierz zgodności z wymaganiami prawnymi. To zalążek warstwy. Nasze stanowisko: GRC dodaje do niego zabezpieczenia, dowody i testowanie.
Pojedynczy wpis w takiej macierzy łączy: zobowiązanie → wymaganie szczegółowe → zabezpieczenie lub proces → właściciela → dowód → częstotliwość testu → widoki, w których dowód może być użyty. To odróżnia warstwę GRC od samego rejestru zgodności, który kończy się na pierwszych dwóch elementach.
Przykład: kwartalny przegląd uprawnień uprzywilejowanych w usłudze obsługującej dane klienta. Wspólnym dowodem jest protokół przeglądu z decyzjami o odebraniu lub utrzymaniu uprawnień, zatwierdzony przez właściciela zabezpieczenia. Każdy widok ocenia go jednak po swojemu:
| Widok | Odniesienie | Jak ocenia ten sam dowód |
|---|---|---|
| ISO/IEC 27001:2022 | A.8.2 (uprzywilejowane prawa dostępu), A.5.18 (prawa dostępu), uzasadnione w Deklaracji Stosowania | audytor sprawdza zasadność wyboru i działanie zabezpieczenia w audycie certyfikującym i nadzoru |
| SOC 2 | kryteria dostępu logicznego (Trust Services Criteria) | firma CPA ocenia projekt (typ 1) lub skuteczność w badanym okresie (typ 2) |
| ustawa o KSC | element systemu zarządzania bezpieczeństwem informacji | audyt podmiotu kluczowego; podmioty ważne na żądanie organu |
| ISO 9001:2026 | 8.5.3 (mienie klienta, wg uwagi do punktu także dane osobowe) oraz 4.2 c), jeśli wymóg wynika z umowy | audyt wewnętrzny i certyfikujący: czy organizacja zabezpiecza mienie klienta i objęła wymóg systemem |
Ponowne użycie dowodu nie zwalnia audytora ani firmy atestacyjnej z oceny, czy dowód pasuje do ich kryteriów, zakresu i okresu badania.
Dlaczego nie „jeden rejestr ryzyk”?
Bo ryzyka z różnych perspektyw mają różne kryteria, metody i właścicieli, a ich sztuczne zrównanie kończy się sporem o proporcje zamiast decyzją. Bezpieczeństwo informacji ocenia się przez poufność, integralność i dostępność oraz Deklarację Stosowania (ISO/IEC 27001, 6.1.2–6.1.3). Ciągłość działania przez analizę wpływu na biznes i ocenę ryzyka (ISO 22301, 8.2.2–8.2.3). BHP przez identyfikację zagrożeń (ISO 45001, 6.1.2.1), a środowisko przez aspekty środowiskowe (ISO 14001, 6.1.2). Przewodnik ISO mówi, że wymagania dotyczące ryzyka mają się mieścić w istniejących ramach organizacji, a ISO 31000:2018 w pkt 5.3 wskazuje, że zarządzanie ryzykiem ma być częścią ładu, strategii i operacji, nie czymś oddzielnym.
Nasze stanowisko: integrować należy decyzje, nie rejestr. Wspólne powinny być lista zobowiązań, biblioteka zabezpieczeń i dowody oraz jedno forum, na którym kierownictwo widzi perspektywy ryzyk obok siebie, z jawną regułą eskalacji. Pytanie „ile ryzyk z którego obszaru” przestaje wtedy mieć sens, bo nikt nie sumuje rzeczy niesumowalnych.
Uczciwie trzeba przyznać argument drugiej strony: wiele organizacji świadomie prowadzi jeden rejestr ryzyka przedsiębiorstwa (ERM) ze wspólnym apetytem na ryzyko i bywa to dobre rozwiązanie. Wspólny apetyt, wspólne kryteria wagi skutków i wspólna skala eskalacji są potrzebne także w naszym modelu. Spór dotyczy czego innego: nie wspólnych progów, lecz sumowania wyników różnych metod w jednej liczbie. ISO 9001:2026 w pkt 9.3.2 wymaga zresztą, by przegląd zarządzania oceniał skuteczność działań wobec ryzyk i szans, a IAF MD 11 wśród cech zintegrowanego systemu wymienia przegląd uwzględniający ogólną strategię biznesową.
Z praktyki audytora: scenariusz modelowy
Poniższy scenariusz jest modelowy. Zbudowano go na wzorcach typowych niezgodności, nie na konkretnym przypadku.
Organizacja usługowa ma certyfikowane systemy jakości i bezpieczeństwa informacji, raport atestacyjny SOC 2 dla klienta zagranicznego i obowiązki z ustawy o KSC. Wszystkie cztery widoki opierają się na tej samej bibliotece zabezpieczeń. W teście zabezpieczenia „przegląd uprawnień uprzywilejowanych” okazuje się, że w jednym kwartale przeglądów nie wykonano.
W modelu rozproszonym ta sama luka pojawia się trzy razy: jako niezgodność w audycie ISO, wyjątek w raporcie atestacyjnym i brak w dokumentacji systemu bezpieczeństwa informacji, każda z innym właścicielem i terminem. W modelu warstwowym luka ma jednego właściciela, a przyczynę źródłową rozpoznaje się wspólnie i koordynuje działania naprawcze. Każdy widok nadal ocenia ją odrębnie: w audycie ISO może to być niezgodność, w raporcie SOC 2 wyjątek, a w ocenie według ustawy o KSC osobny wniosek, o różnej wadze i skutkach. Zyskujemy wspólne rozpoznanie źródła problemu i skoordynowaną naprawę, nie jedną ocenę. Korelację widać nawet w samym świecie ISO: IAF MD 11 (pkt 2.5 i 5) każe jednostce certyfikującej rozważyć wpływ niezgodności w jednej normie objętej audytem zintegrowanym na pozostałe. Dokument nie obejmuje raportów SOC 2 ani oceny prawnej według KSC, ale logika jest podobna: awaria wspólnego zabezpieczenia może dotknąć wiele widoków naraz, a jego naprawa jest warunkiem przywrócenia każdego z nich, choć każdy ocenia ją odrębnie. Warunkiem jest właściciel zabezpieczenia, a nie normy, oraz organizacja, która potrafi utrzymać taką macierz. Tu wdrożenia zawodzą najczęściej: model jest macierzowy, więc wymaga dojrzałości i świadomości.
Kiedy warstwa GRC się nie opłaca
Warstwa ma koszt: ktoś musi utrzymywać mapowania, wyznaczać właścicieli zabezpieczeń i testować je według planu. W małej firmie z jedną normą i kilkoma zobowiązaniami wystarczy macierz zgodności w arkuszu, jak w przewodniku ISO, i nie warto kupować platformy. Sam przewodnik wymienia punkty uwagi: kompetentni audytorzy, umiejętności projektowe i akceptacja zmian w procesach. Warstwa zaczyna się opłacać, gdy te same wymagania pojawiają się w kilku widokach (kilka norm, atestacja, prawo, klienci), a koszt jednego testu rozkłada się na kilka audytów. To nasza ocena, nie wynik badań.
Jak zacząć
- Zinwentaryzować zobowiązania (prawo, klienci, schematy, normy) i zdecydować, które obejmuje system (ISO 9001:2026, 4.2 c; ISO 37301, 4.5). Przy zobowiązaniach prawnych pomaga spojrzenie przez pryzmat ryzyka prawnego.
- Zebrać bibliotekę zabezpieczeń z tego, co organizacja już stosuje, zmapować ją na zobowiązania i uzasadnić wybór (ISO/IEC 27001, 6.1.3).
- Wyznaczyć właścicieli i plan testów oraz ustalić forum decyzyjne i sposób aktualizacji macierzy.
Praktyczne implikacje: pytania, które zada audytor
- Czy organizacja ma jedną listę zobowiązań (prawo, klienci, schematy) i wie, które z nich obejmuje system? (ISO 9001:2026, 4.2 c; ISO 37301, 4.5)
- Czy każde zabezpieczenie ma właściciela i dowód, a jego wybór jest uzasadniony? (ISO/IEC 27001, 6.1.3)
- Czy kierownictwo widzi perspektywy ryzyk obok siebie, z regułą eskalacji? (ISO 9001:2026, 9.3.2)
- Kto i jak aktualizuje macierz po zmianie normy lub prawa? (ISO 37301, 4.5)
Podsumowanie
Piotr Fiderkiewicz słusznie widzi, że norm jest wiele, a wzorzec jeden, i słusznie krytykuje mnożenie papierów. Nie potrzebujemy jednak jednej normy, bo rdzeń już mamy, a mega-norma miałaby różne cykle rewizji modułów. Potrzebujemy warstwy, która nie jest normą: wspólnych zobowiązań, zabezpieczeń i dowodów, widzianych przez kilka audytów. Normy ISO dobrze się w niej mieszczą. ISO 9001:2026 daje punkt wyjścia, bo to ona każe zdecydować, które wymagania obejmuje system.
Zachęcamy do lektury przewodnika ISO „Integrated management systems: A practical guide” (3. wydanie, 2026) oraz norm, na które się powołujemy: ISO 9001:2026, ISO/IEC 27001:2022 i ISO 37301:2021. Tekst przedstawia ogólny model zarządzania; nie stanowi projektu systemu dla konkretnej organizacji.
Bibliografia
- P. Fiderkiewicz, Jeden system, dziesięć etykiet, LinkedIn, 23.09.2026. Wpis źródłowy.
- Rozporządzenie (UE) 2024/1689 (AI Act). EUR-Lex.
- Rozporządzenie (UE) 2026/1744 (Digital Omnibus on AI).
- Ministerstwo Cyfryzacji, Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa (KSC): najważniejsze terminy. gov.pl.
- ISO 9001:2026 Quality management systems — Requirements.
- ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection — Information security management systems — Requirements.
- ISO 37301:2021 Compliance management systems — Requirements with guidance for use.
- ISO 31000:2018 Risk management — Guidelines.
- ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements.
- ISO 45001:2018 Occupational health and safety management systems — Requirements with guidance for use.
- ISO 14001:2015 Environmental management systems — Requirements with guidance for use.
- EN 18286:2026 Artificial intelligence — Quality management system for EU AI Act regulatory purposes.
- ISO, Integrated management systems: A practical guide, wyd. 3, 2026. iso.org.
- IAF MD 11:2023 (Issue 3), Application of ISO/IEC 17021-1 for audits of integrated management systems. iaf.nu.
- OCEG, GRC Capability Model (Red Book) 3.5; Cloud Security Alliance, Cloud Controls Matrix v4; AICPA, SOC 2 i Trust Services Criteria.
- NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, 26.02.2024. csrc.nist.gov.
- COSO, Enterprise Risk Management: Integrating with Strategy and Performance, 2017. coso.org.
- Secure Controls Framework (SCF). securecontrolsframework.com.
- Unified Compliance Framework (UCF), Unified Compliance. unifiedcompliance.com.
- Źródło uzupełniające: BSI PAS 99:2012 Specification of common management system requirements as a framework for integration.
FAQ: Zintegrowany system zarządzania a GRC
Nie automatycznie. Norma ISO 9001:2026 wymaga, by organizacja zdecydowała, które wymagania stron zainteresowanych obejmie systemem (pkt 4.2 c), ale same normy nie zastępują oceny zgodności z prawem ani raportów wymaganych przez klientów. Wspólna struktura norm ułatwia integrację wymagań ISO, a prawo, atestacje i schematy klientów trzeba objąć osobnym mapowaniem.
Najwyżej 20% względem sumy czasów audytu dla poszczególnych norm. To maksymalny dopuszczalny pułap, a jego uzasadnienie zależy od poziomu integracji i zdolności zespołu audytowego do oceny wielu norm. Wszystkie wymagania każdej normy nadal muszą zostać zaudytowane.
SOC 2 to raport atestacyjny niezależnej firmy CPA według kryteriów Trust Services Criteria, a nie certyfikat. Raport typu 2 ocenia skuteczność zabezpieczeń w badanym okresie, a typu 1 ich zaprojektowanie na wskazany dzień. Certyfikacja ISO/IEC 27001 jest oceną systemu zarządzania bezpieczeństwem informacji według normy.
Nie. Cykliczny audyt co najmniej raz na 3 lata dotyczy podmiotów kluczowych, a podmioty ważne audytuje się na żądanie organu. Pierwszy audyt do 3 kwietnia 2028 r. dotyczy podmiotów kluczowych, które wcześniej nie były operatorami usług kluczowych.
Żadna z norm omawianych w artykule nie wymaga jednego rejestru. Przewodnik ISO mówi, że wymagania dotyczące ryzyka mają mieścić się w istniejących ramach zarządzania ryzykiem organizacji. Wspólne powinny być apetyt na ryzyko, kryteria wagi skutków i skala eskalacji, a sumowanie wyników różnych metod w jednej liczbie bywa wątpliwe.
Ekspert w zakresie systemów zarządzania ISO, cyberbezpieczeństwa, compliance i AI governance. Audytor, konsultant, trener.
Ilustracje w tym wpisie zostały wygenerowane przy użyciu narzędzi sztucznej inteligencji. Treść merytoryczna powstała w redakcji COE i jest podpisana imiennie.