Zgodność z cyberbezpieczeństwem nie jest osiągana wyłącznie dzięki politykom. Wymaga weryfikowalnych dowodów, jasnej odpowiedzialności oraz kontroli działających jako część codziennej pracy organizacji. Specjaliści ds. cyberbezpieczeństwa i zgodności opisują podejścia obejmujące ciągłe zbieranie zapisów audytowych, wyznaczanie właścicieli działań naprawczych, ograniczanie dostępu do danych, automatyzację kontroli zgodności oraz testowanie odporności operacyjnej, zanim regulatorzy lub audytorzy poproszą o dowody.

Priorytet dla weryfikowalnych zabezpieczeń po incydencie

Po incydencie w St. Paul Edith Forestal przygotowała pakiet zgodności dla regulatorów miejskich, oparty na krótkoterminowych działaniach opisanych w jej analizie. Pakietował wieloskładnikowe uwierzytelnianie (MFA) odporne na phishing dla poczty e-mail, VPN i ról administratora; minimalny inwentarz aktywów i tożsamości oraz segmentację usług krytycznych, w tym finansów i operacji awaryjnych.

Obejmował także dowody na niezmienialne kopie zapasowe offline oraz udaną próbę odtworzenia systemu o znaczeniu krytycznym. Scentralizowane logi zostały przekazane do systemu zarządzania informacją i zdarzeniami bezpieczeństwa (SIEM) z wykrywaniem kradzieży poświadczeń i nietypowego zachowania administratorów.

Forestal powiedziała, że podejście koncentrowało się najpierw na kontrolach zarówno wysokoskutecznych, jak i weryfikowalnych. Linie bazowe konfiguracji, wyniki testów i dane z logowania zostały przedstawione w celu spełnienia wymagań audytora.

— Edith Forestal, CISSP, CISM, CEH, założycielka i specjalistka ds. cyberbezpieczeństwa, Forestal Security

Zbieranie dowodów przeglądu w ramach rutynowych operacji

Udaya Bhaskar Vemuri powiedział, że dowody audytowe powinny powstawać w ramach normalnych procesów bezpieczeństwa, a nie być gromadzone bezpośrednio przed audytem. Jego podejście obejmowało prowadzenie zapisów przeglądów bezpieczeństwa, wyników skanowania, zgłoszeń naprawczych, decyzji o akceptacji ryzyka oraz dowodów, że problemy były śledzone do zamknięcia.

Te zapisy pomogły wykazać, że kontrole nie tylko istnieją na papierze, ale są stosowane w praktyce. Podczas audytu, jak powiedział Vemuri, odpowiedź powinna pozostać prosta: wyjaśnić kontrolę, przedstawić dokumentację potwierdzającą i wskazać wyjątki lub nierozwiązane kwestie.

Jego główny wniosek był taki, że gotowość jest łatwiejsza, gdy dowody są zbierane w sposób ciągły. Jeśli zespoły czekają, aż audytor zażąda konkretnych zapisów, zazwyczaj poświęcają więcej czasu na odtwarzanie tego, co się wydarzyło. Vemuri zaznaczył, że jego uwagi odzwierciedlają jego osobiste poglądy zawodowe, a nie stanowisko pracodawcy.

— Udaya Bhaskar Vemuri, starszy analityk bezpieczeństwa aplikacji

Mapowanie kontroli na dowody generowane maszynowo

Ace Zhuo powiedział, że audytorzy przykładają większą wagę do logów i innych dowodów na żywo niż do obszernych dokumentów polityk. Podczas przeglądu IT klienta-brokera działającego na MT5 w infrastrukturze TradingFXVPS zespół przeprowadził audytora aktualne dowody, zamiast wyjaśniać szczegółowy podręcznik polityk.

Dowody obejmowały niezmienialne logi dostępu dla wszystkich logowań administratorów do serwera transakcyjnego, egzekwowanie MFA na każdym koncie oraz zapis poprawek z sygnaturą czasową, pokazujący, że wszystkie krytyczne aktualizacje zostały wdrożone w ciągu 72 godzin. Historie zmian reguł zapory sieciowej zostały wyeksportowane i powiązane z odpowiednimi numerami zgłoszeń.

