En systemoversikt skal vise hvilke tjenester virksomheten er avhengig av, hvem som eier dem og hvordan informasjon beveger seg mellom dem. Den er grunnlag for tilgangsstyring, sikkerhetsarbeid, leverandøroppfølging og gjenoppretting. En liste over programnavn er en start, men viser sjelden hvilke forbindelser som kan spre feil eller personopplysninger videre.
For forbindelser mellom systemer kan TLS- og sertifikatkontrollen brukes til å dokumentere hvor krypteringen avsluttes, hvem som eier sertifikatet og hvordan fornyelse følges opp.
Denne veiledningen gir en praktisk metode for å lage og vedlikeholde kartet. NSMs beskrivelse av kategorien identifisere og kartlegge forklarer hvorfor forståelse av tjenester, teknologi og brukere er et grunnlag for sikkerhet. Når systemene behandler personopplysninger, støtter oversikten også virksomhetens arbeid etter GDPR. Et systemkart erstatter likevel ikke behandlingsprotokoll eller egne risikovurderinger.
Velg et konkret bruksområde for første versjon
Start med et avgrenset spørsmål som kartet skal hjelpe dere å besvare. Det kan være hvilke systemer som behandler kundedata, hva som må fungere for lønnsutbetaling eller hvilke leverandører som har administrative tilganger. Et tydelig bruksområde gjør det lettere å velge detaljnivå og prioritere opplysninger som må kontrolleres.
Unngå å samle alle tekniske detaljer før noen har bestemt hvordan kartet skal brukes. IP-adresser, programversjoner og nettverksregler kan være viktige i en teknisk oversikt, men ledelsen trenger først forståelse av tjenester og avhengigheter. Dere kan koble flere oversikter gjennom stabile referanser i stedet for å legge alt i ett regneark som blir vanskelig å vedlikeholde.
Ta utgangspunkt i virksomhetens leveranser
Be fagavdelingene beskrive sine viktigste oppgaver og hvilke verktøy de bruker. Spør om lokale regneark, nettløsninger, private kjøp som senere er tatt i bruk på jobb, og tjenester som følger med andre leveranser. Innkjøpsregisteret alene fanger ikke nødvendigvis opp løsninger som er gratis, inngår i en pakke eller administreres av en samarbeidspartner.
Beskriv hva systemet gjør, ikke bare hva det heter. «Behandler henvendelser fra kunder og lagrer vedlegg» er mer nyttig enn en produktbetegnelse når dere vurderer personvern og beredskap. Knytt tjenesten til en faglig eier som kan forklare behovet og konsekvensen av bortfall. Teknisk drift kan beskrive infrastrukturen, men vet ikke alltid hvilke arbeidsprosesser som stopper.
Skill mellom system, miljø og integrasjon
Et produkt kan ha forskjellige miljøer for produksjon, test og utvikling. Opplysningene og tilgangene kan variere mellom disse. Registrer miljøene når forskjellen har betydning for sikkerhet eller personvern. Et testmiljø med en kopi av reelle kundedata trenger en vurdering selv om det ikke brukes til daglig kundebehandling.
Integrasjoner bør registreres som forbindelser med formål, retning og ansvar. Angi om opplysninger sendes automatisk, hentes ved behov eller eksporteres manuelt. En fil som lastes ned månedlig og sendes til en samarbeidspartner, er også en dataflyt. Den kan være mer sårbar enn en kontrollert teknisk forbindelse, selv om den ikke vises i et integrasjonsverktøy.
Minimumsfelter for systemregisteret
| Felt | Innhold som gjør oversikten anvendelig |
|---|---|
| Referanse | Stabil identifikator som tåler navnebytte |
| Funksjon | Arbeidsoppgaven eller tjenesten systemet støtter |
| Eiere | Faglig ansvarlig og teknisk kontakt |
| Brukere | Roller, eksterne tilganger og administrasjon |
| Informasjon | Hovedkategorier og behov for beskyttelse |
| Leverandør | Juridisk avtalepart og relevant tjeneste |
| Forbindelser | Inngående og utgående dataflyter |
| Avhengigheter | Identitet, nettverk, lagring og andre tjenester |
| Kontinuitet | Konsekvens ved bortfall og avtalt alternativ |
| Dokumentasjon | Avtaler, vurderinger, rutiner og siste kontroll |
Tilpass feltene til bruksområdet og kapasiteten til vedlikehold. En oversikt med få kontrollerte felter kan være mer verdifull enn en omfattende database full av antakelser. Merk hva som er bekreftet av eier, hva som bygger på leverandørinformasjon og hva som fortsatt er uavklart.
Kartlegg tilgang som en egen forbindelse
Registrer hvor identitet opprettes og hvordan rettigheter tildeles. Et system kan bruke sentral innlogging, men ha lokale administratorer eller nødkontoer. Undersøk også tjenestekontoer som brukes av integrasjoner. Manglende eier på en slik konto kan gjøre det vanskelig å vite hvem som skal godkjenne endringer eller stenge tilgangen.
Knytt kartet til autentiseringsreglene. Vis hvilke systemer som er avhengige av samme innloggingstjeneste, og hvor alternativ tilgang finnes. Dette gir både et sikkerhetsbilde og grunnlag for beredskap. Et bortfall i identitetstjenesten kan ramme flere ellers uavhengige systemer samtidig.
Forbind systemkartet med behandlingsprotokollen
En behandlingsaktivitet kan bruke flere systemer, og ett system kan støtte flere aktiviteter. Hold derfor formålene i behandlingsprotokollen adskilt fra den tekniske systemlisten, men lag tydelige koblinger. Da kan et systembytte oppdateres uten å måtte omskrive alle beskrivelser av virksomhetens formål.
Koblingen gjør det mulig å finne hvilke aktiviteter som berøres av en leverandørhendelse eller endret dataflyt. Den hjelper også ved innsyn, sletting og informasjon til registrerte. Ikke trekk rettslige konklusjoner automatisk fra systemtypen: et HR-system kan inneholde både lovpålagte opplysninger og valgfrie aktiviteter med et annet behandlingsgrunnlag.
Beskriv hvor kopier oppstår
Se etter rapporter, eksportmapper, sikkerhetskopier og arbeidsfiler. Spør brukerne hva de gjør når systemets standardrapport ikke dekker behovet. Svaret kan avdekke en fast praksis med lokale kopier som ikke er dokumentert noe annet sted. Kartet bør vise hvem som lager kopien og hvilket formål den har.
Vurder om kopien fortsatt er nødvendig, og koble den til dataminimering og oppbevaring. En eksport kan være nødvendig for en bestemt avstemming, men unødvendig som varig parallellregister. Hvis kopier utelates, kan et senere slettearbeid i hovedsystemet gi et misvisende inntrykk av at opplysningene er borte.
Hypotetisk eksempel: kundebehandlingen har skjulte avhengigheter
En tenkt virksomhet kartlegger sitt kundesystem før en beredskapsøvelse. Fagavdelingen nevner kundesystemet og e-post. Gjennomgangen finner også en skjematjeneste, en automatisk filoverføring og et regneark som brukes til å fordele saker. Alle er avhengige av samme innlogging, mens filoverføringen bruker en gammel tjenestekonto uten registrert eier.
Virksomheten oppdaterer kartet og peker ut ansvar for kontoen. Den endrer beredskapsplanen fordi det planlagte reservearket også var utilgjengelig ved bortfall av innlogging. Eksemplet viser hvorfor kartlegging trenger intervjuer og praktisk kontroll. En automatisk liste over installert programvare ville ikke nødvendigvis ha funnet arbeidsmåten eller den kritiske felles avhengigheten.
Bruk kartet til å prioritere sikkerhet
Se etter systemer med mange forbindelser, omfattende rettigheter eller opplysninger med stor konsekvens ved misbruk. Disse kan trenge tidligere oppfølging enn et isolert system med begrenset innhold. Knytt funn til ansvar og tiltak, men unngå å rangere risiko bare etter antall integrasjoner. Dataenes karakter og den faktiske kontrollen er også viktige.
Kartet kan brukes når dere fastsetter sikkerhetslogging og kryptering. Det viser hvilke overganger og handlinger som trenger kontroll. En leverandørbeskrivelse av ett system må vurderes i sammenheng med kundens konfigurasjon, tilgangsmodell og forbindelser til andre tjenester.
Gjør vedlikehold til en del av endringsprosessen
Bestem hvilke hendelser som skal utløse oppdatering: ny tjeneste, endret eier, ny integrasjon, flytting av data eller avslutning. Legg oppgaven der beslutningen allerede tas, for eksempel i innkjøp og systemendringer. Dersom kartet bare oppdateres under en årlig kampanje, kan viktige endringer være ukjente i lang tid.
Gi hver eier et avgrenset ansvar for å kontrollere sine oppføringer. En sentral forvalter kan kontrollere struktur og følge opp manglende svar, men kan ikke bekrefte alle faglige opplysninger alene. Lag en enkel status som skiller verifisert informasjon fra åpne spørsmål. Dato for siste gjennomgang bør følge av en faktisk kontroll, ikke automatisk endres ved eksport.
Kontroller at kartet svarer på spørsmålene
Prøv konkrete oppgaver: Finn alle mottakere av en bestemt kategori kundedata. Finn hvilke systemer som stopper hvis innloggingen er utilgjengelig. Finn hvem som kan avslutte en integrasjon hos en leverandør. Hvis svaret krever omfattende muntlig leting, mangler kartet sannsynligvis en forbindelse eller en tydelig eier.
Bruk deretter kartet i kontinuitetsplanen og dokumenter hva øvelsen avdekker. Kontroller også tilgangen til selve oversikten. Den kan inneholde opplysninger om kritiske systemer og sikkerhetsarkitektur som ikke bør deles bredt. Lag en egnet oversiktsvisning for samarbeid og begrens mer detaljerte tekniske opplysninger etter behov.
Avslutt systemer uten å miste historikken
Når et system avvikles, bør statusen vise når tjenesten sluttet å behandle nye opplysninger og hvor nødvendig informasjon ble flyttet. Bevar relevante referanser til tidligere vurderinger og hendelser uten å beholde hele systemets innhold i kartet. En slettet rad kan ellers gjøre det vanskelig å forstå historiske dataflyter.
Registrer at integrasjoner og tilganger er håndtert, og knytt saken til dokumentasjon av tilbakelevering eller sletting. Oversikten skal vise både hva virksomheten bruker i dag og hvor tidligere avhengigheter er avsluttet. Det gir et mer troverdig grunnlag for senere kontroll enn et register der gamle systemer bare forsvinner uten forklaring.