Även om datormiljön påverkar revisionen så är de allmänna revisionsmålen desamma. Det är organisationen kring och användningssättet av datorn som är väsentligt för den interna kontrollen.

Behörighetssystem och rutiner för säkerhetskopiering bör särskilt uppmärksammas av revisorerna konstaterar Anders Malmeby och Ingemar Glans vid Bohlins Revisionsbyrå i Stockholm. De pekar också på att bristen på säkerhetskopior har medfört så stora ekonomiska konsekvenser att företag tvingats gå i konkurs.

Företagen datoriserar sina verksamheter i en allt större utsträckning, detta förändrar dock inte de allmänna revisionsmålen. Inriktningen av och metoderna för granskningen måste däremot successivt förändras så att de motsvarar god revisionssed. Vi avser i denna artikel behandla problemställningar som revisorerna träffar på vid revision i datormiljö och som bör beaktas vid planering och genomförande av granskningen. Tyngdpunkten i artikeln ligger på granskning av administrativa kontroller.

Sambandet mellan olika moment och åtgärder i revisionsprocessen kan beskrivas med följande modell som ansluter till FARs synsätt (se figur 1).

Figur 1. Modell över sambandet mellan olika moment i revisionsprocessen

REVISIONSMÅL

Redovisningsrevision

Förvaltningsrevision

Planering

– förberedande informationsinsamling

– riskanalys

– prioritering

– totalplanering med hänsyn till väsentlighet och risk

Åtgärdsbank

Val av granskningsmetoder

– intern kontroll

– substans granskning

Löpande år

Bokslut och Årsredovisning

Planering för nästa år

REVISIONSBERÄTTELSE

I en inledande planeringsfas inhämtas viss grundinformation avseende klientens allmänna organisation, redovisningssystem samt övriga system.

Är redovisningssystem etc datorbaserade bör övergripande uppgifter om ADB-organisation, maskinkonfiguration m m inhämtas inför totalplaneringen d v s planeringen av granskningens inriktning och omfattning.

Då totalplanering gjorts under beaktande av principerna om väsentlighet och risk vidtar den detaljerade planeringen och granskningsmetoder väljs från en åtgärdsbank.

REVISIONSMODELLENS ÅTGÄRDSBANK

För att uppnå revisionsmålet på ett ändamålsenligt och effektivt sätt väljer revisorn en lämplig fördelning av granskningsarbetet mellan intern kontrollgranskning å ena sidan och substansgranskning å andra sidan.

Granskningen av intern kontroll kan delas in i administrativa kontroller och redovisningskontroller. Dessa diskuteras översiktligt nedan, vidare behandlas användningen av datorstödd revision.

Administrativa kontroller

De administrativa kontrollerna avser miljön runt tillämpningssystemen och underindelas vanligen i områdena upphandling, organisation, systemutveckling och drift. Väsentliga brister inom dessa områden kan sätta den interna kontrollstruktur revisorn avser att förlita sig på helt ur spel.

Området anskaffning av maskin- och programvara samt tjänster är fyllt av många fallgropar. Dessa aktualiseras särskilt för mindre och medelstora företag inom vilka det ofta saknas specialkunskap avseende ADB-upphandling. Vi kan som revisorer bidra med mycken hjälp till klienten om vi kommer in i rätt tid.

Vid granskning och rådgivning i samband med upphandling beaktas krav avseende intern kontroll och säkerhet samt externa krav som exempelvis bokföringslagens regler. I större företag granskas metoderna för anskaffning av utrustning, programvara och tjänster. Denna granskning är ofta väl motiverad ur förvaltningsrevisionell synvinkel.

Organisationsavsnittet omfattar granskning av ADB-verksamhetens organisation samt ansvars- och arbetsfördelning mellan företagets ledning, användare och ADB-funktion. Systemutveckling avser metoder och rutiner vid utveckling och underhåll av tillämpningssystem. Området drift innefattar bl a granskning av operativ-, databas- och behörighetssystem samt säkerhet.

Redovisningskontroller

Granskning av redovisningskontroller avser klientens tillämpningssystem med tillhörande systemdokumentation. Granskningen utförs system för system enligt en prioritering som beaktar principerna om väsentlighet och risk. Genom utredning, verifiering och bedömning av programmerade och manuella kontroller bildar revisorn sig en uppfattning om huruvida övergripande kontrollsyften uppfylls (godkännande, fullständighet, riktighet och sammanhängande verifieringskedja).