Zespół pokazał także wyniki ostatniego ćwiczenia backupowego, w tym jedno odtworzenie, które się nie powiodło, oraz kroki podjęte w celu jego skorygowania. Zhuo powiedział, że ta porażka zwiększyła zaufanie audytora, ponieważ wykazała, że przeprowadzono rzeczywiste testy, a nie ćwiczenie symulowane.

Jego metoda przygotowania do audytu polegała na jak najwcześniejszym mapowaniu każdej kontroli na dowód generowany maszynowo. Zalecał także traktowanie kontroli jako niezaliczonej, jeśli jej dowód nie może być pobrany w ciągu pięciu minut na żądanie audytora.

— Ace Zhuo, CEO; sprzedaż i marketing, ekspert ds. technologii i finansów, TradingFXVPS

Wyznaczanie właścicieli i terminów dla działań naprawczych

Przygotowując się do audytu SOC 2 Type II, Ankit Sarawagi kierował pracami nad przekształceniem zaległości ustaleń ryzyka w audytowalny program naprawczy. Każde ustalenie otrzymało konkretnego właściciela i termin. Pilne kwestie, w tym uprawnienia i szyfrowanie, zostały priorytetyzowane, a poprawki o niższym priorytecie zaplanowano w miesięcznych sprintach.

Proces ten umożliwił organizacji pokazanie audytorom, kto podjął działania, co zostało zmienione i jaki jest status każdego ustalenia. Zmniejszył też doraźne przygotowania i pozwolił zespołowi wykazać stały postęp podczas audytu.

— Ankit Sarawagi, kurator, CFO Matrix

Śledzenie, w jaki sposób narzędzia AI uzyskują dostęp do informacji i je wykorzystują

Shubham Paikrao powiedział, że jedną z jego najważniejszych lekcji dotyczących zgodności była ocena, czy asystent AI używany do sortowania zgłoszeń mógł wpłynąć na zgodność, uzyskując dostęp do danych podlegających regulacjom w nieprzewidziany sposób. Istniejąca dokumentacja była pisana z myślą o ludziach podejmujących decyzje, a nie o modelu oceniającym informacje i sugerującym działania w tle.

Zamiast traktować narzędzie jak zwyłą aplikację i zbierać standardowe dowody jego bezpieczeństwa, zespół ocenił je jako nowego dostawcę z własnym profilem ryzyka, podobnie jak zewnętrzny interfejs programowania aplikacji (API) pobierający dane klientów.

Paikrao przeanalizował logi pokazujące dokładnie, jakie informacje narzędzie przyjęło, do czego miało dostęp, ale nie działało, i jak te aktywności odpowiadały polityce klasyfikacji danych organizacji. Stworzył także krótki diagram przepływu danych dla audytora. Praktyki ponownego uczenia dotyczące danych wysyłanych do modelu zostały oznaczone, a zespół zgłosił zastrzeżenia, powołując się na warunki umowy.

Pytanie dla organizacji korzystających z AI, jak powiedział Paikrao, nie dotyczy tylko tego, czy ich kontrole działają. Muszą one także być w stanie udowodnić, co ich narzędzia AI zrobiły z danymi, które przetworzyły, i rozumieć własne operacje AI. Audytorzy niekoniecznie oczekują doskonałych odpowiedzi, ale oczekują, że organizacje rozumieją swoją widoczność kontroli i narzędzi używanych w codziennych operacjach.

— Shubham Paikrao, analityk bezpieczeństwa informacji

Wąskie granice danych dla SOC 2

W 2025 roku zespół Evgienija Leonowa dążył do certyfikacji SOC 2 dla aplikacji neobanku obsługującej rynek USA. Organizacja potraktowała przegląd jako problem architektoniczny i wymagała, aby każda kontrola pozostawiała dowód, który audytor mógł prześledzić od wymagania do działającego systemu.

