Granskning av ekonomisystemet och integrationer till försystem

Granskning av ekonomisystemet och integrationer till försystem Malmö Stadsrevision Malmö Stadsrevision November, 2008

Sammanfattning Malmö Stadsrevision har önskat en granskning av systemdokumentationen över integrationer mellan försystem och ekonomisystem och verifierande walk-throught granskning av ett antal transaktioner i produktionsmiljö. Granskningen har genomförts av Transcendent Group. Malmö kommun har under perioden 2006 2007 successivt implementerat ett nytt ekonomisystem Raindance. Arbetet med övergången har varit mycket omfattande. Totalt har ca 6 000 användare berörts. Implementeringen har bl a inneburit att ett stort antal verksamhetssystem behövt integreras till det nya ekonomisystemet. Integrationerna har byggts i integrationsmotorn Teis. Granskningen inkluderade indatakontroller (1), kontroller för bearbetning av information (2), integritet och riktighet i fasta data/parametrar (åtkomstkontroller) (3) och utdatakontroller (4). I denna granskning omfattar områdena 1 och 4 integrationen mellan ekonomisystemet Raindance och försystemen Origo, Husar, Primas, Bill, Elite och Procapia, via integrationsmotorn Teis. Område 2 och 3 omfattar ekonomisystemet Raindance. Granskningen visade att hanteringen av Raindance och dess integrationer med försystem fungerar tillfredsställande men att det finns ett flertal risker kopplat till denna hantering. Utöver ett antal övergripande risker identifierades brister i överföringskontroller, bearbetningskontroller och åtkomstkontroller. Totalt noterades 10 förbättringsområden varav tre bedömdes som mycket kritiska. Dessa var: - Systemdokumentation saknas - Högt personberoende - Gruppkonton i Raindance och Teis Stockholm, 2008-11-27 Magnus Thyllman Uppdragsansvarig Certifierad IT-revisor Malmö Stadsrevision 2 (13)

Innehållsförteckning 1 Inledning...4 1.1 Bakgrund... 4 1.2 Omfattning... 4 1.3 Utfört arbete och angreppssätt... 4 2 Resultat...6 2.1 Övergripande kontroller... 6 2.2 Överföringskontroller... 6 2.3 Bearbetningskontroller i Raindance... 11 2.4 Åtkomstkontroller i Raindance... 11 3 Identifierade förbättringsområden...13 Malmö Stadsrevision 3 (13)

1 Inledning Malmö Stadsrevision har önskat en granskning av systemdokumentationen över integrationer mellan försystem och ekonomisystem och verifierande walk-throught granskning av ett antal transaktioner i produktionsmiljö. Granskningen har genomförts av Transcendent Group. 1.1 Bakgrund Malmö kommun har under perioden 2006 2007 successivt implementerat ett nytt ekonomisystem Raindance. Arbetet med övergången har varit mycket omfattande. Totalt har ca 6 000 användare berörts. Implementeringen har bl a inneburit att ett stort antal verksamhetssystem behövt integreras till det nya ekonomisystemet. Integrationerna har byggts i integrationsmotorn Teis. 1.2 Omfattning Granskningen inkluderade följande områden: 1. Indatakontroller 2. Kontroller för bearbetning av information 3. Integritet och riktighet i fasta data/parametrar (åtkomstkontroller) 4. Utdatakontroller I denna granskning omfattar områdena 1 och 4 integrationen mellan ekonomisystemet Raindance och försystemen Origo, Husar, Primas, Bill, Elite och Procapia, via integrationsmotorn Teis. Område 2 och 3 omfattar ekonomisystemet Raindance. 1.3 Utfört arbete och angreppssätt Granskningen omfattar följande steg: 1. Identifiering av nyckelpersoner för informationsinsamling 2. Fastläggande av tidplan för informationsinsamling 3. Förberedande arbete inför granskning (främst inläsning av relevant dokumentation) 4. På-plats-granskning a. Intervjuer b. Verifiering av befintliga kontroller (manuella och programmerade) c. Observation av system- och integrationsdokumentation d. Walk through av ett antal transaktioner 5. Analys 6. Faktaavstämning 7. Rapportering i form av skriftlig rapport till Stadsrevisionen 1.3.1 Intervjuade personer 17 personer har intervjuats och deltagit i utredningen. Dessa är: Maria Kolak, Projektledare Raindance Charlotte Valsberg, f.d. systemägare Raindance Marianne Jönsson, Redovisningschef Malmö Stadsrevision 4 (13)

