Dostosować SAP do SOX

Dla kogo SOX

Uchwalona przez Kongres USA Ustawa Sarbanes-Oxley Act (SOX) była odpowiedzią amerykańskiego rządu na afery gospodarcze (m.in. Enronu) z lat 2000-2001. Jej celem było odbudowanie straconego zaufania inwestorów do rynków finansowych oraz zarządów spółek notowanych na giełdzie, agencji audytorskich i doradców finansowych. Poprawę jakości sprawozdawczości uzyskano, zwiększając odpowiedzialność audytorów i zarządów, podnosząc efektywność kontroli wewnętrznych i zaostrzając wymagania przejrzystości na rynkach finansowych.

Standardem wskazywanym jako punkt odniesienia przy kontroli wewnętrznej wynikającej z SOX jest model COSO, przygotowany przez Amerykańską Komisję Papierów Wartościowych. Kontrola wewnętrzna została dokładnie opisana w standardach COSO I i COSO II, obejmuje dobre praktyki zarządzania ryzykiem korporacyjnym, które jest kategorią szerszą od kontroli wewnętrznej. Oba opracowania stanowią polecany model dla uzyskania zgodności z wymaganiami SOX.

Ustawa obowiązuje spółki działające w USA i notowane na amerykańskiej giełdzie, jednak jej standardów przestrzegają również spółki powiązanie kapitałowo z firmami zarejestrowanymi w SEC, np. spółki zależne, oddziały amerykańskich korporacji, podmioty zarejestrowane i działające poza Stanami Zjednoczonymi, ale notowane na giełdach amerykańskich, a także firmy spoza Stanów, które dobrowolnie przyjęły dobre praktyki wprowadzone przez tę ustawę.

Wprowadzenie i utrzymanie standardów SOX niesie ze sobą różne konsekwencje. Niedostosowanie organizacji do jej wymogów grozi utratą reputacji i dobrego wizerunku, a także restrykcjami dla kadry zarządzającej (łącznie z karą więzienia i wysoką grzywną). Ponadto, należy liczyć się z rozrostem biurokracji związanej z koniecznością raportowania i rosnącą liczbą procesów do sprawdzenia. Odbywa się więcej kontroli, a koszty wdrożenia COSO, a następnie uaktualniania dokumentacji związanej z kontrolą wewnętrzną i sprawozdawczością finansową oraz jej archiwizowaniem są wysokie.

System SAP jest w dużych firmach podstawowym narzędziem, w którym są realizowane operacje finansowe, a środowisko SAP jest głównym środowiskiem raportowania. Dlatego sposób funkcjonowania systemów SAP w firmie, ich funkcjonalność, procedury utrzymania i rozwoju mają istotny wpływ na cały wachlarz zagadnień powiązanych z SOX.

Systemy SAP obsługują szeroko pojęte procesy finansowo-księgowe przedsiębiorstw, a zatem SAP FI, ale też inne obszary, w których przetwarzane są dane finansowe (np. SAP HR), podlegają wymogom kontroli SOX. Wymogi SOX mogą wymusić spore zmiany w sposobie zbierania, przechowywania i zarządzania informacjami składowanymi w SAP.

Oznacza to, że firma, która decyduje się wprowadzić standardy SOX, powinna dokonać swego rodzaju „rachunek sumienia” w zakresie SAP, czy szerzej IT, realizując kompleksowy przegląd spójności funkcjonujących rozwiązań ze standardami SOX.

Taki audyt, realizowany z udziałem pracowników firmy i ewentualnych ekspertów zewnętrznych, powinien objąć kilka niżej wymienionych obszarów SAP/IT:

• dostęp do programów i danych (system uprawnień),
• procedury odtworzeniowe i ciągłość działania,
• zarządzanie zmianą,
• rozwój funkcjonalności SAP,
• ochrona stacji roboczych.

Dostęp do programów i danych

W każdej firmie, która raportuje dane zgodnie z praktykami SOX, musi zostać opracowana polityka kontroli dostępu do danych, również tych utrzymywanych w systemach SAP. Powinna ona zostać należycie udokumentowana i poddawana regularnym przeglądom, wynikającym z potrzeb biznesowych i wymagań bezpieczeństwa.

Odpowiednio ustanowiona polityka kontroli dostępu definiuje:

• zarządzanie dostępem użytkowników – zapewnia dostęp autoryzowanym użytkownikom i zapobiega nieuprawnionemu dostępowi do systemów informacyjnych,
• rejestrację użytkowników – przyznawanie i odbieranie dostępu do wszystkich systemów i usług informacyjnych powinno opierać się na formalnej procedurze rejestrowania i wyrejestrowywania użytkowników,
• zarządzanie przywilejami – należy ograniczać i kontrolować przyznawanie i korzystanie z przywilejów,
• zarządzanie hasłami użytkowników – przydzielanie haseł powinno być kontrolowane za pośrednictwem formalnego procesu zarządzania,
• przegląd praw dostępu użytkowników – kierownictwo powinno dokonywać regularnych przeglądów praw dostępu użytkowników na podstawie formalnego procesu.

Ponadto należy udokumentować procedury eksploatacyjne tak, aby były dostępne dla wszystkich użytkowników, którzy ich potrzebują, jak również rozdzielić obowiązki i zakresy odpowiedzialności w taki sposób, aby ograniczyć możliwości nieuprawnionej lub nieumyślnej modyfikacji lub niewłaściwego użycia aktywów organizacji.

Procedury odtworzeniowe

Co z planami zachowania ciągłości działania? Nie są one konkretnie wymienione w SOX, natomiast sekcja  406(c)(2) wymaga pełnego, rzetelnego, dokładnego i terminowej przedstawienia sprawozdań okresowych. W jaki sposób organizacja może zapewnić dostępność raportów w systemach SAP? Zachowanie ciągłości działania jest jednym z najlepszych rozwiązań. Jednym z najważniejszych elementów utrzymania systemów SAP (oprócz działań prewencyjnych pozwalających zapobiec awarii) jest przywrócenie sprawności i dostępności systemu, w przypadku gdy w wyniku zdarzeń losowych bądź celowych działań jego dostępność zostanie przerwana. Istnieje wiele sposobów działania w takich okolicznościach – od postępowania ad hoc, w którym na bieżąco określamy (improwizujemy) kolejne kroki, po działanie usystematyzowane, „sterowane” procedurami na podstawie opracowanych Planów Ciągłości Działania (ang. Business Continuity Plan).

W pierwszym przypadku istnieje bardzo duże prawdopodobieństwo błędów oraz niepowodzenia całej operacji. W drugim prawdopodobieństwo to jest zminimalizowane, ponieważ istnieje ściśle określony i (co bardzo ważne) sprawdzony sposób postępowania. Plany Ciągłości Działania są więc elementem (oraz jednym z produktów końcowych) Zarządzania Ciągłością Działania. ZCD pozwala na zapewnienie niezbędnego dla danej organizacji poziomu działania operacyjnego w warunkach krytycznego zakłócenia. Proces ten wraz z Planami Ciągłości Działania powinien być obecny w każdej organizacji, w której jakikolwiek przestój generuje straty (np. w produkcji, usługach, logistyce).

Plany Ciągłości Działania dla systemów SAP identyfikują ścieżki dla poszczególnych systemów, które warunkują prawidłowe działanie, wskazują osoby odpowiedzialne za ich uruchomienie i realizację, zawierają opis procedur, jakie należy wykonać, by przywrócić dostępność danych i możliwość funkcjonowania procesów (np. częstotliwość backupów, sposoby archiwizacji itp.).

Częścią PCD jest plan odtwarzania utraconych zasobów (ang. Disaster Recovery Plan – DRP). To procedura postępowania w wypadku zdarzenia losowego (np. powodzi lub pożaru) lub krytycznej awarii, w wyniku której procesy w organizacji zostają przerwane, a zasoby i dane zniszczone (np. plan uruchamiania systemu z backupu).

SOX a zarządzanie zmianą

W szerszym kontekście ustawa SOX, oprócz warstwy systemów SAP czy w ogóle IT, obejmuje także warstwę sprzętową. Zmiany konfiguracji sprzętu czy oprogramowania są codziennością w działach IT. Jednak świadomość, że sprawne i efektywne przeprowadzenie procesu zmiany w znacznym stopniu zmniejsza ryzyko niestabilnej pracy urządzeń lub wystąpienia przerw w wykonywaniu usług, nie jest już tak powszechna.