Zaplecze zostało podzielone na mikroserwisy z oddzielnymi bazami danych i wąskimi zakresami danych. Zespół wsparcia nie miał wglądu w informacje finansowe, a serwis transakcyjny otrzymywał dane płatnicze bez pełnego kontekstu osobistego użytkownika. Firma nie przechowywała zdjęć paszportów ani innych danych tożsamości na własnych serwerach; informacje te były wysyłane bezpośrednio do dostawcy KYC i banku.

Deweloperzy musieli zweryfikować swoją tożsamość i poprosić DevOps o dostęp do serwisów. Dostęp produkcyjny pozostał przy DevOps i liderach zespołów. Kopie zapasowe Cloud SQL i replikacja wspierały odtwarzanie.

Firma zmniejszyła także ilośćnej infrastruktury wewnątrz granic audytu. Bond obsługiwał funkcje bankowe, Persona i Sardine zajmowały się weryfikacją tożsamości i wykrywaniem oszustw, a Auth0 obsługiwał uwierzytelnianie. Każdy dostawca miał określoną odpowiedzialność, co ułatwiało wykazanie własności.

Do konfiguracji chmury zespół używał Terraform i Terragrunt. Leonow powiedział, że poddana przeglądowi, wersjonowana historia zmian stanowi silniejszy dowód niż ręcznie skonfigurowane środowisko. Certyfikowane usługi zarządzane mogą także skrócić przygotowania do przeglądów SOC 2, HIPAA i GDPR, gdy ich dowody kontroli odpowiadają wymaganiom systemu.

Zespół zdał certyfikację SOC 2, choć bank miał do ukończenia odrębną certyfikację, zestaw kontroli i odpowiedzialność. Leonow podsumował podejście jako wersjonowanie infrastruktury, minimalizowanie pieczy nad danymi, definiowanie właścicieli dostępu i jawne określanie zakresu zgodności każdego dostawcy.

— Evgeny Leonov, dyrektor techniczny, Ronas IT | Software Development Company

Automatyzacja ciągłych zapisów zgodności

Mark Sternig powiedział, że zgodność powinna być wykazywalna w zwykły dzień, a nie składana w tygodniu poprzedzającym przegląd. Jego zasada pracy polega na tym, że wewnętrzne działania powinny odzwierciedlać to, co sprawdziłby zewnętrzny recenzent. W tym modelu wykazywanie zgodności staje się przejściem przez istniejący system, a nie wysiłkiem konstruowania narracji.

Kontrole powinny dokumentować się same. Zamiast polegać na pracownikach wykonujących zrzuty ekranu przed przeglądem, systemy powinny raportować w sposób ciągły i z sygnaturami czasowymi, dzięki czemu dryf konfiguracji jest wykrywany w momencie jego wystąpienia, a nie tuż przed tym, jak audytor zacznie szukać.

Sternig powiedział, że jego organizacja wcześniej potrzebowała kilku dni na zebranie logów z różnych systemów, odtworzenie incydentów i przygotowanie opisów pisemnych. Po zastosowaniu AI w tym procesie praca, która zajmowała dni, została skrócona do około 30 minut, z powtarzalnymi i udokumentowanymi wynikami.

Powiedział, że celem nie było usunięcie osądu ludzkiego, lecz automatyzacja zbierania dowodów i monitorowania przy zachowaniu ludzi do decyzji. Recenzenci łatwiej weryfikują widoczne, powtarzalne dowody niż jednorazowe wyjaśnienie.

— Mark Sternig, dyrektor techniczny, Focus

Egzekwowanie uwierzyelniania e-mail w czasie rzeczywistym

Al Iverson powiedział, że organizacje wykazujące zgodność z bezpieczeństwem poczty e-mail powinny pokazać, że polityki uwierzytelniania są egzekwowane w czasie rzeczywistym, a nie polegać wyłącznie na statycznych rekordach DNS. Pokazanie, że każdy autoryzowany nadawca jest uwzględniony, a nieautoryzowane wiadomości są aktywnie blokowane na podstawie egzekwowanych polityk DMARC, stanowi bezpośredni dowód działania kontroli.

