En karta över IT-system ska hjälpa er att fatta beslut: vilka tjänster påverkas om ett system stannar, vart skickas personuppgifter och vem kan bekräfta att en integration fungerar? Börja med en verklig arbetsprocess och följ informationen genom den. En lista över programnamn räcker inte när det är kopplingarna mellan programmen som skapar riskerna.
Den här guiden visar hur ni bygger ett systemregister, en karta över dataflöden och en rutin för uppdatering. Ett genomgående, fiktivt exempel följer en beställning från kundportal till fakturering. Kartan blir ett arbetsunderlag för verksamhet, IT och dataskydd; den ersätter inte bedömningen av vilka behandlingar som är lagliga.
Bestäm vilken fråga kartan ska besvara
Välj ett avgränsat första syfte. Det kan vara att förbereda ett leverantörsbyte, förstå ett kritiskt avbrott eller hitta vilka system som behöver omfattas av en begäran om tillgång. Syftet styr detaljnivån. En verksamhetschef behöver se tjänster och ansvar, medan driftteamet behöver veta vilka databaser, identiteter och anslutningar som krävs.
Utse en ägare för kartläggningen och en kontakt per verksamhetsområde. Bestäm vad ett ”system” betyder i ert register. Är kundportalen en egen post trots att den delar databas med ärendehanteringen? Dokumentera regeln så att teamen inte räknar samma lösning på olika sätt. Använd stabila interna ID:n, eftersom produktnamn och leverantörer kan ändras.
Gör också tydligt vad som inte är kartlagt ännu. En streckad pil kan betyda att flödet är uppgivet i en intervju men inte tekniskt verifierat. En heldragen pil kan betyda att ansvarig har bekräftat det med ett aktuellt underlag. Skriv teckenförklaringen på själva kartan.
Samla fakta från flera håll
Kombinera intervjuer med tekniska inventeringar, inköpsunderlag och listor över godkända tjänster. Nätverksinventeringen hittar inte nödvändigtvis en molntjänst som marknadsavdelningen köper direkt. Ett avtal visar att tjänsten finns men inte säkert vilka uppgifter som laddas upp i dag.
Be medarbetaren beskriva sin senaste utförda arbetsuppgift. Vilket formulär användes, vilken fil exporterades och vem fick resultatet? Följ även undantag: vad händer om integrationen misslyckas eller en kund ringer i stället för att använda portalen? Manuella kalkylblad och mejl kan vara viktiga delar av det faktiska flödet.
Spara källa och verifieringsdatum på varje post. Om ekonomi säger att en gammal tjänst har avvecklats men IT ser aktiva anslutningar ska motsägelsen stå kvar som en öppen fråga med ansvarig. Välj inte den uppgift som gör kartan enklast. Kontrollera vad som faktiskt körs innan ni stänger posten.
Bygg ett litet men användbart systemregister
Börja med fält som någon kan underhålla. Registrera system-ID, funktion, verksamhetsägare, teknisk kontakt, leverantör, driftmiljö, centrala datakategorier och kritiska beroenden. Länka till avtal och säkerhetsdokument där de finns, i stället för att kopiera stora dokument till varje systempost.
| System i exemplet | Funktion och ägare | Data och beroende | Nästa kontroll |
|---|---|---|---|
| SYS-01 Kundportal | Tar emot beställningar; försäljningschef | Kontaktuppgifter och order; beroende av identitetstjänst | Verifiera vad som köas när ordersystemet stannar |
| SYS-02 Ordersystem | Planerar leverans; driftchef | Order, leveransadress och status | Kontrollera vilka fält som går vidare till ekonomi |
| SYS-03 Ekonomisystem | Skapar fakturor; ekonomichef | Fakturaunderlag och betalningsstatus | Bekräfta hantering av krediteringar och rättelser |
Uppgiften ”personuppgifter: ja” är ofta för grov. Ange om systemet hanterar exempelvis kundkontakter, anställdas uppgifter eller information som kan vara känslig. Beskriv kategorier, inte verkliga personers innehåll. Kartläggningen ska inte bli en extra databas med kundärenden.
Beskriv pilarna lika noggrant som systemen
Varje dataflöde behöver en riktning, en utlösande händelse, datakategorier och en ansvarig. Ange om det är en automatisk integration, en schemalagd fil eller en manuell export. Beskriv även vad som händer när mottagaren inte svarar: kö, nytt försök, felmeddelande eller förlust av information.
Ifylld flödespost FL-01: Kundportalen skickar en ny godkänd beställning till ordersystemet. Flödet innehåller ordernummer, tjänst, kontaktuppgift och leveransadress. Betalningskort och kundens övriga profil ska inte ingå. Integrationsansvarig äger överföringen. Vid fel ligger beställningen kvar i portalens kö, och kundtjänst får en avisering. Uppgiften är bekräftad genom ett kontrollerat prov med fiktiva data.
Den posten kan granskas mot en matris för uppgiftsminimering. Om ett nytt fält läggs till blir frågan konkret: behöver mottagaren fältet för sitt arbete, eller följde det bara med i standardexporten? Markera också var krypteringen börjar och slutar, utan att lagra nycklar eller hemligheter i kartan.
Använd flera vyer över samma underlag
En verksamhetsvy visar aktiviteter och tjänster. En applikationsvy visar system och flöden. En teknisk vy visar bland annat databaser, servrar och identitetstjänster. En driftvy kan beskriva platser, nät och leverantörsberoenden. De ska använda samma ID:n så att en läsare kan följa sambanden.
I exemplet kan den förenklade kedjan skrivas: kundportal → ordersystem → ekonomisystem. Under varje system finns en koppling till dess driftmiljö. Identitetstjänsten visas som ett gemensamt beroende för personalens åtkomst. Om identitetstjänsten slutar fungera kan flera program vara tekniskt tillgängliga samtidigt som personalen ändå inte kan använda dem.
Lägg inte alla tekniska detaljer i en enda bild. Dela hellre upp den och länka till systemposterna. En läsbar karta ska visa de beslutspunkter som hör till frågan, medan registret innehåller detaljerna som behövs för kontroll.
Koppla systemen till GDPR-registret
Registerförteckningen enligt artikel 30 är organiserad kring behandlingsaktiviteter. Systemkartan beskriver den tekniska och operativa miljön. Ett system kan stödja flera behandlingar, och en behandling kan använda många system. Skapa därför länkar mellan dem i stället för att ersätta det ena underlaget med det andra.
I GDPR beskriver artikel 30 registerinnehållet och artikel 32 säkerhetsbedömningen. Kartläggningen hjälper er att hitta det faktiska underlaget för dessa uppgifter. Den säger däremot inte automatiskt vilken rättslig grund, lagringstid eller mottagarroll som är korrekt.
När portalen skickar kunduppgifter till en extern supportleverantör behöver ansvarig kontrollera mottagaren och eventuell biträdesroll. Jämför flödet med personuppgiftsbiträdesavtalet. Om åtkomst sker från ett tredjeland behöver även den situationen bedömas, inte bara lagringsplatsen som står i produktbladet.
Låt en störning pröva kartans nytta
Ta bort ett system i en skrivbordsövning och följ konsekvenserna. Kan portalen ta emot nya order när ordersystemet är nere? Kan kundtjänsten se dem? Får kunden en automatisk bekräftelse som felaktigt ser ut som ett leveranslöfte? Dessa frågor gör systemkartan användbar för kontinuitetsplanen.
IT använder samma flöden för att kontrollera var fel kan upptäckas. Om portalen visar ”skickad” men ordersystemet saknar posten behövs loggar som kan koppla ihop händelserna. Ange lämpliga korrelations-ID:n och hänvisa till rutinen för säkerhetsloggning. Undvik att lösa spårbarheten genom att kopiera hela kundinnehållet till varje logg.
IMY:s vägledning om informationssäkerhet utgår från risker och lämpliga åtgärder. Använd kartan för att göra dessa bedömningar konkreta: vilket flöde kan röjas, ändras eller bli otillgängligt, vilka personer påverkas och vilken kontroll kan visa om skyddet fungerar?
Gör upptäckta luckor till åtgärder
Anta att ni hittar en aktiv export till en tidigare leverantör. Radera inte bara pilen. Verksamhetsägaren behöver först bekräfta om flödet fortfarande fyller ett ändamål. IT kontrollerar senaste körningen och vilka konton som används. Avtalsansvarig utreder vad som gäller för kvarvarande uppgifter hos mottagaren.
Om flödet ska stängas dokumenterar ni stoppdatum, ansvarig och hur resultatet verifieras. Kontrollera efteråt att inget schemalagt jobb fortsätter skicka och att reservrutinerna inte återskapar exporten. Uppdatera både kartan och berörda behandlingar. Det är den genomförda förändringen som minskar risken, inte att kartan ser mer ordnad ut.
Välj verktyg och underhåll som teamet klarar
Ett kalkylblad och tydliga diagram kan räcka för en begränsad miljö. Vid fler beroenden kan ett särskilt verktyg underlätta. Jämför alternativen genom samma arbetsprov: lägg till ett system, ändra ett flöde, tilldela en ansvarig, begränsa åtkomst och exportera ett läsbart underlag. Bedöm vad ni faktiskt har sett fungera.
Skydda kartan efter innehållet. Den kan avslöja administrativa gränssnitt och sårbara beroenden. Ge verksamheten tillgång till användbara vyer utan att sprida hemligheter eller detaljer som inte behövs. Lägg reglerna för ägarskap i informationssäkerhetspolicyn.
Bestäm slutligen vilka förändringar som utlöser uppdatering: nytt system, ändrad integration, ny leverantör, avveckling eller nytt användningsområde. Kräv att den som godkänner förändringen även bekräftar kartan. Visa senaste verifieringsdatum och öppna frågor. Då kan nästa granskare skilja en aktuell beskrivning från ett diagram som bara råkar finnas kvar.