prosjekt NorSox God IT Styring og Kontroll i norske foretak Sluttrapport - Del 2: Veiledning for innføring av god IT-styring og -kontroll

Transkript

1 God IT Styring og Kontroll i norske foretak Sluttrapport - Del 2: Veiledning for innføring av god IT-styring og -kontroll Standard Norge, desember 2009 prosjekt NorSox

2 Prosjekt NorSox Sluttrapport Omfatter to separate deler: Del 1 Modell Del 2 Veiledning for innføring av god IT-styring og -kontroll Publisert: Desember 2009 Prosjekteier: Standard Norge Prosjekt partnere: IKT Norge, Norsk Akkreditering, Software Innovation ASA og Standard Norge. Prosjektsekretariat: Standard Norge Publiseringsansvarlig: Standard Norge Strandveien 18 Postboks Lysaker info@standard.no ISBN Standard Norge 2009 Generelt om rettigheter for anvendelse av innhold i sluttrapport NorSox Som prosjekteier er Standard Norge den som forvalter alle rettigheter knyttet til sluttdokumentet fra prosjekt NorSox. Ved alle former for gjengivelse av det omtalte sluttdokument fra prosjekt NorSox del 1 og del 2, skal den som gjengir påse at kravet i åndsverkloven 3 om å navngi opphavsmannen / kildehenvisning blir ivaretatt. 2

3 God IT Styring og Kontroll i norske foretak Prosjekt NorSox Sluttrapport Del 2: Veiledning for innføring av God IT-styring og Kontroll 3

4 Dette dokumentet, sluttrapport fra prosjekt NorSox (bestående av Del 1 og Del 2) gir ledelse og styre i alle typer virksomheter grunnlag til å forstå hvordan etablere gode og helhetlige prinsipper for foretaksledelse med tilhørende systemer for helhetlig internkontroll, alt med fokus på at IT er en integrert del av virksomheten som understøtter foretakets forretningsstrategi. Del 2 er en veiledning til hvordan etablere God IT Styring og Kontroll. Prosjekt NorSox Standard Norge er prosjekteier og sekretariat for prosjektet. Prosjektet NorSox er et BIA-prosjekt (Brukerstyrt Innovasjonsarena) i regi av Norges Forskningsråd. Partnere i prosjektet har vært: IKT Norge Norsk Akkreditering Software Innovation ASA Standard Norge Prosjektets mandat utrykker dette slik: Lage nøytrale og forståelige prinsipper for god og helhetlig virksomhetsstyring med særskilt fokus på IKT. Retningslinjer basert på disse prinsippene vil bidra til at virksomheter innfører god risikostyring og internkontroll med utgangspunkt i det operative risikobildet. Prinsippene omfatter rammeverk, prosesser, oppgaver, atferd og andre forhold som bidrar til å sikre at virksomheten opererer i samsvar med relevante lover, forskrifter og internasjonale standarder. Retningslinjene skal tilfredsstille lovmessige krav og forskrifter som gjelder for styring av virksomheter av allmenn interesse: Dvs. børsnoterte selskaper, statlig eide virksomheter, offentlige/departementale foretak, finansvirksomhet, SMB-virksomheter m.m. Utgangspunktet for prosjektet er at Norge, som EØS-medlem, skal innføre tre EU-direktiver i norsk lovverk, 4., 7. og 8. selskapsdirektiv. Disse direktivene påvirker nasjonal lovgivning med hensyn til følgende lover: Regnskapsloven, bokføringsloven, aksjeloven, allmennaksjeloven m.m., gjeldende fra medio i Kravet som ligger i Aksjelovens 6.12, tredje ledd, om at Styret skal holde seg orientert om selskapets økonomiske stilling og plikter, samt påse at dets virksomhet, regnskap og formuesforvaltning er gjenstand for betryggende kontroll, står fast. I forbindelse med Aksjelovens 6.12 har man til nå fokusert på de to siste elementene om regnskap og formuesforvaltning hvor den eksterne revisor gir sin revisjonsberetning. Prosjekt NorSox vil rette fokuset mot de nye krav som stilles til styret i bla Regnskapsloven 3-3b. Redegjørelse om foretaksstyring. Denne skal innholde opplysninger om: Angivelse av de anbefalinger og regelverk om foretaksstyring som foretaket er omfattet av eller som selskapet for øvrig velger å følge. Samt beskrivelse av hovedelementene i foretakets systemer for internkontroll og risikostyring knyttet til regnskapsprosessen. Prosjekt NorSox anbefaler et helhetlig system for internkontroll og risikostyring. Målet for loverendringene og presiseringene er krav om bedre total selskapsstyring. Prosjektet har utarbeidet dette sluttdokumentet gjennom en prosess som er basert på konsensus. Arbeidet har foregått i en arbeidsgruppe med en referansegruppe som kvalitetssikrer innholdet. Arbeidsgruppen: Jan T. Bjørnsen, Ageto Rådgivning AS (Leder) Ole J. Kvammen, Security & Risk Management AS Rune Berggren, IBM Norge as Øyvind Schønemann, Infocom Group AS Vibeke Gjøsdal, Security & Risk Management AS Sekretariat: August Nilssen, Standard Norge Referansegruppen: Roar Gulbrandsen, PricewaterhouseCoopers (leder) Inger Mette Gulbrandsen, Det Norske Veritas Gaute Lien, ISACA Norge Alf M. Hanssen, Norske Interne Revisorers Forening Jan Kirkerud, Software Innovation ASA Per Morten Hoff, IKT Norge Knut Lindelien, Standard Norge 4