Åtgärdsbank – Datorstödd revision

Även om bruket av ADB-teknik många gånger kan skapa speciella problem avseende intern kontroll och sårbarhet för företagen medger tekniken också ökade möjligheter till granskning. Datorstödd revision, d v s användning av dator i revisionen, blir möjlig.

Datorstödd revision är ett hjälpmedel som kan användas vid substansgranskning och granskning av intern kontroll (se figur 2).

Figur 2 Datorstödd revision används vid substansgranskning och granskning av intern kontroll

ÅTGÄRDSBANK

GRANSKNING AV INTERN KONTROLL

* Före installation (upphandling)

* Organisation

* Systemutveckling

* Drift

DATORSTÖDD REVISION

Redovisningskontroller

* Rutinerade kontroller

* Dokumentation

SUBSTANSGRANSKNING

Vid granskning av den interna kontrollen används datorstödd revision för att verifiera:

– att dataregister innehåller giltiga koder enligt systemdokumentationen

– att de programmerade kontroller man avser förlita sig på varit i drift

– att väsentliga behandlingsregler fungerar på avsett sätt

– att olika former av rapportering är korrekta.

För substansgranskningen kan revisorn genom olika typer av registeranalyser:

– göra kontrollsummeringar

– göra egna beräkningar av olika slag

– selektera ut poster efter olika kriterier

– strukturera/sortera registerinnehåll på ett för granskningen mer ändamålsenligt sätt

– matcha olika register mot varandra och därigenom sammanställa information

– göra saldobrevsförfrågningar

– göra stickprovsurval.

Speciella programpaket kan även användas för utvärdering och design av stickprov.

Analytisk granskning kan underlättas genom att:

– flerårsstatistik och nyckeltal hanteras med hjälp av programvara för simulering/kalkylering

– regressionsanalys används för att studera samband mellan olika variabler.

Som programvara för registeranalyser används, beroende på tillgång och tillämpning:

– Speciella standardpaket för revisionsanalyser

– Generella rapportgeneratorer

– Specialskrivna program i lämpligt programspråk

– Hjälpprogram

– Applikationsbundna rapportgeneratorer.

Många gånger kan en kombination av rapportgenerator och egenutvecklat program vara effektiv. För regressionsanalyser finns programpaket utvecklade speciellt för revisionstillämpningar, vidare kan generella standardpaket för statistiska analyser användas.

Datorstödd revision – god revisionssed

Datorstödd revision kan, där metoden är lämplig, innebära stora fördelar i revisionsprocessen. Granskningen effektiviseras, totalgranskning av aktuellt material kan ske, manuellt uppföljningsarbete inriktas på väsentligheter etc. Ofta är datorstödd revision enda sättet att på ett tillfredsställande sätt granska stora transaktionsvolymer eller komplicerade system. Datorstödd revision får betraktas som en förutsättning för revision enligt god revisionssed på många uppdrag.

DATORMILJÖER

Vid diskussion avseende intern kontrollgranskning i datormiljö anser vi att det ofta är meningsfullt med en uppdelning efter stor-, mini- och mikrodatormiljö. Den interna kontrollen skiljer sig många gånger väsentligt mellan de tre miljötyperna. Att definiera dessa skillnader i tekniska termer eller kostnadsintervaller ställer sig svårt, inte minst mot bakgrund av den snabba tekniska utvecklingen. Sådana definitioner är dessutom mindre intressanta i revisionssammanhang då det är organisationen kring, och användningssättet av datorn, som konstituerar väsentliga egenskaper från intern kontrollsynpunkt.

STORDATORMILJÖ

Databehandling med hjälp av stordatorer administreras i regel av speciella ADB-avdelningar inom företagen. Beroende på datorns storlek, databehandlingens omfattning, personalens utbildning och antal kan arbetsfördelningen mellan olika personalkategorier inom företags ADB-avdelningar variera starkt. Vid sin bedömning av den interna kontrollen måste därför revisorn sätta sig in i hur arbetsfördelningen fungerar såväl inom ADB-avdelningen som mellan denna och företagets övriga avdelningar. Dessa mera allmänna granskningsmoment lämnar vi dock i stort sett därhän i denna artikel vad gäller stordatormiljö då problematiken bör vara väl känd för de flesta revisorer. Vi koncentrerar oss i stället på de problem som basprogramvarorna kan ge upphov till och behandlar nedan respektive huvudgrupp var för sig. Vissa av de synpunkter och kommentarer som framförs under respektive rubrik är även giltiga i mini- och mikrodatormiljö.

