Zadania cyberbezpieczeństwa w backlogu Jiry mają jedną wspólną cechę: niemal zawsze lądują na samym dole. Nie dlatego, że bezpieczeństwo jest nieważne. Lądują tam, ponieważ nie są właściwie zdefiniowane, nie mają jasnego właściciela i nie konkurują o miejsce w sprincie na tych samych zasadach co inne zadania.
W tym artykule wyjaśniamy, dlaczego tak się dzieje i jak skutecznie zmienić to podejście. Pokazujemy również, jakie narzędzia pomagają wbudować zadania cyberbezpieczeństwa w backlog Jiry od pierwszego dnia projektu.
Dlaczego zadania cyberbezpieczeństwa trafiają na koniec backlogu w Jirze?
Przyczyn jest kilka i zazwyczaj nakładają się na siebie.
Bezpieczeństwo nie ma swojego Product Ownera. W większości organizacji nikt nie jest odpowiedzialny za priorytety zadań cyberbezpieczeństwa w backlogu Jiry. Funkcje takie jak nowe funkcjonalności, poprawki błędów czy wymagania klientów mają jasno określonych właścicieli. Bezpieczeństwo natomiast jest „wspólną odpowiedzialnością”, co w praktyce oznacza, że nikt się nim aktywnie nie zajmuje.
Zadania cyberbezpieczeństwa są zbyt ogólne. Epik w stylu „zapewnienie zgodności z NIS2” nie jest zadaniem. Nie ma właściciela, nie ma kryterium akceptacji i nie wiadomo, kiedy jest skończone. Takie zadania nie przechodzą przez sprint planning, bo nikt nie wie, jak je wycenić ani komu przypisać.
Presja dostarczania funkcjonalności jest silniejsza. W środowisku zwinnym priorytety są ustalane pod kątem wartości dla użytkownika i terminów delivery. Zadania cyberbezpieczeństwa rzadko mają bezpośredni wpływ na te kryteria, dlatego regularnie przegrywają z zadaniami biznesowymi podczas planowania sprintu.
Bezpieczeństwo pojawia się za późno. Gdy zadania cyberbezpieczeństwa są dodawane do backlogu Jiry dopiero na etapie testów lub przed audytem, ich realizacja koliduje z delivery. Zespół traktuje je wtedy jako zakłócenie, nie jako naturalną część procesu.
Brak widoczności skutków odkładania. Jeśli nikt nie mierzy ryzyka wynikającego z braku realizacji zadań cyberbezpieczeństwa, decyzja o przesunięciu ich na kolejny sprint nie ma żadnych widocznych konsekwencji. Dopóki nie nadejdzie audyt lub incydent.
Skutki odkładania zadań cyberbezpieczeństwa w backlogu Jiry
Odkładanie zadań cyberbezpieczeństwa na koniec backlogu Jiry generuje konkretne, mierzalne koszty.
Koszty audytów. Organizacje, które nie realizują zadań cyberbezpieczeństwa systematycznie, ponoszą znacznie wyższe koszty przygotowania do audytów ISO 27001, NIS2 lub DORA. Dokumentowanie działań wstecznie, tworzenie dowodów realizacji i angażowanie zewnętrznych konsultantów generuje koszty wielokrotnie wyższe niż regularna realizacja zadań w backlogu Jiry.
Luki w zabezpieczeniach. Zadania cyberbezpieczeństwa, które nie trafiają do sprintu, to kontrole, które nie są wdrożone. W przypadku incydentu brak realizacji konkretnych zadań może oznaczać bezpośrednią odpowiedzialność organizacji za naruszenie regulacji NIS2 lub DORA.
Reaktywne podejście do bezpieczeństwa. Gdy zadania cyberbezpieczeństwa realizowane są wyłącznie przed audytem, organizacja nigdy nie buduje prawdziwej kultury bezpieczeństwa. Zamiast tego wdraża kontrole na chwilę, a po audycie wraca do poprzednich nawyków.
Jak zmienić podejście do zadań cyberbezpieczeństwa w backlogu Jiry?
Zdefiniuj zadania cyberbezpieczeństwa tak jak każde inne zadanie w Jirze
Zadania cyberbezpieczeństwa muszą spełniać te same kryteria co każde inne zadanie w backlogu Jiry. Szczegółowy opis tego, jak definiować i strukturyzować wymagania, znajdziesz w artykule Jak zarządzać wymaganiami bezpieczeństwa w Jirze. Powinny mieć konkretny opis, jasne kryterium akceptacji, szacowany nakład pracy i przypisanego właściciela. Dopiero wtedy mogą konkurować o miejsce w sprincie na równych zasadach.
Zamiast ogólnego epiku „zgodność z ISO 27001” backlog powinien zawierać konkretne zadania, na przykład „Zidentyfikuj i udokumentuj zasoby informacyjne projektu zgodnie z wymaganiem ISO 27001 pkt 8.1” z przypisanym właścicielem, terminem i opisem kroków realizacji.
Przypisz właściciela do zadań cyberbezpieczeństwa w backlogu Jiry
Każda kategoria zadań cyberbezpieczeństwa powinna mieć swojego właściciela w backlogu Jiry. Project Manager odpowiada za realizację w harmonogramie. Security Support odpowiada za merytoryczną poprawność kontroli. Compliance Officer odpowiada za zgodność z regulacjami. Bez jasno określonej odpowiedzialności zadania cyberbezpieczeństwa zawsze będą przegrywać z zadaniami, które mają swojego championsa.
Wprowadź klasyfikację ryzyka jako podstawę priorytetyzacji
Priorytet zadań cyberbezpieczeństwa w backlogu Jiry powinien wynikać z poziomu ryzyka, nie z intuicji. Projekty o wysokim ryzyku, na przykład te przetwarzające dane osobowe lub objęte regulacją DORA, powinny mieć zadania cyberbezpieczeństwa w każdym sprincie. Projekty o niskim ryzyku mogą realizować je rzadziej, jednak nigdy nie powinny całkowicie ich pomijać.
Dodaj zadania cyberbezpieczeństwa do definicji ukończenia projektu
Jednym ze skutecznych sposobów na podniesienie priorytetu zadań cyberbezpieczeństwa w backlogu Jiry jest włączenie ich do definicji ukończenia (Definition of Done) na poziomie projektu lub epiku. Projekt, który nie zrealizował wymaganych zadań cyberbezpieczeństwa, nie może być uznany za zakończony. To prosta zmiana procesowa, która ma jednak duże znaczenie dla priorytetyzacji.
Mierz i raportuj dług bezpieczeństwa
Organizacje, które regularnie raportują stan realizacji zadań cyberbezpieczeństwa w backlogu Jiry, szybciej reagują na rosnący dług. Regularne przeglądy backlogu z udziałem Compliance Officera i kierownictwa pozwalają utrzymać presję na systematyczną realizację zadań, zanim staną się one problemem audytowym.
Jak Cyrima rozwiązuje problem zadań cyberbezpieczeństwa w backlogu Jiry?
Cyrima to aplikacja zintegrowana z Jira Cloud, która rozwiązuje opisany problem u źródła. Zamiast czekać, aż zespół samodzielnie doda zadania cyberbezpieczeństwa do backlogu Jiry, Cyrima generuje je automatycznie na podstawie profilu ryzyka projektu i obowiązujących regulacji.
Każde zadanie cyberbezpieczeństwa wygenerowane przez Cyrima zawiera opis aktywności, przypisane role, kroki realizacji i instrukcje stanowiskowe. Dzięki temu zadania są gotowe do wyceny i przypisania do sprintu od pierwszego dnia projektu. Nie są ogólnymi epikami, lecz konkretnymi, wykonalnymi zadaniami w backlogu Jiry.
Cyrima obsługuje standardy ISO 27001, NIS2, DORA, GDPR, COBIT i ITIL. Organizacje mogą również korzystać z wbudowanego Marketplace, który umożliwia połączenie z certyfikowanymi ekspertami bezpośrednio z poziomu zadania w Jirze.
Więcej informacji znajdziesz na stronie cyrima.com. Aplikacja jest dostępna na Atlassian Marketplace.