5 NorSox Et dokument om God IT Styring og Kontroll Ledelsen både i privat og offentlig sektor blir i dag utfordret til å etablere God IT Styring og Kontroll eller IT Governance i sin virksomhet. Det er særlig myndigheter, eiere og ansatte som stiller strengere krav til tydeliggjøring av ansvar og konsekvenser. Dette gjelder spesielt dersom virksomheten ikke kan dokumentere god styring og kontroll. Prosjektet NorSox, i regi av Standard Norge, har laget dette dokumentet for å gi styremedlemmer og den ansvarlige ledelsen et grunnlag til å forstå nok til å plassere Internkontroll og styring innen IT på dagsorden. Dokumentet henvender seg til alle som har eller vil få verv i styrer, eller har et lederansvar i en virksomhet. Det bygger på internasjonalt anerkjente standarder og internasjonale rammeverk. Det betyr at man må forholde seg til noen termer og begrep som er helt sentrale for å forstå hvordan god styring og kontroll kan bygges opp. God IT Styring og Kontroll er en måte å forklare viktigheten av å ha styring og kontroll (ofte omtalt som intern kontroll ) over virksomhets bruk av IT. Dette er knyttet tett sammen med generelle krav om god virksomhetsstyring ( Corporate Governance ). For å beskrive hvilke prosesser som må på plass for å styre og kontrollere bruk av IT, anvendes CobiT som en anerkjent de facto standard. Her beskrives 34 prosesser, fordelt innen 4 hovedområder, for å ivareta bruk, organisering, administrering og drift av IT. De 4 områdene er: Planlegging og Organisering som ivaretar de administrative aktivitetene for å få til en styrt og kontrollerbar bruk og drift av IT Anskaffelse og Implementering som ivaretar de operative aktivitetene for å anskaffe nye systemer eller oppdatere eksisterende Driftsleveranser og Support som ivaretar de operative aktivitetene for å sikre effektiv og stabil IT drift Monitorering og Evaluering som ivaretar de operative og administrative aktivitetene med å følge opp og sikre en optimal bruk av IT Dette gjøres for at virksomhetens krav til IT skal: være målrettet være effektiv sikre konfidensialitet sikre integritet sikre tilgjengelighet oppfylle lovpålagte krav være robust ( Resilient ) Dette dokumentet fra NorSox binder sammen COSO, CobiT, ITIL og ISO-standarder ved å beskrive IT Styring og Kontroll innenfor temaer som strategiske tilpassinger, leveransekvalitet, risikostyring, ressursstyring og ytelsesmåling. I de nye lovtekstene er begrepet Foretak blitt benyttet konsekvent. Imidlertid er Virksomhetsstyring et innarbeidet begrep hos mange i dag. Når NorSox i dette dokumentet bruker begge begrepene om hverandre, så menes de å omfatte både private virksomheter, aksjeselskaper, offentlige foretak/etater og organisasjoner. 5

6 Innhold Del 2: Side Tillegg A: Prosesser for innføring av et rammeverk for helhetlig og god ITstyring 7 og kontroll A1: Planlegging og Organisering 10 A2: Anskaffelse og Implementering 12 A3: Driftsleveranser og Support 18 A4: Monitorering og Evaluering 20 Tillegg B: Sjekklister 22 B1: Sjekkliste for Styret uansett størrelse av foretak 22 B2: Sjekklister med referanse til COSO 23 Tillegg C: Relevante paragrafer fra lovtekster 26 Tillegg D: Tabell over Operasjonell risiko 29 6

7 Tillegg A: Prosesser for innføring av et rammeverk for god helhetlig IT-styring og kontroll I dette tillegget fokuserer vi på de prosesser som styret og administrasjonen blir involvert i når styret har besluttet at man skal benytte et robust og velprøvd rammeverk for God IT styring og kontroll Vi bruker informasjon fra rammeverket CobiT v.4.1 for å illustrere dette arbeidet, samt rollene og ansvaret i en slik prosess. IT Governance består av 5 elementer hvor CobiTs 34 prosesser inngår. De 5 elementene må utføres for å ha God helhetlig IT-styring og kontroll eller IT Governance, basert på rammeverket CobiT. Dette er illustrert i figur 1 og figur 3 nedenfor og brukt som utgangspunkt for presentasjonen og beskrivelsene videre. De 34 prosessene er samlet og omtalt under de 4 hovedområder i CobiT: Planlegging og Organisering (PO) som ivaretar de administrative aktivitetene for å få til en fornuftig bruk og drift av IT Anskaffelse og Implementering (AI) som ivaretar de operative aktivitetene for å anskaffe nye systemer eller oppdatere eksisterende Driftsleveranser og Support (DS) som ivaretar de operative aktivitetene for å sikre effektiv og stabil IT drift Monitorering og Evaluering (ME) som ivaretar de operative og administrative aktivitetene med å følge opp og sikre en optimal bruk av IT Figur 1: Fundament for god helhetlig IT Styring og Kontroll (IT Governance) viser struktur og retning som styret kan anvise for den daglige ledelsen med hensyn på forvaltning og bruk av IT i foretaket. Styrets oppgave innen IT Governance er: evaluere forretningsmuligheter (Evaluate) peke ut en retning (forretningsmessig og teknologisk) (Direct) se til at internkontroll er etablert og fungerer etter sin hensikt (Monitor) I figur 2 nedenfor viser vi hvordan de tre oppgavene styret har ansvar for, blir plassert i et årshjul. Ved å styre og kontrollere disse overordnede prosessene, vil Styret gi direktiver til Daglig ledelse som kan ivareta planlegging og organisering av alle de øvrige prosessene. Styret må legge inn aktivitetene i sitt årshjul, og dette må koordineres med ledelsens årshjul for virksomheten totalt. 7

