Gdy audytor jest gotowy do rozpoczęcia faktycznych testów, osoba kontaktowa (delegowana przez zarząd) powinna domagać się harmonogramu na spotkaniu otwierającym. Osoba ta przyjmuje audytora i ułatwia mu komunikację z personelem IT, którego usługi mogą być potrzebne do asystowania przy testach audytu. Osoba kontaktowa powinna otrzymać kopię programu audytu przed spotkaniem otwierającym, aby zaplanować zasoby adekwatne do wsparcia procesu audytu. Jeżeli to nie nastąpi, audytor powinien zostać zobowiązany do dostarczenia programu audytu na spotkaniu otwierającym, tak aby osoby zarządzające mogły przejrzeć go i wykorzystać do zaplanowania, wraz z audytorem (zespołem ds. audytu) niezbędnych zasobów.

Zbieranie informacji, rezultaty i sterowanie kompensujące

Pozyskiwanie informacji do audytu to proces identyfikacji osób, procesów i technologii w ramach danego środowiska systemowego, które podlega oczekiwanym działaniom kontrolnym. Zarząd odpowiedzialny za rezultaty audytu musi zapewnić warunki, w których audytor zawsze rozmawia z ekspertem kompetentnym w obszarze podlegającym przeglądowi. Powinien także poinformować personel, aby unikał niedomówień, odpowiadając na pytania audytora, i w sprawach wątpliwych kierował go do odpowiedniego eksperta lub osoby kontaktowej z zarządu.

Programy audytu są zazwyczaj podawane w terminach ogólnych i mogą być obsługiwane przy użyciu szerokiego zakresu technik i narzędzi technologicznych.

Gdy audytor nie może znaleźć dowodów, że cele kontroli zostały osiągnięte, wówczas zwraca się do odpowiedzialnego menedżera, żeby wyjaśnić, czy istnieją pewne działania w ramach organizacji, które kwalifikują się jako spełniające założone cele, a które nie były przewidziane przez audytora w związku z brakiem doświadczenia lub niedostateczną znajomością kontrolowanego środowiska. Jeżeli zostaną znalezione, to mogą być uznane za tzw. sterowanie kompensujące. Pozwala to na wyciągnięcie wniosku, że cele kontrolne osiągnięto, nawet jeżeli oczekiwane działania sterujące nie istnieją, ponieważ nowo znalezione działania rekompensują brak tych oczekiwanych.

Jeśli audytor nie może znaleźć żadnego materiału dowodowego odpowiadającego celom przeprowadzanej kontroli, problem będzie określony jako wynik (ustalenie) audytu.

Na każdym etapie zbierania informacji audytor będzie dysponował listą potencjalnych wyników (wniosków). Mogą one nie być jeszcze w pełni udokumentowane, ale stan może być już rozpoznany. Osoba współpracująca ze strony zarządu IT powinna często kontaktować się z audytorem podczas zbierania informacji i odpytywać, czy są jakieś potencjalne wnioski. Jej rolą jest pomaganie zarówno zarządowi, jak i audytorowi w zakresie materiału dowodowego, który powinien pokazać, czy cele kontrolne zostały osiągnięte.

Raport oceniający

Niezależnie od wyników, każdy audyt powinien kończyć się raportem oceniającym. Winien on opierać się na dokumentacji z przeglądu, a każda teza w nim zawarta powinna zostać poparta faktycznymi obserwacjami. Przy opracowywaniu raportu podstawowym wymogiem jest zamieszczenie w nim opisu zaobserwowanego stanu faktycznego, ryzyka związanego z zaobserwowanym stanem oraz ewentualnych rekomendacji zmian i usprawnień. Ponadto powinien on obejmować wiele innych informacji, które są określone w standardach audytowania systemów IT.

Raport jest formalną opinią audytora dotyczącą obszarów zarządzania poddanych audytowi. Powinny się w nim znaleźć ustalone cele audytu, krótko opisana metodologia i profesjonalna opinia audytora, czy sprawy zarządzania są odpowiednio zaadresowane. Gdy pojawiają się wnioski, to należy je zamieścić. Raport może także zawierać rekomendacje, które wynikają z tych wniosków. W przypadku, gdy audytorzy są stałymi pracownikami organizacji lub wynajętymi do monitorowania powtarzających się problemów zarządzania, to mogą żądać formalnego zobowiązania do wprowadzenia specjalnego planu wyeliminowania niedociągnięć. Takie działania naprawcze często formalnie przedłużają proces audytu, który jest uznawany za otwarty dopóty, dopóki nie zostaną zakończone działania naprawcze.

Menedżer IT, działający w obszarze objętym audytem, jest wraz z audytorem odpowiedzialny za ocenę problemów zarządzania.

W razie różnicy zdań przy dowolnym kluczowym aspekcie audytu, problem należy omówić w całym łańcuchu zarządzania. Taka wewnętrzna komunikacja w zarządzie IT może nie mieć żadnego wpływu na proces audytu, ale będzie służyć pokazaniu, że audytowani w pełni rozumieją ten proces i są chętni do otwartej dyskusji o problemach wynikających z audytu.