logoRevisjon og regnskap

Logg på for å laste ned PDF
Revisjon

Senior rådgiver

Mazhar B. Ahmad

Information Risk Management i KPMG

De tre kjerneområdene innen IT-revisjon

Formålet med denne artikkelen er å forklare hvorfor det er tre områder som bør prioriteres i en IT-revisjon, uavhengig av hvor omfattende revisjonen er.

IT-revisjon er som finansiell revisjon avhengig av en risikovurdering og en prioritering av revisjonsområder. Det er essensielt å prioritere de IT-områder som påvirker vesentlige deler av virksomhetens finansielle operasjoner da IT kun er et hjelpemiddel/verktøy for å implementere og oppnå virksomhetens forretningsstrategier.

Formålet med IT-revisjon er å:

  • Dokumentere forståelse (risiko, svakheter og styrker) for etablert internkontroll

  • Avdekke om virksomheten har etablert betryggende sikkerhet for å ivareta forretningsrisiko, dvs. at det er etablert hensiktsmessige og tilfredsstillende kontroller (sett i forhold til ønskede eller fastsatte kontrollmål). Dette oppnås ved å vurdere og å teste samsvar med relevante lover, regler og standarder. I internrevisjonssammenheng vurderer man også samsvar (compliance) i forhold til produktivitets- og effektivitetshensyn («beste praksis») på området.

  • Rapportere forhold som har betydning for avleggelsen av endelig regnskap, eventuelt korrigerende tiltak som bør iverksettes for å oppnå betryggende sikkerhet på området.

Tre hovedkategorier av kontroller

  • Kontroll 1) kontroller på selskaps-/konsernnivå som relaterer seg til IT-virksomhetsstyring og IT-kontrollmiljø

  • Kontroll 2) applikasjonskontroller

  • Kontroll 3) generelle IT-kontroller

Disse kontrollene henger sammen på følgende vis:

Jeg har først og fremst tatt for meg de generelle IT-kontroller (og områdene applikasjonsutvikling/endringsadministrasjon, IT-drift og tilgangsadministrasjon) i det etterfølgende, men jeg berører også temaene applikasjonskontroller og IT-virksomhetsstyring/-kontrollmiljø. Jeg har valgt å prioritere de generelle IT-kontrollene fordi denne delen av internkontrollen vanskeligst lar seg relatere til konkrete feil og fordi disse kontrollene understøtter alle andre kontroller som er etablert på IT-området.

På grunn av omfang og innvirkning på den finansielle rapporteringen og andre nøkkelopplysninger, er en vurdering av de tre nevnte kontrollkategoriene en avgjørende del av en helhetlig revisjon (forutsatt at IT-miljøet er vesentlig), hvor IT-revisjon er en integrert del av den finansielle revisjonen.

Klassifisering i SOX

Følgende klassifisering er fremsatt i Section 404 i Sarbanes Oxley Act (SOX) i forhold til definisjonen av tre kategorier av kontroller på IT-området:

  1. Kontroll 1) IT-virksomhetsstyring og IT-kontrollmiljøOmråder som etikk og holdninger, kompetanse, eierstyring og selskapsledelse, ansvarsforhold og organisasjonsstruktur, visjon og misjon, kjerneverdier, forretningsmessige mål og «whistle-blowing».

  2. Kontroll 2) ApplikasjonskontrollerDekker både ERP-systemer og relevante forsystemer som er i scope.

  3. Kontroll 3) Generelle IT-kontroller (ofte forkortet GCC) Dekker områdene applikasjonsutvikling/endringsadministrasjon, IT-drift og tilgangsadministrasjon.

Kontroll 1) kontroller på selskaps-/konsernnivå som relaterer seg til IT-virksomhetsstyring og IT-kontrollmiljø

Dette er den logiske veien å starte for å evaluere etablert internkontroll i en virksomhet (en «top-down» approach), da den kan ha en gjennomgripende effekt på organisasjonen som en helhet. Dette inkluderer en gjennomgang av de fem COSO internkontroll-elementene:

  • Control Environment

  • Risk Assessment

  • Information and Communication

  • Control Activities

  • Monitoring

For å bygge forståelse for den etablerte internkontrollen, må man ta utgangspunkt i IT-kontrollmiljøet og IT-virksomhetsstyringen som overstyrer og gjennomsyrer organisasjonen før man går videre til Kontroll 2 og Kontroll 3.

Kontroll 2) applikasjonskontroller

Sikringen av forretningsprosesser, tilganger og arbeidsdeling inne i en applikasjon ivaretas ofte av applikasjonskontroller. Applikasjonskontroller kan ofte relateres til enkelte konti i regnskapet, avhengig av hvilke funksjoner (forretningsprosesser) de ivaretar. Et varelagersystem kan for eksempel påvirke varebeholdningen i balansen og beholdningsendringer i resultatregnskapet, mens et salgssystem kan påvirke salgsinntekter i resultatregnskapet og kundefordringer i balansen etc. Da de generelle IT-kontrollene også ivaretar sikkerheten rundt en applikasjon, herunder relevante databaser, vil det være en sammenheng mellom applikasjonskontroller og generelle IT-kontroller som vist nederst på siden.

Kvaliteten på de generelle IT-kontrollene har derfor betydning for kvaliteten på applikasjonskontrollene.

Kontroll 3) generelle IT-kontroller