8 Figur 2: Styrets oppgaver relatert til et årshjulperspektiv. Det anbefales at styret, i et eget møte minst en gang per år, evaluerer IT-bruken i foretaket. Foretakets forretningsplaner drøftes og legges til grunn for gjennomgangen av IT-bruken. I samme møte kan man for eksempel: Drøfte om man skal ha selvstendige enheter med egne IT-systemer/infrastruktur eller skal man ha sentraliserte løsninger. Fastsette den tekniske arkitekturen for å levere de tjenester som er nødvendig for å oppfylle forretningsplanen. Dette vil gi IT-ledelsen og administrasjonen rammer for den Strategiske IT-planen foretaket skal etablere for å kunne levere de tjenester som er nødvendige for å oppfylle forretningsplanen. Det viktigste elementet er selve bruken av IT uttrykt i en strategisk IT-plan for virksomheten. Denne vil være et underdokument til foretakets forretningsstrategi. Tabell 1 nedenfor viser hvordan CobiT beskriver IT-prosesser med et eksempel fra området Planlegging og Organisering (PO). Eksemplet illustrer hvorfor den Strategiske IT-planen er så viktig. Define a strategic IT plan (CobIT - PO1) that satisfies the business requirement for IT of sustaining or extending the business strategy and governance requirements whilst being transparent about benefits, costs and risks by focusing on incorporating IT and business management in the translation of business requirements into service offerings, and the development of strategies to deliver these services in a transparent and effective manner is achieved by Engaging with business and senior management in aligning IT strategic planning with current and future business needs Understanding current IT capabilities Providing for a prioritisation scheme for the business objectives that quantifies the business requirements and is measured by Percent of IT objectives in the IT strategic plan that support the strategic business plan Percent of IT projects in the IT project portfolio that can be directly traced back to the IT tactical plans Delay between updates of IT strategic plan and updates of IT tactical plans Tabell 1: Eksempel på beskrivelse av en IT prosess i CobiT (Prosess PO1 Definere plan for ITstrategi) 8

9 For hver av de 4 hovedområdene i CobiT, er det viktig å være klar over at noen av de 34 prosessene inngår i flere av de fem elementene som beskriver IT Governance (ref. figur 3 nedenfor). Det vil derfor være slik at visse aktiviteter innen en prosess som går mot ett element, mens andre aktiviteter fra samme prosess går mot et annet element. Eksempelvis vil prosessen PO9 (Manage Risk) ha aktiviteter både under Strategisk tilpassing og under Risikostyring. Figur 3: Sammenheng mellom CobiTs 34 prosesser med fordeling av prosessaktiviteter ut på hovedområdene som utgjør IT Governance 9

10 A1: Planlegging og Organisering Prosesser innen planlegging og organisering av God IT-styring og kontroll treffer foretaket på alle de 5 elementene av IT Governance. Dette betyr at det er behov for en Strategisk IT-Planlegging som Styret og Daglig ledelse står for; og en Operativ IT-Planlegging som foretakets enheter utfører hos seg selv. De 10 prosessene som omhandler Planlegging og Organisering er følgende: A1 CobiT prosessene som inngår i området Planlegging og Organisering (Plan and Organise) PO1 - Define a Strategic IT Plan PO2 - Define the Information Architecture PO3 - Determine Technological Direction PO4 - Define the IT Processes, Organisation and Relationships PO5 - Manage the IT Investment Tabell 2: CobiTs PO-prosesser PO6 - Communicate Management Aims and Direction PO7 - Manage IT Human Resources PO8 - Manage Quality PO9 - Assess and Manage IT Risks PO10 - Manage Projects Dette gir et sett av aktiviteter som daglig ledelse bør sikre seg styrets tilslutning til å: 1) planlegge, 2) utføre, 3) evaluere og 4) handle. A1.1 Planlegge Alt planarbeid må forankres hos foretakets ledelse helst basert på et styrevedtak som presiserer at dette arbeidet vil bli fulgt opp regelmessig av styret, og hvor Styret instruerer Daglig ledelse om hva som skal prioriteres. (Evaluate and Direct). Administrerende direktør bør utarbeide en prosjektplan som viser de viktigste milepæler med roller og ansvar for å få dette gjort. Eksempel: Vårt eksempel, basert på omfattende erfaring, viser forslag til milepæler med aktiviteter som skal utføres i foretaket i løpet av de første 6-12 månedene. Eksempelet viser at styret ønsker å iverksette aktiviteter innen de fire IT Governance elementene: Strategic Alignment Value Delivery Risk Management Resource Management I dette eksempelet tar styret et bevisst valg om å tone ned Performance Measurement, og innen Risk Management vil styret at det fokuseres på Kontinuitets- og Beredskapsplaner (KBP). Dette gir 10 milepæler med tilhørende aktiviteter som daglig ledelse må ha Styrets tilslutning til. Eksempel A1 - Milepælsplan Nr. Milepæler Dato åååå-mm-dd Strategi IT Governance (Arkitektur): 1 Når policydokumentet er fremlagt og godtatt av Styret/ledelsen Strategi IT Governance (Arkitektur): åååå-mm-dd 2 Når prinsippdokumenter innen drift, sikkerhet og kontroll er godkjent av den ansvarlige innen ledergruppen Strategi IT Governance (Arkitektur): åååå-mm-dd 3 Når strategidokumenter er etablert og godkjent 10