Zarządzanie zmianą (Change Management) jest jednym z pięciu procesów bezpieczeństwa wymaganych przez SOX. Proces ten zapewnia standardowe procedury i metody skutecznej i terminowej obsługi zmian w infrastrukturze IT, tak aby uzyskać biznesową równowagę pomiędzy potrzebą zmiany a ryzykiem negatywnego jej wpływu na jakość usług IT. Ponadto w procesie planuje się i koordynuje przeprowadzane w infrastrukturze IT zmiany, czyli ocenia je, ustala priorytety i bada zależności.

Z zarządzaniem zmianą nierozerwalnie wiąże się Configuration Item (jednostka konfiguracji – CI), która określa pojedyncze urządzenie, sprzęt, element sieci, oprogramowanie technologiczne, aplikacje, środowisko, systemy czy urządzenia przenośne zarządzane przez dział IT. Terminem „zmiana” określana jest każda istotna modyfikacja CI, obejmująca również dodanie lub usunięcie jednostki konfiguracji.

Przyczyn przeprowadzania zmiany w dziale IT jest wiele. Mogą to być problemy z działaniem urządzeń czy systemów, związana z rozwojem firmy rozbudowa systemu informatycznego, ale także konieczność poprawy wydajności obecnego systemu czy też ograniczenie kosztów pracy. Aby proces zmiany został zamodelowany poprawnie, należy najpierw przemyśleć kilka istotnych zagadnień. Znawcy tematu, Brian Johnson i Peter Waterhouse, wyodrębniają siedem kluczowych pytań, na które należy odpowiedzieć przed przeprowadzeniem procesu zmiany:

• Kto zgłosił zmianę? Odpowiedź na to pytanie pozwoli określić, czy zmiana jest uprawniona i w konsekwencji wyeliminować zmiany zbędne.
• Jaka jest przyczyna zmiany? To ustalenie zablokuje przeprowadzenie zmian, które nie przynoszą żadnych korzyści biznesowych, a wiążą się z dużym ryzykiem. Informacje o przyczynach zmiany pozwolą na wyodrębnienie strategicznych innowacji spośród przynoszących mniej korzyści zmian taktycznych.
• Jaki efekt powinna przynieść zmiana? Odpowiedź na to pytanie pozwoli zrozumieć przyszłe konsekwencje zmian, a w szczególności efekty związane z rentownością finansową. Wyjaśnienie tej kwestii umożliwi określenie priorytetów dla zmian strategicznych.
• Jakie ryzyko niesie ze sobą zmiana? Jest to istotne pytanie, pogłębiające naszą wiedzę o zmianie. Odpowiedź na nie pozwoli na oszacowanie poziomu ryzyka związanego z wprowadzeniem zmiany, a docelowo na opracowanie scenariuszy dla sytuacji, w których sprawy nie ułożą się zgodnie z naszymi planami. Należy pamiętać, że części ryzyk można uniknąć, część zmniejszyć, a pozostałe trzeba zaakceptować.
• Jakie zasoby są niezbędne do przeprowadzenia zmiany? Pytanie to dotyczy zarówno ludzi,jak i sprzętu informatycznego. W stosunku do ludzi konieczne jest uzyskanie wiedzy, jakie kompetencje powinien posiadać zespół odpowiedzialny za przeprowadzenie zmiany; a w kontekście sprzętu otrzymamy informację o tym, jaka infrastruktura jest potrzebna do przeprowadzenia zmiany i czy jest ona dostępna. W rezultacie pozwoli to oszacować koszty i harmonogram związany z przeprowadzeniem zmiany.
• Kto jest odpowiedzialny za tworzenie, testowanie i wdrożenie zmiany? W wyniku odpowiedzi na to pytanie powinien powstać dokładny dokument opisujący podział odpowiedzialności za te zadania. Podział powinien obejmować cały proces zmiany, od momentu jej zgłoszenia do momentu wdrożenia zmiany.
• Jaki jest związek pomiędzy wprowadzaną zmianą i innymi zmianami? Poprawnie zbudowana i aktualizowana baza danych jednostek konfiguracji (CMDB) w znacznym stopniu ułatwi odkrycie związków istniejących w złożonych systemach informatycznych. Określenie zależności pomiędzy poszczególnymi CI pozwoli wyeliminować niepoprawną lub nieoptymalną kolejność wykonywania zmian.

Rzetelnie opracowane odpowiedzi na przedstawione powyżej pytania pozwalają obiektywnie podejść do zmiany i, co się z tym wiąże, do analizy związanego z nią ryzyka. Wszystko to bezpośrednio wpływa na zwiększenie niezawodności i dostępności usług IT zarówno dla klientów wewnętrznych, jak i zewnętrznych. Ponadto wiedza wynikająca z odpowiedzi pozwala na identyfikację ewentualnych braków w naszej organizacji IT, zarówno sprzętowych, jak i kadrowych.