Peter Johansson, Informationssäkerhetschef Christer Christoffersson, IT-driftchef Johan Almqvist, IT-drift Harald Nilsson, f.d. systemägare Origo Anders Ljungdahl, systemägare Elit Ann Åkesson superanvändare Elit Ingegärd Holmberg superanvändare Elit Mats Rudolfsson, systemägare Bill Ann-Charlotte Malmros, systemägare Husar Ann-Christine Nordqvist, bitr. systemägare Husar Kaj Persson, systemägare Procapita Majvi Zahlee, systemägare Prima Irene Ek, ekonomichef SDF Centrum Torbjörn Sundell, Alfa Malmö Stadsrevision 5 (13)

2 Resultat Granskningen visade att hanteringen av Raindance och dess integrationer med försystem fungerar tillfredsställande men att det finns ett flertal risker kopplat till denna hantering. 2.1 Övergripande kontroller Raindance tar främst emot filer från andra försystem och för de försystem som ingick i denna granskning skickas inga filer från Raindance. Den utdata som sker från Raindance är främst i form av rapporter som tas ut. Som rapportgenerator används QlikView, vilken kan analysera stora mängder data. Analysprogrammet kan användas för att kontrollera data genererad från olika moduler inom Raindance. QlikView bedöms fungera väl. Vidare har en riskanalys för Raindance utförts med hjälp av IFACTS där risker kopplat till tillgänglighet, sekretess och integritet har utvärderats på en övergripande nivå. Granskningen visade att det saknas systemdokumentation för Raindance och dess integrationer med olika försystem. För Raindance och för filöverföringar till vissa försystem finns användarhandböcker och beskrivningar för användarna men det saknas dokumentation på teknisk/funktionell nivå. För Raindance finns material från förstudien som beskriver hur de ville att systemet skulle kunna användas. Detta material bör kunna ligga till grund för att upprätta systemdokumentation. Filerna till Raindance går via integrationsmotorn Teis. För Teis finns script med hårdkodad info om alla data som ska hämtas från olika databaser. Dessa script skulle dock vara svåra att förstå för en utomstående person, även med teknisk bakgrund. Mer lättförståeliga beskrivningar av integrationerna, t ex i form av flödesbeskrivningar finns endast för ett fåtal system Kryptering används inte vid filöverföringar inom Malmö Stads nätverk, med undantag för bankbetalningar. Detta innebär att all intern nätverkstrafik skickas i klartext. Det har inte heller tagits något formellt ledningsbeslut eller ställningstagande avseende detta. I samband med granskningen har noterats att det finns ett stort nyckelpersonsberoende kring en av projektledarna för Raindance. Orsaken till detta är främst att två andra nyckelpersoner kopplat till Raindance nyligen avslutat sina tjänster. 2.1.1 Slutsats Granskningen visade att det saknas systemdokumentation för Raindance och dess integrationer med olika försystem, vilket är en väsentlig brist. Det finns även ett riskfyllt nyckelpersonsberoende. Ingen kryptering sker av information som skickas inom Malmö Stad (med undantag för filer till bank). 2.2 Överföringskontroller Raindance tar emot data från ca 60 system. Det är filöverföringar som överförs med en viss periodicitet (oftast månadsvis) av redovisningsdata. Vissa filer läses in och uppdaterar Malmö Stadsrevision 6 (13)