11 Risk Management (Beredskap): Når planer for Informasjonssikkerhet/KBP og kartlegging er etablert og gjort kjent i organisasjonen Value Delivery (Kartlegging Nå-situasjon): Når analyse-planer av kritiske prosesser/systemer er besluttet Value Delivery (Kartlegging Nå-situasjon): Når personell som skal delta på analysene er utpekt Value Delivery (Kartlegging Nå-situasjon): Når analysene er gjennomført og tiltak foreslått: - IT Drift (IT-installasjoner, Nettverk og Kritiske forretningssystemer) - Forretningsenhet 1 (Prosesser, Nettverk og Kritiske forretningssystemer) - Forretningsenhet 2 (Prosesser, Nettverk og Kritiske forretningssystemer) - Internkontroll (Prosesser, dokumentasjon av Egenkontroll og Internontrollaktiviteter) Risk Management (Beredskap): Når Beredskapsplaner er utarbeidet innen: - IT Drift: (Backup/restore, IT Kontinuitet; IT Beredskap) - Forretningsenhetene Forretningsmessige Beredskapsplaner - Kriseledelse for Konsernledelsen Resource Management (Organisasjonsutvikling, kommunikasjon og holdninger): Når ny Internkontroll er organisert, og rutiner kjent og akseptert innen foretaket: - RACI Kart (ref. figur 6) - Beskrive nye roller og prosesser og funksjoner for egenkontroll og internkontroll innen organisasjonen - Beslutte behov for reell kontroll-organisasjon vs. virtuell rapporteringsorganisasjon av utvalgte egenkontroll-aktiviteter - Kommunisere organisering og opplæring til ansatte - Kurs og presentasjon gjennomført hos Pilot Risk Management (Informasjonssikkerhet): Når ny elektronisk sikkerhetshandbok er lansert på internweb: - Etablere retningslinjer for brukere og utviklere - Etablere instrukser for brukere - Etablere instrukser for driftspersonell - Publisering på internweb er gjennomført åååå-mm-dd åååå-mm-dd åååå-mm-dd åååå-mm-dd åååå-mm-dd åååå-mm-dd åååå-mm-dd 11 Status og Neste steg Tabell 3: Eksempel på milepæler som inngår i planprosessen for Styret og Daglig Ledelse + 6 måneder A1.2 Utføre Daglig ledelse vil iverksette de nødvendige aktivitetene i linjen for å løse de oppgavene den er pålagt av Styret. Dette vil i første omgang være å få på plass de nødvendige strategiske planene og utnevne ansvarlige i linjeorganisasjonen til å utføre oppgavene. Dette tilsvarer milepæl 4 til 10 i Milepælsplanen i tabell 3 over. A1.3 Evaluere og handle Daglig ledelse vil bli forelagt en statusrapport fra den innføringsansvarlige hvor man vurderer hvor vellykket innføringen av internkontroll og egenkontroll har vært, med forslag til hva som bør være neste steg i planleggingsprosessen hos styret. Dette vil medføre en revidert Milepælsplan med justert strategi for andre implementeringsaktiviteter. 11

12 A2: Anskaffelse og Implementering I forhold til de 5 hovedelementene til IT Governance, vil prosesser innen anskaffelse og implementering i hovedsak være rettet mot Leveransekvalitet og Ressursstyring. Det vil være noen strategiske føringer som må treffes av Daglig ledelse, men dette er i hovedsak operative prosesser som skal sikre at behov for utstyr og personell blir ivaretatt. De 7 prosessene som omhandler Anskaffelse og implementering, er følgende: A2: Anskaffelse og implementering (Acquire and Implement) AI1 - Identify Automated Solutions AI2 - Acquire and Maintain Application Software (SW) AI3 - Acquire and Maintain Technology Infrastructure (HW) AI4 - Enable Operation and Use Tabell 4: CobiTs AI-prosesser AI5 - Procure IT Resources AI6 - Manage Changes AI7 - Install and Accredit Solutions and Changes A2.1 Planlegge Der det er nødvendig med forbedring i prosessene rundt anskaffelser og implementering av forretningssystemer, må dette også etter hvert tas opp med Styret som en strategisk retning man ønsker bedre styring og kontroll over. Her ligger det mye rundt å gjøre produktutvikling og endringsstyring av IT systemer og applikasjoner på en mest mulig verdiøkende og optimal måte i foretaket. Dette er en konkret videreføring av stegene 5, 6 og 7 i vårt eksempel på milepælsplan. A2.2 Utføre IT-avdelingen vil her kunne vise til ITIL som et godt fundament for etablering av gode prosesser rundt anskaffelse og implementering. Dette vil også kunne brukes på Driftsleveranser og Support hvor ITIL dekker Service Management konseptet rundt bedring av kvalitet i tjenesteleveransene innenfor avtalte ressursrammer. Dersom dette skal brukes, må det inn i en Planleggings- og organiseringsprosess som ivaretar det strategiske behovet foretaket har for et slikt rammeverk. Videre må det gjøres operative grep for å implementere ITILs prosesser i organisasjonen slik at man får en enhetlig og konsistent måte å arbeide på, og som lett kan følges opp av de lokale lederne. A2.3 Evaluere og handle Det er viktig å definere meningsfylte kontrollaktiviteter for å sjekke at anskaffelser og implementeringsprosjekter blir ivaretatt på en betryggende og akseptabel måte. Det må derfor implementeres gode kontrollhandlinger (nøkkelkontroller) i de daglige prosessene slik at det er lett å dokumentere etterlevelse av lovpålagte og selvpålagte krav. På denne måten sikrer man et grunnlag for rapportering oppover i organisasjonen. Eksempel A2: Prosedyre og kontrollbeskrivelse for endringshåndtering (AI6) Under følger et eksempel på en generisk prosessbeskrivelse for en normal endringshåndtering som kan brukes til å innarbeide et kontrollspor. Eksemplet viser en prosedyre som er en beskrivelse av en eller flere prosessaktiviteter: hva som er formålet med denne delen av en endringsprosess hvilke deler av foretaket som omfattes av denne prosessen hvilke roller og hva slags ansvar som pålegges aktørene alltid beskrevet med et Sørge for -ansvar og et Utføre -ansvar en kort skjematisk beskrivelse av hvordan prosessen utføres beskrevet på et så generelt nivå som mulig slik at det tillater enkelte variasjoner i utførelsen for forskjellige grupper av fagpersonell referanser til egne dokumenter eller det målbilde CobiT setter opp for de enkelte aktiviteter, selve delprosessen og for leveransen mot forretningssiden i foretaket 12