Ett av de förhållanden som skiljer stordatormiljön från övriga miljöer är den i många stycken långt drivna specialiseringen inom ADB-avdelningarna. En specialisering som från intern kontrollsynpunkt är positiv i så måtto att i många fall ingen längre har tillräckliga detaljkunskaper för att kunna våga manipulera tillämpningssystemen.

Specialiseringens negativa sida är att företagen i allt högre utsträckning blir beroende av ett relativt litet antal ADB-tekniker som i små grupper eller rent av på individnivå behärskar väsentliga delar av ADB-tekniken. Ett förhållande som ökar företagens sårbarhet.

Operativsystem (OS)

En av förutsättningarna för att kunna nyttja en dator är att det finns ett operativsystem för administration av datorns interna arbete inklusive kommunikationen med periferienheter och applikationssystem. OS utvecklas och underhålls nära nog undantagslöst av det företag som tillverkat datorn. Detta innebär att företagen i sin egen ADB-utveckling i stor utsträckning styrs av respektive leverantörs vidareutveckling av den grundläggande programvaran.

Datorleverantören tillhandahåller tillsammans med datorn en ”grundversion” av OS. Denna underhålls av leverantören genom att denne skickar ut magnetiska media innehållande ändringar. Med dessa följer även en verbal beskrivning av vad respektive förändring innebär. Kundens ADB-avdelning har sedan att efter egen bedömning välja ut de ändringar som är aktuella för installationen eftersom vissa uppdateringar kan avse delar av OS som inte används av alla företag. Själva utbytet av instruktioner i OS genomförs med hjälp av en speciell hjälpprogramvara.

När datorleverantören anser det vara nödvändigt levererar denne en helt ny ”grundversion” av OS. Denna ersätter då tidigare version med tillhörande förändringar. En tid efter det att den nya versionen har levererats till kunderna upphör vanligen leverantören att ens försöka reda ut problem som har med den äldre versionen att göra.

Förfarandet innebär att leverantörerna mer eller mindre tvingar sina kunder att följa med i utvecklingen.

För att upprätthålla en god intern kontroll över underhållet av OS krävs att ADB-ledningen följer upp ADB-teknikernas arbete så:

– att endast av leverantören initierade ändringar tas i produktion

– att endast de ändringar tas i produktion som, med hänsyn till vid systemgenereringen satta parametrar, kan anses ge positiv effekt

– att alla förändringar i OS har dokumenterats såväl genom anteckningar som genom av datorn producerade acceptlistor etc

– att det alltid finns förutsättningar för att vid behov kunna gå tillbaka till det OS som gällde före ändring, vilket kan bli aktuellt om någon/några ändringar skulle vålla problem.

Revisorn bör i sitt arbete granska beslutsprocessen kring underhållet av OS samt bedöma kvaliteten på den arkiverade dokumentationen.

Databashanteringssystem (DBHS)

Utvecklingen av dagens databasteknik skall ses mot bakgrund av de krav från användarnas sida som kom under 1970-talet:

– att informationen skall vara tillgänglig direkt vid arbetsplatsen i det ögonblick den behövs

– att informationen skall vara aktuell med hänsyn taget till de senaste data som användarna registrerat

– att en och samma uppgift endast skall behöva registreras en gång men kunna användas inom flera olika tillämpningsområden

– att tillägg av ny informationstyp skall kunna göras utan att detta direkt påverkar de tillämpningsprogram som redan är i produktion

– att skapa möjligheter för användarna att kunna undersöka samband mellan data och den vägen tillgodose oförutsedda informationsbehov.

Ovanstående krav var helt omöjliga att tillfredsställa med då kända registerhanteringsmetoder. Ett nykonstruktionsarbete blev därför nödvändigt. Resultatet av detta har dels medfört förändringar i metoderna att bygga tillämpningssystem och program, dels givit upphov till de så kallade databashanteringssystemen. Dessa system handlägger läsning och uppdatering av databasen för ett i princip obegränsat antal tillämpningsprogram.