Podszywanie się pod e-mail i spoofing domen to ważne punkty kontrolne audytu w regulowanych sektorach, takich jak usługi finansowe i ochrona zdrowia. Regulatorzy chcą zweryfikować, czy zabezpieczenia obejmują wszystkie domeny korporacyjne i zewnętrzne usługi wysyłkowe.

W Valimail, jak powiedział Iverson, firma automatyzuje zarządzanie hostowanym DMARC, SPF i DKIM. Celem jest zapewnienie ciągłej ochrony domen i wglądu w autoryzowane strumienie poczty bez konieczności ręcznych audytów.

— Al Iverson, lider badań branżowych i współpracy ze społecznością, ValiMail

Wykazywanie zapewnienia operacyjnego podczas egzaminacji

Yousuf Rizvi powiedział, że jego firma doradza firmom fintech i krypto w zakresie kontroli finansowych i gotowości regulacyjnej. W jednym z przykładów firma przygotowała klienta do egzaminacji stanowego przekaźnika pieniężnego (money transmitter), w której pytania dotyczące cyberbezpieczeństwa i bezpieczeństwa informacji były równie szczegółowe jak te dotyczące bilansu.

Klient miał już politykę bezpieczeństwa informacji, politykę kontroli dostępu i plan reagowania na incydenty. Brakowało mu dowodów, że polityki te działają. Zespół zbudował więc ścieżkę dowodową, zanim egzaminator o nią poprosił.

Każda polityka została powiązana z właścicielem kontroli, harmonogramem testów i zapisem potwierdzającym działanie kontroli. Przeglądy dostępu dokumentowały, kto i kiedy sprawdzał jaki dostęp. MFA było udokumentowane zrzutami konfiguracji potwierdzającymi egzekwowanie, a nie tylko stwierdzeniem, że MFA istnieje. Plan reagowania na incydenty został powiązany z ćwiczeniem symulacyjnym i analizą powydarzeniową rzeczywistego, drobnego zdarzenia.

Kiedyzaminator przybył, firma przedstawiła pakiet dowodów zorganizowany według kontroli i wyjaśniła, jak każda z nich była testowana. Pytania, które zwykle wydłużają egzaminację o tygodnie, zostały omówione na pierwszej sesji, ponieważ dowody były już zgromadzone.

Rizvi powiedział, że regulatorzy chcą wiedzieć, czy kontrola działała, kto jest jej właścicielem i jak organizacja dowiedziałaby się o jej awarii. Odpowiedzenie na te pytania dokumentami zamiast wyjaśnień zamienia egzaminację w przegląd, a nie dochodzenie.

— Yousuf Rizvi, CPA, partner, Ridgeway Financial Services

Testowanie zgody na stronie przed inspekcją

Taha Farhane, wcześniej główny audytor w zakresie technologii, procesów i prywatności danych, powiedział, że organizacje łatwo przechodzące przeglądy przedstawiają dowody, a nie polityki. Polityka może stanowić, że uzyskuje się zgodę, ale dowód powinien pokazywać, co konkretny użytkownik widział, jakiego wyboru dokonał i które tagi uruchomiły się później.

Farhane powiedział, że audyty były krótsze, gdy zespoły mogły przedstawić te zapisy dla próbki wybranej przez audytora. Przeglądy trwały dłużej i kończyły się ustaleniami, gdy firmy dostarczały tylko PDF z polityką i zrzut ekranu banera zgody.

Projektując oprogramowanie do zgody dla firm z Zatoki podlegające saudyjskiemu prawu o ochronie danych, Farhane zaczął testować strony internetowe z zewnątrz, tak jak zrobiłby to regulator. Proces polegał na załadowaniu strony głównej w czystej przeglądarce i sprawdzeniu, co uruchamia się, zanim użytkownik cokolwiek kliknie.