13 en beskrivelse av den egenkontroll-handlingen som utføres under selve arbeidet, og som det er mulig å etterprøve. Vårt eksempel på de neste sidene viser hvordan en prosedyre kan komponeres for å dokumentere hva som skal gjøres, hvem som skal gjøre det, roller og ansvar samt den egenkontrollen som skal utføres for å dokumentere at han/hun har utført sin oppgave riktig. Beskrivelsen av selve kontrollhandlingen (egeneller nøkkelkontrollaktivitet) bakerst i prosedyreeksempelet har følgende oppbygging: Eksempel på hvordan beskrive en kontrollaktivitet Kontrollmålsetting (Objective): Hentes fra CobiT og/eller IT Governance Institute (ITGI) Risiko (Risk) Hentes for eksempel fra ITGI materiale IT CONTROL OBJECTIVES FOR SARBANES-OXLEY, 2nd EDITION Design av styrings- og kontrollaktivitet (Control activity) Hva Hvordan Aksjon i tilfelle avvik under kontrollen (Actions in case of deviations) Hva Hvordan Kontrollspor (Audit trail) Hvordan kontrollen ivaretas (møtenotat, signatur på sjekkliste osv.) Hvor kontrollsporet lagres (i egen filfolder, tas ut på papir osv.) Test av styrings- og kontrollaktiviteten 1 (Test of control) Hvordan kan for eksempel møtereferatet gi sikkerhet for at egenkontroll-aktiviteten er utført Hvor skal denne testen rapporteres og dokumenters Viktige momenter ifm. styring og kontroll (Key Control characteristics) Hvem er prosesseier Hvilke roller utfører kontrollaktivitetene Hvor ofte utføres kontrollene Er det en automatisert eller manuell kontrollaktivitet Er det en preventiv eller oppdagende kontroll (hindrer den feil eller uhell eller oppdager og begrenser den skaden etter at hendelsen har skjedd) Hvilke applikasjoner er involvert (hvis det er relevant) Kontrollreferanse (andre styrende dokumenter som er relevante, hvor er kontrollen forankret) Andre kontrollreferanser Tabell 5: Eksempel på disposisjon og krav til innhold i en kontrollaktivitet I eksempel A2 på neste side er disposisjonsteksten gulmerket og lagt inn som liten skrift til hvert enkelt punkt i prosedyren. Den skal fjernes når prosedyren er endelig godkjent. 1 (Husk piloten som fyller ut sin sjekkliste (egenkontroll) og signerer denne. Bakkemanskapet mottar og bekrefter overfor tårnet at han har mottatt sjekklisten signert av riktig person (nøkkelkontroll) før flyet får lov til å ta av. Sjekklisten blir lagret og kan hentes fram av Havarikommisjonen for å teste at både egenkontrollen og nøkkelkontrollen er utført dersom noe skjer med flyet.) 13

14 Eksempel A2 Prosedyre (Dokumentert beskrivelse av en prosess) Prosedyrebeskrivelse: Endringsstatus - Sporing og rapportering for Dataservere og Nettverk (CobiT aktivitet AI6.4) 1 FORMÅL Gjøremål: Gi en kort og dekkende beskrivelse av hensikten med å gjennomføre aktivitetene i prosedyren. CobIT Statement AI6.4; Change Status Tracking and Reporting Establish a tracking and reporting system to document rejected changes, communicate the status of approved and in-process changes, and complete changes. Make certain that approved changes are implemented as planned. Denne prosedyren dokumenterer de aktivitetene som faggruppene i IT Driftavdelingen gjennomfører for å vite om endringer er blitt akseptert eller forkastet, og hvilken status endringer har (godkjent for endring, under endring og ferdigstilt). Dette gjøres i etterkant av Change Management prosessen som ledes av Change Manager, eller det gjøres av lederne av faggruppene dersom endringen gjennomføres utenom en PM-kjøring. 2 OMFANG Gjøremål: Her angis: hvilke produkter og tjenester prosedyren omfatter hvilke deler av organisasjonen prosedyren gjelder for under hvilke forhold/ i hvilken situasjon prosedyren gjelder For faggruppeansvarlige i IT Driftavdelingen gjelder det å vurdere konsekvensen av endringer i Foretakets IKT-driftsmiljø før endringer produksjonstestes og driftsettes. For Datadriftgruppa og Windowsgruppa gjelder det å vurdere konsekvensen av endringer i system og databaseoppsett før dette produksjonstestes. Alle disse oppdateringene/endringene skal testes ut i et separat testmiljø for å se mulige konsekvenser før en massiv utrulling foretas. Database- og driftservere blir ofte endret i oppsett av regelsett/policyer. Her bør foretaket ha dublerte utrustninger slik at endringen kan testes og implementeres på en enhet først før den andre enheten oppdateres. For Nettverksgruppa gjelder det å vurdere konsekvensen av endringer i nettverket før dette produksjonstestes. En del av disse oppdateringene/endringene er det ikke mulig å teste ut i testmiljø, men det er mulig å implementere dem på et lite antall (pilot-)nettsegmenter for å se konsekvensene før en massiv utrulling foretas. Brannmurer (firewalls) og overvåkningsservere blir ofte endret i oppsett av regelsett/policyer. Her bør foretaket ha dublerte utrustninger slik at endringen kan testes og implementeres på en enhet først før den andre enheten oppdateres. Disse oppgavene vil bli utført av fagpersonell. Dette betyr: en forhåndsavtalt og standardisert fremgangsmåte for å håndtere endringene på en effektiv måte formelt definert forventet løsning og ytelse målinger konsistente endringsprosedyrer 3 ANSVAR Gjøremål: Her angis hvem som har ansvar for at dokumentet: godkjennes, distribueres og revideres (dokumentansvarlig) etterleves og følges opp I de tilfeller prosedyren berører flere enheter, eller berører/påvirker aktiviteter i andre prosedyrer, må grensesnitt i ansvarsforhold sjekkes/avklares. Dokumentet eies av de Faggruppeansvarlig i IT Driftavdelingen som enten alene, eller sammen med Endringsrådet, beslutter og sørger for at fagpersonell gjennomfører uttesting ved behov. Dersom konsekvensen er innenfor akseptabel risiko, kan faggruppeansvarlig sammen med kundens applikasjonsforvalter beslutte å rulle ut ny endring uavhengig av PM-kjøringen ved manuelle oppdateringer av dataservere. 14

