Supply chain er en af de hyppigste reelle angrebsveje, fordi angribere ofte går efter den nemmeste adgang: en leverandør, en integration eller en glemt konto. Det er ikke dommedag, men det er hverdagsrisiko, og den kan håndteres med struktur, tydelige krav og løbende opfølgning.
I denne artikel får du en praktisk, SEO-venlig guide til leverandørstyring og cybersikkerhed: hvordan du klassificerer leverandører, hvad et standard security addendum bør indeholde, hvordan et due diligence-flow ser ud fra indkøb til årlig review, hvad du skal være opmærksom på i cloud, og hvordan du gør dokumentation audit-klar. Til sidst får du en konkret 1-side skabelon til et leverandørscorecard.
Hvad betyder supply chain-sikkerhed, og hvorfor betyder det noget?
Supply chain-sikkerhed handler om at styre cyberrisiko, der opstår gennem tredjeparter: leverandører, konsulenter, cloud-tjenester, underleverandører og systemintegrationer. Kort sagt: Hvis en ekstern part kan tilgå dine data, dine systemer eller din drift, kan de også blive din svageste led.
Det betyder noget, fordi konsekvenserne sjældent kun er tekniske. Et leverandørbrud kan give datalæk, driftstop, regulatoriske krav, tab af omsætning og langvarig skade på tillid. Samtidig er det et område, hvor mange virksomheder stadig arbejder ad hoc, uden klare minimumskrav og uden et fast review-loop.
Mini-konklusion: Hvis du vil reducere risiko hurtigt, er leverandørstyring ofte et af de mest effektive steder at starte.
Klassificér leverandører: kritiske vs. ikke-kritiske
Før du skriver krav eller laver kontrol, skal du vide, hvem der er vigtigst. Klassificering gør det muligt at bruge kræfterne rigtigt og undgå at behandle en kontorforsyningsleverandør som en driftspartner med adgang til produktion.
Kriterier for en kritisk leverandør
En leverandør er typisk kritisk, hvis de kan påvirke fortrolighed, integritet eller tilgængelighed af dine vigtigste aktiver. Tænk både på data, drift, økonomi og omdømme.
- Adgang til persondata, finansdata eller forretningshemmeligheder
- Direkte adgang til interne systemer, netværk eller admin-konti
- Driftskritiske services: ERP, e-mail, identitet, hosting, betaling
- Mulighed for at ændre kode, konfiguration eller sikkerhedsindstillinger
- Single point of failure uden realistisk alternativ
- Lovkrav eller kontraktkrav fra kunder, der afhænger af leverandøren
Ikke-kritiske leverandører og proportional kontrol
Ikke-kritiske leverandører kan stadig udgøre risiko, men kontrollerne bør være proportionelle. Et typisk fejltrin er at lave samme lange spørgeskema til alle, hvilket skaber friktion og udvander fokus.
Mini-konklusion: En simpel kritikalitetsmodel (kritisk/ikke-kritisk) er ofte nok til at skabe momentum og målrette din sikkerhedsindsats.
Standard security addendum: minimumskrav der kan genbruges
Et standard security addendum er en fast bilagsskabelon til kontrakter, der definerer minimumskrav til informationssikkerhed. Fordelen er hastighed og ensartethed: indkøb, IT og jura arbejder ud fra samme baseline, og leverandøren ved, hvad der forventes.
Minimumskrav du bør få på plads
Hold kravene konkrete og testbare, så de kan verificeres ved review og audit. Her er en robust minimumspakke, der passer til mange virksomheder.
- MFA: Multi-factor authentication på alle administrative konti og fjernadgange, samt på brugere med adgang til følsomme data.
- Logging: Logning af adgang, ændringer og sikkerhedshændelser, med defineret log-retention og mulighed for udlevering ved incident.
- Incident notification: Varslingspligt ved sikkerhedshændelser inden for en fast tidsramme, inklusive indholdskrav til første rapport.
- Data location: Klarhed om hvor data lagres og behandles, inkl. datacentre og jurisdiktion.
- Underleverandører: Krav om godkendelse eller oplysningspligt ved brug af underleverandører, samt flow-down af samme sikkerhedskrav.
Typiske spørgsmål: hvad koster det, og hvem skal gøre hvad?
Omkostningen ved et security addendum er primært intern tid: at definere krav, få dem juridisk afstemt og operationalisere dem i indkøb. Mange leverandører har allerede processer for MFA, logging og incident response; udfordringen er ofte at få det dokumenteret og bundet kontraktligt. For små leverandører kan kravet om MFA og basallogning være en reel investering, så vær tydelig om, hvad der er must-have, og hvad der er nice-to-have.
Mini-konklusion: Et genbrugeligt addendum reducerer både risiko og friktion, fordi forventninger bliver klare fra start.
Due diligence flow: før køb, ved kontrakt, årligt review
Den bedste praksis er at behandle leverandørdue diligence som en livscyklus, ikke en engangsøvelse. Det sænker sandsynligheden for, at en løsning glider fra “sikker nok” til “ukendt risiko”, når der kommer nye features, nye underleverandører eller ændrede adgangsbehov.
Før køb: screening og kravafklaring
I indkøbsfasen bør du afgøre kritikalitet, data-typer og integrationsomfang. Undgå den klassiske fejl at købe først og spørge om sikkerhed bagefter. Brug korte, målrettede spørgsmål, der matcher leverandørens rolle.
- Hvilke data behandles, og er der persondata eller særlige kategorier?
- Hvordan styres adgang, herunder MFA og rolleniveauer?
- Hvilke standarder eller rapporter kan deles, fx SOC 2 eller ISO 27001?
- Hvordan ser backup, restore og incident response ud i praksis?
Ved kontrakt: bind det, der betyder noget
Når du ved, hvad der er kritisk, skal det ind i kontrakten: security addendum, databehandleraftale, SLA, og rettigheder ved brud. Her er en typisk faldgrube at acceptere uklare formuleringer som “reasonable security”, uden målbare krav.
Hvis du arbejder med compliance-krav, kan det være nyttigt at se på NIS2 leverandørstyring som ramme for, hvordan du dokumenterer krav, opfølgning og ansvar uden at overkomplicere processen.
Årligt review: verificér, justér og luk huller
Et årligt review bør være standard for kritiske leverandører, og risikobaseret for resten. Her kommer mange til at fejle ved kun at “samle et dokument” i stedet for at kontrollere, om ændringer har skabt nye eksponeringer.
- Opdater klassificering og dataflow, især hvis scope har ændret sig.
- Indhent ny dokumentation: rapporter, attesteringer, penetrationstest-resumé.
- Gennemgå adgang: aktive konti, roller, API-nøgler, service accounts.
- Test exit-plan: kan data eksporteres, og kan drift flyttes?
Mini-konklusion: Et fast flow i tre trin gør sikkerhed til en rutine, ikke et projekt, der kun sker efter en hændelse.
Cloud-leverandører: shared responsibility, misconfigs og kontrol
Cloud ændrer ikke behovet for kontrol, men flytter det. Shared responsibility betyder, at leverandøren typisk sikrer platformen, mens du sikrer din konfiguration, dine identiteter og dit dataindhold. Mange sikkerhedsbrud i cloud skyldes ikke “hack” i klassisk forstand, men misconfiguration og overprivilegerede konti.
Adgangsstyring som første forsvarslinje
Prioritér identitet og adgangsstyring: least privilege, stærk autentifikation og tydelig separation mellem admin og bruger. En hyppig fejl er at dele admin-konti eller lade service accounts leve uden udløb og rotation.
- RBAC: Brug rollebaseret adgang, og fjern “owner”-rettigheder fra daglig drift.
- MFA: Kræv MFA for alle admin-roller og SSO hvor muligt.
- API-nøgler: Rotér, begræns scope, og monitorér brug.
- Netværk: Begræns offentlige endpoints og brug private forbindelser, når det er realistisk.
Backup og exit-plan: din forsikring mod lock-in og ransom
Backup er ikke kun en teknisk indstilling; det er en proces, du skal kunne forklare og teste. Spørg: Hvor ofte tages backup, hvor længe gemmes den, og kan den gendannes uafhængigt af leverandøren? En klassisk faldgrube er at tro, at “cloud har backup”, mens der i praksis kun er redundans, ikke gendannelse.
Exit-planen bør beskrive dataeksport, sletning, format, tidsramme og omkostninger. Det er her mange opdager for sent, at de ikke kan flytte hurtigt, hvis leverandøren får en hændelse eller ændrer vilkår.
Mini-konklusion: Cloud-sikkerhed er i høj grad konfigurationssikkerhed, og den kræver tydeligt ejerskab hos kunden, ikke kun hos leverandøren.
Faldgruber i leverandørstyring og hvordan du undgår dem
Typiske fejl går igen på tværs af brancher. De handler sjældent om manglende vilje, men om uklare processer, for bredt scope og manglende opfølgning.
- One-size-fits-all: Samme kontrol til alle leverandører. Løsning: klassificér og skaler krav.
- Utydelige krav: “God sikkerhed” uden testbarhed. Løsning: målbare minimumskrav og tidsfrister.
- Ingen ejer: Hvem følger op på findings? Løsning: udpeg en leverandøransvarlig pr. kritisk leverandør.
- Skjulte underleverandører: Du ved ikke, hvor data ender. Løsning: krav til oplysning, ændringsnotifikation og flow-down.
- Glemsel af adgang: Konti bliver ikke lukket ved kontraktophør. Løsning: offboarding-checkliste og kvartalsvis access review.
Mini-konklusion: De største gevinster kommer ofte fra at gøre de basale ting konsekvent, ikke fra at jage perfektion.
Dokumentation: hvad du gemmer, og hvordan du gør det audit-klart
Dokumentation er din bro mellem “vi gør det” og “vi kan bevise det”. Audit-klar dokumentation betyder, at du hurtigt kan finde beslutninger, vurderinger og beviser uden at lede i mails og chat-tråde.
Hvad du bør gemme pr. leverandør
Hold det simpelt, men komplet. Gem hellere få, stærke artefakter end en bunke ubrugelige PDF’er.
- Klassificering og begrundelse, inklusive data-typer og systemadgang.
- Kontrakt, security addendum og eventuel databehandleraftale.
- Due diligence-resultater: spørgeskema, rapporter, attester, risikovurdering.
- Access-oversigt: integrationspunkter, brugere, roller, API-nøgler.
- Incident-historik og kommunikation, inklusive læringspunkter.
- Årlige reviews: dato, ændringer, actions og status.
Sådan gør du det audit-klart i praksis
Brug et fast filnavneskema og en standard mappe- eller ticketstruktur. Sørg for versionsstyring og en enkel sporbarhed: hvem godkendte, hvornår, og på hvilket grundlag. En praktisk tommelfingerregel er, at en kollega skal kunne forstå leverandørens risikobillede på 10 minutter uden at kende historikken.
Mini-konklusion: Audit-klarhed er ikke papirarbejde for papirarbejdets skyld; det er det, der gør dig hurtig og troværdig, når der opstår spørgsmål eller hændelser.
1-side leverandørscorecard: skabelon du kan bruge med det samme
Nedenfor er en konkret 1-side leverandørscorecard skabelon. Brug den til både nye leverandører og til årlige reviews. Den kan ligge i et regneark, et GRC-værktøj eller et simpelt dokument, så længe felterne er ens hver gang.
- Leverandørnavn og servicebeskrivelse (hvad leveres, til hvem)
- Kritikalitet (kritisk/ikke-kritisk) og kort begrundelse
- Data og scope (data-typer, volumen, systemer, integrationspunkter)
- Adgang (SSO/MFA, admin-adgange, API-nøgler, service accounts)
- Hosting og data location (lande, cloud-udbyder, multi-tenant/isolering)
- Logging og monitorering (hvad logges, retention, udlevering ved incident)
- Incident notification (tidsfrist, kontaktpunkter, eskalationsvej)
- Underleverandører (liste, ændringsnotifikation, flow-down krav)
- Backups og restore (RPO/RTO, testfrekvens, uafhængighed)
- Exit-plan (dataeksport, sletning, format, tidsramme, omkostninger)
- Dokumentation (SOC/ISO, pen test-resumé, politikker, seneste dato)
- Risikovurdering (lav/middel/høj) og top 3 risici
- Actions (tiltag, ansvarlig, deadline, status)
- Godkendelse (navn, rolle, dato for seneste review)
Mini-konklusion: Et scorecard gør leverandørrisiko synlig, sammenlignelig og handlingsorienteret, så du kan styre supply chain-sikkerhed uden at drukne i detaljer.
