Kortlægning af it-systemer forbinder virksomhedens aktiviteter med de applikationer, leverandører, data og tekniske forbindelser, der får arbejdet til at fungere. Et anvendeligt systemkort kan besvare, hvor en kundeoplysning sendes hen, hvilket login en kritisk opgave afhænger af, og hvem der kan bekræfte en bestemt integration.
Kortlægningen består typisk af et register og flere enkle visninger. Den er ikke færdig, fordi alle kendte servere er tegnet på én stor figur. Også SaaS-tjenester, manuelle eksporter, eksterne administratorer og enheder kan være afgørende. Denne guide viser en praktisk metode med en udfyldt kæde fra kundeportal til fakturering.
Afklar hvilket spørgsmål kortet skal løse
Vælg først et konkret anvendelsesformål. Ved et systemskift skal kortet vise berørte integrationer og opgaver. Ved et sikkerhedsbrud skal det vise mulige dataveje og kontakter. Ved beredskabsplanlægning skal det vise de afhængigheder, der kan stoppe en prioriteret aktivitet. Det samme grundregister kan understøtte alle tre, men visningerne bør være forskellige.
Datatilsynets vejledning om beskyttelse af personoplysninger beskriver sikkerhed gennem systemets livscyklus. Et systemkort kan støtte dette arbejde ved at gøre ændringer og behandlingssteder synlige. Kortlægningen er dog ikke i sig selv en vurdering af, om hver behandling er lovlig.
Den franske ANSSI’s metode til systemkortlægning er en teknisk og organisatorisk reference for at beskrive et informationssystem. Den kan inspirere de valgte visninger, men gør ikke franske myndighedskrav til danske virksomhedspligter. I dansk praksis skal kortet forbindes med organisationens faktiske krav og ansvar.
Et systemregister med stabile referencer
Giv hvert system en entydig reference. Navne ændrer sig ved indkøb, sammenlægninger og leverandørskift, mens en stabil reference gør det muligt at forbinde historik og bilag. Det samme gælder integrationer: to forbindelser mellem de samme programmer kan have forskelligt indhold og forskellige ejere.
I den fiktive virksomhed Brohandel registreres følgende tre centrale systemer:
| Reference | System og opgave | Systemejer | Relevante oplysninger |
|---|---|---|---|
| S01 | Kundeportal til bestillinger | Salgschef | Kontaktoplysninger, bestilling og leveringssted |
| S02 | Ordre- og lagerstyring | Driftschef | Ordrelinjer, beholdning og leveringsstatus |
| S03 | Regnskabstjeneste | Økonomichef | Fakturagrundlag og nødvendige kundedata |
Registeret indeholder desuden driftsleverandør, teknisk kontakt, loginmetode og dato for seneste bekræftelse. Usikre oplysninger markeres som uafklarede med en ansvarlig. Hvis salgschefen ikke ved, hvor portalens fejllogs opbevares, skal feltet ikke udfyldes med en antaget serverplacering.
Detaljeringsgraden følger formålet. En samlet applikationspost kan være tilstrækkelig til en forretningsvisning. Ved en konkret sikkerhedsundersøgelse kan databaser, gateways og administrative forbindelser skulle beskrives særskilt. Brug samme referencekæde, så oplysningerne kan forbindes uden at alle brugere skal læse den dybeste tekniske visning.
Indsaml fra både teknik og arbejdsprocesser
Et teknisk inventar kan finde kendte enheder og installeret software, men overser ofte tjenester, som en afdeling har købt direkte. Spørg derfor medarbejderne, hvor de faktisk udfører opgaven. Indkøbslister, leverandøraftaler, integrationsopsætninger og de eksisterende behandlingsfortegnelser kan vise forskellige dele af virkeligheden.
Bed en medarbejder gennemgå én normal ordre fra modtagelse til afslutning. Noter de steder, hvor oplysninger tastes igen, eksporteres til regneark eller sendes med mail. En manuel overførsel er også en datavej, selv om den ikke fremgår af netværksdiagrammet. Det er netop disse mellemtrin, der ofte har uklare slette- og adgangsregler.
Bevar kilden til hver væsentlig oplysning. En leverandørs arkitekturbeskrivelse kan vise den planlagte løsning, mens en driftskontrol viser den aktuelle opsætning. Hvis de to afviger, skal uoverensstemmelsen afklares. Markér ikke den pæneste beskrivelse som sand alene, fordi den kommer fra et formelt dokument.
Beskriv forbindelsen, ikke kun pilen
En pil mellem to systemer skal have en mening. Angiv retning, udløsende hændelse, indhold, modtager og ansvarlig for forbindelsen. Noter desuden, hvad der sker ved fejl: bliver data gemt i en kø, sendt igen, eller skal en medarbejder gøre noget?
Brohandels forbindelse F01 går fra kundeportalen S01 til ordresystemet S02. Den udløses af en accepteret bestilling og indeholder ordrenummer, varenummer, antal, kundereference og leveringsadresse. Portalteamet ejer afsendelsen, mens driftsteamet ejer modtagelsen. Ved utilgængeligt ordresystem står bestillingen i portalens kø og får endnu ingen lagerbekræftelse.
Forbindelse F02 går fra S02 til regnskabstjenesten S03 efter klarmelding til fakturering. Den sender fakturagrundlag, men behøver ikke hele kundesagens fritekst. Denne afgrænsning kan vurderes med dataminimering. En fælles datamodel med alle felter i hver overførsel ville gøre det sværere at begrunde mængden.
Tegn flere visninger af samme oplysninger
Forretningsvisningen kan vise bestilling, lagerkontrol og fakturering. Applikationsvisningen viser S01, S02 og S03 med forbindelserne F01 og F02. Den tekniske visning viser driftsmiljø, netværk, identitetstjeneste og backup. En adgangsvisning viser medarbejderroller, administratorer og eksterne konti.
Ingen af visningerne bør opfinde sit eget navn for den samme applikation. Det gør ændringer svære at gennemføre korrekt. Brug en kort tegnforklaring: En fuld pil er en bekræftet dataoverførsel; en stiplet markering kan være en uafklaret afhængighed, hvis den konvention forklares. Undgå at tegne en antaget forbindelse på samme måde som en observeret.
Beskyttelsesniveau og publikum skal også passe sammen. Ledelsen har normalt ikke brug for netværksadresser eller detaljer om nødadgang for at prioritere en kritisk aktivitet. Den detaljerede driftsvisning kan derfor have snævrere adgang end den overordnede procesvisning.
Forbind kortet med behandlingsfortegnelsen
Fortegnelsen over behandlingsaktiviteter beskriver behandling ud fra formål og de relevante lovbestemte oplysninger. Systemkortet beskriver de komponenter, der understøtter behandlingen. En aktivitet kan benytte flere systemer, og det samme system kan understøtte flere aktiviteter.
I Brohandel forbindes aktiviteten ordrebehandling med S01 og S02, mens fakturering forbindes med S03 og den nødvendige del af S02. Kortlægningen gør det muligt at spørge, om en ny integration ændrer modtagere, oplysninger eller opbevaring. Den ændrer ikke automatisk behandlingsgrundlaget eller giver lov til et nyt formål.
Når oplysninger går til en leverandør, afklares rollen særskilt. En teknisk pil er ikke nok til at afgøre, om modtageren er dataansvarlig eller databehandler. Kortet leverer fakta om formål og middelvalg, som den juridiske vurdering bygger på.
Brug afhængigheder til sikkerhed og beredskab
Brohandel opdager, at alle tre systemer bruger samme identitetstjeneste. Selv om kundeportalen teknisk er tilgængelig, kan medarbejderne ikke åbne den ved fejl i login. Den oplysning skal indgå i beredskabsplanen, ellers bygger nødarbejdet på en adgang, der kan være væk.
Kortet viser også, hvor en fejlet ordreoverførsel kan undersøges. Sikkerhedslogningen skal kunne forbinde de relevante referencer uden at kopiere hele kundeordren til alle logs. Systemejeren og driftsteamet aftaler, hvilket led der dokumenterer modtagelse, så et teknisk forsøg ikke forveksles med en gennemført ordre.
Ved kryptering viser datavejene, hvor beskyttede forbindelser slutter, og hvor data ligger læsbart til rådighed for applikationen. Den viden er nødvendig for at vurdere risikoen ved en kompromitteret komponent. Et enkelt symbol for krypteret system kan ellers skjule forskellige former for adgang.
En opdaget gammel integration skal undersøges
Under kortlægningen finder økonomiteamet en ugentlig eksport til den tidligere regnskabsleverandør. Systemregistret kalder leverandøren afviklet, men driften kan se en aktiv planlagt opgave. Teamet sletter ikke blot den gamle pil. Først afklares, om eksporten stadig har et gyldigt formål, hvilke oplysninger den sender, og hvem der modtager dem.
I det fiktive forløb bekræfter økonomichefen, at eksporten ikke længere er nødvendig. It planlægger lukning, kontrollerer de resterende adgange og afklarer behandling af eksisterende kopier med leverandøren. Efter lukningen kontrolleres, at opgaven ikke kører, og at en eventuel fejl ikke automatisk genaktiverer den.
Kortet opdateres med afslutningsdato og reference til beslutningen. Fundet kan også udløse en særskilt vurdering af de hidtidige overførsler. Kortlægningen hjælper med at identificere forholdet, men må ikke bruges til at kalde al tidligere behandling lovlig efterfølgende.
Vælg et værktøj, der kan vedligeholdes
Et mindre register kan begynde i et kontrolleret regneark med enkle diagrammer. Ved flere teams og mange ændringer kan et dedikeret værktøj lette referencer, adgang og versionsstyring. Vurder værktøjet på samme opgave: opret et system, forbind et flow, ret en ejer og eksporter en læsbar visning.
Kontroller især, om faktuelle ændringer bliver synlige i de relevante visninger. Hvis systemejeren opdateres i registeret, men figuren stadig peger på en fratrådt medarbejder, er materialet ikke sammenhængende. Eksporten skal også kunne forstås uden særlige interne forkortelser eller adgang til det levende værktøj.
Forankr opdatering ved systemindkøb, ændring af integrationer, leverandørskift og afvikling. Informationssikkerhedspolitikken kan placere dette ansvar. En planlagt gennemgang kan opdage oversete ændringer, men den bør supplere ændringsprocessen, ikke være den eneste anledning til at rette kortet.
Ved aflevering gennemgår forretning og drift mindst én hel kæde sammen. Begge skal kunne forklare oplysninger, ansvar og fejladfærd. Bevar uafklarede punkter med en ejer, frem for at skjule dem i et tilsyneladende komplet diagram. Henvisningerne er kontrolleret 8. september 2026; Brohandel og dens systemkæde er et udfyldt, fiktivt eksempel.