15 4 BESKRIVELSE AV FREMGANGSMÅTE Gjøremål: Her beskrives hovedtrekkene i prosedyren, eventuelt med spesifikke og mer detaljerte fremgangsmåter der dette er nødvendig for å unngå at unødige misforståelser og uklarheter oppstår. Alternativt kan det henvises til annen dokumentasjon, f.eks. andre håndbøker, prosedyrer, standarder eller arbeidsbeskrivelser. Henvisningene må i tillegg føres opp under dokumentets pkt. 5 Referanse og definisjoner. Krav til registreringer må fremkomme tydelig i forhold til aktiviteter og resultater. Rutinen fungerer på følgende måte: 4.1 Endring i Operativsystem på databaseservere Datadriftgruppa velger ut en eller flere dataservere som skal få endringene implementert først. Ved oppdatering av doble servere ( fail over -løsninger), velges det å gjennomføre endringen på en server først, teste denne, for deretter foreta installasjon på den andre maskinen. Rutinen fungerer som følger: fagpersonell setter opp en kjøreplan som brukes underveis for å sikre progresjon utvalgte servere oppgraderes med ny endring av fagpersonell serverne testes av faggruppeansvarlige for Datadrift for endringer i driftsmønsteret serverne testes av faggruppeansvarlige for Windows for endringer i driftsmønsteret hvis OK så implementeres oppgraderingen på de øvrige maskinene full test utføres før det aksepteres å sette endringen i drift (release) 4.2 Endring i regelsett på systemservere Datadriftgruppa velger ut en av enhetene i den dublerte løsningen som får endringene implementert først, tester databaseendringene på denne ved å kjøre berørte applikasjoner og se at de ikke blir negativt påvirket av endringen, for deretter foreta installasjon på den andre maskinen. Rutinen fungerer som følger: fagpersonell settes opp en kjøreplan som brukes underveis for å sikre progresjon utvalgte regelsett/policyer oppgraderes med ny endring berørte applikasjoner eller tjenester testes av faggruppeansvarlige for Datadrift eller Windows for endringer i sitt driftsmønster som følge av endret regelsett hvis OK så implementeres oppgraderingen på den andre maskinen full test utføres før det aksepteres å sette endringen i drift (release) 4.3 Endring i Operativsystem på overvåkningsservere eller nettverkskomponenter Nettverksgruppa velger ut en eller flere pilotinstallasjoner som får endringene implementert først. Ved oppdatering av doble servere velges det å gjennomføre endringen på en server først, teste denne, for deretter foreta installasjon på den andre maskinen. Rutinen fungerer som følger: fagpersonell setter opp en kjøreplan som brukes underveis for å sikre progresjon utvalgte nettverkskomponenter eller servere oppgraderes med ny endring av fagpersonell komponentene/serverne testes av faggruppeansvarlig Nettverk for endringer i driftsmønsteret hvis OK så implementeres oppgraderingen på de øvrige maskinene full test utføres før det aksepteres å sette endringen i drift (release) 4.4 Endring i regelsett på branmurer (firewalls), IDS eller lignende Nettverksgruppa velger ut en av enhetene i den dublerte løsningen som får endringene implementert først, teste denne ved å kjøre berørte applikasjoner og se at de ikke blir negativt påvirket av endringen for deretter foreta installasjon på den andre maskinen. Rutinen fungerer som følger: fagpersonell settes opp en kjøreplan som brukes underveis for å sikre progresjon utvalgte regelsett/policyer oppgraderes med ny endring berørte applikasjoner eller tjenester testes av faggruppeansvarlig Nettverk for endringer i sitt driftsmønster som følge av endret regelsett hvis OK så implementeres oppgraderingen på den andre maskinen full test utføres før det aksepteres å sette endringen i drift (release) 15

