Pierwszy obszar - środowisko kontroli IT - obejmuje m.in. kwestie stworzenia samej struktury kontroli oraz przydzielenia odpowiedzialności za poszczególne procedury sprawdzające.

Rozwój systemów obejmuje m.in. wybór sprzętu i oprogramowania, zasady testowania i zapewniania jakości, dokumentacji i szkoleń.

Procedury wprowadzania zmian to m.in. autoryzacja i śledzenie zmian.

Dostęp do danych obejmuje wszystkie kwestie bezpieczeństwa.

Bieżąca praca systemów to m.in. procedury odtworzeniowe, procedury tworzenia kopii zapasowych, zarządzanie obciążeniem systemów IT.

Szerszy opis streszczonych tu procedur kontroli znajduje się w dokumencie "Sarbanes-Oxley Act: Section 404. Practical Guidance for Management" opublikowanym w lipcu 2004 r. przez PricewaterhouseCoopers. Nawet jednak szerszy opis kontroli systemów IT nie zajmuje więcej niż trzy i pół strony w 150-stronicowym dokumencie. W praktyce szefowie działów IT nie nadążają rozwiewać swoich wątpliwości i z przerażeniem patrzą na ogrom czekającej ich pracy.

Lista wątpliwości

Wątpliwości mnożą się już w samych firmach audytorskich, które zastrzegają się, że ich poradniki można uznać za właściwe do czasu pojawienia się nowych zasad, modyfikacji i interpretacji amerykańskiej Komisji Papierów Wartościowych i Komisji Nadzoru nad Księgowością Spółek Publicznych. Zaś interpretacja SOX cały czas, ku rozpaczy szefów działów IT i zarządów publicznych spółek, podlega ewolucji.

Problemy pojawiają się już na etapie określania zakresu kontroli, którym powinny zostać objęte systemy IT. Niektórzy CIO są zdania, że SOX nie dotyczy procedur odtwarzania danych i zapewnienia ciągłości procesów biznesowych. Inni są zdania, że procedury te mają bardzo wyraźny wpływ na raportowanie finansowe i w związku z tym muszą zostać objęte systemem kontroli wewnętrznej.

Na forach dyskusyjnych związanych z ustawą (prawdopodobnie najlepsze znajduje się pod adresemhttp://www.sarbanes-oxley-forum.com ) wskazówek jest prawdopodobnie tyle, co dyskutantów. Są tacy, którzy twierdzą, że po to, aby pozostać w zgodzie z SOX, należy od razu zbudować zapasowe centrum przetwarzania danych, które w chwili awarii w ciągu sekund przejmie przetwarzanie transakcji. Inni spekulują, że być może wystarczy mieć harmonogram tworzenia kopii zapasowych i regularnie sprawdzać poprawność ich wykonania. Słowa "dokumentacja, testowanie, plan, harmonogram, procedura, kontrola" przewijają się zresztą w każdym wątku. Ktoś zauważył ironicznie, że tak naprawdę wykładnia zależy od audytora i z nim należy ustalić zasady kontroli. Notabene wynikiem tej dyskusji było stwierdzenie, że zapewnienie ciągłości procesów biznesowych (business continuity planning) nie jest objęte przez SOX, ale odtwarzanie systemów po awarii (disaster recovery) już tak, gdyż ostatecznym celem SOX jest zapewnienie dostępności w każdej chwili prawdziwych i kompletnych danych finansowych, co bez procedur disaster recovery trudno sobie wyobrazić. Nie wiadomo tego jednak na pewno.

Kolejna żywo dyskutowana wątpliwość dotyczy arkuszy kalkulacyjnych - czy testować je pod kątem wiarygodności i procedur dostępu do danych, czy stosować kontrolę wersji i śledzenie zmian? Sporo przedsiębiorstw radzi sobie z problemem, kwalifikując używane arkusze do grup niskiego, średniego i wysokiego ryzyka i stosując odpowiednie procedury jedynie w odniesieniu do tych ostatnich. Przyporządkowanie to jest jednak dość intuicyjne i prawdopodobnie z łatwością może zostać zakwestionowane przez przepracowanego lub złośliwego audytora.

Kolejna wątpliwość: czy raport SAS70 sporządzony 90 dni wcześniej to już stary dokument, który nie odzwierciedla bieżącej sytuacji i musi zostać zaktualizowany? Jedni audytorzy są zdania, że 60-dniowy raport jest już zbyt stary, by był wiarygodny; inni akceptują raporty sporządzone kwartał wcześniej. Standard nr 2 nie rozwiewa tych wątpliwości, nie wspomina bowiem ani o arkuszach kalkulacyjnych, ani o raportach SAS70.

Na razie ci, którzy mają już audyt IT za sobą, zgodnie potwierdzają, że regulacje SOX są na tyle płynne i niejasne, że pozostawiają audytorom ogromne pole do interpretacji. Zauważają jednocześnie, że dla samych audytorów kontrola systemów IT jest na tyle nowym wyzwaniem, iż ci poprzestają często na przeglądzie - za to bardzo szczegółowym - dokumentacji, nie sięgając do żywych systemów.

Jaki standard?

SOX nie określa, jakie standardy w zakresie kontroli wewnętrznej powinny być wykorzystywane przez firmy próbujące uzyskać zgodność z ustawą. Takich wytycznych udziela jednak SEC, który określił m.in., że Guidance on Assessing Control, opublikowany przez Kanadyjski Instytut Dyplomowanych Księgowych (the Canadian Institute of Chartered Accountants), oraz the Turnbull Report, opublikowany przez Instytut Dyplomowanych Księgowych w Anglii i Walii (the Institute of Chartered Accountants in England & Wales), są przykładami standardów dobrze spełniających wymagania ustawy. Aprobowanym standardem jest również COSO.

Porządkując kwestie związane z technologiami informatycznymi wiele przedsiębiorstw odwołało się do standardu CObIT. Opublikowany w 1992 r. CObIT jest niezależnym od technologii zbiorem zasad kontroli systemów IT, napisanym z perspektywy biznesowej. CObIT określa 318 szczegółowych obszarów kontroli IT w przedsiębiorstwie. Połowa z nich została uznana za istotne z perspektywy SOX. Dotyczy to zwłaszcza planowania strategicznego w zakresie IT oraz fizycznego bezpieczeństwa systemów informatycznych.