Według Homera Simpsona istnieją trzy rodzaje ludzi: ci, którzy potrafią liczyć, i ci, którzy takiej umiejętności nie mają. Ja muszę zaliczać się do tych drugich, bo wszyscy mówią, że w ramach zarządzania projektami istnieje dziesięć obszarów, a dla mnie jest ich dwanaście. Już tłumaczę:

Z jednej strony mamy integrację, gdzie cały proces zarządzania nabiera jednolitego znaczenia i charakteryzuje się jednolitym podejściem. Następnie istnieje zakres, skupiający się na realizowanych celach oraz na tym, co należy zrobić (i w jaki sposób), aby je osiągnąć. Mamy także planowanie i zarządzanie kosztami oraz zarządzanie ryzykiem, do którego należałoby dodać jakość, komunikację i zasoby (już jest ich osiem). Nie możemy zapomnieć o zainteresowanych stronach oraz dostawcach, czyli już dziesięć. I wreszcie, co nie mniej ważne, mamy zarządzanie bezpieczeństwem i zarządzanie innowacjami. W sumie dwanaście.

A tak na serio to zarządzanie bezpieczeństwem i zarządzanie innowacjami nie figurują formalnie, jako odrębna pozycja, w metodologiach zarządzania projektami takich jak PMBOK czy PM² (promowana przez Komisję Europejską). Brakuje również wzmianki na ich temat w podejściach typu agile. Niemniej jednak mają one ogromne znaczenie dla coraz większej liczby projektów.

Najpierw przeanalizujemy tu kwestię zarządzania bezpieczeństwem, pozostawiając zarządzanie innowacjami na kolejny artykuł.

Zarządzanie bezpieczeństwem

Cyfryzacja nie tylko stwarza nam nieograniczone możliwości i daje niezliczone korzyści, ale także naraża organizacje i użytkowników na nowe zagrożenia ze strony ataków informatycznych. Dojrzałe organizacje zarządzają cyberbezpieczeństwem na poziomie korporacyjnym, udostępniając środki zapewniające bezpieczeństwo informacji i ciągłość działania oraz szkoląc personel w zakresie określonych w tym celu procedur i dobrych praktyk. A co się dzieje z rozwiązaniami opracowywanymi wewnętrznie lub na użytek osób trzecich?

Security by default i security by design to dwa podstawowe paradygmaty bezpieczeństwa informacji. Systemy muszą zostać zaprojektowane tak, aby były bezpieczne, bez konieczności dostosowywania ich dodatkowo przez użytkownika (security by default). Poza tym bezpieczeństwo powinno być zintegrowane z produktem już na etapie jego projektowania, a nie dodawane później za pośrednictwem produktów i usług stron trzecich (security by design). Obydwa paradygmaty dążą do zapewnienia bezpieczeństwa systemów od samego początku i przez cały cykl ich życia. Wywierają zatem wpływ na wszystkie fazy projektu i wszystkie obszary zarządzania nim:

• Należy upewnić się, że zadania i procedury zdefiniowane zostały w sposób zgodny z wymogami bezpieczeństwa i prywatności, bez względu na ich charakter (przepisy, standardy, wymagania klienta itp.), od etapu projektowania aż po testy akceptacyjne. Środki bezpieczeństwa muszą być również dobrane proporcjonalnie do scenariuszy dotyczących istniejących zagrożeń i zakresów tolerancji akceptacji ryzyka. Oznacza to, że w pełni wpływają one na zakres i zarządzanie ryzykiem projektu.
• Zadania z zakresu bezpieczeństwa należy zaplanować (harmonogram) i uwzględnić związane z nimi koszty robocizny i materiałów (koszty).
• Aby zrealizować cele projektu, należy ustanowić odpowiednie procedury jakości, przeprowadzając jego audyt (pod kątem bezpieczeństwa) z częstotliwością, jaka zostanie uznana za odpowiednią.
• W ramach projektu należy udostępnić odpowiednie zasoby umożliwiające podjęcie związanych z bezpieczeństwem zadań, które zwykle wymagają wysokiego stopnia specjalizacji.
• Niezależnie od komunikacji wewnętrznej w obrębie zespołu, należy zwrócić uwagę na fakt, iż projekt może dotyczyć informacji wrażliwych, a nawet tajnych, co z kolei może wpływać na środki, których podjęcie należy rozważyć, aby uniknąć naruszenia wymogów bezpieczeństwa informacji i prywatności. Nie zapominajmy o znaczeniu LOPD/RODO w takich przypadkach.
• Zasadniczą rolę odgrywa zaopatrzenie, gdyż zazwyczaj wiąże się ze stosowaniem specjalistycznych rozwiązań i usług doradczych stron trzecich lub usług outsourcingowych, takich jak centra operacyjne cyberbezpieczeństwa (SOC).
• Cyberbezpieczeństwo ma także swoich interesariuszy. Istnieje wiele konkretnych podmiotów i ekspertów zajmujących się kwestią bezpieczeństwa, w tym m.in. dyrektor ds. bezpieczeństwa informacji (lub CISO) i inspektor ochrony danych.

Jeśli zarządzanie bezpieczeństwem jest powiązane ze wszystkimi obszarami razem i z każdym z nich osobno, a także z ich specyfiką, czy nie byłoby sensowne potraktowanie go jako osobnego obszaru?

Agencja Unii Europejskiej ds. Programu Kosmicznego (EUSPA) umacnia proces wdrażania zabezpieczeń w obrębie głównych europejskich programów kosmicznych (takich jak Galileo i EGNOS). W przypadku projektów powiązanych z tymi programami wymaga realizacji zadań związanych z kwestią Cyber Security Management i Cyber Internal Audits, wraz z odpowiadającymi im menedżerami, którzy – w uproszczeniu – pełniliby funkcję tożsamą z funkcjami kierownika projektu i menedżera ds. jakości w sekcji cyberbezpieczeństwa. GMV świadczy te usługi w ramach rzeczonych programów od 2013 roku. Od tego czasu zadania i obowiązki tych osób ewoluowały wraz ze stanem zaawansowania oraz dojrzałości statusu bezpieczeństwa Galileo i EGNOS, co przyniosło więcej niż znaczące sukcesy wszystkim zaangażowanym w te inicjatywy stronom.

Inwestycje w cyberbezpieczeństwo rosną z każdym rokiem w dwucyfrowym tempie, co stanowi wyraz wzrostu liczby cyberataków, ich konsekwencji oraz świadomości organizacji co do konieczności zapewnienia im należytej ochrony. Jednocześnie społeczeństwo ewoluuje w kierunku gospodarki projektowej, w przeciwieństwie do tradycyjnej, operacyjnej. Cyfryzacja, rosnąca ekspozycja na zagrożenia i gospodarka projektowa to więcej niż wystarczające argumenty, aby wynieść cyberbezpieczeństwo na poziom osobnej kategorii zarządzania projektami.

Autor(ka): Ángel Gavín