16 5 REFERANSER OG DEFINISJONER Hvis det er hensiktsmessig, deles referansepunktet i 2 deler for å tydeliggjøre knytningen til overordnet dokument. 5.1 Referanser Gjøremål: Liste over henvisninger til andre prosedyrebeskrivelser, håndbøker, lover og forskrifter ol. som har direkte betydning for gjennomføring av den aktuelle prosedyren og/eller vedlegg til dette dokument. Figur 5: CobiT prosess AI6 Endringshåndtering 5.2 Knytning til overordnet dokument Gjøremål: Her definere hvilket dokument som gir rammebetingelsene for dette dokumentet i den grad det er naturlig. Arbeidsbeskrivelser vil naturlig ha en knytning til en prosedyre. 5.3 Definisjoner Definisjon av ord og uttrykk, som er viktig for å forstå fremgangsmåte, bør samles i et eget dokument (ordliste) som det henvises til i arbeidsbeskrivelsen under referanser. 5.4 VEDLEGG Vedlegg skal alltid ha eget referanse og dokumentnummer. 6 KONTROLLAKTIVITETER Egenkontroll/nøkkelkontroll Kontrollaktiviteten skal dokumenteres som vist i tabell 5 over. Punktene nedenfor er eksempler på alternative kontrollaktiviteter som kunne vært brukt: sørg for at det finnes en prosess som hele tiden viser status for endringsanmodningen gjennom endingsprosessen som et revisjonsspor sørg for at endringsanmodningens status er kjent (avslått, godkjent men ikke utført, godkjent, under arbeid, ferdig). sørg for at faggruppeansvarlig gjennomgår endringsoversikter regelmessig sørg for at åpne hendelser blir lukket når saken er ferdigbehandlet 6.1 Hva (skal gjøres): Punktene nedenfor er et eksempel på hva som bør gjøres (disse er valgt ut): faggruppeansvarlig for Datadrift eller Windows vurderer konsekvensene slik de er beskrevet fra leverandør og uavhengige sikkerhetsorganisasjoner faggruppeansvarlig Nettverk vurderer konsekvensene slik de er beskrevet fra leverandør og uavhengige sikkerhetsorganisasjoner fagpersonell baserer sin prioritering på grunnlag av vurderingene og begrunner sin prioritering skriftlig i sin månedlige rapport til Faggruppeansvarlig for Datadrift, Windows eller Nettverk fagpersonell setter opp en kjøreplan for endringen 16

17 6.2 Hvordan (skal det gjøres): Fagpersonell legger fram kjøreplan og månedsrapport for Standard endringer og Planlagte endringer til Faggruppeansvarlig for Datadrift, Windows eller Nettverk. Dersom det oppdages avvik (med angivelse av hvordan), må det innhentes kjøreplan, månedsrapporter eller annen dokumentasjon fra fagpersonell. 6.3 Revisjonsspor: For å sikre revisjonsspor må: kjøreplaner arkiveres månedsrapporter fra fagpersonell arkiveres Tabell 6: Eksempel på en prosedyre som beskriver en prosessaktivitet 17

18 A3: Driftsleveranser og Support I forhold til de 5 hovedelementene innen IT Governance, vil prosesser innen driftleveranser og support i hovedsak være rettet mot Leveransekvalitet, Risikostyring og Ressursstyring. Det vil være noen strategiske føringer som må treffes av Daglig ledelse når det gjelder monitorering og oppfølging, men dette er i hovedsak operative prosesser som skal sikre at forretningsmessige krav blir tilfredsstilt. De 13 prosessene som CobiT sier må være på plass innen Driftsleveranse og Support, er følgende: A3: Driftsleveranse og Support (Delivery and support) DS1 - Define and Manage Service Levels DS2 - Manage Third-party Services DS3 - Manage Performance and Capacity DS4 - Ensure Continuous Service DS5 - Ensure Systems Security DS6 - Identify and Allocate Costs DS7 - Educate and Train Users DS8 - Manage Service Desk and Incidents DS9 - Manage the Configuration DS10 - Manage Problems DS11 - Manage Data DS12 - Manage the Physical Environment DS13 - Manage Operations Tabell 7: CobiTs DS-prosesser A3.1 Planlegge Der det er nødvendig med forbedring i prosessene rundt drift og support, må dette også tas opp med Styret som en strategisk retning man ønsker å få bedre styring og kontroll over. Her er det vesentlig å sørge for at de forretningsmessige kravene til målrettet, effektiv og sikker databehandling blir ivaretatt. Bruk av rammeverk som ITIL og ISO er gode utgangspunkt for å lage praktiske aktiviteter i disse prosessene. Husk at ITIL biblioteket inneholder generelle beskrivelser av god praksis ( best practice ) som må tilpasses den enkelte virksomhets art og størrelse. Det må kartlegges hva man faktisk gjør i dag, og hvor mye dette avviker fra foreslåtte god praksis på området. Ofte er det små korrigeringer i beskrivelsen som skal til, eller små justeringer på den måten man jobber på, som skal til før man har dokumentert en tilfredsstillende prosess for sin virksomhet. A3.2 Utføre Når et foretak først har bestemt seg for hvordan operativ drift skal foregå, vil det være en jobb å motivere og engasjere fagpersonellet til å forstå at man i stor grad skal gjøre akkurat det man er vant til i dag, men at det skal struktureres, kontrolleres og følges opp periodisk og regelmessig framfor sporadisk og etter innfallsmetoden. Det settes derfor større krav til en bevisst og strukturert prosessbeskrivelse for å ivareta løpende kontrollaktiviteter. Ved å bruke ITIL og/eller ISO/IEC som grunnlag og beskrivelse av den gode praksisen som foretaket skal innarbeide, vil man relativt enkelt kunne velge mellom de 13 definerte prosessene innen Driftsleveranse og Support og få disse dokumentert i prosedyrer. Det ligger utenfor dette prosjektet og dette dokumentets rammer å gi en komplett innføringsguide i ITIL. Det har imidlertid vist seg at de aller fleste organisasjoner har aktiviteter som er tilnærmet lik god praksis, men de mangler dokumentasjon. Det er derfor viktig å tilpasse den generiske beskrivelsen i for eksempel ITIL til hvordan det i praksis gjøres i virksomheten. Det er også viktig å utfordre fagpersonellet på hva slags egenkontroll-aktivteter de utfører siden dette overhode ikke er nevnt i ITILs beskrivelser. Når man er omforent om arbeidsprosess og sørget for at prosedyren beskriver aktivitetene på en ryddig og prinsipiell måte, kan man begynne å kreve at fagpersonellet skal etterlate seg det avtalte kontrollsporet i sin daglige jobb. A3.3 Evaluere og handle Når foretaket først har bestemt seg for hvordan operativ drift skal foregå, vil det være en jobb å motivere og engasjere fagpersonellet til å ha et bevisst forhold til hva man skal utføre av kontrollaktiviteter i sin daglige jobbsituasjon. Erfaring viser at de aller fleste utfører kontrollaktiviteter som et sett med ubevisste handlinger gjennom dagen. Det er viktig at man blir seg bevisst på hvordan kontrollen kan bli dokumentert. I eksemplet til A2 ser vi at man har valgt en enkel kontrollaktivitet som grunnlag for 18

