Definisjon AV IT-revisjon – EN IT-revisjon kan defineres som enhver revisjon som omfatter gjennomgang og evaluering av automatiserte informasjonsbehandlingssystemer, relaterte ikke-automatiserte prosesser og grensesnittene blant dem. Planlegging AV it-revisjonen innebærer to hovedtrinn. Det første trinnet er å samle informasjon og gjøre noen planlegging det andre trinnet er å få en forståelse av den eksisterende intern kontroll struktur. Flere og flere organisasjoner går over til en risikobasert revisjonstilnærming som brukes til å vurdere risiko og hjelper en it-revisor til å ta beslutningen om å utføre samsvarstesting eller substansiell testing. I en risikobasert tilnærming er it-revisorer avhengig av interne og operasjonelle kontroller samt kunnskapen til selskapet eller virksomheten. Denne typen risikovurderingsbeslutning kan bidra til å relatere kost-nytte-analysen av kontrollen til den kjente risikoen. I» Samle Informasjon » – trinnet MÅ it-revisor identifisere fem elementer:
- Kunnskap om næringslivet
- tidligere års revisjonsresultater
- siste finansiell informasjon
- regulatoriske statutter
- Iboende risikovurderinger
en sidenotat på «Iboende risiko», er å definere det som risikoen for at det foreligger en feil som kan være vesentlig eller signifikant når den kombineres med andre feil som oppstår under revisjonen, forutsatt at det ikke er noen relaterte kompenserende kontroller. Som et eksempel er komplekse databaseoppdateringer mer sannsynlig å bli feilskrevet enn enkle, og tommelstasjoner er mer sannsynlig å bli stjålet (misappropriert) enn bladservere i et serverskap. Iboende risiko eksisterer uavhengig av revisjonen og kan oppstå på grunn av virksomhetens art.
i trinnet «Få En Forståelse Av Den Eksisterende Internkontrollstrukturen» må it-revisor identifisere fem andre områder/ elementer:
- kontrollmiljø
- kontrollprosedyrer
- Deteksjonsrisikovurdering
- Kontrollrisikovurdering
- Likestille total risiko
Når IT-revisor har «Samlet Informasjon» og «Forstår Kontrollen», er DE klare til å begynne planleggingen, eller valg av områder, som skal revideres. Husk en av de viktigste bitene av informasjon som du trenger i de første trinnene er en gjeldende Business Impact Analysis (BIA), for å hjelpe deg i å velge programmet som støtter de mest kritiske eller sensitive forretningsfunksjoner.
Mål for EN IT-revisjon
OFTE KONSENTRERER it-revisjonsmålene seg om å underbygge at de interne kontrollene eksisterer og fungerer som forventet for å minimere forretningsrisiko. Disse revisjonsmålene inkluderer å sikre overholdelse av juridiske og regulatoriske krav, samt konfidensialitet, integritet og tilgjengelighet (CIA – nei ikke det føderale byrået, men informasjonssikkerhet) av informasjonssystemer og data.
IT audit strategies
Det er to områder å snakke om her, den første er om å gjøre compliance eller materielle testing og den andre er «Hvordan går jeg om å få bevis for å tillate meg å revidere programmet og gjøre min rapport til ledelsen?»Så hva er forskjellen mellom compliance og substantial testing? Compliance testing samler bevis for å teste for å se om en organisasjon følger sine kontrollprosedyrer. På den annen side er substantiell testing å samle bevis for å evaluere integriteten til individuelle data og annen informasjon. For eksempel kan samsvarstesting av kontroller beskrives med følgende eksempel. En organisasjon har en kontrollprosedyre som sier at alle programendringer må gå gjennom endringskontroll. SOM IT-revisor kan du ta den nåværende kjørekonfigurasjonen til en ruter, samt en kopi av -1-generasjonen av konfigurasjonsfilen for den samme ruteren, kjør en fil sammenlign for å se hva forskjellene var; og ta deretter disse forskjellene og se etter støtte for endringskontrolldokumentasjon. Ikke bli overrasket over å finne at nettverksadministratorer, når de bare re-sekvenseringsregler, glemmer å sette endringen gjennom endringskontroll. For substantiv testing, la oss si at en organisasjon har policy / prosedyre om sikkerhetskopier på ekstern lagringssted som inkluderer 3 generasjoner (bestefar, far, sønn). EN it-revisor ville gjøre en fysisk oversikt over båndene på ekstern lagringssted og sammenligne den beholdningen til organisasjonens beholdning, så vel som å se for å sikre at alle 3 generasjoner var til stede.
det andre området omhandler «Hvordan går jeg om å få bevis for å tillate meg å revidere programmet og gjøre min rapport til ledelsen?»Det burde ikke komme som noen overraskelse at du trenger å:
- Gjennomgå it organisasjonsstruktur
- Gjennomgå it-retningslinjer og prosedyrer
- Gjennomgå IT-standarder
- Gjennomgå IT-dokumentasjon
- Gjennomgå organisasjonens BIA
- Intervju riktig personell
- Observer prosessene og ansattes ytelse
- Undersøkelse, som inkorporerer ved nødvendighet testing av kontroller, og inkluderer derfor resultatene av testene.
som ytterligere kommentarer til innhenting av bevis, kan observasjon av hva en person faktisk gjør kontra hva de er ment å gjøre, gi it-auditøren verdifulle bevis når det gjelder å kontrollere implementering og forståelse av brukeren. Også utføre en walk-through kan gi verdifull innsikt i hvordan en bestemt funksjon blir utført.
Søknad vs. generelle kontroller
Generelle kontroller gjelder for alle områder i organisasjonen, inkludert IT-infrastruktur og støttetjenester. Noen eksempler på generelle kontroller er:
Applikasjonskontroller refererer til transaksjoner og data knyttet til hvert databasert applikasjonssystem; derfor, de er spesifikke for hver applikasjon. Formålet med applikasjonskontrollene er å sikre fullstendigheten og nøyaktigheten av postene og gyldigheten av oppføringene som er gjort til dem. Programkontroller er kontroller OVER IPO (input, processing, output) funksjoner, og inkluderer metoder for å sikre at:
- bare fullstendige, nøyaktige og gyldige data blir oppgitt og oppdatert i et applikasjonssystem
- Behandling oppnår den utformede og korrekte oppgaven
- behandlingsresultatene oppfyller forventningene
- Data opprettholdes
som IT-revisor bør oppgavene dine når du utfører en programkontrollrevisjon inkludere:
- Identifisere de betydelige applikasjonskomponentene; flyten av transaksjoner gjennom applikasjonen (systemet); og for å få en detaljert forståelse av søknaden ved å gjennomgå all tilgjengelig dokumentasjon og intervjue riktig personell, for eksempel systemeier, dataeier, dataansvarlig og systemadministrator.
- Identifisere styrken på applikasjonskontrollen og evaluere virkningen, hvis noen, av svakheter du finner i applikasjonskontrollene
- Utvikle en teststrategi
- Teste kontrollene for å sikre deres funksjonalitet og effektivitet
- Evaluere testresultatene dine og eventuelle andre revisjonsbevis for å avgjøre om kontrollmålene ble oppnådd
- Evaluere applikasjonen mot ledelsens mål for systemet for å sikre effektivitet og effektivitet.
IT audit control reviews
ETTER å ha samlet alle bevisene VIL it-revisor gjennomgå det for å avgjøre om de reviderte operasjonene er godt kontrollert og effektive. Nå er dette hvor din subjektive vurdering og erfaring kommer inn i bildet. For eksempel kan du finne en svakhet i ett område som kompenseres av en veldig sterk kontroll i et annet tilstøtende område. DET er DITT ansvar som it-revisor å rapportere begge disse funnene i revisjonsrapporten.
revisjonsleveringen
så hva er inkludert i revisjonsdokumentasjonen og hva MÅ it-revisor gjøre når revisjonen er ferdig. Her er vaskerilisten over hva som skal inkluderes i revisjonsdokumentasjonen din:
- Planlegging og forberedelse av revisjonens omfang og mål
- Beskrivelse og/eller gjennomganger på det omfattede revisjonsområdet
- Revisjonsprogram
- utførte revisjonstrinn og innhentet revisjonsbevis
- Hvorvidt tjenester fra andre revisorer og eksperter ble brukt og deres bidrag
- Revisjonsfunn, konklusjoner og anbefalinger
- Revisjonsdokumentasjon forhold til dokumentidentifikasjon og datoer (din kryssreferanse av bevis til revisjonstrinn)
- en kopi av rapporten utstedt Som Følge av revisjonsarbeidet
- bevis på tilsynet gjennomgå
når du kommuniserer revisjonsresultatene til organisasjonen, vil det vanligvis gjøres ved et avslutningsintervju hvor du får mulighet til å diskutere med ledelsen eventuelle funn og anbefalinger. Du må være helt sikker på:
- fakta som presenteres i rapporten er riktige
- anbefalingene er realistiske og kostnadseffektive, eller alternativer har blitt forhandlet med organisasjonens ledelse
- de anbefalte implementeringsdatoene vil bli avtalt for anbefalingene du har i rapporten.presentasjonen din ved dette avslutningsintervjuet vil inneholde et sammendrag på høyt nivå (Som Sgt. Friday bruker å si, bare fakta, vær så snill, bare fakta). Og uansett grunn, et bilde er verdt tusen ord så Gjøre Noen PowerPoint lysbilder eller grafikk i rapporten.
revisjonsrapporten din skal være strukturert slik at den inkluderer:
- En introduksjon (sammendrag)
- funnene er i en egen seksjon og gruppert etter tiltenkt mottaker
- din generelle konklusjon og mening om tilstrekkeligheten av kontroller undersøkt og eventuelle identifiserte potensielle risikoer
- eventuelle forbehold eller kvalifikasjoner med hensyn til revisjonen
- Detaljerte funn og anbefalinger
Til Slutt er det noen andre hensyn som du må være oppmerksom på når du forbereder og presenterer sluttrapporten. Hvem er publikum? Hvis rapporten går til revisjonsutvalget, trenger de kanskje ikke å se minutia som går inn i den lokale forretningsenhetsrapporten. Du må identifisere organisatoriske, faglige og statlige kriterier som BRUKES SOM GAO-Yellow Book, CobiT ELLER NIST SP 800-53. Rapporten vil ønske å være betimelig, slik som å oppmuntre rask korrigerende tiltak.