Test przeprowadzono na 1 556 saudyjskich sklepach internetowych. Według Farhane'a 60% uruchamiało trackery bez wyświetlania jakiegokolwiek banera zgody, a 68% ładowało śledzenie, zanim użytkownik dokonał wyboru. Powiedział, że test zajmuje 30 sekund, i zalecił organizacjom przetestowanie własnych stron, przechowywanie zapisów zgody i wykorzystanie ich do audytu opartego na próbkowaniu, a nie na sporze.

— Taha FARHANE, CEO, Arqam360

Dostarczanie surowych wyników skanowania repozytoriów

Timur Rakhmatullin opisał wewnętrzny audyt bezpieczeństwa w Softline, która zarządza platformą danych GCP na ponad 1 500 kontach klientów. Audytor zażądał dowodów, że każde repozytorium ma odpowiednie listy materiałowe oprogramowania (SBOM), brak znanych CVE w zależnościach i czyste łańcuchy licencji. Przegląd obejmował ponad 30 repozytoriów.

Rakhmatullin zbudował open-source'owe narzędzie npm o nazwie ai-project-audit do skanowania pod kątem zgodności licencyjnej, luk bezpieczeństwa i kompletności SB. Uruchomił je na wszystkich repozytoriach w ciągu nocy i następnego ranka miał ustrukturyzowane raporty. Raporty zawierały sygnatury czasowe, drzewa zależności i identyfikatory podatności.

Powiedział, że audytorzy powinni otrzymywać surowe logi, a nie podsumowanie stwierdzające, że wszystko wygląda dobrze. Pakiet przekazany audytorowi zawierał identyfikatory CVE z datami, wersje zależności, surowe wyniki skanowania JSON, wygenerowany SBOM i listę oznaczonych problemów dla każdego repozytorium. Kilka nieaktualnych zależności przechodnich zostało zidentyfikowanych i naprawionych przed audytem.

Czas przygotowań skrócił się z około dwóch tygodni do trzech dni. Większość pozostałego czasu zajęła naprawa oznaczonych elementów, a nie ich wyszukiwanie.

— Timur Rakhmatullin, starszy inżynier oprogramowania, Softline Solutions

Wykorzystanie ćwiczeń symulacyjnych do wykazania odporności

W jednym z przeglądów zgodności gotowość reagowania na incydenty została wykazana poprzez dowody pozostawione po ćwiczeniu symulacyjnym, a nie poprzez dopracowaną prezentację. Pakiet obejmował scenariusz, role uczestników, dziennik decyzji, projekty komunikatów, wnioski i zgłoszenia follow-up.

Sherif Koussa podkreślił zmiany wprowadzone po ćwiczeniu, w tym jaśniejsze progi eskalacji i lepsze zbieranie logów aplikacji. Audytorzy często spotykają plany, które dobrze brzmią, ale nigdy nie były testowane w warunkach niepewności. Ukończone ćwiczenie pokazało, czy zespoły techniczne, prawne i inżynieryjne mogą podejmować skoordynowane decyzje przy niepełnych informacjach.

Ćwiczenie wykazało także ciągłe doskonalenie, które — jak powiedział Koussa — może być bardziej wymowne niż twierdzenie o doskonałości. Skuteczne dowody audytowe uwidaczniają odporność poprzez powtarzalne zachowania, udokumentowaną naukę i mierzalne zmiany operacyjne.

— Sherif Koussa, CEO, Software Secured

Projektowanie zabezpieczeń przed wdrożeniem

Oscar Moncada powiedział, że jego firma projektowała pod kątem zgodności przed napisaniem kodu swojej platformy kosztów i bezpieczeństwa chmurowego. Ponieważ firma spodziewała się dążyć do SOC 2, stosowała najlepsze praktyki bezpieczeństwa od początku. Gdy audyt się rozpoczął, organizacja dokumentowała kontrole już wbudowane w infrastrukturę, zamiast je dobudowywać.