Raindance automatisk, t ex leverantörsfakturor som är attesterade. De flesta filöverföringarna baseras på manuellt moment i form av att en person sätter igång inläsning av filen. Vid inläsning av data sker ingen automatisk avstämning av skickat från försystem mot mottaget i RD. Dock finns överföringslista som kan tas ut där totalt överfört belopp anges. Detta kan stämmas av manuellt. Vissa formatkontroller utförs här (ex felaktiga värden, datum osv). Överföringsrapport vid inläsning till RD (formatkontroller) Kryptering används inte vid filöverföringar inom Malmö Stads nätverk, med undantag för bankbetalningar. Detta innebär att all intern nätverkstrafik skickas i klartext. Vid överföring av information till Raindance från olika försystem görs inga automatiska kontroller av att filen inte har modifierats under överföringen. IT-driftavdelningen kontroller att filerna har rätt format och att de flyttas på ett korrekt sätt. Övervakning finns från kl. 7-17 vardagar enligt avtal. IT-driften erhåller felmeddelande via e-mail om det händer något. Serviceavtal finns upprättade för varje applikation. Intrångsövervakning finns också. Varje dag görs kontroller av Teissystemet på morgonen, vid lunch samt på eftermiddagen. Genom övervakningsfunktionen i Teis kan de se hur många noder/integrationer som är igång. Vid fel blir dessa rödmarkerade. Granskningen av överföringskontroller omfattade filöverföringar till Raindance från försystemen Origo, Elit, Bill, Husar, Procapita och Prima. Granskningen bestod dels av en utvärdering av interna rutiner och kontroller i samband med dessa överföringar och dels av ett s.k. walk through test där utvalda transaktioner följdes för att verifiera överföringskedjan från försystemet till Raindance. Walk through testet gjordes för transaktioner från samtliga försystem i granskningen och omfattade en stor majoritet av alla transaktionstyper för dessa försystem. Resultatet från testet visade att transaktionerna gick att följa in i Raindance för samtliga testade transaktionstyper utom vid överföring av information från försystemet Elit som skickas via Bill in i Raindance. Detta beror på att det i Bill görs en schablonfördelning mellan skolorna utifrån summan av alla fakturerade avgifter. Det går därmed ej att verifiera att avgiften för just det utvalda barnet finns med i beloppet som fördelas ut på skolorna och som bokförs i Raindance. Dock gick det att bevisa att det schablonberäknade beloppen i Bill överfördes på ett korrekt sätt in i Raindance. Resultatet från testerna visar att överföringen till Raindance från försystem fungerar tillfredsställande. 2.2.1 Origo Origo används för hantering av ärenden inom vård och omsorg. Filöverföringarna från Origo går inte direkt in i Raindance utan går via systemen Bill och Prismodulen. Bill används för fakturering av hyror och matabonnemang till köparen av tjänsten medan Prismodulen används för internfakturering mellan olika förvaltningar. Det finns dokumenterade lathundar som beskriver handhavandet vid dessa filöverföringar. Det sker en överföring per månad mellan Origo och Bill. I samband med överföringen går ett mail till debiteringsenheten och systemförvaltaren för Origo och Bill för manuell rimlighetskontroll. Vid inläsning till Bill från Origo framställs också en rapport där Malmö Stadsrevision 7 (13)

extremvärden t ex i form av alltför stora vård- och omsorgsbelopp listas enligt ett bestämt gränsvärde. I Origo finns även en Obs lista, vilket är en lista med dubbelutbetalningar mm som kan tas ut av verksamheten. Från Origo till Prismodulen sker överföringen genom att databastabellen Zorigo uppdateras automatiskt. Detta sker enligt ett fastställt arbetsschema. Lathund finns för kontroller vid överföring till Prismodulen från Origo (Zorigo). En avstämningslista i Origo för kommande köp/sälj-data som ska överföras till Prismodulen används för att reglera fel mellan köpare och säljare. En på köparsidan och en på säljsidan tar ut denna rapport och kontrollerar exempelvis om de glömt skriva ut en person från en vårdplats. Köparna i det här fallet är myndigheter och säljarena är stadsdelarna. Personal vid serviceförvaltningens debiteringsenhet jobbar med ekonomitransaktionerna i Prismodulen. De gör rimlighetsbedömningar av importerade filer enligt dokumenterad instruktion. Information från Origo som går via Prismodulen attesteras av budgetansvariga i Raindance på respektive förvaltning innan de bokas där. Listor skapas i Origo som används som fakturaunderlag för utbetalning till vårdhem etc. Dessa attesteras och leverantörsfakturor skapas manuellt. 2.2.2 Elit Elit hanterar förskolor, grundskolor och gymnasieskolor och vilka barn/elever som finns i dessa. Filöverföringarna från Elit går inte direkt in i Raindance utan går via systemen Bill och Prismodulen. Bill används för fakturering av förskoleavgifter och föräldrabidrag medan Prismodulen används för internfakturering mellan olika förvaltningar. Det finns dokumenterade lathundar som beskriver handhavandet vid dessa filöverföringar. Systemleverantören Alfa är även förvaltare av systemet och kontrollerar att alla körningar görs. Validering vid registrering i Elit sker i de flesta fall mot fakta tabeller. På individnivå sker alla kontroller mot kommuninvånareregistret och/eller kommunens personalregister. Rimlighetskontroller finns även mellan verksamheterna t ex om registrering av ett barn skulle ske både på förskola/skolbarnomsorg. Från Origo till Prismodulen sker överföringen genom att databastabellen Zelit uppdateras automatiskt. Detta sker enligt ett fastställt arbetsschema. Lathund finns för kontroller vid överföring till Prismodulen från Elit (Zelit). Information från Elit som går via Prismodulen attesteras av budgetansvariga i Raindance på respektive förvaltning innan de bokas där. Listor skapas i Elit som används som fakturaunderlag för utbetalning till skolorna. Dessa attesteras och leverantörsfakturor skapas manuellt. 2.2.3 Bill Bill är ett faktureringssystem som en gång i månaden uppdaterar Raindance. Fem importfiler från Elit slås ihop till en fil in i Raindance. Överföringen görs via en schemalagd batch. Pseudokoder används i Bill vilket omvandlas till kontosträng i Raindance Från Origo kommer en fil in i Bill som är uppdelat på två transaktionstyper, dels hyror och dels matabonnemang. Pseudokoder används i Bill vilket omvandlas till kontosträng i Malmö Stadsrevision 8 (13)