Starkt förenklat går hanteringen till så att applikationsprogrammet gör ett anrop till DBHS. Detta system söker sedan via en logisk databeskrivning fram var den önskade informationen rent fysiskt finns lagrad på datorns externminne. DBHS returnerar därefter den önskade informationen tillsammans med en statuskod till det program som gjorde anropet. Statuskoden anger om uppdraget har kunnat utföras korrekt eller inte.

I samband med att ett tillämpningsprogram gör ett anrop kan DBHS kontrollera att det program som begär informationen är behörigt att läsa alternativt ändra i databasen.

Databastekniken medför avsevärda förändringar vad gäller hantering av information. Beroende på ofullständiga kunskaper uppstår brister hos ansvariga chefer om skillnaden mellan databasorienterade informationssystem och konventionella d:o med register anpassade till det ”egna” behovet. Detta beroende på dels databasteknikens komplexitet, dels den ökande integrationen tillämpningssystemen emellan som tekniken erbjuder.

Riskerna är som vi ser det:

– att de som utvecklar tillämpningssystemen inte längre behärskar tekniken att konstruera de register som behövs vilket försvårar felsökning etc. Sårbarheten har därmed ökat.

– att det tillkommit en ny grupp av experter (databasadministratörer) inom ADB-avdelningen som har till uppgift att underhålla DBHS samt konstruera och underhålla databaser. Företagen har därmed i sin ADB-hantering mer än tidigare blivit beroende av ett fåtal datatekniker.

– att felaktiga data snabbt kan spridas inom olika delar av företaget vilket kan få stora återverkningar.

– att ett fel i ett tillämpningsprogram eller DBHS så småningom kan göra att databasen blir helt obrukbar för användning inom ett eller flera tillämpningsområden.

– att koncentrationen av alltmer av företagets information till en eller ett fåtal databaser ökar sårbarheten.

Grundläggande principer för intern kontroll är tillämpliga även för databasorienterade system. Revisorn bör därför som tidigare i sitt arbete granska de administrativa kontrollerna inom företaget. De förändrade förutsättningarna för den interna kontrollen som uppstår i en databasmiljö, jämfört med vad som gäller i en miljö med konventionella system, kräver som vi ser det några kompletterande moment. Dessa är bland annat granskning av:

– olika intressenters behörighet vad gäller tillgång till produktionsdatabaserna och DBHS.

– databasadministratörsfunktionens arbetsuppgifter inom områdena:

* underhåll av databaskatalogen inklusive dokumentation av vidtagna åtgärder

* anskaffning och underhåll av databashanteringssystem inklusive dokumentation

* rutiner för reorganisation och rekonstruktion av databaser

* underhåll av sekretessystem.

* funktioner inom ramarna för DBHS såsom

* transaktionsloggning

* återstarts- och rekonstruktionsrutiner

* driftstatistikrutiner (via dessa ska det gå att verifiera att uppställda behörighetsregler följs).

Utöver ovanstående mera generella granskningsmoment bör revisorn även överväga att inom ramen för sin granskning av ett tillämpningssystem via kontrollbearbetningar verifiera såväl detta system som DBHS.

Hjälpprogram

Utöver de mera grundläggande programvarorna såsom operativsystem, databashanteringssystem etc brukar datorleverantören även tillhandahålla ett antal s k hjälpprogram. Ett av dessa behövs till exempel för att lägga in de ändringar i OS som datorleverantören distribuerar.

Inom gruppen hjälpprogram inryms program med vars hjälp det exempelvis går att gå direkt in i en databas och ändra vilka uppgifter som helst. Önskvärt vore naturligtvis att det överhuvudtaget inte fanns något behov av sådana programvaror. Rent praktiskt kan det dock uppstå situationer där det på grund av fel i applikations- eller standardprogramvaran inte finns någon annan lösning på problemet än att gå in i databaserna och rätta med hjälp av en generell programvara av denna typ.

Vi anser att vid de tillfällen när rättning i register/databaser sker med hjälpprogram ska detta dokumenteras minutiöst och ansvariga chefer löpande följa upp vilka ändringar som gjorts. Som ett av underlagen för denna granskning används lämpligen driftstatistiken i vilken det bör vara möjligt att se vilka hjälpprogram som använts och när detta har skett. Alla inblandade bör dock vara medvetna om att en skicklig ADB-tekniker kan manipulera OS och på så sätt undvika loggningen för driftstatistiken.