De generelle IT-kontroller eller enklere sagt de kontrollene man har på IT-området - funksjoner som ivaretas helt eller delvis av en IT-avdeling/IT-ansvarlig, helt eller delvis av en outsourcingsleverandør eller i samarbeid med applikasjons-/informasjons-/prosess-/systemeiere) - utgjør en vesentlig del. Dette fordi disse områdene sikrer og understøtter fullstendighet, rettidighet, nøyaktighet, pålitelighet og sporbarhet av forretningstransaksjoner, øvrige IT-leveranser (batch-jobber) og sikkerheten rundt informasjonssystemer (operativsystemer, databaser, verktøy, programmer, applikasjoner, IT-systemer mv). Svakheter i de generelle IT-kontrollene kan ofte påvirke hele regnskapet.

Teorien sier at hvis det er vesentlige negative funn innen de generelle kontrollene på IT-området, så kan man forkaste den informasjon som er produsert av IT-systemene fordi alle revisjonsmålsetninger blir påvirket. Når input til systemet er eller kan bli beheftet med feil så vil sluttresultatet, output, også bli feil. Dette gjelder også sekundær informasjon, som igjen kan påvirke beslutningsdokumenter, kalkyler/beregninger i Excel mv, noteopplysninger etc. som ligger på fellesområder. Dette fordi verken fullstendighet, rettidighet, nøyaktighet, sporbarhet eller pålitelighet er ivaretatt. Ofte har man imidlertid kompletterende eller kompenserende løsninger/kontroller på plass for å redusere risikoen for feilinformasjon. Dette kan være manuelle avstemminger og kontroller, sjekk mot eksterne datakilder, stikkprøver mv.

ISO 17799

ISO 17799 er retningslinjer, «beste praksis», innen sikkerhetsadministrasjon og -ledelse. Standarden gir konkrete anbefalinger for informasjonssikkerhetsarbeid i virksomheter.

Standarden dekker blant annet følgende områder:

  • Sikkerhetspolitikk

  • Sikkerhetsarbeid i organisasjonen

  • Klassifisering og sikring av aktiva

  • Personellsikkerhet

  • Fysisk og miljømessig sikkerhet

  • Kommunikasjons- og driftsadministrasjon

  • Tilgangskontroll

  • Systemutvikling og vedlikehold

  • Kontinuitetsplanlegging

  • Overensstemmelse

Cobit 4.0

Rammeverket Cobit 4.0 omfatter virksomhetsstyring og kontroll på IT-området, og er utarbeidet på bakgrunn av «beste praksis». Rammeverket er forretnings- og prosessorientert, og vurderer både kvalitative og operasjonelle aspekter ved bruk av informasjonsteknologi i virksomheten. Rammeverket harmoniserer dessuten med andre de facto industristandarder.

 Rammeverket inndeler IT-området inn i 4 områder: Planlegging og Organisering, Anskaffelse og Implementering, Leveranse og Støtte og Overvåkning.

Capability Maturity Model (CMM)

På no.Wikipedia.org (den frie encyklopedi) kan man lese følgende om CMM: Capability Maturity Model eller CMM er en metode for å evaluere hvor moden en organisasjon er på en skala fra 1 til 5. Metoden ble utviklet ved Software Engineering Institute ved Carnegie Mellon University. Den har vært i vid bruk innenfor fagfeltet programvareutvikling siden den ble utgitt på 1980-tallet.

Nivåer

CMM har fem nivåer på modenhet, fra 1 til 5.

  • Initiell: Utviklingsprosessen er ad hoc og til tider kaotisk. Det er vanskelig å estimere omfang av prosjekter, da ingen data er kjent.

  • Repeterbar: Enkle prosjektstyringsprosesser er i bruk for å holde styr på tidsplaner, kostnader og produktets funksjonalitet.

  • Definert: Det eksisterer en definert standardprosess i organisasjonen, både for utvikling og prosjektstyring, og prosessene er innbyrdes konsistente.

  • Styrt: Organisasjonen setter kvalitetsmål både for produkter og prosesser. Prosessen er i stor grad forutsigbar.

  • Optimalisert: Organisasjonen måler og søker kontinuerlig å forbedre prosessen.

Ovenstående informasjon er hentet fra: no.wikipedia.org/wiki/Capability_Maturity_Model

Det er verdt å merke seg at nivå 1 ofte kalles «innfallsmetoden», og det er her de fleste systemutviklingsorganisasjoner ligger. På nivå 5 utstedes det en sertifisering av «Software Engineering Institute» (SEI).

Rammeverket ITIL

Rammeverket ITIL kan være til stor nytte når man skal effektivisere flyt og prosesser, organisere en IT-avdeling. Dette kan gjelde arbeidsdeling, arbeidsoppgaver og eskaleringsnivåer for support-, drifts-, og utviklingsavdeling. Et eksempel på dette kan være å «løfte» en kritisk og prioritert hendelse som er innmeldt av bruker/oppdaget av IT-avdelingen, til en endringsanmodning, og til løsningen ender opp som en daglig driftsoppgave.

ITIL beskriver følgende prosesser innen IT-drift og -support:

  • Hendelseshåndtering

  • Problemhåndtering

  • Endringshåndtering

  • Konfigurasjonshåndtering

  • Utrulling

  • Support

Rammeverket beskriver også følgende IT-leveranser knyttet til:

  • Tilgjengelighetsledelse

  • Kapasitetsledelse

  • Kontinuitetsledelse

  • Service-level ledelse

  • Finansiell ledelse