Firma przygotowała także polityki bezpieczeństwa na długo przed audytem, unikając pośpiechu w tworzeniu dokumentacji. Organizacjom posiadającym już produkty Moncada zalecił stosowanie praktyk bezpieczeństwa do każdej nowej funkcji i komponentu infrastruktury, zamiast prób zmiany wszystkiego naraz. Zalecił także używanie narzędzia, które w sposób ciągły identyfikuje nieane luki bezpieczeństwa i zgodności w środowiskach chmurowych.

Dla klientów Stratus10 najtrudniejszą częścią SOC 2 jest często usuwanie luk w istniejącej infrastrukturze AWS. Przykłady obejmują szeroko przyznane role IAM, do których nigdy nie powrócono, logowanie scentralizowane i niespójne szyfrowanie między serwisami. Wczesne wykrycie tych luk pozwala uniknąć tygodni napraw w trakcie audytu.

— Oscar Moncada, współzałożyciel i CEO, Stratus10

Powiązanie wymagań z regularnymi przeglądami

Podczas procesu rejestracji FCA Michael Foote szybko zrozumiał, że dokumentacja jest kluczem do wykazania zgodności. Regulatorzy nie chcieli obietnic, lecz dowodów na to, jak chronione są dane klientów.

Jego organizacja zbudowała bibliotekę zgodności mapującą każdą kontrolę bezpieczeństwa na konkretny wymóg regulacyjny, który spełniała. Firma przeprowadzała także kwartalne wewnętrzne audyty i rejestrowała każdy incydent bezpieczeństwa, także drobne.

Gdy audytor przeglądał systemy, firma mogła pokazać historię ciągłego doskonalenia, zamiast na ostatnią chwilę udowadniać zgodność. Foote powiedział, że to proaktywne podejście zaoszczędziło tygodnie pracy i wykazało, że firma poważnie traktuje ochronę danych, co ma znaczenie przy zarządzaniu cudzymi pieniędzmi.

— Michael Foote, założyciel, Quotegoat

Traktowanie cyberbezpieczeństwa jako codziennych operacji

Dean Rotchin powiedział, że BLACKJET zbudował swój framework cyberbezpieczeństwa wokół audytów certyfikacyjnych Part 135 i traktuje bezpieczeństwo danych tak samo systematycznie jak konserwację samolotów. Z jego doświadczenia wynika, że regulatorom bardziej zależy na powtarzalnych procesach niż na konkretnej technologii.

Firma udokumentowała kontrolę dostępu, procedury reagowania na incydenty i oceny zewnętrznych dostawców. Podczas ostatniego audytu pokazano audytorom zaszyfrowane systemy rezerwacji i wyjaśniono, jak dane płatnicze klientów są oddzielone od danych operacji lotniczych.

Rotchin powiedział, że cyberbezpieczeństwo powinno być przedstawiane jako dyscyplina operacyjna wpisana w codzienne przepływy pracy, a nie odpowiedzialność wyłącznie IT. Firma prowadzi szczegółowe logi i przeprowadza kwartalne audyty wewnętrzne. Podkreślił także budowanie dokumentacji razem z systemami i szkolenie każdego członka zespołu, ponieważ każdy pracownik może stać się źródłem podatności.

— Dean Rotchin, CEO w BLACKJET, BlackJet

Wczesne ustanawianie obrony godnej zaufania

Roman Vasilenko powiedział, że prowadzenie platformy fintech w sektorze edukacji kryptowalutowej wymagało od firmy zajęcia się bezpieczeństwem od początku, ponieważ zaufanie użytkowników było kluczowe, a sektor przyciąga uwagę regulatorów.

ego podejście kładło nacisk na konkretne dowody. Firma prowadziła szczegółowe zapisy praktyk przetwarzania danych, protokołów szyfrowania, kontroli dostępu i procedur reagowania na incydenty. Podjęła też dążenie do zgodności SOC 2, zanim stała się obowiązkowa, wykorzystując audyt do sformalizowania praktyk i identyfikacji luk.