Raindance. En rimlighetskontroll görs av systemägaren varje månad där större avvikelser kontrolleras. En Origorapport (OBS-lista) tas även ut med sammanställning över debiteringskörningen som rimlighetskontrolleras. Rapporten sparas och sätts in i en pärm. Från Elit kommer 5 importfiler som sedan klumpas ihop till en fil som skickas till Raindance. Filen är en schablonfördelning mellan skolorna utifrån summan av alla fakturerade avgifter. Systemägaren stämmer av att alla dessa har kommit in i Bill. Om de inte har det utreder han vad som hänt. Avstämning görs sedan även på det totala beloppet som skulle bli utbetalt totalt i Bill och jämför med lista från Raindance med vad som faktiskt har blivit utbetalt. Denna kontroll skrivs ut och sätts in i pärm som sparas månad för månad. Avstämningen skickas även till Sven-Olof Jeppsson, Serviceförvaltningens huvudkontor. 2.2.4 Husar Husar används för hantering av avtal och debitering av fastighetskontorets markupplåtelser, arrenden och tomträtter. Månadsvis görs en hyreskörning i Husar och den bitr. systemägaren gör då en utskrift till respektive enhet. De får någon dag på sig att kontrollera listan och signera den med eventuella ändringar. Sedan skapas den definitiva bokföringslistan, vilken lämnas till enheterna. Definitiva bokföringsfilen är då skapad. Interna upplåtelser går in i Raindance och externa går för utprintning av faktura. Fördelningen baseras på kundkod hos motpart. Vid överföring till ekonomi skapas en aviseringsfil som läggs på en lokal server. Integrationsmotorn Teis hämtar sedan filen från servern. Det finns ingen logg i Husar vid filflytten till serverytan. Ändring av hyror skulle kunna ske av någon av de olika enheterna. De har inte begränsat åtkomst mellan enheterna. Större förskingring skulle upptäckas i rimlighetskontroller men ej mindre belopp. Inbetalningar kommer via BGC in i Husar (OCR-fil). Vissa betalar manuellt via bankgiro. På samma sätt som ovan skapas en inbetalningsfil som läses in i Raindance. När filen lästs in i Raindance (RD) kontrollerar bitr. systemägaren en överföringsrapport (ÖF-rapport) och kontrollerar att allt gått in i RD (rapporten genereras automatiskt i RD och visar transaktioner som ej gått över korrekt vanligtvis 0-aviseringar). Bitr. systemägaren tar sedan ut en verifikationsutskrift från Raindance och jämför med Husar. ÖF-kontrollistan är en kontroll i Raindance som är generell vid all inläsning. En gång i månaden stämmer bitr. systemägaren av kundreskontra samt post- /och bankgiro mellan Raindance och Husar. Ett problem som uppmärksammats är att Raindance inte tar emot betalningar från Husar med förfallodatum på helgerna. Vid årsskiftet blev det då problem vilket innebar att de var tvungna att gå in i produktionsdatabasen i Raindance för att modifiera detta. 2.2.5 Procapita Procapita används för hantering av bidrag inom individ- och familjeomsorgen. Det finns en roll i Procapita som används för att släppa iväg betalningarna. Respektive förvaltning skapar en batchkörning manuellt varje dag (på de flesta förvaltningar). Bokföringsfilen som skickas till Raindance är på detaljnivå. 11 filer skickas en för varje nämnd plus en gemensam för de fem Arbete- och integrationscentrumen. Malmö Stadsrevision 9 (13)

