Hvorfor MSP-kontrakter er et ISO 27001:2022-hotspot
MSP-kontrakter er et hotspot i henhold til ISO 27001:2022, fordi revisorer nu behandler leverandøraftaler som primært bevis for, hvordan dine kontroller strækker sig ind i forsyningskæden. De forventer skriftlige forpligtelser, roller og hændelsesprocesser, der viser, at dine ISMS-systemer (Managed Service Management System) rækker ind i de tjenester, du køber og leverer, ikke kun interne diagrammer eller politikker. Kommentarer og implementeringsvejledning til ISO/IEC 27001:2022 understreger, at organisationer skal demonstrere, hvordan kontroller gælder for relevante leverandører, og certificeringsorganer bruger almindeligvis kontrakter som en del af dette bevismateriale. For udbydere af administrerede tjenester fungerer hverdagskontrakter nu også som sikkerhedsartefakter, der kan styrke eller svække certificering og kundernes tillid.
MSP-aftaler er ikke længere blot kommercielle værktøjer; de er en del af din sikkerhedspolitik. ISO 27001:2022 forventer, at sikkerhedsforpligtelser, ansvar og hændelseshåndtering afspejles i kontrakter og relaterede dokumenter, som i mange organisationer vil omfatte hovedserviceaftaler (MSA'er), arbejdsbeskrivelser (SoW'er), serviceniveauaftaler (SLA'er), databehandlingsaftaler (DPA'er) og sikkerhedsplaner, selvom standarden ikke foreskriver specifikke dokumentetiketter. Hvis disse elementer mangler eller er vage, vil revisorer have svært ved at se, hvordan dine Annex A-kontroller fungerer i den virkelige verden.
Oplysningerne her er generelle og udgør ikke juridisk rådgivning; kontraktlige beslutninger kræver input fra kvalificeret advokat.
Hvordan ISO 27001:2022 inkluderer MSP-kontrakter i anvendelsesområdet
ISO 27001:2022 trækker MSP-kontrakter ind i deres anvendelsesområde ved at behandle leverandørsikkerhed som et kontraktligt ansvar, der skal defineres og aftales skriftligt. Standarden forventer, at I i jeres aftaler viser, hvordan ansvar for informationssikkerhed, regler for datahåndtering og hændelsesprocesser er fordelt på tværs af kunde, MSP og upstream-udbydere. Dette skift sætter direkte fokus på de kontrakter, jeres virksomhed er afhængig af.
I ISMS.online-undersøgelsen State of Information Security i 2025 nævnte omkring 41 % af organisationerne håndtering af tredjepartsrisici og sporing af leverandørcompliance som en af de største udfordringer inden for informationssikkerhed.
Udbydere af administrerede tjenester befinder sig midt i lange forsyningskæder. Du er afhængig af cloudplatforme, datacentre, sikkerhedsværktøjer og specialiseret SaaS, og dine kunder er afhængige af dig. Når hændelser har spredt sig gennem disse kæder, har efterforskere gentagne gange set det samme mønster: kommercielle vilkår var detaljerede, men sikkerhedsroller, datahåndtering, hændelsesrespons og tilsyn var vage eller manglede i kontrakter. Gennemgange af forsyningskædeangreb i cloud- og outsourcingsammenhænge fremhæver ofte, at den kontraktlige opmærksomhed fokuserede på pris og servicefunktioner, mens sikkerhedsansvar forblev underforstået, hvilket begrænsede indflydelsen betydeligt, når der opstod fejl. Hvis forventningerne er underforståede snarere end nedskrevne, har du ringe indflydelse, når noget går galt.
Undersøgelsen af informationssikkerhedens tilstand i 2025 viste, at et flertal af organisationer var blevet påvirket af mindst én tredjeparts- eller leverandørrelateret sikkerhedshændelse i det foregående år.
Regulatorer og kunder har reageret ved at stille langt skarpere spørgsmål. Det er ikke længere nok at sige "vi er ISO-afstemte" eller "vores leverandører følger branchestandarder". Købere ønsker at vide, hvordan ansvaret deles, hvor hurtigt du vil informere dem om problemer, hvordan underdatabehandlere kontrolleres, og hvad der sker med data, når et forhold ophører. Tilsynsvejledning i mange sektorer henviser nu eksplicit til skriftlige outsourcingaftaler og forventer, at virksomheder dokumenterer, hvordan de fører tilsyn med tredjeparter, så revisorer rutinemæssigt udtager stikprøver af disse aftaler, når de vurderer kontroleffektiviteten. Inden for områder som operationel robusthed og outsourcing inden for finansielle tjenester præciserer forsigtighedsregler f.eks. behovet for dokumenteret ansvar, underretningspligt og udtrædelsesbestemmelser i outsourcingkontrakter, og denne tankegang afspejles i stigende grad i bredere praksis for tredjepartsrisiko.
For MSP'er betyder det, at kontrakter nu er en del af angrebsfladen og en del af bevismaterialet. Hvis sikkerhedskrav, serviceniveauer, hændelsesprocesser og revisionsrettigheder ikke er dokumenteret, vil revisorer tvivle på, om Annex A-kontrollerne virkelig strækker sig ind i forsyningskæden. Endnu vigtigere er det, at du kan miste muligheden for at insistere på afhjælpning eller samarbejde, når en upstream-leverandør fejler eller modstår kontrol.
En platform som ISMS.online kan hjælpe ved at forbinde leverandørregistre, risikovurderinger og kontraktdokumentation ét sted, men dit udgangspunkt er et klart overblik over, hvad bilag A.5.20 forventer, at dine aftaler skal indeholde.
Klare kontrakter forvandler påtaget sikkerhed til et håndhævbart ansvar.
Hvorfor dette er vigtigt for MSP-revisioner og kundetillid
Klare, sikkerhedsbevidste kontrakter gør MSP-revisioner mere problemfrie og giver kunderne mere tillid til jeres tjenester. Når aftaler viser, hvem der er ansvarlig for nøglekontroller, hvordan hændelser håndteres, og hvordan data beskyttes, bliver jeres forklaringer under vurderinger og salgssamtaler mere præcise og mindre defensive.
Ifølge ISMS.online-undersøgelsen fra 2025 forventer kunderne i stigende grad, at deres leverandører overholder formelle rammer som ISO 27001, ISO 27701, GDPR, Cyber Essentials, SOC 2 og nye AI-standarder.
At behandle kontrakter som sikkerhedsartefakter ændrer, hvordan dine revisioner føles, og hvordan kunderne bedømmer dig. Revisorer kan spore risici ned til forpligtelser; kunderne ser, at sikkerhed er en del af din måde at drive forretning på, ikke en eftertanke. Når disse elementer mangler, er begge grupper tvunget til at gætte, hvad du mente, og at usikkerhed undergraver tilliden.
For MSP'er er den praktiske effekt enkel: hver gang du forhandler eller fornyer en aftale, enten styrker eller svækker du din sikkerhedspolitik. Hvis du standardiserer stærke klausuler og anvender dem konsekvent, opbygger du en forsvarlig basislinje, der holder i certificeringsrevisioner, udbud af tilbud og gennemgange af regulatorer. Hvis du bruger ad hoc-formulering, skaber du variabilitet, der bliver synlig på præcis de tidspunkter, hvor du mest ønsker forudsigelighed og kontrol.
Book en demoHvad ISO 27001:2022 A.5.20 rent faktisk kræver
ISO 27001:2022 A.5.20 kræver, at du identificerer informationssikkerhedskrav for hver leverandørrelation og integrerer dem i håndhævelige aftaler. Hvor en leverandør kan påvirke fortroligheden, integriteten eller tilgængeligheden af dine oplysninger eller tjenester, skal du definere, hvad du forventer af dem, i kontrakter eller tilsvarende dokumenter, som begge parter forstår og kan handle ud fra. Dette stemmer overens med ordlyden i bilag A.5.20 i ISO/IEC 27001:2022, som kræver, at informationssikkerhedskrav identificeres for leverandørrelationer og implementeres i aftaler, så disse skriftlige forventninger derefter udgør en del af dit revisionsbevis.
I praksis flytter bilag A.5.20 sikkerhedskrav ud af interne dokumenter alene og ind i de aftaler, der styrer, hvordan tjenester leveres. For MSP'er betyder det, at kundekontrakter og upstream-leverandørkontrakter skal vise, hvordan sikkerhedsansvaret deles, hvordan data håndteres, og hvordan hændelser håndteres. Revisorer vil se efter den sporbare forbindelse mellem leverandørrisici, interne kontroller og kontraktformulering.
Sondring mellem A.5.20 og andre leverandørkontroller
A.5.20 adskiller sig fra kontrolforanstaltninger for tilstødende leverandører, fordi den fokuserer på, hvad der er skrevet i kontrakter, snarere end hvordan leverandører udvælges eller overvåges. Forståelse af denne sondring hjælper dig med at designe den rette dokumentation for hver kontrol og undgå at behandle alt som et enkelt, sløret krav.
A.5.19, "Informationssikkerhed i leverandørrelationer", fokuserer på den overordnede livscyklus: valg af leverandører, vurdering af risici, overvågning af performance og håndtering af forandringer. A.5.21, "Håndtering af informationssikkerhed i IKT-forsyningskæden", fremhæver komplekse kæder, underleverandører og risiko for privatlivets fred eller personoplysninger, især hvor flere leverandører samarbejder om at levere en service. Oversigter over ISO/IEC 27001:2022 og relateret vejledning præsenterer konsekvent A.5.19 som livscyklusstyringskontrollen og A.5.21 som den specifikke IKT-forsyningskædekontrol, hvilket understøtter brugen af dem sammen med A.5.20 i stedet for at behandle dem som dubletter. Sammen beskriver de, hvordan du styrer tredjepartsrisiko over tid.
Bilag A.5.20, "Håndtering af informationssikkerhed i leverandøraftaler", fokuserer på indhold: hvad der fremgår af kontrakter, tidsplaner og vilkår. Revisorer ser ofte solidt arbejde på A.5.19 (leverandørregistre, risikovurderinger, due diligence-spørgeskemaer), men svag udførelse på A.5.20, hvor kontrakterne stadig siger lidt mere end "leverandøren vil overholde gældende love og branchestandarder." Den slags sprog viser sjældent, at specifikke risici er blevet omsat til forpligtelser, der kan håndhæves og testes.
Kerneforpligtelser A.5.20 pålægger MSP-aftaler
A.5.20 pålægger MSP-aftaler adskillige kerneforpligtelser, centreret omkring dokumentation af klare ansvarsområder og minimumsforventninger til sikkerhed. For hver leverandør, der påvirker jeres ISMS, skal I kunne vise, hvor roller, regler for datahåndtering, hændelsesprocesser, regulatoriske pligter og tilsynsmekanismer er defineret og accepteret af begge parter.
Konkret forventer A.5.20, at du:
- Definer sikkerhedsrelevante roller og ansvarsområder mellem dig og hver leverandør i et klart sprog.
- Angiv, hvordan oplysninger kan tilgås, behandles, opbevares, overføres og slettes af den pågældende leverandør.
- Registrer krav til hændelsesmeddelelse og samarbejde, herunder timing og kommunikationskanaler.
- Afspejl relevante lovgivningsmæssige forpligtelser, især omkring personoplysninger og outsourcingregler.
- Sørg for overvågning, gennemgang og, hvor det er relevant, revision eller uafhængige sikkerhedsmekanismer.
For MSP'er bør "leverandør" fortolkes bredt. Cloudplatforme, forbindelsesudbydere, ticketværktøjer, fjernovervågningssoftware, SOC-partnere, underleverandører til ingeniører og nogle strategiske konsulenter kan alle være omfattet, hvis de kan påvirke kundeservice eller håndtere følsomme oplysninger. Standarden antager ikke, at kun store, åbenlyse outsourcere har betydning.
Nøglen er sporbarhed. For hver vigtig leverandørrisiko, du registrerer i dit ISMS, vil en revisor gerne vide, hvor den er adresseret: i tekniske kontroller, i driftsprocesser og i kontraktklausuler. A.5.20 er, hvor dine interne forventninger bliver til eksterne forpligtelser, som kunder, tilsynsmyndigheder og revisorer kan se.
ISO 27001 gjort nemt
Et forspring på 81% fra dag ét
Vi har gjort det hårde arbejde for dig, hvilket giver dig en 81% forspring fra det øjeblik, du logger på. Alt du skal gøre er at udfylde de tomme felter.
Omsætning af A.5.20 til konkrete MSP-kontraktemner
At omsætte A.5.20 til konkrete MSP-kontraktemner betyder at omdanne brede sikkerhedsforventninger til en kort, gentagelig liste over klausulområder. Hvis alle væsentlige leverandøraftaler dækker disse områder på et passende detaljeringsniveau, opfylder du det meste af kontrollens intention og gør revisioner og fornyelser lettere at administrere.
For MSP'er er fordelen ved en emnebaseret tilgang konsistens. Når I har besluttet, hvilke temaer der skal optræde i næsten alle kontrakter, kan jeres juridiske, sikkerhedsmæssige og kommercielle teams arbejde ud fra en fælles tjekliste i stedet for at improvisere formuleringer fra sag til sag. Det gør det nemmere at sammenligne aftaler, finde mangler og forklare jeres tilgang til revisorer og kunder.
Grundlæggende emner, som enhver MSP-leverandørkontrakt bør dække
Emner i basiskontrakter er de tilbagevendende temaer, du ønsker at se i næsten alle leverandøraftaler, der berører dit ISMS. De giver dine teams en pragmatisk tjekliste til gennemgang og hjælper dig med at vise revisorer, at specifikke risici er blevet adresseret på et ensartet og forståeligt sprog i stedet for spredte, engangsklausuler.
En praktisk basislinje omfatter normalt mindst følgende:
- Omfang og brug af oplysninger: – godkendte data og systemer, tilladte anvendelser, forbudte anvendelser.
- Forventninger til adgangskontrol: – godkendelsesmetoder, adgang med færrest rettigheder, fjernadgang og regler for kontolivcyklus.
- Logføring og overvågning: – krævede logfiler, opbevaringsperioder og tilgængelighed af optegnelser under undersøgelser.
- Sårbarhedshåndtering og patching: – ejerskab over opdagelse, vurdering og afhjælpning, med tidsrammer for problemer med høj risiko.
- Hændelsesdetektion og -notifikation: – hvad der tæller som en sikkerhedshændelse, hvor hurtigt I bliver informeret, og hvordan I samarbejder.
- Forretningskontinuitet og katastrofeberedskab: – minimumstilgængelighed, genopretningsmål og deltagelse i test, hvor det er relevant.
- Underleverandører og underdatabehandlere: – hvornår de må anvendes, hvordan du bliver informeret eller godkender, og hvordan forpligtelserne følger.
- Databeskyttelse og privatliv: – betingelser for behandling af personoplysninger, placeringer, overførselsmekanismer, fortrolighed og støtte til registreredes rettigheder.
- Dataopbevaring, returnering og sletning: – opbevaringsperioder, returformater ved afslutning, og hvordan sikker sletning dokumenteres.
- Sikkerhed og tilsyn: – rapporter, certificeringer, spørgeskemaer eller aftalte revisioner, du kan stole på, og hvornår de leveres.
Disse emner kræver ikke alle lange klausuler, men de bør være genkendelige i dine standardpositioner og højrisikokontrakter. Efter at have gennemgået en stikprøve af aftaler, bør du være i stand til at svare med sikkerhed: "Hvor dækker vi hvert af disse punkter, og hvordan ændrer det sig efter leverandørniveau?"
For MSP'er, der håndterer personoplysninger på vegne af kunder, skal privatlivsbetingelserne være i overensstemmelse med disse sikkerhedsklausuler. Behandlingsinstruktioner, fortrolighedsforpligtelser, regler for underdatabehandlere og revisionsrettigheder bør understøtte, ikke være i konflikt med, jeres bredere sikkerhedskrav. Det undgår en situation, hvor databehandleraftalen siger én ting, sikkerhedsplanen siger en anden, og ingen af delene matcher de kontroller, der er beskrevet i jeres ISMS.
Sammenkædning af kontraktemner med interne ISMS-spørgsmål
At forbinde kontraktemner med interne ISMS-spørgsmål betyder, at man sikrer, at hver klausulfamilie besvarer et klart risikospørgsmål, som man allerede sporer. Når jeres risikoregistre, kontroller og kontrakter bruger den samme mentale model, bliver det meget nemmere at forklare revisorer, hvordan I styrer leverandører fra start til slut.
En kort tabel kan hjælpe dig med at afstemme disse emner med de spørgsmål, du stiller internt:
| Kontraktemne | Nøglespørgsmål at besvare | Typisk dokumentplacering |
|---|---|---|
| Adgangskontrol | Hvem har adgang til hvad, og hvordan gives eller fjernes adgang? | Sikkerhedsplan / arbejdsbeskrivelse |
| Hændelsesanmeldelse | Hvornår og hvordan vil du høre om hændelser? | Sikkerhedsplan / serviceniveauaftale |
| Underdatabehandlere | Hvem er ellers involveret, og hvem godkender dem? | Databehandleraftale / underleverandørklausul |
| Datareturnering og sletning | Hvad sker der med dataene, når forholdet ophører? | Bestemmelser om udtræden eller opsigelse |
| Revision og forsikring | Hvordan kan du kontrollere, at sikkerheden fungerer som aftalt? | Revisionsrettigheder eller revisionsafsnit |
Når disse forbindelser er tydelige, kan du for hver vigtig leverandør dokumentere, hvor specifikke risici er adresseret. Det giver revisorerne tillid til, at du ikke er afhængig af generiske formuleringer, og giver kunderne en ensartet forklaring, når de spørger, hvordan du håndterer outsourcingrisiko.
Design af en genanvendelig MSP-kontraktgrundlinje
At designe en genanvendelig MSP-kontraktgrundlinje betyder at skabe en standardstruktur og et sæt klausuler, der fungerer på tværs af mange aftaler med risikobaserede variationer. I stedet for at genopfinde formuleringen hver gang, opretholder du én kontrolleret grundlinje og justerer dybde og styrke afhængigt af leverandørens indflydelse på dine tjenester og kunder.
En genanvendelig baseline forvandler en lang liste af emner til en praktisk kontraktstruktur, som du kan implementere på tværs af din portefølje. Målet er at stoppe med at udarbejde fra bunden af hver aftale og at opretholde et enkelt sæt positioner, som du kan stramme eller lempe på en risikobaseret måde, samtidig med at den overordnede konsistens bevares.
Opbygning af en modulær kontraktstruktur for MSP'er
En modulær kontraktstruktur giver dig mulighed for at opretholde en sammenhængende basislinje, samtidig med at juridiske, kommercielle og tekniske teams får et klart ejerskab over deres sektioner. Ved at adskille servicebeskrivelser, juridisk standardtekst og sikkerhedsindhold gør du opdateringer nemmere og reducerer risikoen for, at en ændring på ét område utilsigtet svækker et andet.
De fleste MSP'er synes, at en modulær struktur fungerer bedst, fordi den giver dig mulighed for at opdatere individuelle dele uden at omskrive alt. En klar adskillelse mellem juridisk standardtekst, servicebeskrivelser og sikkerhedsforventninger hjælper også forskellige teams med at eje deres sektioner.
Typiske komponenter omfatter:
- A Hovedserviceaftale (MSA) indeholdende centrale juridiske termer og ansvarsområder på overordnet niveau.
- En eller flere Arbejdsbeskrivelser (SoW'er) beskrivelse af specifikke tjenester, aktiver og lokationer.
- A serviceniveaubilag definition af tilgængelighed, respons- og løsningsmål, rapportering og servicekreditter.
- A sikkerhedsplan koncentrering af informationssikkerheds- og privatlivsforpligtelserne i henhold til A.5.19-A.5.21.
- Hvor personoplysninger behandles, skal en databehandleraftale (DPA) i overensstemmelse med sikkerhedsplanen.
Inden for denne struktur bliver sikkerhedsplanen det primære redskab for A.5.20. Den behøver ikke at være lang, men den bør systematisk dække kerneemnerne fra det foregående afsnit. Brug af korte, nummererede afsnit eller tabeller i stedet for spredte referencer gør det lettere for begge sider at forstå og vedligeholde indholdet over tid.
Forvandling af din baseline til et levende klausulbibliotek
At omdanne jeres baseline til et levende klausulbibliotek betyder, at I indsamler genanvendelig formulering, knytter den til kontroller og gør det nemt for teams at anvende den rigtige variant. Jeres mål er at undgå engangssætninger begravet i gamle kontrakter og i stedet opretholde et kurateret sæt af klausuler, der udvikler sig i takt med jeres risikoappetit og lovgivningsmæssige kontekst.
For at gå fra teori til daglig brug har du brug for formuleringer, der er teknologiuafhængige, sporbare til kontroller og lette at tilpasse til forskellige risikoniveauer. På den måde kan du anvende de samme kernepositioner på tværs af hosting, SOC, SaaS og professionelle tjenester, samtidig med at du afspejler deres forskellige risikoprofiler.
For at opbygge en basislinje kan du:
Trin 1 – Start med dit ISMS
Start med at identificere de kontroller og politikker, som leverandører skal respektere, såsom adgangskodestandarder, krypteringsforventninger, logføring og tidsrammer for hændelser, så du ved, hvilke krav der skal fremgå af kontrakter.
Trin 2 – Gruppér krav i kontraktemner
Gruppér hver forventning i et klausulområde som adgangskontrol, hændelsesstyring, kontinuitet eller datahåndtering, så du reducerer dobbeltarbejde og hurtigt kan se, hvor der er huller i udkast til aftaler.
Trin 3 – Udkastneutral, resultatorienteret formulering
Skriv klausuler, der beskriver ansvar og resultater, ikke specifikke værktøjer eller konfigurationer, så din formulering overlever teknologiske ændringer og forbliver relevant på tværs af forskellige typer leverandører.
Trin 4 – Tag klausuler til ISO-kontroller internt
I din interne dokumentation skal du registrere, hvilke ISO 27001-kontroller og relaterede kontroller hver klausul understøtter, for at forenkle revisionsforklaringer, understøtte kontroltest og fremhæve eventuelle overlap eller konflikter.
Trin 5 – Definer standard- og forbedrede varianter
Opret en standardklausul plus strengere versioner til situationer med højere risiko, såsom kortere tidsfrister for hændelser eller stærkere revisionsrettigheder for kritiske tjenester, så forhandlerne ved, hvilke positioner de skal starte fra, og hvornår de skal eskalere.
Udrulning af baseline er et forandringsprogram i sig selv. En almindelig tilgang er at anvende baseline på alle nye kunde- og leverandøraftaler, bruge fornyelser og væsentlige ændringer til at opgradere eksisterende højrisikokontrakter og føre et register over undtagelser, hvor man accepterer svagere vilkår med dokumenterede begrundelser og kompenserende kontroller.
ISMS.online kan understøtte dette ved at gemme dit klausulbibliotek, linke hver klausul til kontroller og leverandører og registrere, hvilken version af baseline hver kontrakt bruger. Det reducerer administrative omkostninger og gør det nemmere at besvare spørgsmål som "Hvilke hostingudbydere bruger stadig den ældre standard for brudnotifikation?"
Frigør dig selv fra et bjerg af regneark
Integrer, udvid og skaler din compliance uden besvær. IO giver dig robustheden og selvtilliden til at vokse sikkert.
Samling af A.5.19, A.5.20 og A.5.21 til "altid tændt"-klausuler
At samle A.5.19, A.5.20 og A.5.21 i "altid-på"-klausuler betyder at designe et lille sæt af klausulfamilier, der i fællesskab dækker leverandørens livscyklusstyring, kontraktindhold og IKT-forsyningskæderisici. I stedet for at behandle tre kontroller som separate projekter, bruger du gentagelig formulering, der opfylder dem samlet, hvor risikoprofilen kræver det.
Hvis man behandler A.5.19, A.5.20 og A.5.21 som tre usammenhængende tjeklister, bliver leverandørstyring hurtigt kompleks og svær at forklare. Standarder for forsigtighed og operationel risiko i sektorer som finansielle tjenester har bevæget sig i retning af integreret outsourcing og tredjepartsrammer i stedet for fragmenterede kravlister, og den samme logik gælder, når man designer kontroller til ISO 27001-leverandørklausuler. Ved at designe klausulfamilier, der følger leverandører fra onboarding til exit, får man én fortælling: hvordan man vælger leverandører, hvordan man indgår kontrakter med dem, og hvordan man overvåger deres sikkerhed gennem hele forholdet.
De fleste organisationer i undersøgelsen af informationssikkerhedens tilstand i 2025 rapporterede, at de allerede havde styrket risikostyringen fra tredjepart og planlagde at investere yderligere i den.
Klausulfamilier, der opfylder A.5.19, A.5.20 og A.5.21 tilsammen
Klausulfamilier er grupper af relaterede forpligtelser, der går på tværs af leverandørudvælgelse, kontraktindgåelse og løbende tilsyn. Ved at definere disse én gang og anvende dem gennem hele livscyklussen, gør du din tilgang lettere at forklare, lettere at forhandle og mere robust, når personale eller leverandører ændrer sig.
Nyttige familier inkluderer:
- Onboarding og due diligence: – videregivelse af vigtige sikkerhedsoplysninger under udvælgelsen, accept af jeres baseline og bekræftelse af relevante certificeringer eller rapporter.
- Gennemgang af ydeevne og sikkerhed: – regelmæssige møder, målinger, rapportering af hændelser og sårbarheder samt retten til at anmode om afhjælpningsplaner.
- Forandringsledelse: – underretning om væsentlige ændringer af infrastruktur, underdatabehandlere, lokationer eller sikkerhedskontroller, før de sker, plus ret til at gøre indsigelse eller revurdere risikoen.
- Styring af underleverandører: – gennemsigtighed i leverandørens egen kæde, forudgående godkendelse af nye underdatabehandlere og nedjustering af minimumsforpligtelser.
- Udgang og overgang: – sikkerhedsbevidste opsigelsesklausuler, der sikrer kontrolleret overdragelse, returnering eller destruktion af data og tilbagetrækning af adgang.
Disse familier giver dig mulighed for at implementere A.5.19's livscyklusstyring (udvælgelse, overvågning, ændring, opsigelse), A.5.20's kontraktindhold og A.5.21's fokus på komplekse IKT-forsyningskæder uden at skrive tre forskellige sæt klausuler. Du beskriver livscyklussen én gang og tilpasser derefter intensiteten efter leverandørniveau i stedet for at genopfinde strukturen hver gang.
Risikobaseret niveauinddeling for leverandørkontrakter
Risikobaseret niveauinddeling for leverandørkontrakter betyder, at du anvender dine klausulfamilier i forskellige styrker afhængigt af, hvor meget skade en fejl hos den pågældende leverandør kan forårsage. Ved at definere niveauer og tilsvarende forventninger på forhånd undgår du improvisation fra sag til sag og kan forklare revisorer, hvorfor nogle kontrakter er strengere end andre.
Risikobaseret niveauinddeling forfiner klausulfamilier, så kritiske leverandører har stærkere forpligtelser, mens rutinemæssige leverandører stadig opfylder et minimumsgrundlag. Dette hjælper dig med at forklare revisorer og kunder, hvorfor sikkerhedsforventningerne varierer, og viser, at variationen er bevidst og ikke tilfældig.
For eksempel kan du definere:
- Niveau 1 – Kritiske leverandører: såsom primær hosting eller SOC-partnere, med revisionsrettigheder på stedet, strammere tider for hændelsesmeddelelser, stærkere kontinuitetsforpligtelser og mere detaljeret rapportering.
- Niveau 2 – Vigtige leverandører: såsom SaaS-udbydere inden for samme branche, der er afhængige af uafhængige revisionsrapporter plus målrettede spørgeskemaer og standardvarselstider.
- Niveau 3 – Standardleverandører: såsom mindre værktøjer, ved hjælp af en forenklet basislinje med ikke-omsættelige klausuler om fortrolighed, underretning om hændelser og underleverandører.
På tværs af alle niveauer bør visse forventninger "altid være gældende": fortrolighed, defineret omfang af behandling, minimumssamarbejde i forbindelse med hændelser og forpligtelser til at respektere dine klassificerings- og håndteringsregler for følsomme oplysninger. Niveauinddeling bliver derefter et spørgsmål om at styrke, ikke fjerne, disse fundamenter.
Ved at udforme klausuler på denne måde kan du vise revisorer og kunder, at leverandørtilsyn er struktureret snarere end ad hoc, og at kontraktlige forventninger vokser i styrke med risikoen. Det gør det også lettere at beslutte, hvor man skal fokusere afhjælpningsindsatsen, når man opdager svagheder i eksisterende aftaler.
Almindelige revisionshuller i MSP-kontrakter og deres konsekvenser
Almindelige huller i revisioner i MSP-kontrakter opstår, når centrale sikkerhedsemner mangler, er vage eller inkonsistente på tværs af aftaler. Revisorer og kunder bemærker hurtigt mønstre såsom svage tidsfrister for hændelser, manglende bestemmelser for underleverandører og utilstrækkelige revisionsrettigheder, og disse huller eskalerer ofte til fund, afhjælpningsplaner eller tabte muligheder.
Når certificeringsorganer og kunder gennemgår MSP-kontrakter i forhold til A.5.20, finder de gentagne gange lignende svagheder. Regulatorisk vejledning om cloud- og outsourcingaftaler dokumenterer også tilbagevendende problemer såsom vage sikkerhedsvilkår, underleverandørers uigennemsigtighed og svage revisionsrettigheder, hvilket afspejler, hvad mange revisorer rapporterer, når de udtager stikprøver af MSP-kontrakter. Tidlig genkendelse af disse mønstre gør det lettere at adressere dem, før de udvikler sig til afvigelser, regulatoriske spørgsmål eller kontraktlige tvister.
Mønstre, som revisorer og kunder markerer i MSP-aftaler
Mønstre, som revisorer og kunder markerer i MSP-aftaler, har en tendens til at gruppere sig omkring vag formulering på et par tilbagevendende områder. Når stikprøvekontrakter viser det samme bløde sprog for hændelser, underleverandører, revisionsrettigheder og lovgivningsmæssige pligter, sætter kontrollører hurtigt spørgsmålstegn ved, om jeres leverandørbaseline er stærk nok til de risici, I står over for.
Revisorer starter normalt med at udtage stikprøver fra et lille antal kontrakter for at se, hvordan jeres baseline anvendes i praksis. Hvis disse stikprøver viser vage forpligtelser og manglende emner, kan de hurtigt eskalere bekymringer om jeres leverandørtilsyn mere generelt. Overensstemmelsesvurdering og interne revisionsstandarder skelner typisk mellem mindre og større fund baseret på alvor og omfang af dækning, så svage klausuler kan graderes forskelligt afhængigt af, hvor udbredte de er, og hvor meget skade de kan forårsage.
Typiske huller omfatter:
- Vage sikkerhedsløfter: hvor udtryk som "branchestandardsikkerhed" mangler detaljer om adgangskontrol, logføring eller hændelsesrespons.
- Udefinerede tidslinjer for hændelser: hvor leverandører lover at rapportere "uden unødig forsinkelse", men der er ikke fastsat nogen tidsramme for indledende underretning eller opdateringer.
- Ingen omtale af underleverandører: så du kan ikke se, om leverandøren muligvis bruger underdatabehandlere, eller hvordan forpligtelser nedskrives.
- Manglende eller svage revisionsrettigheder: hvilket efterlader dig uden nogen pålidelig måde at verificere, at kontrollerne fungerer som forventet.
- Forkerte regulatoriske pligter: hvor kontrakter udelader sektorspecifikke outsourcing- eller databeskyttelseskrav, der gælder for dig.
Når revisorer opdager disse mønstre, kan de klassificere dem som mindre eller større afvigelser afhængigt af alvorlighed og dækning. Kunder, især i regulerede sektorer, kan behandle lignende mangler som grundlag for at kræve afhjælpningsplaner, strammere vilkår eller i nogle tilfælde et skift af leverandør.
Hvordan svage klausuler bliver til resultater, tvister og tabt tillid
Svage klausuler bliver til resultater, tvister og tabt tillid, når hændelser eller uenigheder afslører hullerne i dine kontraktlige forventninger. Uden klare ansvarsområder, tidslinjer og eskaleringsruter risikerer du langsomme reaktioner, omstridte forpligtelser og en fortælling, der underminerer tilliden hos kunder og tilsynsmyndigheder.
En simpel sammenligning illustrerer, hvorfor detaljer er vigtige:
| Miljø | Eksempel på svag klausul | Eksempel på stærk klausul |
|---|---|---|
| Hændelsesanmeldelse | "Giv besked uden unødig forsinkelse." | "Underret inden for fire timer efter registrering, derefter daglige opdateringer." |
| Underdatabehandlere | Ingen omtale. | "Identificér, søg godkendelse for og forpligte alle underdatabehandlere." |
| Revision og forsikring | "Udlever rapporter efter anmodning, hvor det er muligt." | "Udarbejd årlige revisionsrapporter og samarbejd med evalueringer." |
Forsinkede eller ufuldstændige underretninger betyder, at du kan opdage en hændelse via pressen eller dine kunder i stedet for din leverandør, hvilket reducerer din evne til at reagere og kommunikere troværdigt. Vejledning om tredjepartsrisiko i regulerede sektorer har dokumenteret tilfælde, hvor svage underretningsforpligtelser har fået organisationer til at lære om problemer fra eksterne kilder i stedet for deres leverandører, hvilket er præcis det scenarie, du ønsker at undgå. Tvetydige ansvarsområder fører til fingerpegning på det værst tænkelige tidspunkt. Manglende revisionsrettigheder gør det sværere at presse på for afhjælpning eller validere rettelser, især hvis tilsynsmyndigheder eller kunder holder øje med situationen.
Den positive side er, at resultaterne på dette område normalt kan rettes. Ved at omdanne dem til et struktureret forbedringsprogram – hvor man opdaterer basisskabeloner, omskoler forhandlere og målretter afhjælpning mod de højest risikable kontrakter først – får du en klar status over fremskridtene ved den næste revision eller kundegennemgang. ISMS.online kan hjælpe dig med at prioritere programmet ved at vise, hvor ældre klausuler eller svagere positioner stadig findes, og hvordan de relaterer sig til leverandørens risikoniveauer.
Administrer al din compliance, alt på ét sted
ISMS.online understøtter over 100 standarder og regler, hvilket giver dig en enkelt platform til alle dine overholdelsesbehov.
Styring: at holde din baseline på plads og reviderbar
Governance holder din A.5.20-baseline på plads og kan revideres ved at definere ejerskab, gennemgangscyklusser og dokumentation for leverandørsikkerhedsklausuler. Uden klar governance kan selv et veldesignet klausulbibliotek forsvinde over tid og skabe tavse huller mellem din angivne risikoappetit, dine kontrakter og din operationelle virkelighed.
I rapporten om informationssikkerhedens tilstand fra 2025 sagde cirka to tredjedele af organisationerne, at hastigheden og omfanget af lovgivningsmæssige ændringer gør det sværere at opretholde overholdelse af regler.
En kontraktbaseline leverer kun værdi, hvis den vedligeholdes og anvendes konsekvent. Governance er det lag, der forbinder dit klausulbibliotek med daglige beslutninger, leverandørrelationer og revisionsbeviser, og det er ofte forskellen mellem en engangsoprydning og en bæredygtig A.5.20-implementering.
Tildeling af ejerskab for leverandørsikkerhedskontrakter
At tildele ejerskab til leverandørsikkerhedskontrakter betyder at være tydelig omkring, hvem der definerer forventninger, hvem der forhandler formuleringer, hvem der overvåger præstationer, og hvem der tester overensstemmelse. Når disse ansvarsområder er klare, er det langt mindre sandsynligt, at vigtige klausuler vil blive udvandet eller omgået i sideaftaler.
En simpel model starter ofte med:
- Informationssikkerhed: definition af kontrolforventninger, risikoappetit og ikke-forhandlingsbare positioner.
- Juridiske og kontraktmæssige teams: omsætte disse til håndhævbar formulering og styre forhandlinger.
- Service- og leverandørchefer: overvåge præstationer, føre tilsyn med forpligtelser og indhente dokumentation.
- Intern revision eller tilsvarende funktion: regelmæssigt teste, om kontrakter og praksisser stemmer overens.
Ved at forbinde gennemgange af baseline-systemet med dine ISMS-processer holdes det aktuelt. Når risikovurderinger fremhæver nye trusler, når større hændelser opstår, eller når regler ændres, bør disse udløsere indgå i planlagte skabelongennemgange. Ledelsesgennemgange kan derefter overveje, om kontraktklausuler stadig matcher organisationens risikoprofil, og om yderligere ændringer er nødvendige.
Værktøjer og gennemgange, der holder A.5.20-beviser aktuelle
Værktøjer og gennemgange holder A.5.20-dokumentationen opdateret ved at give dig overblik over, hvilke kontrakter der bruger hvilke klausuler, og hvor der er afvigelser. Med den visning kan du prioritere opdateringer, understøtte forhandlinger og give revisorer en klar forklaring på, hvordan leverandørforventningerne opretholdes over tid.
Styring er nemmere, når man med et hurtigt blik kan se, hvilke kontrakter der bruger hvilke klausuler, og hvor undtagelserne er placeret. Denne synlighed understøtter både operationel beslutningstagning og revisionsforberedelse, især i MSP-miljøer med mange kunder og leverandører. Praksis fra versionskontrol- og ændringsstyringsdiscipliner viser, at sporing af, hvilke dokumentversioner der gælder i hvilke kontekster, er en central del af at demonstrere kontrol, og det samme princip gælder for kontraktgrundlinjer og afvigelser.
Et praktisk værktøjssæt til forvaltning omfatter ofte:
- A kontrakt- og leverandørregister som viser hvilken baselineversion hver relation bruger, risikoniveauet, nøgledatoer og eventuelle godkendte afvigelser.
- A afvigelsesproces dokumentation af, hvem der kan godkende undtagelser fra basislinjen, på hvilket grundlag og med hvilke kompenserende kontroller.
- Træning og vejledning: for salgs-, indkøbs- og juridiske teams, så de forstår, hvilke sikkerhedspositioner der ikke kan forhandles, og hvordan de skal forklare dem.
- Prøveprøve: ved intern revision, hvor et udvalg af kontrakter sammenlignes med basiskravene og A.5.20-kravene, og hvor det kontrolleres, om den operationelle virkelighed stemmer overens med aftalerne.
Brug af et system i stedet for regneark gør dette meget nemmere. En ISMS-platform kan opbevare leverandørlagre, linke dem til kontrakter og kontroller samt spore gennemgange og godkendelser. ISMS.online kan for eksempel registrere, hvilke leverandører der falder ind under hvilket risikoniveau, hvilke klausuler der gælder, og hvor undtagelser er blevet godkendt. Det giver et klart revisionsspor og reducerer risikoen for, at en stille kontraktændring underminerer din sikkerhedstilstand.
Med governance på plads holder din A.5.20-implementering op med at være en engangsafhjælpningsøvelse og bliver en bæredygtig del af, hvordan du håndterer tredjepartsrisici og demonstrerer sikkerhed over for kunder og revisorer.
Book en demo med ISMS.online i dag
ISMS.online hjælper dig med at omdanne ISO 27001 A.5.20 til en gentagelig MSP-kontraktgrundlag, der holder dine leverandøraftaler sikre, ensartede og auditerbare. Ved at centralisere leverandørregistre, klausulbiblioteker, kontrolkortlægninger og dokumentation gør platformen det nemmere at vise, at informationssikkerhedskrav er adresseret i aftaler og understøttet af den daglige praksis.
At se din A.5.20-baseline fungere i et rigtigt ISMS
At se din A.5.20-baseline fungere i et rigtigt ISMS betyder, at du kan spore leverandører, risici, kontrakter og kontroller i ét enkelt miljø. Når du kan gøre det, skifter samtaler med revisorer og kunder fra at søge efter dokumenter til at forklare, hvordan din leverandørstyring fungerer, og hvordan undtagelser håndteres.
Når du kan forbinde leverandører, risici, kontrakter og Annex A-kontroller ét sted, bliver samtaler med revisorer og kunder enklere og mere sikre. I stedet for at søge gennem fildelinger og indbakker kan du pege på en enkelt visning, der viser, hvilken basisversion der gælder for hver relation, hvilke undtagelser der findes, og hvordan disse beslutninger blev begrundet.
Inden for et enkelt miljø kan ISMS.online hjælpe dig med at forbinde leverandører til risikovurderinger, kontrakter og kontrolsæt, så det bliver nemmere at se, hvilke aftaler der understøtter hvilke dele af dit ISMS. Arbejdsgange understøtter gennemgange, godkendelser og fornyelser, hvilket hjælper dig med at sikre, at nye aftaler anvender baseline, og at højrisikokontrakter prioriteres til opgraderinger. Dashboards giver ledelsen et præcist overblik over leverandørdækning, udestående handlinger og kommende fornyelsesvinduer.
Hvad du kan forvente, når du udforsker ISMS.online
Når du udforsker ISMS.online, kan du se, hvordan struktureret leverandørstyring og A.5.20-kontraktgrundlinjer fungerer i et live ISMS snarere end i teorien. Fokus er på, hvordan dine eksisterende kontrakter, risici og kontroller kan organiseres i et enkelt, reviderbart billede, der reducerer manuel indsats og øger tilliden.
At udforske ISMS.online handler om at se, hvordan din nuværende leverandørstyring kan udvikle sig til et struktureret, reviderbart system i stedet for at tilføje endnu et værktøj til vedligeholdelse. Du kan gennemgå eksempler på A.5.20-klausulsæt, mappings og rapporter, der er skræddersyet til managed service providers, og teste, hvordan de passer til dine eksisterende kontrakter og processer.
For informationssikkerhedsledere, juridiske teams og MSP-ejere forkorter denne kombination af struktur og synlighed forberedelsen af revisioner, reducerer forhandlingsfriktion og styrker sikkerheden. At vælge ISMS.online giver mening, når du ønsker, at dine leverandøraftaler skal understøtte din ISO 27001-certificering, demonstrere kontrol over for kunderne og reducere tredjepartsrisiko uden at tilføje unødvendig kompleksitet. Hvis disse resultater er vigtige for dig, er det et naturligt næste skridt at se platformen i aktion.
Book en demoOfte stillede spørgsmål
Hvordan skal en MSP fortolke ISO 27001:2022 A.5.20 i daglige leverandør- og kundekontrakter?
Du bør behandle A.5.20 som et krav til specifikke, testbare sikkerhedsforpligtelser i dine kontrakter, ikke beroligende, men vage udsagn om "robust" eller "branchestandard" sikkerhed.
Når en revisor, en større kunde eller en tilsynsmyndighed læser dine aftaler, skal de kunne se, hvem der er ansvarlig for hvilke kontroller, hvad "godt" ser ud, og hvordan du kontrollerer, at det rent faktisk sker.
Hvordan ser "klare og kontrollerbare sikkerhedsklausuler" ud i praksis?
For en MSP er A.5.20 opfyldt, når leverandør og kunde indgår ensartede kontrakter:
- Fordel sikkerhedsansvar:
Angiv præcis, hvem der står for patching, endpoint-beskyttelse, backups, identitets- og adgangsstyring, overvågning og hændelsesprioritering – inklusive eventuelle delte ansvarsområder.
- Beskriv hvordan information håndteres:
Dæk hvordan data inden for området tilgås, behandles, lagres, overføres, sikkerhedskopieres, opbevares og slettes, på et sprog som en ikke-teknisk korrekturlæser kan følge.
- Definer regler for underretning om hændelser og samarbejde:
Brug konkrete udløsere ("bekræftet kompromittering af kundedata", "serviceafbrydelse > X minutter"), tidslinjer ("indledende alarm inden for X timer"), navngivne kontaktruter og forventninger til fælles undersøgelser og kommunikation.
- Afspejl gældende regler og sektorregler:
Inddrag forpligtelser vedrørende privatliv, outsourcing, modstandsdygtighed eller sektorspecifikke forpligtelser i aftalen i stedet for udelukkende at stole på politikker eller uformelle garantier.
- Inkluder brugbare sikkerheds- og tilsynsmekanismer:
Give dig ret til at se dokumentation (ISO 27001-certifikater, SOC 2-rapporter, pen-testresuméer, fokuserede spørgeskemaer) i en aftalt rytme og til at følge op, hvor det er nødvendigt.
En hurtig selvkontrol, der giver genlyd hos revisorer, er:
Hvis vi kun havde denne kontrakt på bordet, kunne vi så vise, at vores informationssikkerhedskrav er definerede, risikobaserede og håndhævelige – eller ville vi udfylde hullerne med, "hvad alle ved, vi mente"?
Hvis svaret er tættere på sidstnævnte, bør dit ISMS registrere det som en svaghed og føre til en ændring i formulering, skabeloner eller godkendelsesregler.
En platform som ISMS.online gør det langt nemmere at demonstrere. Du kan linke hver kontraktklausul tilbage til de risici og kontroller, den understøtter, og vise, hvordan A.5.20 implementeres gennem reelle aftaler i stedet for at stole på hukommelse eller uformelle noter.
Hvordan passer A.5.20 sammen med A.5.19 og A.5.21 for en MSP?
De tre kontroller danner en en enkelt tredjeparts sikkerhedslivscyklusHvem du arbejder med, hvad du har brug for på papiret, og hvordan du styrer den lagdelte forsyningskæde, der leverer dine tjenester.
Hvordan bør en MSP se på A.5.19-A.5.21-kæden?
For de fleste MSP'er ser mønsteret sådan ud:
- A.5.19 – leverandørens livscyklus:
Hvordan du udvælger, vurderer, godkender, onboarder, overvåger og, når det er nødvendigt, forlader leverandører – herunder kriterier, due diligence og periodiske gennemgange.
- A.5.20 – kontraktlig informationssikkerhed:
Hvor disse forventninger omdannes til bindende forpligtelser i hovedserviceaftaler (MSA'er), arbejdsbeskrivelser (SoW'er), SLA'er, DPA'er og sikkerhedsplaner.
- A.5.21 – IKT-forsyningskæde og privatlivsrisiko:
Hvordan du kontrollerer og overvåger lagdelte udbydere – cloudplatforme, specialværktøjer, underleverandører – og den måde, de håndterer personlige og følsomme data.
I den daglige drift er A.5.20 den bro mellem dit risikoperspektiv og din juridiske position:
- Din leverandørregister og risikovurderinger (A.5.19) beskriv risikoen og de kontroller, du vil stole på.
- Din kontrakter (A.5.20) formalisere, hvem der skal udføre disse kontroller, og hvad der sker, når de ikke gør det.
- Din tilsyn med forsyningskæden (A.5.21) kontrollerer, at virkeligheden stemmer overens med både ISMS og kontrakten, herunder datastrømme og underleverandører.
Revisorer og store kunder vil naturligvis stille disse op. Hvis dit risikoregister siger, at en cloud-udbyder er "kritisk, højrisiko", men kontrakten kun indeholder generiske formuleringer om "rimelig sikkerhed", vil de påpege det.
ISMS.online giver dig mulighed for at samle disse prikker ét sted: leverandørregistre knyttet til risici, kontroller og specifikke kontraktklausuler. Det betyder, at når nogen spørger "Hvordan administrerer du dine underdatabehandlere i henhold til A.5.21?", kan du vise leverandører, kontrakter, kontroller og gennemgangscyklus samlet i stedet for at svare fra hukommelsen.
Hvordan kan man omdanne ISO 27001 A.5.20 til et praktisk sæt af MSP-kontraktklausuler?
Du gør A.5.20 praktisk ved at aftale en kort, ufravigelig tjekliste over sikkerhedsemner det skal altid overvejes, og derefter besluttes, hvor hvert emne normalt findes i din kontraktpakke.
Det gør enhver ny aftale eller fornyelse til en øvelse i at anvende et mønster i stedet for at opfinde formuleringer under deadlinepres.
Hvad hører hjemme på en MSP's standard A.5.20-tjekliste?
De fleste MSP'er ender med en kerneliste i stil med dette:
- Omfang og tilladt anvendelse: – hvilke tjenester, systemer og data der er omfattet; hvad den anden part må og ikke må; eventuelle geografiske eller lovgivningsmæssige grænser.
- Adgangskontrol: – hvordan identiteter og konti oprettes, godkendes, gennemgås og fjernes; håndtering af privilegeret adgang; forventninger til udenrigsministeriet.
- Logføring og overvågning: – minimumsforventninger til logføring, opbevaringsperioder og hvordan du kan indhente logfiler til undersøgelser eller revision.
- Sårbarheds- og forandringshåndtering: – forventninger til programrettelser og afsløring af sårbarheder; forudgående varsel om væsentlige ændringer, der kan påvirke sikkerhed eller tilgængelighed.
- Hændelseshåndtering: – hvad der tæller som en hændelse, udløsere og tidsfrister for underretninger, påkrævet indhold til underretninger, eskaleringsstier og forventninger til fælles efterforskning.
- Forretningskontinuitet og katastrofeberedskab: – gældende RTO/RPO'er, backupfrekvens og test, failover-forventninger, hvor tilgængelighed virkelig betyder noget.
- Underleverandører: – hvornår yderligere udbydere kan anvendes, hvad der skal oplyses eller godkendes, og hvordan de skal arve dine sikkerheds- og privatlivskrav.
- Databeskyttelse og privatliv: – behandlingsinstruktioner, datakategorier, placeringer og overførsler, understøttelse af registreredes rettigheder og meddelelser om brud.
- Dataopbevaring, returnering og sletning: – hvor længe data opbevares, hvad der sker ved afslutning, hvordan sikker sletning udføres, og hvordan dokumentation foreligger.
- Sikkerhed og tilsyn: – den dokumentation, du rent faktisk kan anmode om og stole på (certificeringer, rapporter, bekræftelsesbreve, svar på målrettede spørgeskemaer), og hvor ofte.
Det hjælper med at få et simpelt overblik over, hvor disse normalt bor:
| Emneområde | Typisk kontraktmæssigt hjemsted for en MSP |
|---|---|
| Omfang, tilladt brug | MSA / SoW |
| Adgang, logning, overvågning | Sikkerhedsplan / teknisk bilag |
| Sårbarhed, forandring, hændelser | Sikkerhedsplan / SLA |
| Kontinuitet, DR | Sikkerhedsplan / SLA |
| Underleverandører, databeskyttelse | Sikkerhedsplan + DPA |
| Opbevaring, returnering, sletning | Sikkerhedsplan + udgangsbestemmelser i MSA |
| Sikring og tilsyn | Sikkerhedsplan / styringsafsnit |
Når dette mønster er fastlagt, kan du opbygge interne tjeklister og gennemgå trinene omkring det. ISMS.online kan derefter forbinde hvert emne med de relevante leverandører, risici og kontroller, så for eksempel en risiko for en hændelsesmeddelelse automatisk fører dig tilbage til de relevante klausuler og berørte kontrakter.
Hvordan kan en MSP designe en genanvendelig A.5.20-kontraktgrundlinje, der stadig holder i virkelige forhandlinger?
En brugbar tilgang er at opbygge en modulær kontraktstruktur og vedligeholde en bibliotek med taggede klausuler der ligger sammen med dit ISMS, med klare regler for, hvornår og hvordan du kan variere formuleringen.
Målet er at kunne forklare konsekvent, hvorfor dine kontrakter ser ud, som de gør, og hvordan de understøtter din risikoprofil, selv efter hårde forhandlinger.
Hvordan ser en modulær A.5.20-baseline ud for MSP'er?
Mange MSP'er går sammen om en struktur som denne:
- A hovedserviceaftale (MSA) for overordnede juridiske termer, ansvar, ejerskab og ansvar på overordnet niveau.
- Arbejdsbeskrivelser (SoW'er): der definerer tjenester, systemer og data inden for rammerne, placeringer og eventuelle kundespecifikke krav eller variationer.
- A serviceniveaubilag fastsættelse af mål for tilgængelighed, respons og løsning, herunder hvor disse understøtter sikkerheden (f.eks. responstider for hændelser).
- En dedikeret sikkerhedsplan der samler temaerne A.5.19–A.5.21 ét sted med resultatbaseret sprog, så du kan opdatere forventningerne uden at omskrive hele MSA'en.
- Hvor personoplysninger behandles, skal en databehandleraftale (DPA) der refererer til og stemmer overens med sikkerhedsplanen i stedet for at duplikere eller modsige den.
Bag den struktur opretholder du en internt klausulbibliotek hvor hver sætning er mærket med:
- sikkerhedsemne den omhandler (f.eks. adgangsgennemgange, tidslinjer for hændelser, oplysning om underleverandører).
- ISO 27001 og relaterede kontroller den understøtter især A.5.19, A.5.20 og A.5.21.
- En eller flere risikoniveauer – for eksempel standard-, vigtige og kritiske tjenester eller kunder.
Dette giver dig tre nøglegreb:
- Et sæt af minimumsbasispositioner som du sjældent bevæger dig under (for eksempel maksimale forsinkelser ved hændelsesmeddelelser).
- Et sæt af forbedrede varianter Klar til situationer med højere risiko, så du kan styrke kontrakter for kritiske tjenester uden at improvisere.
- Et sæt af undtagelsesregler, herunder hvem der kan godkende afvigelser fra baseline, hvilke kompenserende foranstaltninger du forventer, og hvornår disse beslutninger vil blive gennemgået.
Hvis klausulbiblioteket og godkendelsessporet findes på en platform som ISMS.online, og er knyttet til dit risikoregister og leverandørregistre, kan du vise, at opdateringer til din A.5.20-baseline følger af reelle ændringer – nye trusler, hændelser, lovgivningsmæssig vejledning – i stedet for ad hoc-grænser.
I forhandlinger gør denne struktur også samtaler mindre personlige. I stedet for at diskutere formuleringsstil kan du og din modpart vælge mellem klart definerede varianter knyttet til en aftalt risikoprofil, og I kan dokumentere præcis, hvorfor en stærkere eller svagere mulighed blev valgt.
Hvilke informationssikkerhedskrav bør næsten altid fremgå af MSP-leverandøraftaler under A.5.20?
Nogle krav er så grundlæggende, at de hører hjemme i næsten hver leverandøraftale inden for rammerne, uanset kontraktværdi eller servicekategori. Disse "altid aktive" elementer danner grundlaget for din A.5.20-implementering.
Hvad hører typisk hjemme i en MSP's "altid-på" A.5.20-lag?
De fleste medlemmer af byrådet lægger sig fast på en kortfattet liste, der kun varieres ved undtagelse og med en klar begrundelse:
- Fortrolighed og acceptabel brug:
Pligter til at beskytte dine oplysninger og kundeoplysninger, plus illustrative eksempler på forbudt adfærd såsom uautoriseret kopiering, videregivelse eller datamining.
- Tilpasning til dine vigtigste politikker:
Et krav om at følge specificerede politikker for informationssikkerhed, acceptabel brug og, hvor det er relevant, sikker udvikling, som I offentliggør og vedligeholder via jeres ISMS.
- Adgangs- og identitetskontrol:
Forventninger til brug af stærk autentificering, håndhævelse af færrest rettigheder, gennemgang af adgang i en defineret kadence og tilbagekaldelse af adgang omgående, når den ikke længere er nødvendig.
- Hændelsesmeddelelse og samarbejde:
Klare kriterier for, hvad der skal rapporteres, tidsrammer for indledende og opfølgende meddelelser, minimumsindhold (tidslinje, indvirkning, berørte data, inddæmningsforanstaltninger) og hvordan fælles undersøgelser og ekstern kommunikation håndteres.
- Gennemsigtighed hos underleverandører:
Forpligtelser til at oplyse væsentlige underleverandører, give forhåndsvarsel om væsentlige ændringer og pålægge disse parter væsentligt lignende sikkerheds- og privatlivsvilkår.
- Vilkår for databeskyttelse:
Hvor der er tale om personoplysninger, vilkår der stemmer overens med dine lovmæssige ansvarsområder (f.eks. i henhold til GDPR eller CCPA) og med dine egne privatlivs- og opbevaringspolitikker.
- Datareturnering og sikker sletning:
Instruktioner for, hvordan data returneres, overføres eller slettes sikkert ved afslutningen af forholdet eller tjenesten, og en rimelig forventning om bevis for, at sletning har fundet sted.
- Sikringsmekanismer:
Aftalte måder, hvorpå I kan overvåge sikkerhedstilstanden – såsom ISO 27001-certifikater, SOC 2-rapporter, korte spørgeskemaer eller formelle attester – og hvor ofte I vil modtage dem.
Et nyttigt spørgsmål at huske på er:
Hvis denne leverandør oplevede en alvorlig hændelse i aften, har vi så nok i denne kontrakt til at handle hurtigt, insistere på passende afhjælpning og forklare vores tilsyn til kunder eller tilsynsmyndigheder?
Hvis du tøver, kan et af disse områder, der altid er aktive, mangle eller være for svagt. At indfange dem som en del af din baseline og integrere dem i standardskabeloner reducerer afhængigheden af individuelle forhandleres instinkter og giver revisorer og kunder en klar historie.
ISMS.online kan styrke dette yderligere ved at forbinde disse basisklausuler til leverandørregistreringer, risici og ledelsesgennemgange, så du kan vise, at det grundlæggende lag eksisterer, anvendes og gennemgås, når omstændighederne ændrer sig.
Hvordan kan en MSP holde sin A.5.20-kontraktgrundlinje i overensstemmelse med ISMS og let at dokumentere over tid?
Du holder A.5.20 på linje ved at behandle kontraktens ordlyd som en del af din sikkerhedsstyring, med navngivne ejere, planlagte gennemgange og klare forbindelser til leverandørstyring og risikohåndtering, snarere end en separat juridisk øvelse, der udvikler sig over tid.
Hvordan ser bæredygtig A.5.20-forvaltning ud for en MSP?
Selv i mindre MSP'er gør en simpel styringsmodel en stor forskel:
- Informationssikkerhed:
Definerer sikkerhedsforventninger, elementer, der altid er tændt, og ikke-forhandlelige positioner i et letforståeligt sprog, knyttet til ISO 27001-kontroller og andre rammer, du stoler på.
- Juridisk eller kontraktmæssigt team:
Ejer den faktiske formulering, rådgiver under forhandlinger og registrerer, hvor basislinjer overskrides eller lempes, herunder begrundelse og eventuelle kompenserende sikkerhedsforanstaltninger.
- Leverandørchefer eller serviceejere:
Overvåg om leverandørerne opfylder deres forpligtelser i praksis, indsaml dokumentation (certifikater, rapporter, svar) og rejst problemer, når forventningerne ikke opfyldes.
- Intern revision eller tilsvarende:
Udtager regelmæssigt stikprøver af et sæt kontrakter, sammenligner dem med din baseline, leverandørregister og risikoregistreringer og anbefaler forbedringer.
Disse roller følger derefter en forudsigelig rytme:
- Kontraktskabeloner og klausulbiblioteker gennemgås som en del af din risikovurdering og ledelsesgennemgangscyklusser, så hændelser, næsten-uheld og lovgivningsmæssige ændringer fører til målrettede opdateringer af formuleringen.
- Et centralt register viser hvilke kontrakter bruger hvilken baseline-version, hvilke leverandører der befinder sig i hvilket risikoniveau, og hvor I har accepteret afvigelser, herunder en oversigt over, hvem der godkendte dem, og hvorfor.
- Kort håndbøger og tjeklister hjælpe salgs-, indkøbs- og kundeteams med at forstå, hvilke vilkår der er obligatoriske, hvor de har fleksibilitet, og hvornår de har brug for at inddrage sikkerheds- eller juridiske specialister.
I meget lille skala kan du holde meget af dette samlet med dokumenter og delte mapper. Efterhånden som din kundebase, leverandørliste og rammedækning vokser, bliver det hurtigt skrøbeligt.
ISMS.online giver dig mulighed for at samle leverandørlagre, kontraktgrundlinjer, kontroller, risici, revisioner og ledelsesgennemgange i én visning, så når nogen spørger:
- "Hvordan sikrer I, at A.5.20 anvendes konsekvent på kritiske leverandører?"
- "Hvor registrerer I undtagelser fra jeres standardpositioner?"
- "Hvordan påvirker kontraktændringer jeres risikoregister?"
Du kan svare med aktuelle, sammenkædede beviser i stedet for et kludetæppe af filer.
Det strukturniveau signalerer til kunder, revisorer og tilsynsmyndigheder, at I driver leverandør- og kundesikkerhed som en administreret disciplin. Det viser, at jeres kontrakter, jeres ISMS og jeres daglige adfærd stemmer overens, hvilket igen gør det lettere at vinde og fastholde den type kunder, der bekymrer sig mest om tredjepartsrisiko.