Zgodność została wpisana w proces rozwoju poprzez regularne przeglądy bezpieczeństwa, aktualizacje zależności i szkolenia pracowników. Gdy audytorzy pytali, jak firma pozostaje na bieżąco, mogła pokazać trwający proces, a nie jednorazową ocenę.

Vasilenko powiedział także, że firma była transparentna co do sytuacji, w których priorytetyzowała szybkość kosztem teoretycznej doskonałości, i wyjaśniła, dlaczego te kompromisy miały sens dla bootstrapowego startupu. Zgodność opisał nie jako zdanie audytu, lecz jako budowanie systemów, które organizacja mogłaby publicznie z powodzeniem bronić.

— Roman Vasilenko, menedżer reklamy display, Vasilenko AdOps

Wbudowanie polityk w kod infrastruktury

Sudhanshu Dubey powiedział, że organizacje mogą poprawić gotowość regulacyjną, przechodząc od reaktywnych przygotowań do ciągłej, zautomatyzowanej architektury compliance-as-code. W swojej pracy ze złożonymi platformami finansowymi zastąpił ręczne zbieranie logów i zrzutów ekranu politykami zgodności zintegrowanymi bezpośrednio z szablonami infrastructure-as-code.

Korzystając z NIST Cybersecurity Framework (NIST CSF) i SOC 2 jako wzorców, zespół nie polegał już na ręcznych kontrolach, gdy audytorzy żądali weryfikacji zarządzania tożsamością i dostępem lub polityk szyfrowania. Zamiast tego pokazywał wersjonowaną historię repozytorium i zautomatyzowane silniki egzekwowania polityk, które blokowały niezgodne z przepisami dostarczanie zasobów w czasie rzeczywistym.

Działający dashboard telemetrii dostarczał dowodów stanu środowiska także poza datą oceny. Dubey powiedział, że traktowanie zgodności jako jednorazowego ćwiczenia dokumentacyjnego pozostawia organizacje narażone na dryf konfiguracji między cyklami audytu. Wbudowanie reguł w potoki dostarczania oprogramowania czyni postawę bezpieczeństwa weryfikowalną i zdolną do automatycznego korygowania niektórych problemów.

— Sudhanshu Dubey, kierownik dostaw i architekt rozwiązań korporacyjnych, Errna

Budowanie zaufania przez gotowość personelu i przejrzystość

Cor Tham powiedziała, że pracując z potencjalną firmą audytorską nad przeglądem bezpieczeństwa i zgodności CheapForexVPS dla partnera płatniczego, najpierw wyjaśniła, jak dane klientów przepływają przez firmę i kto ma do nich dostęp. Wyjaśniła też potencjalne straty komercyjne w przypadku wycieku danych. To nadało kontrolom opisanym w raporcie audytowym jasne uzasadnienie operacyjne.

Tham przygotowała także personel pierwszej linii i wsparcia. Audytorzy mogą testować pracowników odpowiadających na zgłoszenia przez całą dobę, sprawdzając, czy wiedzą, jak obsłużyć podejrzane żądanie logowania. Pewna i spójna odpowiedź młodszego pracownika może stanowić silniejszy dowód właściwej kultury bezpieczeństwa organizacji niż jakiekolwiek dokumenty polityk i procedur.

Tam gdzie kontrole miały luki, Tham udokumentowała wymagane działania naprawcze, wskazała, kto je wykona i w jakim terminie, oraz potwierdziła, że dział finansów zaakceptował budżet na niezbędne prace.

Jej celem było uczynienie zgodności przejrzystą relacją z firmą, a nie testem do zdania. Jak powiedziała, to podejście uczyniło proces spokojniejszym, szybszym i bardziej współpracy sprzyjającym.

— Corina Tham, dyrektor sprzedaży, marketingu i rozwoju biznesu, CheapForexVPS

Artykuł źródłowy jest dostępny na BlockTelegraph.