Filerna läggs på Procapita-servern där integrationsmotorn Teis hämtar dessa och skickar vidare till Raindance. Tieto Enator kontrollerar varje dag att en fil har framställts och lagts på servern. Ekonomiavdelningen på respektive förvaltning kontrollerar också att totalsumman som kommer in i Raindance stämmer med underlag från Procapita. I Procapita sätter varje förvaltning upp en beloppskontroll i systemet för utbetalningar. Kontroll görs också av att kontot är giltigt och att det ligger inom den perioden som utbetalningen avser. Varje förvaltning har sin uppsättning och kan göra lokala ändringar. En logg finns för överföringen men ingen granskning sker av denna Vid tidpunkten för intervjun gjordes förvaltningarnas attest och godkännande efter att utbetalningen skett. Efter en allvarlig incident där dubbla socialbidrag betalades ut som följd av att ett index i systemet gick i taket har rutinerna ändrats. Numera ringer varje förvaltning till Internetbanken (eller bankgirot för leverantörsbetalningar) för att stämma av och godkänna beloppet innan utbetalning sker. Den nya rutinen är tidskrävande för förvaltningarna men ses som en nödvändighet tills en smidigare lösning kan hittas. Det finns inga dokumenterade rutiner i form av lathund eller liknande som beskriver processen för filöverföringarna i samband med utbetalning av bidragen. 2.2.6 Primas Primas är ett delsystem inom lönesystemet Prima där lönefilen skapas. I Primas skapas bokföringsposter. Lönefilen delas upp på en fil per förvaltning i systemet KO innan den når Raindance via integrationsmotorn Teis. Filen innehåller lön plus semesterskuld. Förvaltningarna ansvarar själva för schemaläggning av lönekörningarna. Vid lönekörningen skapas en fellista för de poster som ej är giltiga. Dessa poster stoppas i körningen och måste köras igen när de är rättade. Detta görs av respektive förvaltning tills samtliga poster gått igenom körningen. I Primas kontrolleras också att alla motbokningar blir noll. Budgetansvariga på respektive förvaltning stämmer även av att sina anställda fått rätt lön och att detta kommit in i Raindance. Efter lönekörningen får lönekontoret ett belopp på utbetalda löner och skickar en betalningsanmodan till Kassan på Finansförvaltningen där det bokas motsvarande belopp på Finansförvaltningen. Efter några dagar kommer ett kontoutdrag från banken som beloppet stäms av mot. Det finns inga dokumenterade rutiner i form av lathund eller liknande som beskriver processen för filöverföringarna i samband med lönekörningarna. 2.2.7 Slutsats Överföringarna till Raindance sker genom integrationsmotorn Teis. Det sker en mängd manuella kontroller i samband med överföringarna, vilket inkluderar rimlighetskontroller och Malmö Stadsrevision 10 (13)

avstämningskontroller på totalnivå. Det saknas dock automatiska kontroller som säkerställer att filerna som skickas ej har modifierats under transporten. Lathundar för hantering av filöverföringar minskar risken för fel i samband med dessa. Detta finns för de flesta försystem men saknas för Procapita och Primas. Trots vissa svagheter i interna kontroller identifierades inga felaktigheter i samband med granskning av transaktionsflödena (walk through-tester) in i Raindance 2.3 Bearbetningskontroller i Raindance Hanteringen av informationen i Raindance baseras på ett flertal inställda regler och styrparametrar. Ändring av dessa styrparametrar är begränsat till 5 personer på redovisningsavdelningen och ett fåtal personer på respektive förvaltning (som endast kan ändra i sina versioner av Raindance). Utöver detta finns ca 15 personer hos systemleverantören Logica med denna åtkomst. Ändringar av dessa styrparametrar kan ha en stor påverkan på informationen som hanteras i systemet. Det krävs dock inget formellt godkännande eller dokumentation av orsak till ändringar. Ändringarna loggas i systemet men det sker ingen regelbunden uppföljning av loggarna. Det är därmed inte säkert att missbruk av åtkomsten till dessa regler och styrparametrar skulle upptäckas. Samtliga aktiviteter i Raindance loggas. Det sker dock ingen strukturerad granskning och uppföljning av kritiska loggar i Raindance eller i de granskade försystemen. Exempel på kritiska loggar kan vara systemaktiviteter utförda av höga behörigheter, ändringar av höga behörigheter samt ändringar av känsliga systemparametrar. En bra kontroll i Raindance finns i form av Centralen som kan användas för att kontrollera fakturastatus, ankomstregistrerade fakturor, höga belopp, fakturor i omlopp med mera. Varje förvaltning har access att kontrollera sina fakturor. 2.3.1 Slutsats Bearbetningen av information i Raindance har god spårbarhet och kan vid behov följas upp. Det saknas dock en rutinmässig uppföljning av kritiska loggar. Ändringar av regler och styrparametrar i Raindance kan göras av ett flertal personer men kräver inga formella godkännanden, dokumenteras inte och följs inte upp i efterhand. 2.4 Åtkomstkontroller i Raindance En generell behörighetsrutin finns upprättad och det finns även lathundar som beskriver processen för hantering av behörigheter i Raindance. En behörighetsblankett som fylls i av ansvarig chef används för tilldelning av lämpliga behörighetsnivåer. Ett konto läggs up i nätverkskatalogen LDAP och en separat behörighet och eventuell attesträtt läggs upp i Raindance av systemförvaltare på respektive förvaltning. Om en person ska jobba på redovisningsavdelningen lägger redovisningsavdelningen upp denna. Den blankett som används vid nyupplägg används inte vid borttag och ändringar. Personalavdelningen meddelar om någon slutar. Från-datum och slut-datum anges i personalsystemet, vilket är synkat med LDAP-katalogen och därmed tas åtkomsten till Malmö Stadsrevision 11 (13)