Rozwój funkcjonalności SAP a wymagania SOX

Szczególnym przypadkiem zmiany jest wdrożenie nowych funkcji systemu IT. Wdrożenie nowych funkcjonalności SAP w firmie, która jest zobligowana spełniać wymogi SOX, powinno być realizowane zgodnie z procesami wytwarzania oprogramowania oraz zarządzania projektami. Procesy te powinny być odpowiednio sformalizowane (zdefiniowane etapy, dokumentacja merytoryczna poszczególnych etapów, zdefiniowanie metod planowania, analiza wymagań) i wdrożone.  Wszystko po to, aby:

• nowe funkcjonalności w SAP były zatwierdzane odpowiednio przez biznes oraz IT (potrzeby biznesu w stosunku do IT zmieniają się dynamicznie);
• metodologia i rozwój funkcjonalności SAP miały zdefiniowane odpowiednie cele kontrolne, które można wykorzystać do sporządzania sprawozdań finansowych;
• podczas projektowania i wdrażania nowych funkcjonalności SAP regulacje prawne były tak zdefiniowane, aby zachować integralność, poufność oraz dostępność danych;
• powstała dokumentacja kontrolna dla nowych funkcjonalności, wykorzystywana podczas przeprowadzania kontroli finansowych przez dział audytu;
• w przypadku rozwoju interfejsów zapewnić bezpieczne przesyłanie danych pomiędzy aplikacjami;
• uruchomiony został systemem do kontrolowania i zarządzania zmianami oraz zapewniona jakość wprowadzanych zmian;
• została zachowana integralność danych w przypadku migracji z systemu testowego na produktywny,
• nowa funkcjonalność w SAP została udokumentowana, wraz z instrukcją obsługi dla użytkownika;
• wszyscy użytkownicy SAP korzystający z nowych funkcjonalności zostali odpowiednio przeszkoleni.

Ochrona stacji roboczych

Aby zapewnić pełną ochronę komputerów w firmie, należy zadbać o zabezpieczenie wszystkich jednostek stacjonarnych oraz laptopów, na których jest dostęp do danych finansowych w SAP. IT powinno udokumentować, przetestować i ocenić kontrole w celu zapewnienia:

• zabezpieczenia zapobiegającego, wykrywającego i usuwającego kod złośliwy oraz właściwych procedur uświadamiania użytkowników,
• takiej konfiguracji systemu, która zapewni, aby uprawniony kod mobilny działał zgodnie z określoną polityką bezpieczeństwa, zaś kod nieuprawniony nie mógł się uruchomić,
• regularnego tworzenia kopii zapasowych informacji i oprogramowania oraz testowania go zgodnie z ustaloną polityką wykonywania kopii zapasowych,
• wdrożenia formalnej polityki wymiany informacji, procedur i zabezpieczeń, które zapewnią ochronę wymiany informacji przekazywanych różnymi środkami komunikacji,
• odpowiedniego zabezpieczenia informacji zawartych w wiadomościach elektronicznych,
• odpowiedniej ochrony informacji zawartych w transakcjach on-line, która zapobiegać ma niekompletności transmisji, błędnemu rutingowi, nieautoryzowanym zmianom, nieautoryzowanemu ujawnieniu, nieautoryzowanemu kopiowaniu lub powtórzeniu,
• ochrony integralności informacji umieszczanych w publicznie dostępnych systemach, aby zapobiec nieuprawnionej modyfikacji.

Przed zmianami – audyt

Rozsądnym punktem wyjścia do zmian w IT w związku z SOX jest wykonanie audytu różnych obszarów IT (w tym systemu SAP) pod kątem zgodności z SOX. Audytorzy wnikliwie mogą sprawdzić, na ile już są spełnione wymogi ustawy Sarbanes-Oxley w zakresie procedur IT i co należy zmienić, by tę zgodność uzyskać. Analizie podlegać powinna polityka bezpieczeństwa systemów informatycznych, procedury zarządzania uprawnieniami do systemów i danych, interfejsy pomiędzy systemami składującymi dane czy generującymi raporty finansowe. Audytem warto objąć dokumentację IT, zabezpieczenia serwerowni i sieci komputerowej, sposób wykonywania kopii zapasowych.