Med hänvisning till det ovan sagda anser vi att tillgången till hjälpprogrammen bör begränsas till ADB-teknikfunktionen. Detta bland annat för att ingen som mer eller mindre direkt arbetar med tillämpningssystemen ska få tillgång till nämnda verktyg och på så sätt kringgå den interna kontrollen.

Revisorn bör i sitt arbete förhöra sig om i vilken omfattning de generella hjälpprogrammen används samt sätta sig in i hur den interna kontrollen i detta stycke är uppbyggd.

Behörighetskontrollsystem

I början av sextiotalet när datorerna började bli mera allmänna ute på företagen var det inte många som ägnade datasäkerhet och behörighetskontrollproblematiken en tanke. I och med att det med hjälp av de tekniska landvinningarna blev möjligt för användarna att bearbeta data via terminaler skärptes kraven något. Detta inte p g a att det ansågs nödvändigt med några restriktioner vad gällde tillgången till information, utan mera för kontroll av att den som förbrukade datorkraft också var behörig att ådraga företaget/avdelningen kostnader.

Numera finns sofistikerade generella behörighetskontrollsystem att tillgå på marknaden. Dessutom finns det som nämns i avsnittet databashanteringssystem även behörighetskontrollfunktioner inbyggda i denna typ av basprogramvaror. Dessa är dock enbart avsedda för skydd av databaser etc, medan det via de generella systemen går att skydda alla typer av register. Sådana system kan därför sägas ligga som en ”överrock” för skydd mot obehörigt utnyttjande av register, tillämpningsprogram, systemprogramvaror och datorkraft.

Enligt vår mening bör ett väl fungerande behörighetskontrollsystem bland annat:

– vara lätt att installera och inte kräva förändringar i OS

– vara användarvänligt i så måtto att det ska vara enkelt att följa upp respektive användares behörighetsprofil

– utgöra ett skydd oavsett om utnyttjandet av datorn eller den lagrade informationen kan ske via satsvis arbetande system eller från någon typ av terminal

– kunna identifiera varje enskild användare och kontrollera vilka bearbetningar denne är behörig att utföra. Kontrollen skall vid behov även kunna avse enskilda transaktionstyper inom ramarna för ett tillämpningssystem. I begreppet användare inkluderas systemmän/programmerare, driftpersonal, systemprogrammerare etc

– tillåta att användaren vid behov på eget initiativ kan byta ut det passerord med vars hjälp användaren bevisar för systemet att det är den som har angiven identitet som begär tillträde till datorn

– tvinga användarna att med viss minimifrekvens byta ut sina passerord eftersom det finns en risk för att passerord kan bli kända även av andra än ägaren. Byts passerorden ut då och då förhindras att någon under en längre tid obehörigen kan utnyttja annans identitet

– utestänga den användare från tillgång till datorn som efter exempelvis tre försök inte kunnat ange rätt passerord

– tillåta att bearbetning av känsliga rutiner begränsas till vissa terminaler

– automatiskt kunna logga ur en användare som varit inne i systemet mer än X minuter utan att under denna tid ha utnyttjat förbindelsen

– innehålla rutiner för driftstatistik via vilken det bland annat är möjligt att följa upp användarnas bearbetning av olika rutiner

– kryptera eller på annat sätt skydda passerorden så att ingen via utlistning av behörighetstabeller etc kan avslöja dem.

Underhållet av behörighetskontrollsystemet bör skötas inom ADB-teknikfunktionen. Tilläggas bör i detta sammanhang att de personer som underhåller OS och övriga basprogramvaror som regel har tillräckliga kunskaper för att kringgå behörighetssystemets kontroller.

Revisorn bör som ett led i revisionen bland annat granska:

– att organisationen kring underhållet av behörighetssystemet är lämplig från intern kontrollsynpunkt.

– att användarnas tillgång till tillämpningssystem och register är så fördelade att god intern kontroll kan uppnås. Jämförelse bör även göras mellan tilldelad behörighet och organisatorisk placering enligt plan.

– att driftstatistikfunktionen i systemet användes som ett instrument för ledningens uppföljning av datoranvändningen. Om så inte är fallet bör revisorn överväga att för sin egen uppföljning begära utskrifter av den lagrade informationen.