nätverket automatiskt bort när personen slutar. Vid byte av tjänst inom Malmö kommun fungerar dock inte denna rutin utan den gamla behörigheten ligger ofta kvar även efter bytet. Det görs idag inga regelbundna kontroller av att befintliga behörigheter är korrekta och uppdaterade i Raindance. Gruppkonton (konton som kan användas av flera personer med ett gemensamt lösenord) finns för leverantören Logica, vilket innebär att det saknas individuell spårbarhet av systemaktiviteter som utförs av dessa konton. Dessa skapades under utvecklingen av Raindance men har inte tagits bort ännu. Enligt uppgift pågår ett arbete för att ta bort dessa och skapa unika användaridentiteter även för leverantören. Gruppkonton förekommer även i integrationsmotorn Teis, både för systemleverantören Tieto Enator och för den interna driftpersonalen på förvaltningsenheten. 2.4.1 Slutsats Behörighetsrutin finns upprättad och inkluderar även kontroller för att säkerställa att anställda som slutar ej kan komma åt systemen. Det finns dock brister i behörighetshanteringen av anställda som byter arbetsuppgifter inom Malmö Stad. Det saknas också rutiner för regelbunden uppföljning av befintliga behörigheter. Det noterades även en väsentlig risk i form av de gruppkonton som finns, både i Raindance och i Teis, vilka saknar individuell spårbarhet. Malmö Stadsrevision 12 (13)

3 Identifierade förbättringsområden Under vår utredning har vi gjort ett antal iakttagelser där vi ser att Malmö Stad har förbättringsmöjligheter som enligt vår bedömning bör beaktas. Riskklassificering Respektive förbättringsområde har riskklassificerats enligt följande skala: 1. Mycket kritiskt för myndighetens effektivitet och uppfyllande av verksamhetsmål på kort och lång sikt 2. Kritiskt för en god intern kontroll, effektivitet och tillförlitlighet i myndighetens IT-verksamhet 3. Väsentligt för en god intern kontroll, effektivitet och tillförlitlighet i myndighetens IT-verksamhet Risk- och ansvarsklassificering av förbättringsområden Risk Förbättringsområden 1 2 3 Övergripande kontroller 1. Systemdokumentation saknas 1 2. Högt personberoende 1 3. Kryptering vid kommunikation mellan egna system saknas 2 Överföringskontroller 4. Lathundar saknas för vissa integrationer 2 5. Automatiska integritetskontroller saknas vid inläsning i Raindance 2 Bearbetningskontroller 6. Ändring av styrparametrar i Raindance 2 7. Loggar kontrolleras ej regelbundet 3 Åtkomstkontroller 8. Bristande underhåll av behörigheter 2 9. Bristande rutiner för borttag av behörigheter vid byte av tjänst 10. Gruppkonton i Raindance och Teis 1 3 Respektive förbättringsområde beskrivs i detalj i bilaga 1 Malmö Stadsrevision 13 (13)