19 egenkontrollbeskrivelsen. Dersom dette oppfattes som tilfredsstillende av alle berørte parter, skal man ikke legge mere inn i kontrollaktiviteten, men spørre hvordan man oppbevarer kontrollsporet som gir en mulighet til å teste gjennomføringen og kvaliteten på kontrollaktiviteten. Hva skal gjøres: faggruppeansvarlig for Datadrift eller Windows vurderer konsekvensene slik de er beskrevet fra leverandør og uavhengige sikkerhetsorganisasjoner faggruppeansvarlig Nettverk vurderer konsekvensene slik de er beskrevet fra leverandør og uavhengige sikkerhetsorganisasjoner fagpersonell baserer sin prioritering på grunnlag av vurderingene og begrunner sin prioritering skriftlig i sin månedlige rapport til Faggruppeansvarlig for Datadrift, Windows eller Nettverk fagpersonell setter opp en kjøreplan for endringen Tabell 8; Utdrag fra Eksempel A2 19

20 A4: Monitorering og Evaluering I forhold til de 5 hovedelementene til God IT-styring og kontroll /IT Governance (se figur 3), vil prosesser innen monitorering og evaluering (ME) være fordelt innen alle de fem elementer, og ha fokus på kontrollog evalueringsfunksjoner av mer administrativ og strategisk art. Det påligger daglig ledelse, styret og internrevisjonen (hvis den er etablert) å påse at dette området er tilfredsstillende håndtert slik at foretaket kan dokumentere etterlevelse av lovkrav og gjennomføring av internkontroll for å sikre God IT Styring og Kontroll i de øvrige 4 hovedelementene. De 4 prosessene innen Monitorering og evaluering er vist i tabell 8: A4: Monitorering og Evaluering (Monitor and Evaluate) ME1 - Monitor and Evaluate IT Performance ME2 - Monitor and Evaluate Internal Control Tabell 9: CobiTs ME-prosesser ME3 - Ensure Regulatory Compliance ME4 - Provide IT Governance A4.1 Planlegge Mange virksomheter tar et bevisst valg om ikke å prioritere målinger, monitorering og evaluering ved når de skal bygge opp prosesser for Styring og kontroll som beskrevet i dette dokumentet. Vi anbefaler at man gjør en enkel vurdering av hvordan foretaket etterlever lovpålagte krav og selvpålagte krav i styrende dokumenter, samt hva som finnes av IT-Styring og kontrollprosessen. 2 A4.2 Utføre Det er viktig å formulere ytelsesmål som er kvantitative og mulige å evaluere for å vurdere om leveransene har vært suksessfylte eller ikke (ME1). Dette er særdeles viktig i forbindelse med utkontraktering og eksterne og interne SLA-avtaler (Service Level Agreement) eller OLA-avtaler (Operation Level Agreement). Når det gjelder ME2, oppfølging av Intern Kontroll, vil det være viktig at man har en klar beskrivelse av hvem som har Sørge for, Utføre- og Påse -ansvar hos de involverte. Tabell 9 nedenfor viser hvordan et RACI-kart (Responsible, Accountable, Consulted, Informed) kan skille mellom: de som har Utførende ansvar og driver IT Management (outsourcer eller intern IT Drift) de som har et Sørge for og Påse-ansvar (IT Governance). eksterne interessenter (som forretningsenheter osv.) Eksempel: I figur 6 nedenfor vises et RACI-kart for de forskjellige IKT-prosessene for å vise samhandling og dialog for de enkelte IKT aktivitetene som må utføres for hver enkelt IKT prosess. Det må legges vekt på å få fram roller og ansvar for Planlegging, Utførelse, Sjekking og Handling. 2 Erfaringsbasert observasjon: Dessverre blir ofte et prosjekt iverksatt for å innføre Internkontroll og internkontroll-rapportering helt uavhengig av (og ofte fullstendig uvitende om) arbeid som allerede er gjort for å etablere gode egenkontrollhandlinger i foretaket. Slike prosjekter er ofte initiert ut fra økonomirelaterte behov om oppfyllelse av Bokføringsloven, Regnskapsloven og Aksjeloven, og konkluderer ofte med at COSO skal være foretakets rammeverk for Internkontroll av forretningsprosesser. Som vi har forsøkt å vise tidligere i dette dokumentet, vil et slikt snevert syn bare fokusere på å få, ha og utføre finansiell kontroll i selskapet. Dette skjer uten at man vurderer hvordan man får kontroll på den operative risikoen selskapet også har for å redusere denne type risiko ned til et akseptabelt nivå. 20