– att passerorden byts ut med viss frekvens.

MINIDATORMILJÖ

På vissa företag motsvarar minidatormiljön rent arbetsfördelningsmässigt vad som förekommer vid mikrodatorinstallationer. De synpunkter vi tar upp under mikrodatoravsnittet är då delvis tillämpliga.

Organisation

I minidatormiljö existerar många gånger en arbetsfördelning mellan ADB-funktion och användarfunktion. Användarna styr bearbetning och rapportuttag i olika tillämpningssystem medan övergripande arbetsmoment rörande datordrift och i vissa fall begränsat programutvecklings- och underhållsarbete hanteras av härtill speciellt utsedd personal. ADB-funktionen sysselsätter normalt ett fåtal personer. En otillfredsställande arbetsfördelning kan föreligga om systemutvecklingsarbete även utförs av driftpersonal.

Program och data för olika tillämpningssystem är vanligen direkt tillgängliga från samtliga terminaler. För erhållande av god arbets- och ansvarsfördelning i företagets olika rutiner krävs p g a detta att ett ändamålsenligt behörighetssystem utnyttjas i tillräcklig omfattning. Se vidare under Drift nedan.

Systemutveckling

Företagets programvara utgörs ofta av standardpaket utvecklade av hårdvaruleverantören eller av ett från denna fristående företag. Konsulter anlitas vanligen för att göra större eller mindre anpassningar av standardprogram efter specifika krav på data och behandlingsregler. Det är viktigt att anpassningsarbetet utförs strukturerat samt dokumenteras ordentligt både i program- och användardokumentation. Förutsättningarna för framtida underhållsarbete blir annars försämrade vilket väsentligt påverkar underhållskostnaderna i negativ riktning. Vidare kan ett till konsulten oönskat beroendeförhållande uppstå.

Drift

Centralenhet och externminne är vanligen placerade i ett separat utrymme. Leverantören föreskriver ofta vissa miljökrav för installationen vilket bl a innebär att klimataggregat används för att hålla luftfuktighet och temperatur inom rekommenderade intervaller samt att utrymmet är lämpligt med tanke på damm, smuts och statisk elektricitet.

Används separat utrymme för anläggningen innebär detta att tillträdet rent fysiskt kan och bör begränsas.

Behörighetssystem som begränsar åtkomsten till bl a register och program eller rutiner medföljer ofta den av hårdvaruleverantören levererade systemprogramvaran (operativsystem och olika hjälpprogram). Dessa behörighetssystem är många gånger tillräckligt avancerade för att medge tillfredsställande arbets- och ansvarsfördelning mellan användare om de administreras korrekt. Viktigt är att kontrollera vilka som har tillgång till hjälpprogram och rapportgeneratorer med vilka registerinformation enkelt kan ändras utan att detta lämnar några spår efter sig. Åtkomsten till dessa skyddas sedan om möjligt inom ramen för behörighetssystemet. Går ej detta får man försöka begränsa tillgången fysiskt. I sammanhanget bör nämnas att logglistor utvisande vem som kört vad och när, sällan finns eller används.

Även om säkerhetskopieringsrutin ofta finns i denna miljö kan dock kvaliteten på rutinen enligt vår erfarenhet skifta betydligt. Vid granskning av denna bör man ej glömma att kontrollera huruvida säkerhetskopia av system- och programdokumentation finns och förvaras på lämpligt ställe. Även om program och data kan återställas utifrån säkerhetskopior efter exempelvis en skivminneskrasch kan frånvaro av program- och användardokumentation, speciellt vid företagsspecifika program, orsaka stora problem.

MIKRODATORMILJÖ

Mikrodatorinstallationer har trots mångfalden märken och typer ofta vissa gemensamma egenskaper. Några av dessa utmärks också av svagheter avseende administrativa kontroller.

Organisation

Arbets- och ansvarsfördelningen karaktäriseras ofta av att en eller ett fåtal personer har full kontroll över och tillgång till dataregister, system- och applikationsprogram. Det är inte ovanligt att en person som hanterar viss tillgång även sköter redovisningen av densamma samt därmed relaterade avstämningsrutiner. Många gånger ställer det sig i små företag svårt att rent praktiskt lösa dessa frågor på ett tillfredsställande sätt. Finns erforderliga personella resurser tillgängliga i företaget kan en från intern kontrollsynpunkt tillfredsställande arbetsfördelning vara möjlig att arrangera. Är detta omöjligt hänvisas revisorn till substansgranskning. Se även avsnittet Drift nedan.

