Wymóg z przepisu przełożony na konkretne ustawienie w Waszym systemie — i na dowód, który to pokazuje.
Inżynier i audytor patrzą na to samo — i rozumieją to samo.
Tak wygląda punkt wyjścia w wielu firmach, które dowożą szybko i podlegają regulacjom.
Regulacja mówi ogólnie: zarządzanie ryzykiem, kontrola dostawców, zgłaszanie podatności. Nie mówi, co ustawić w Waszym repozytorium. Przed audytem albo ankietą klienta zespół zbiera dowody ręcznie, zrzut ekranu po zrzucie ekranu.
Zakres ustalamy po diagnozie — zaczynamy od elementu, który najszybciej obniży Wasze ryzyko.
Przepis przełożony na konkretne ustawienie.
Każdy wymóg wskazujemy na konkretne ustawienie w Waszym systemie, które go realizuje — tak, żeby rozumiał to i inżynier, i audytor. To, czego brakuje, wdrażamy, zamiast zostawiać listę zaleceń do samodzielnego zamknięcia. Zbieranie dowodów automatyzujemy, więc materiał powstaje przy każdym wydaniu, a nie w nocy przed audytem. Przygotowujemy też gotowe odpowiedzi na ankiety bezpieczeństwa klientów, bo te pytania i tak przyjdą — pytanie tylko, czy przed podpisaniem umowy, czy po.
Po każdym etapie zostaje u Was konkretny rezultat, a nie notatka ze spotkania.
Każdy wymóg wskazujemy na konkretne ustawienie, które go realizuje.
RezultatMapa: wymóg → ustawienie w Waszym systemie, czytelna dla inżyniera i audytora
To, czego brakuje, wdrażamy — nie zostawiamy listy zaleceń.
RezultatWdrożone brakujące ustawienia zamiast listy zaleceń
Materiał powstaje przy każdym wydaniu, nie w nocy przed audytem.
RezultatDowody zbierane automatycznie przy każdym wydaniu
Gotowe odpowiedzi na pytania, które i tak przyjdą przed podpisaniem umowy.
RezultatBiblioteka odpowiedzi na ankiety bezpieczeństwa klientów
Wdrożenie kończy się działającą konfiguracją i dowodami, a nie raportem z listą zaleceń. Tak to wygląda na przykładzie.
# dowód zapisywany przy każdym wydaniu
- name: Eksport ochrony gałęzi
run: |
gh api "repos/$GITHUB_REPOSITORY/branches/main/protection" \
> dowody/ochrona-galezi.json
- name: Archiwizacja z numerem wydania
run: cp -r dowody "archiwum/$GITHUB_REF_NAME"Materiał dla audytora powstaje sam, a nie w nocy przed audytem.
| Wymóg | Ustawienie |
|---|---|
| ISO/IEC 27001:2022, A.8.32 — zarządzanie zmianą | ochrona gałęzi i wymagana recenzja |
| NIS2 art. 21 ust. 2 lit. e — bezpieczeństwo w rozwoju i utrzymaniu | skan zależności przy każdej zmianie |
| SOC 2 CC6.1 — dostęp logiczny | SSO i MFA w repozytorium |
Każdy wymóg ma wskazane miejsce, które go realizuje.
Ankieta przestaje blokować podpisanie umowy.
Ilustracja. Zakres i narzędzia dobieramy po diagnozie. Pokrywamy warstwę techniczną. Pełna zgodność wymaga też działań organizacyjnych i prawnych i nie zastępuje formalnego audytu.
Zakres ustalamy po rozmowie i diagnozie. Mniejsze wdrożenia zamykają się w kilku tygodniach, większe dzielimy na etapy, żeby efekt był widoczny po pierwszym.
Zwykle nie do całego. W większości przypadków wystarczy dostęp do konfiguracji procesu budowania i ustawień organizacji. Zakres ustalamy pisemnie przed startem.
Tak, ale nie na pełen etat. Potrzebujemy kontaktu z osobą, która zna system, i przeglądu naszych zmian. Reszta jest po naszej stronie.
Wpinamy się w to, co u Was działa. Wymiana narzędzia to najdroższy i najrzadziej potrzebny sposób poprawy bezpieczeństwa.
Nie. Pracujemy na standardach i narzędziach, które Wasz zespół zna albo szybko pozna — nie na autorskiej metodyce, którą rozumiemy wyłącznie my. Wszystko jest udokumentowane i przekazane.
Tak wpinamy kontrole, żeby działały w tle. Jeśli któraś zaczyna blokować pracę, dostrajamy ją albo zmieniamy jej miejsce w procesie.