Systemutveckling

Vid mikrodatorinstallationer är det inte så vanligt att systemutvecklingsarbete bedrivs i företagets regi. Applikationsprogram införskaffas från leverantör i standardutförande. Många gånger anpassas ej programvaran till företagets krav även om det är funktionellt påkallat. En sådan anpassning ställer sig ofta för dyr i relation till anskaffningskostnaden. Det blir därför vanligen kostnadseffektivare att göra om företagets rutiner eller justera ned ambitionsnivån för applikationen. För mikro- liksom för minidatorinstallationer är valet av programvaruleverantör viktigt. Denne måste kunna ställa upp med erforderligt programunderhåll, tillfredsställande användardokumentation och användarutbildning under den tid applikationen/-erna används vid företaget.

Drift

En mikrodator ställer inga större krav på installationsmiljön. Den placeras ofta centralt och öppet på kontoret och blir därmed fysiskt lättillgänglig. Data och program kan enkelt läsas in på sekundärminne, vanligen diskettstation eller hårddisk. I många fall görs detta i samband med bearbetning. Utbudet av programvara, både tillämpningssystem och olika typer av hjälpprogram är stort, distributionen sköts i flera fall okonventionellt och av personer med bristande kompetens.

Som nämnts under avsnittet Organisation ovan kännetecknas mikrodatorinstallationer ofta av bristande arbetsfördelning. Är installationen diskettorienterad och arbetsfördelningen godtagbar begränsas tillgången till program och data lämpligen genom att aktuella disketter hålls oåtkomliga. Då installationen är försedd med hårddisk förvaras program och data vanligen direkt åtkomliga på denna. Risken för obehörig åtkomst kan måhända reduceras genom att väsentliga program- och datafiler ej förvaras på hårddisken annat än då bearbetning skall ske. Detta är dock en något teoretisk lösning som förutsätter tillgång till backup-rutiner som ej är alltför omständliga. Finns ett generellt behörighetssystem av tillfredsställande kvalitet kan detta användas. Ett sådant system måste medge kontroll av såväl operativsystem som hjälpprogram för att vara till nytta.

Behörighetssystem integrerade med tillämpningssystem är ofta av mindre värde då program och data relativt enkelt kan ändras via hjälpprogram utanför applikationen.

Ett problemområde som enligt vår erfarenhet förtjänar speciell uppmärksamhet i revisionen är rutiner för säkerhetskopiering. Ett lämpligt antal generationer måste sparas och kopiering ske med erforderlig frekvens. Detta är lika viktigt för mikro- som mini- och stordatorinstallationer. Vid val av förvaringsutrymme bör hänsyn tas till att magnetmedia redan vid måttlig uppvärmning kan bli oläsbar. Om data förloras kan förlusten bli kännbar för företaget. Störningar p g a exempelvis oläsbara disketter då säkerhetskopior saknas, kan orsaka driftsavbrott med förseningar och extraarbete som följd, i vissa fall kan skadan få betydande ekonomiska konsekvenser. Det finns exempel på företag som tvingats gå i konkurs då data och program förstörts!

SPECIELLA PROBLEMOMRÅDEN

Högnivåspråk

Systemutveckling och programmering har alltsedan de första datorerna presenterades på marknaden varit en specialitet för ADB-experter, en personalkategori som det under många år varit konstant brist på. Med hänsyn till detta och till att ADB-expertisen ej alltid haft förmågan att sätta sig in i användarnas problem och skapa en helt tillfredsställande totallösning har det under senare år kommit ut s k högnivåspråk på marknaden. Dessa fjärde generationens språk etc skiljer sig från de traditionella språken för datorer, bland annat på det sättet att programmeringen sker med hjälp av för användaren enkla instruktioner i direkt dialog med datorn. Användaren får i och med detta ett stöd i utvecklingsarbetet som gör det möjligt, även för personer utan djupare utbildning i informationsbehandling, att skapa egna system. En möjlighet som är positiv i så måtto att användarna dels kan få system som på pricken motsvarar deras intentioner, dels kan underhålla desamma i den takt kraven förändras.

Emellertid finns en icke negligerbar risk för att användarna med sina begränsade kunskaper i ADB tar fram för ögat måhända imponerande men i praktiken ineffektiva system. Ett förhållande som kräver att ansvariga har teknisk kontroll över vad som tas i produktion.

Problemet med högnivåspråken är inte språken i sig utan de skissartade systemlösningar de inbjuder till när personer som inte är vana vid att utveckla system självständigt och i egen regi ska göra sådana. Resultaten blir då ofta applikationer som är bristfälligt uttestade och ännu sämre dokumenterade, vilket sammantaget i sin tur ökar kravet på underhållsåtgärder. Ideliga underhållsinsatser ställer krav på en god dokumentation och behandlingshistorik så att man i efterhand kan fastställa under vilka förutsättningar ett visst system har fungerat vid en given tidpunkt.

För revisionens del innebär högnivåspråkens intåg på marknaden att det nu kan finnas två olika systemutvecklingsmiljöer att bedöma från intern kontrollsynpunkt:

– dels den rent traditionella i vilken systemutvecklingspersonal i samarbete med användarna utvecklar eller underhåller system,

– dels den nya miljön i vilken användarna själva till stor del utvecklar och underhåller sina system. Hänsyn måste även tas till att en blandning av miljöerna är vanlig då systemutvecklingspersonal ofta utvecklar delar av ett system med hjälp av högnivå- eller annat språk medan användarna själva utvecklar resterande delar.

Enligt vår mening räcker det inte längre med att revisorn stannar vid att bedöma och lägga synpunkter på den interna kontrollen kring utveckling och underhåll av klientens redovisningssystem. Användandet av högnivåspråk kräver som vi ser det att revisorn i ökad utsträckning verifierar att inte väsentliga program ändrats vid sidan av ordinarie programändringsrutiner. Vidare bör revisorn med hjälp av datorstödd revision söka verifiera att den lagrade informationen är i enlighet med systemdokumentation och utdatarapporter.

Rapportgeneratorer

Rapportgeneratorn är ett effektivt hjälpmedel för ADB-användare att vid behov, utan hjälp av ADB-experter, snabbt kunna göra sammanställningar av information i enlighet med de krav som är aktuella för stunden. Genom att rapportgeneratorerna är relativt enkla att använda brukas de ibland av orutinerad personal för utskrifter av stor betydelse för företaget.

Vissa rapportgeneratorer innefattar även uppdateringsfunktioner. Detta innebär att användarna har fått ett instrument till sitt förfogande via vilket de avsiktligt eller av ovarsamhet kan gå in och förändra lagrade data. Det går dock att skydda registren med hjälp av behörighetskontrollsystem.

Med hänsyn till hur enkelt det kan vara för en användare att påverka innehållet i en lista framställd med hjälp av en rapportgenerator måste revisorn själv kunna kontrollera ”programmet”. Vidare bör revisorn överväga att oavsett hur den interna kontrollen bedöms fungera, genom egna kontrollbearbetningar verifiera att de väsentligare redovisningslistorna är riktiga. Görs dessa kontrollbearbetningar på klientens dator måste revisorn förvissa sig om att det inte föreligger någon risk för att ens bli misstänkt för att ha kunnat påverka den lagrade informationen.

Säkerhet

Utöver de säkerhetsaspekter som behandlats ovan anser vi att detta ämne i sig utgör ett så stort problemkomplex att ytterligare kommentarer ej kan ges inom ramen för denna artikel.

I samband med den typ av granskning vi behandlat ovan erhåller revisorn en betydande kunskap om och erfarenhet av företagens säkerhet/sårbarhet. Området är således väl lämpat för klientrådgivning.

SAMMANFATTNING

Den snabba utvecklingen på ADB-området kopplat till företagens ökade datorisering introducerar nya risker och problemområden som revisorn måste kunna hantera. Det är viktigt att granskningsmetoderna anpassas till den successivt förändrade interna kontrollstruktur som införandet av ny ADB-teknik medför.

Tekniken medger att revisorn får nya hjälpmedel till sitt förfogande. Datorstödd revision, d v s användning av datorn i revisionen, blir möjlig. Via datorstödd revision kan granskningens kvalitet och effektivitet ökas.

Anders Malmeby och Ingemar Glans vid Bohlins Revisionsbyrå AB