Hvordan ISO 27001 A.5.17 beskytter MSP-legitimationsoplysninger mod brud på flere lejere

Hvorfor er MSP-legitimationsoplysninger nu den primære angrebsvej?

MSP-legitimationsoplysninger er nu en primær angrebsrute, fordi én privilegeret konto kan låse op for mange kundemiljøer på én gang. Hvert teknikerlogin, token eller API-nøgle koncentrerer risikoen på tværs af din portefølje, ikke kun én klient. Angribere ser din MSP som et knudepunkt, så hvis de får fat i den rigtige identitet, kan de hurtigt skifte mellem lejere og gøre din operationelle rækkevidde til deres løftestang i stor skala. Vejledning til identitets- og adgangsstyring fra nationale cybersikkerhedsorganer, såsom NCSC's 10-trinsråd om identitets- og adgangsstyring, fremhæver også, at kompromittering af privilegerede identiteter er en af de mest almindelige veje ind i organisationer, hvilket gør disse identiteter særligt kritiske i en MSP-model med flere lejere.

Disse oplysninger er generelle og udgør ikke juridisk rådgivning eller rådgivning om compliance. Du bør altid søge professionel vejledning i din specifikke situation.

De fleste organisationer i ISMS.online-undersøgelsen fra 2025 siger, at de har været påvirket af mindst én sikkerhedshændelse hos tredjepart eller leverandør i det seneste år.

Den MSP-brede eksplosionsradius for en enkelt legitimationsoplysninger

En enkelt kompromitteret teknikerkonto eller værktøjslegitimationsoplysninger kan give en ubuden gæst næsten samme rækkevidde, som dit team har. I en MSP-stak med flere lejere kan det betyde adgang til fjernadministrationskonsoller, cloudportaler, backupsystemer og leverandørdashboards, der alle stoler på den samme identitet. Én fejl kan derfor føre til samtidige hændelser på tværs af mange kunder i stedet for et enkelt isoleret brud. Analyser af større brud i forsyningskæden og hos tjenesteudbydere viser gentagne gange, hvordan kompromittering af en enkelt servicekonto, integrationsnøgle eller MSP-værktøjslegitimationsoplysninger kan sprede sig hurtigt på tværs af mange downstream-organisationer.

Når en angriber har den identitet, kan de bevæge sig lateralt på tværs af lejere, implementere malware, som om de var en del af jeres personale, og manipulere med logfiler eller sikkerhedskopier for at skjule deres spor. Resultatet er ikke kun nedetid for én kunde; det kan være langvarigt klienttab, kontraktlige sanktioner og alvorlig omdømmeskade, der underminerer jeres vækstplaner.

Hvorfor traditionelle legitimationsoplysninger mislykkes i miljøer med flere lejere

Traditionelle vaner som at dele administratoradgangskoder, gemme legitimationsoplysninger i browsere eller opbevare dem i ustrukturerede noter var knap nok acceptable i et enkelt organisationsnetværk; de er uacceptable i en MSP. Dine ingeniører bevæger sig hurtigt mellem lejere, værktøjer og supportopgaver, og bekvemmelighedsdrevne genveje er uundgåelige, når der ikke er en central måde at arbejde sikkert på. I en kontekst med flere lejere eksponerer disse genveje mange miljøer på én gang.

Hvis du stadig er afhængig af delte globale administratorkonti eller browsergemte adgangskoder, ved du allerede, hvor ubehagelige revisioner og kundespørgsmål kan føles. Disse adfærdsmønstre ødelægger også ansvarlighed. Hvis flere ingeniører deler én konto, kan du ikke se, hvem der gjorde hvad, så du har svært ved at besvare kundespørgsmål eller revisionsspørgsmål med tillid. Regulatorer og virksomhedskøbere forventer nu, at privilegeret adgang er individuel, tidsbegrænset og overvåget, og de behandler svag praksis omkring godkendelsesoplysninger som en direkte forretningsrisiko. Branchekommentarer beskriver i stigende grad identitet som den nye sikkerhedskampplads, hvor forsikringsselskaber og store købere fokuserer på, om privilegeret adgang er knyttet til navngivne brugere, begrænset i tid og kan revideres.

ISO 27001:2022 kontrol A.5.17 blev introduceret for at håndtere det bredere sæt af moderne risici omkring autentificeringsinformation og opfordrede organisationer - herunder MSP'er - til at bevæge sig væk fra uformelle praksisser for håndtering af hemmelige oplysninger og hen imod styrede, auditerbare kontroller. Den forventer, at du bevæger dig fra uformelle vaner til en styret proces, hvor allokering, brug, overvågning og tilbagekaldelse af autentificeringsinformation er bevidst, dokumenteret og kan gennemgås på tværs af alle de miljøer, du berører.

Book en demo

Hvad forventer ISO 27001 A.5.17 egentlig af en MSP?

ISO 27001:2022 A.5.17 forventer, at du behandler godkendelsesoplysninger som et administreret aktiv med en klar livscyklus. For en MSP betyder det, at alle adgangskoder, tokens, nøgler, pinkoder og gendannelsesfaktorer, du håndterer til interne systemer eller kundemiljøer, skal oprettes, gemmes, bruges, ændres og tilbagekaldes i henhold til regler, du kan forklare og dokumentere. Ejere, sikkerhedsledere og driftsledere skal alle kunne vise, hvordan disse regler fungerer i praksis. Ordlyden af A.5.17 i ISO/IEC 27001:2022 gør det klart, at godkendelsesoplysninger bør styres som en del af dit ISMS med definerede oprettelses-, brugs-, ændrings- og tilbagekaldelsesaktiviteter snarere end ad hoc-beslutninger.

At omdanne tæt kontrolsprog til almindeligt engelsk

Essensen af A.5.17 er, at enhver hemmelig identitetsbevisende handling håndteres bevidst og ikke overlades til personlige præferencer eller stammekundskaber. Kort sagt forventer kontrollen, at du som minimum definerer:

Hvem kan anmode om en legitimationsoplysninger.
Hvem godkender den anmodning.
Hvor stærk legitimationen skal være.
Hvordan det leveres til brugeren eller systemet.
Hvor det opbevares og beskyttes.
Når det skal gennemgås eller ændres.
Hvordan misbrug eller kompromittering opdages.
Hvordan og hvornår det tilbagekaldes.

Disse beslutninger bør være konsistente på tværs af dit interne miljø og dit kundearbejde. Din egen servicedesk, fjernovervågnings- og administrationsplatforme (RMM) og platforme til automatisering af professionelle tjenester (PSA), dokumentationssystemer, backupkonsoller, kildekontrol og identitetsudbydere er tydeligvis omfattet. Det samme gælder kundernes cloud-lejere, lokale domæner, firewalls, SaaS-konsoller og tredjepartsleverandørportaler, hvor dine medarbejdere bruger eller gemmer legitimationsoplysninger til det daglige arbejde.

Ifølge ISMS.online-undersøgelsen fra 2025 forventer mange kunder nu, at deres leverandører overholder formelle rammer som ISO 27001, ISO 27701, GDPR, Cyber Essentials og SOC 2.

Du kan ikke bare sige "det er kundens legitimationsoplysninger", hvis dine medarbejdere håndterer dem regelmæssigt. Hvis en hemmelighed oprettes, gemmes, bruges eller understøttes af dit team, falder den ind under din A.5.17-proces og skal være dækket af dine politikker, procedurer og bevismateriale, selv når systemet teknisk set tilhører kunden.

Omfang af "godkendelsesoplysninger", så du ikke går glip af noget

A.5.17 forventer, at du er præcis omkring, hvad "godkendelsesoplysninger" betyder i din kontekst, i stedet for kun at fokusere på åbenlyse adgangskoder. Støttende vejledning i ISO/IEC 27002:2022 for kontrol A.5.17 udvider eksplicit begrebet til at dække tokens, nøgler og andre hemmeligheder, der bruges til at bevise identitet, ikke kun adgangskoder. I praksis betyder det, at du inkluderer mindre synlige hemmeligheder sammen med brugerlegitimationsoplysninger, så de ikke glemmes i dit kontroldesign. Når du begynder at liste dem, kan antallet af forskellige hemmelighedstyper i en multi-tenant MSP være overraskende.

Du skal normalt redegøre for ting som:

API-nøgler, klienthemmeligheder og tokens, der bruges i automatisering og integrationer.
SSH-nøgler, certifikater og foruddelte VPN-nøgler, der bruges af ingeniører og værktøjer.
Gendannelseskoder og hardwaretoken-seeds til multifaktorgodkendelse.
Biometriske skabeloner på enheder eller systemer, du konfigurerer eller administrerer.

En struktureret scoping-øvelse identificerer, hvor disse elementer findes, hvilke systemer de beskytter, og hvilke teams der bruger dem. Derfra beslutter du, hvilke politikker og procedurer der skal opdateres, hvilke værktøjer der skal integreres i dit informationssikkerhedsstyringssystem (ISMS), og hvor nye kontroller er nødvendige. Målet er, at når en revisor, kunde eller forsikringsselskab spørger "hvordan håndterer du godkendelsesoplysninger?", kan du vise en klar end-to-end livscyklus i stedet for en samling af usammenhængende praksisser.

For at forstærke dette skift hjælper det at kontrastere gamle vaner med praksisser, der er i overensstemmelse med A.5.17:

Miljø	Gammel vane	A.5.17-tilpasset praksis
Oprettelse af legitimationsoplysninger	Oprettelse af ad hoc-konto	Godkendt, logget og knyttet til en risiko/kontrol
Opbevaring	Browser, noter eller delte regneark	Central hvælving med rollebaseret adgang
Rotation og tilbagekaldelse	Kun efter hændelser	Planlagte gennemgange plus hændelsesdrevet tilbagekaldelse
Beviser	Skærmbilleder i e-mailkæder	Kontrollerede poster knyttet til ISMS-kontroller

Når forskellene er fremlagt på denne måde, bliver det lettere for teams at forstå, hvorfor kontrollen er vigtig, og hvor det daglige arbejde skal ændres.

ISMS.online giver dig et forspring på 81% fra det øjeblik, du logger på

ISO 27001 gjort nemt

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.

Kom i gang

Hvor lækker og misbruger MSP'er virkelig autentificeringsoplysninger i dag?

MSP'er lækker og misbruger ofte godkendelsesoplysninger flere steder end ledere forventer, fordi hemmeligheder optræder i mange værktøjer, arbejdsgange og genveje. Når man ser nærmere på teknikernes daglige arbejde, er det almindeligt at finde legitimationsoplysninger spredt på tværs af browsere, chatlogfiler, tickets, personlige adgangskodeadministratorer, dokumentationssystemer og scripts. A.5.17 opfordrer dig til at anerkende disse realiteter og beslutte, hvordan de skal styres.

Spredning af skjulte legitimationsoplysninger på tværs af værktøjer og teams

Den første overraskelse hos de fleste MSP'er er, hvor mange ikke-brugerhemmeligheder der findes, som ingen aktivt ejer. Ud over navngivne brugerkonti vil du typisk opdage:

Delte administratorlogin til RMM-, PSA-, backup- og dokumentationsværktøjer.
Servicekonti i kundedomæner til overvågning, sikkerhedskopiering eller integrationer.
Langlivede API-nøgler til cloudtjenester, webhooks eller leverandør-API'er.
Krypteringsnøgler og certifikater, der opbevares uformelt på ingeniørers enheder.

Mange af disse hemmeligheder har ingen klar ejer, intet dokumenteret formål og ingen udløbsdato. De kan være blevet oprettet under en migrering, et projekt eller en nødsituation og derefter forladt, fordi de "bare virker". Brancheundersøgelser af legitimationsvaner rapporterer lignende mønstre, hvor adskillige værdifulde konti mangler klart ejerskab, dokumentation og defineret udløb i mange organisationer, som fremhævet i arbejde som Security Credential Habits-undersøgelsen. Fordi disse hemmeligheder kører stille i baggrunden, inkluderes de sjældent i rutinemæssige adgangsgennemgange eller risikovurderinger, men de er attraktive mål: kraftfulde, forudsigelige og ofte dårligt overvågede.

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øroverholdelse som en af de største sikkerhedsudfordringer.

A.5.17 giver dig en grund – og et krav – til at bringe disse skjulte aktiver ind i en kontrolleret fortegnelse. Implementeringskommentarer til A.5.17 understreger, at organisationer bør identificere og administrere alle former for autentificeringsinformation, hvilket naturligt fører til at opretholde en fortegnelse over sådanne hemmeligheder som en del af kontrolområdet. Denne fortegnelse er grundlaget for ethvert seriøst forsøg på at reducere angrebsfladen og demonstrere kontrol over for kunder, revisorer og forsikringsselskaber, der ønsker at forstå, hvordan I administrerer privilegeret adgang.

Hverdagsvaner, der underminerer selv stærk teknologi

Selv hvis du implementerer moderne værktøjer, kan hverdagens menneskelige vaner hurtigt underminere dem. Ingeniører kan eksportere adgangskoder fra en hvælving til et regneark, så de kan "arbejde offline", indsætte administratoradgangskoder i tickets eller chatte for nemheds skyld eller genbruge personlige hemmeligheder, når de opretter nye konti. Multifaktor-godkendelse kan håndhæves på flagskibssystemer, men stille og roligt deaktiveres eller omgås, hvor det sinker folk.

Hvis dine hemmeligheder stadig er spredt på tværs af browsere, chat og personlige værktøjer, ved du allerede, hvor svært det er at ræsonnere om risiko. Disse adfærdsmønstre er forståelige under tidspres, men de er i direkte konflikt med A.5.17's forventning om kontrolleret allokering og administration. De gør det også svært at besvare grundlæggende spørgsmål efter en hændelse, såsom "præcis hvilke hemmeligheder kunne denne kompromitterede bærbare computer have afsløret?" eller "hvilke kundelejere var i fare fra denne konto?". Uden disse svar mister din hændelsesrespons og kundekommunikation hurtigt troværdighed.

Små designændringer hjælper med at reducere behovet for usikre løsninger, for eksempel kan du:

Deaktiver lagring af browseradgangskoder for administratorkonti.
Bloker eksport fra din centrale boks via politikker og tekniske kontroller.
Kræv multifaktor-godkendelse for alle privilegerede roller, ikke kun overordnede systemer.

Disse tiltag fjerner ikke al menneskelig risiko, men de mindsker det rum, hvor uformelle løsninger stille og roligt kan udhule dit kontrolmiljø og skabe eksponering af legitimationsoplysninger, der er svært at spore.

Hvordan bør du designe en A.5.17-tilpasset multi-tenant-godkendelsesstrategi?

En A.5.17-tilpasset godkendelsesstrategi for MSP'er klassificerer legitimationsoplysninger efter påvirkning og fastsætter minimumsbeskyttelse pr. niveau. Når du har forstået dit legitimationslandskab, kan du gå fra individuelle vaner til en defineret model, hvor forskellige typer hemmeligheder har klare behandlingsregler. Målet er, at kompromittering af én legitimationsoplysninger ikke automatisk bringer alle de kundelejere, du understøtter, i fare.

Definition af legitimationsniveauer og minimumsbeskyttelse

En praktisk måde at starte på er at definere niveauer af godkendelsesoplysninger baseret på påvirkning og derefter knytte klare minimumskontroller til hvert niveau. Dette giver dig mulighed for at skalere fornuftige regler på tværs af lejere i stedet for at forhandle hver konto individuelt. Personalet lærer også hurtigt, hvilke hemmeligheder der kræver strengere håndtering, og hvorfor visse trin ikke er til forhandling.

Du kan definere niveauer som:

Niveau 1 – Glasbrud og platformsejere: nødkonti, superadministratorer for identitetsudbydere, kerne-RMM og PSA-ejere.
Niveau 2 – Lejer- og systemadministratorer: Kunde-lejeradministratorer, domæneadministratorer, firewalladministratorer, SaaS-roller med høje rettigheder.
Niveau 3 – Ingeniør- og supportroller: Navngivne medarbejderkonti med udvidede, men begrænsede rettigheder i værktøjer og lejere.
Niveau 4 – Service- og automatiseringsidentiteter: servicekonti, scripts, planlæggere og API-integrationer.
Niveau 5 – Standardbrugerkonti og hemmeligheder med lav risiko:

For hvert niveau definerer du minimumskontroller såsom multifaktorgodkendelse, lagringskrav, rotationsfrekvens, overvågningsforventninger og godkendelsesprocesser. Det forvandler vag vejledning til konkrete regler som "Tier 1- og 2-hemmeligheder findes kun i hvælvingen, tilgås via en privilegeret arbejdsgang og roteres automatisk hver halvfems dage eller efter enhver hændelse".

Værdien ved denne model er, at den skalerer. Når du tilføjer lejere, værktøjer eller regioner, klassificerer du nye legitimationsoplysninger i det rigtige niveau og anvender de samme grundlæggende beskyttelser i stedet for at opfinde nye regler hver gang. Med tiden tænker personalet i niveauer og forstår, hvorfor nogle hemmeligheder har strengere håndteringsforventninger.

Balancering af ambitioner, traditionelle begrænsninger og forretningsmål

Det er fristende at designe en perfekt model, hvor der ikke findes nogen privilegeret konto uden just-in-time-elevation, og hvor alle hemmeligheder roteres dagligt. I virkeligheden skal du balancere ambitionen med begrænsningerne i ældre systemer, kundernes budgetter og din egen kapacitet. Nogle systemer kan endnu ikke understøtte moderne modeller, og nogle kunder vil kun bevæge sig i et bestemt tempo.

Du beslutter dig måske for, at "ingen stående privilegier" er opnåelige for cloud-lejeradministratorroller ved hjælp af indbyggede funktioner til privilegeret identitetsstyring, men at visse lokale systemer for nu vil være afhængige af traditionelle konti. Du dokumenterer dette, specificerer kompenserende kontroller såsom strammere overvågning eller strengere fysisk sikkerhed og planlægger periodisk revurdering for at undgå ubestemte undtagelser.

Det er også vigtigt at have forretningsmålene for øje. Din strategi bør understøtte hurtig onboarding af kunder, problemfri integration af opkøb og overholdelse af sektorspecifikke forventninger såsom finansielle eller sundhedsmæssige regler. Brugt på denne måde bliver A.5.17 mindre af et compliance-afkrydsningsfelt og mere en måde at reducere risikoen for, at ét sæt legitimationsoplysninger kan underminere hele din serviceportefølje.

Integrer, udvid og skaler din compliance uden besvær. IO giver dig robustheden og selvtilliden til at vokse sikkert.

Book din demo

Hvilke arkitekturer fungerer rent faktisk til vaults, PAM, KMS og JIT i en MSP-stak?

MSP'er drager fordel af en simpel referencearkitektur, der kombinerer identitet, hemmelighedsopbevaring, administration af privilegeret adgang og nøglehåndtering i ét sammenhængende design. Målet er at reducere, hvor ofte personalet skal se eller håndtere rå hemmeligheder, samtidig med at det stadig understøtter arbejdsgange i den virkelige verden. Når disse byggesten arbejder sammen, får du den synlighed og kontrol, som A.5.17 forventer, uden at lamme dine ingeniører.

En praktisk referencearkitektur bruger en central identitetsudbyder, en delt boks, et lag med privilegeret adgangsstyring og struktureret nøglestyring, der alle forstærker hinanden. Personalet autentificerer én gang, modtager det rette adgangsniveau og håndterer sjældent rå hemmeligheder direkte. Dette reducerer angrebsfladen og gør det lettere at bevise over for kunder og revisorer, at du administrerer godkendelsesoplysninger konsekvent.

Et typisk mønster for en MSP ser sådan ud:

Identitetsudbyder i centrum: Alle medarbejdere autentificerer via en central identitetsplatform, der håndhæver stærk multifaktor-godkendelse og betinget adgang.
Hemmelighedsboks til menneskebrugte legitimationsoplysninger: administratorer undgår browsere eller noter og bruger en central hvælving til at hente privilegerede adgangskoder, når det er nødvendigt.
PAM-arbejdsgange for højrisikooperationer: Teknikere anmoder om godkendt, tidsbestemt forhøjelse i stedet for at bruge delte administratorlogin til lejeradministration.
Nøglehåndtering for kryptografisk materiale: Krypteringsnøgler og certifikater administreres i et dedikeret system, der håndhæver rotation og registrerer brugen.

I dette design integreres hvælvingen, PAM'en og nøglehåndteringssystemet med din identitetsudbyder, så adgangen til dem styres centralt. Medarbejderidentiteter knyttes til roller, og disse roller bestemmer, hvilke hemmeligheder de kan bruge, og under hvilke omstændigheder. Dette understøtter direkte A.5.17's vægtning af kontrolleret allokering, sikker brug, overvågning og tilbagekaldelse af godkendelsesoplysninger.

Design til lejeradskillelse, robusthed og reelle arbejdsgange

Et MSP-specifikt design skal også tage højde for lejeradskillelse og robusthed, så du kan holde tjenesterne kørende sikkert. Du skal kunne besvare spørgsmål som:

Hvordan sikrer man, at en ingeniør med adgang til mange lejere ikke nemt kan krydse grænser, når vedkommende bruger privilegerede værktøjer?
Vil I bruge en enkelt central boks til alle kunder, eller separate logiske eller fysiske bokse til forskellige segmenter eller højrisikoklienter?
Hvad sker der, hvis hvælvingen, identitetsudbyderen eller PAM-tjenesten ikke er tilgængelig under en hændelse eller et større strømafbrydelse?

Svarene afhænger af din størrelse og risikoappetit, men de bør være eksplicitte snarere end antagne. Mange MSP'er anvender mønstre som roller pr. lejer i RMM- og cloudplatforme, logføring pr. lejer hvor det er muligt og klar adskillelse af opgaver mellem de ingeniører, der designer adgang, og dem, der godkender eller gennemgår den.

Daglige realiteter kræver også opmærksomhed. Fjernsupportsessioner, scripting, fejlfinding uden for åbningstid og projektarbejde skaber pres for genveje, hvis din arkitektur er for rigid. Ved at inddrage operationelle ledere tidligt i den arkitektoniske samtale hjælper du med at designe mønstre, der både er sikre og brugbare for dine teknikere.

En platform som ISMS.online kan hjælpe dig med at dokumentere og spore denne arkitektur sammen med de politikker, risici og kontroller, der understøtter den, så du kan udvikle designet uden at miste synet på, hvorfor det ser ud, som det gør, eller hvordan det understøtter A.5.17.

Hvordan kører man livscyklusoperationer for MSP-hemmeligheder i praksis?

Livscyklusoperationer omdanner din strategi og arkitektur til daglig adfærd ved at definere, hvordan hemmeligheder anmodes om, oprettes, bruges, roteres og tilbagekaldes. A.5.17 forventer, at hemmeligheder ikke kun oprettes sikkert, men også ændres, trækkes tilbage og gennemgås på en disciplineret måde. For MSP'er skal denne livscyklus dække personalebevægelser, onboarding og offboarding af kunder, værktøjsændringer og hændelsesrespons på tværs af mange lejere. Vejledning til A.5.17 i ISO/IEC 27002:2022 forstærker dette ved at beskrive livscyklusaktiviteter såsom registrering, administration, tilbagekaldelse og udskiftning af autentificeringsværktøjer.

Definition af standardarbejdsgange for oprettelse, rotation og tilbagekaldelse

En robust livscyklusmodel dækker hele processen for hver legitimationsoplysninger eller nøgle, fra anmodning til tilbagetrækning. Den omdanner ad hoc-reaktioner til en gentagelig rækkefølge af trin, så forskellige legitimationsoplysninger følger ensartede stier med passende godkendelser, kontroller og beviser i hvert trin. Denne konsistens er det, der gør livscyklusstyring synlig og kontrollerbar.

Du kan udtrykke livscyklussen som fem enkle trin.

Trin 1 – Skab med formål og godkendelse

Oprettelse anmodes gennem en defineret proces, begrundes med en forretningsmæssig årsag og godkendes, hvor risikoen er høj. Hemmeligheder genereres ved hjælp af sikre standardindstillinger såsom stærk tilfældighed og unikke værdier, ikke genbrugte mønstre.

Trin 2 – Opbevar og distribuer sikkert

Nye hemmeligheder går direkte ind i den relevante boks eller system og leveres til personale eller systemer via krypterede kanaler. De kopieres aldrig til ukontrollerede steder såsom e-mail, chat eller personlige noter, selv ikke midlertidigt.

Trin 3 – Brug med færrest rettigheder og logføring

Brugen medieres af værktøjer, der håndhæver færrest privilegier, anvender multifaktortjek, hvor det er relevant, og logger, hvem der brugte hvilke legitimationsoplysninger, til hvilket formål og hvornår. Personalet bruger navngivne konti i stedet for delte logins, hvor det er muligt.

Trin 4 – Gennemgå og roter regelmæssigt

Hemmeligheder gennemgås efter en defineret tidsplan for at bekræfte behov, justere privilegier og rotere værdier. Yderligere rotation udløses af hændelser såsom rolleændringer, mistanke om kompromittering, leverandørrådgivning eller væsentlige arkitekturopdateringer.

Trin 5 – Tilbagekald og destruer rent

Når en hemmelighed ikke længere er nødvendig, tilbagekaldes den straks og fjernes fra arkiver, systemer og dokumentation. Cachelagrede kopier ryddes, så legitimationsoplysningerne ikke ved et uheld kan genbruges i scripts, noter eller gamle playbooks.

Nogle af disse trin kan automatiseres; andre er afhængige af menneskelig disciplin. Det vigtige punkt for A.5.17 er, at hver kategori af legitimationsoplysninger har en klar livscyklussti, og at du kan vise revisorer og kunder, hvor du følger den, og hvordan du håndterer undtagelser.

Håndtering af undtagelser, adgang i nødstilfælde og menneskelige faktorer

Ingen livscyklus er fuldendt uden klare regler for undtagelser og nødsituationer. Der vil være systemer, der ikke kan understøtte moderne godkendelse, og der vil være tidspunkter, hvor normale adgangsstier fejler, og du har brug for glasbrudsmuligheder. A.5.17 forbyder ikke dette; det forventes, at du kontrollerer det synligt og gennemtænkt.

For undtagelser kan du tildele en risikoejer, dokumentere, hvorfor undtagelsen findes, definere kompenserende kontroller såsom ekstra overvågning eller strengere fysisk sikkerhed og give den en udløbsdato for revurdering. Det forvandler det, der kunne være en permanent svaghed, til en styret, tidsbegrænset risiko, som du kan diskutere åbent med kunder og revisorer.

Ved nødadgang kan du definere, hvordan særlige konti oprettes, hvor legitimationsoplysningerne gemmes, hvem der kan bruge dem, hvordan brugen logges, og hvordan legitimationsoplysningerne roteres eller tilbagekaldes efter brug. På den måde bevarer du både tilgængelighed under kriser og ansvarlighed bagefter.

Du skal også planlægge for de menneskelige realiteter: personale, der uventet forlader virksomheden, entreprenører, der fuldfører opgaver, fusioner og opkøb, der ændrer, hvem der ejer hvilke systemer eller lejere. Integration af processer for tiltrædelse, flyttelse og afgang på tværs af HR, kunderelationssystemer og identitetsplatforme reducerer dramatisk risikoen for, at privilegerede konti efterlades forældreløse. Når disse livscyklusprocesser registreres som arbejdsgange i dit ISMS med klare ejere og beviser, bliver det meget lettere at vise revisorer og kunder, at A.5.17 ikke bare er en politik på papiret.

ISMS.online understøtter over 100 standarder og regler, hvilket giver dig en enkelt platform til alle dine overholdelsesbehov.

Book din demo

Hvordan styrer, dokumenterer og forbliver I revisionsklare til A.5.17?

Governance er der, hvor kontrolsprog, arkitektur, arbejdsgange og daglige adfærdsmønstre samles i en etage, som udenforstående kan forstå. Når revisorer eller virksomhedskunder vurderer dig, ønsker de ikke blot at se, at du ejer gode værktøjer, men også at du styrer autentificeringsoplysninger på en sammenhængende måde og kan bevise det. Governance hjælper dig med at vise, at dine kontroller er reelle snarere end ambitiøse.

Governance gør den måde, du allerede arbejder på, synlig, bevidst og nemmere at forbedre.

Opbygning af en evidensplatform, der giver mening for udenforstående

A.5.17-relateret bevismateriale falder normalt i flere kategorier, der tilsammen beskriver, hvordan du administrerer godkendelsesoplysninger på tværs af din MSP. At tænke i disse kategorier hjælper dig med at indsamle bevismateriale, der er meningsfuldt for revisorer og kunder, i stedet for en bunke af uforbundne artefakter. Vejledning til implementering af bedste praksis for A.5.17 og bredere ISMS-drift organiserer ofte bevismateriale på denne måde, så politikker, konfigurationer, logfiler og træningsregistre i fællesskab illustrerer, hvordan godkendelsesoplysninger styres i praksis.

Typiske bevissæt omfatter:

Politikker og standarder: der definerer, hvordan godkendelsesoplysninger anmodes om, godkendes, oprettes, gemmes, bruges, roteres og tilbagekaldes.
Procedurer og runbooks: der forklarer, hvordan du håndterer scenarier som onboarding, oprettelse af lejeradministratorer eller mistanke om kompromittering af legitimationsoplysninger.
Konfigurationsposter: fra hvælvinger, systemer til privilegeret adgang, identitetsplatforme og nøglehåndteringsværktøjer, der viser, hvordan design matcher politik.
Logfiler og rapporter: der demonstrerer, hvordan hemmeligheder rent faktisk bruges, herunder privilegerede sessionsposter, adgangsgennemgange og rotationshændelser.
Trænings- og bevidsthedsoptegnelser: der beviser, at personalet er blevet briefet og har anerkendt nøgleansvaret for håndtering af autentificeringsoplysninger.

De stærkeste beviser binder disse elementer sammen til konkrete eksempler, der er relevante. For eksempel kan du vise en standard til håndtering af API-nøgler, der er knyttet til en risikoregisterpost på tredjepartsintegrationer, en runbook til regenerering af nøgler og de tilhørende logfiler, der viser de seneste rotationer. Den form for sporbarhed forsikrer revisorer og kunder om, at din praksis er bevidst og overvåget, ikke improviseret.

Du kan tænke på dette som at fortælle en klar historie: "Her er vores regel, sådan implementerer vi den, sådan tjekker vi den, og her er bevis på, at det virkelig sker." Når denne historie er ensartet på tværs af lejere og værktøjer, føles din ledelsesholdning troværdig snarere end kosmetisk.

Integrering af A.5.17 i din styringsrytme

Styring fungerer bedst, når det er en del af din regelmæssige rytme, ikke et kæmpe stridspunkt før en ekstern revision. Du kan integrere A.5.17 i denne rytme ved at:

Planlægning af periodiske gennemgange af højrisikooplysninger og nøgler, hvor ejere bekræfter nødvendighed, justerer privilegier og verificerer, at lagring og rotation opfylder kravene.
Gennemgang af logfiler og advarsler relateret til privilegeret adgang og hemmelig brug, og behandling af anomalier som udløsere for både hændelsesrespons og procesforfining.
Integrering af erfaringer fra hændelser, nærved-ulykker og penetrationstests i opdaterede politikker, standarder og arkitekturer.
Inkludering af A.5.17-status i ledelsesevalueringer og opdateringer til risikoudvalg, i overensstemmelse med ISO 27001's forventning om, at topledelsen regelmæssigt overvejer status for kontroller og resterende risici på tværs af jeres ISMS.

Omkring to tredjedele af respondenterne i ISMS.online-undersøgelsen fra 2025 siger, at hastigheden og omfanget af lovgivningsmæssige ændringer gør det sværere at opretholde overholdelse af regler.

Hvis du stadig forbereder dokumentation i delte mapper og e-mails et par uger før hver revision, ved du, hvor stressende det kan være. En ISMS-platform som ISMS.online kan gøre dette lettere ved at fungere som det eneste sted, hvor du definerer A.5.17-kontroller, forbinder dem med risici, tildeler ejere, indsamler dokumentation og planlægger gennemgange. I stedet for at stole på ad hoc-dokumenter og regneark får du et levende system, der afspejler, hvordan godkendelsesoplysninger faktisk håndteres, og hvor der stadig er behov for forbedringer.

Når governance er synlig på denne måde, fører A.5.17 til bedre beslutninger. Du behøver ikke længere at gætte på, hvilke hemmeligheder der betyder mest, eller håbe på, at gode vaner holder; du bruger beviser til at styre din MSP mod færre overraskelser og mere robuste kunderelationer.

Book en demo med ISMS.online i dag

ISMS.online hjælper dig med at bringe A.5.17 til live ved at forbinde dine politikker, risici, arkitekturer og bevismateriale i ét struktureret system, så du kan vise revisorer og kunder, at du behandler godkendelsesoplysninger som et kritisk aktiv. For MSP-ledere og sikkerhedsteams betyder det, at dine legitimationsoplysninger og hemmeligheder bliver en kilde til tillid snarere end angst, selvom din kundebase vokser.

Se din A.5.17-etage fra ende til anden

Når du udforsker ISMS.online, kan du se, hvordan det hjælper dig med at forvandle en teknisk kontrol til en klar, auditerbar fortælling. I stedet for at jagte skærmbilleder og regneark før hver audit, arbejder du i et miljø, der forbinder risici, kontroller, handlinger og beviser undervejs. Dette skift gør det nemmere at orientere interessenter og bevise over for krævende kunder, at du driver en disciplineret drift.

I ISMS.online-undersøgelsen fra 2025 angav næsten alle organisationer opnåelse eller opretholdelse af sikkerhedscertificeringer som ISO 27001 eller SOC 2 som en topprioritet.

Du kan bruge ISMS.online til at:

Fastlæg A.5.17-politikker og -standarder i et klart sprog, som ikke-specialister kan forstå og følge.
Kortlæg hemmeligheder og risici for privilegeret adgang på tværs af interne systemer og kundemiljøer i én visning.
Forbind specifikke kontrolaktiviteter – såsom rotation af legitimationsoplysninger eller adgangsgennemgange – med risikoregisterposter og revisionskrav.
Gem og referer til dokumentation såsom konfigurationsskærmbilleder, eksportfiler og mødenotater uden at skulle lede i e-mails og fildelinger.

Denne form for end-to-end-visning forvandler kontrol A.5.17 fra en linje i en standard til en fortælling, du kan stå inde for, når kunder eller revisorer stiller vanskelige spørgsmål. Det giver dig et enkelt, sammenhængende sted at spore, hvordan din MSP allokerer, bruger og tilbagekalder godkendelsesoplysninger på tværs af mange lejere og værktøjer.

Planlæg dine næste halvfems dage med selvtillid

En kort, fokuseret implementeringsplan er ofte mere værdifuld end en fjern, storslået vision. Sammen med dit team og en ISMS.online-specialist kan I forme de næste tre måneder omkring et par konkrete træk, der styrker A.5.17 på praktiske måder uden at overvælde personalet eller forstyrre kundeservicen. I praksis oplever mange travle MSP-teams, at det er mere overkommeligt at arbejde efter en fokuseret 90-dages plan end at forsøge at tackle alt på én gang.

Trin 1 – Opbyg en realistisk opgørelse over legitimationsoplysninger

Identificér dine højrisikooplysninger, servicekonti, API-nøgler og nøglelagre, og registrer, hvor de befinder sig, hvilke systemer de beskytter, og hvem der ejer dem.

Trin 2 – Etabler grundlæggende politikker og standarder

Definer praktiske politikker og standarder for godkendelsesoplysninger, der afspejler din MSP's størrelse, værktøjssæt og eksisterende processer, og tildel klare ejere til hvert dokument.

Trin 3 – Opret essentielle livscyklusarbejdsgange

Implementer et minimalt sæt af arbejdsgange til oprettelse, rotation, gennemgang og tilbagekaldelse af privilegerede konti og nøgler, herunder klare udløsere og ansvarsområder for hvert trin.

Trin 4 – Saml en startpakke med bevismateriale

Indsaml indledende beviser, der viser meningsfulde fremskridt i forhold til A.5.17, så du med tillid kan orientere interessenter, forsikringsselskaber og revisorer og planlægge yderligere forbedringer.

Derfra kan du iterere og tilføje sofistikering, efterhånden som dine medarbejdere, processer og arkitekturer modnes, uden at miste de grundlæggende elementer af syne, du allerede har på plads. Små, konsekvente trin skaber en meget stærkere holdning end lejlighedsvise store fremskridt før revisioner, og en 90-dages plan føles som en realistisk horisont for de fleste MSP-teams.

Hvis du ønsker, at dine legitimationsoplysninger og hemmeligheder skal understøtte din vækst i stedet for at underminere den i stilhed, er det et praktisk næste skridt at vælge ISMS.online som hjemmet for dit ISMS. Det giver dig et rammeværk, indhold og arbejdsgange formet af ægte ISO 27001-erfaring, så du ikke starter fra en blank side eller forsøger at lime spredte dokumenter sammen. Det gør det langt nemmere at levere en A.5.17-implementering, der beskytter dine kunder, understøtter dine teknikere og styrker din forretning.

Book en demo

Ofte stillede spørgsmål

Hvordan ændrer ISO 27001:2022 A.5.17 egentlig godkendelsen for en MSP?

ISO 27001:2022 A.5.17 omdanner effektivt alle adgangskoder, tokens og nøgler, som din MSP berører, til et styret aktiv med klare regler, ejerskab og beviser, ikke kun "ting, som folk husker eller gemmer et sted". Du forventes at definere, hvordan godkendelsesoplysninger oprettes, beskyttes, bruges, roteres og tilbagekaldes, og at du beviser dette konsekvent på tværs af din egen stak og hver kundelejer, du administrerer.

Hvor rækker A.5.17 egentlig ud i et MSP-miljø?

For en typisk MSP rækker A.5.17 langt ud over medarbejderlogin eller en enkelt adgangskodeadministrator. Det omformer, hvordan du håndterer godkendelse i:

RMM- og PSA-platforme: der kan nå hundredvis af slutpunkter og kundelejere.
Dokumentations- og videnssystemer: hvor "vejledningstrin" og adgangskoder ofte blandes sammen.
Backup-, overvågnings- og DR-konsoller: der stille og roligt har bred, vedvarende adgang.
Cloud-lejere og identitetsudbydere: hvor få roller kan ændre alt.
Leverandørportaler og licenssystemer: bruges til at administrere berettigelser på tværs af kunder.

I stedet for at stole på stammeviden eller spredte noter, forventes det, at du:

Bevar et pålideligt overblik over hvem kan nå hvad på tværs af interne og kundesystemer.
Anvend enkle, gentagelige regler for udstedelse, beskyttelse, rotation og tilbagekaldelse hver type legitimationsoplysninger.
Sørg for ændringer i tiltrædelses-, tilflytter- og afgangsforhold faktisk fjerne adgang og udløse rotationer hvor det er nødvendigt.
Hav tilstrækkelig struktureret dokumentation til, at du roligt kan forklare din tilgang til revisorer og virksomhedskøbere.

Når du registrerer disse regler, ansvarsområder og arbejdsgange i et struktureret informationssikkerhedsstyringssystem (ISMS) som ISMS.online, går du fra "vi tror, det er under kontrol" til at kunne vise præcis, hvordan godkendelsesoplysninger styres i en MSP-verden med mange brugere og mange værktøjer.

Det virkelige skift er ikke strengere adgangskoder; det er at behandle enhver hemmelighed som et aktiv med en livscyklus, du kan forklare og bevise.

Hvordan kan en MSP reducere virkningen, når en stærk legitimationsoplysninger uundgåeligt bliver stjålet?

Du reducerer påvirkningen ved at antage, at mindst én værdifuld legitimationsoplysninger vil blive kompromitteret, og designe dit miljø, så det låser op så lidt som muligt, i den kortest realistiske tid, med tydelige spor, når det bruges. A.5.17 opfordrer dig til at konstruere til en mindre, mere synlig "eksplosionsradius" i stedet for at satse alt på aldrig at miste en nøgle.

Hvordan ser en mindre sprængningsradius ud i den daglige MSP-praksis?

I de fleste MSP'er ser et praktisk mønstersæt sådan ud:

Kun navngivne administratoridentiteter: Træk delte "globale administrator"-konti tilbage, og knyt forhøjede roller til individuelle brugere i din identitetsudbyder med stærk multifaktorgodkendelse.
Rollebaseret adgang på tværs af kerneværktøjer: Juster RMM, PSA, cloudplatforme og dokumentationssystemer til "færrest rettigheder for rolle, kundegruppe og geografi", ikke "alle kan gøre alt overalt".
Just-in-time højde: give kun fulde administratorrettigheder til en bestemt opgave og et bestemt tidsvindue, og derefter automatisk gå tilbage til lavere rettigheder.
Kontrollerede administratorindgangspunkter: tvinge privilegeret arbejde gennem hærdede stier (f.eks. administration af privilegeret adgang, bastionværter eller tæt kontrollerede jump boxes) i stedet for nogen bærbar computer på noget netværk.
Centraliseret logføring og alarmering: Send privilegerede aktivitetslogfiler til et fælles sted, så usædvanlige handlinger skiller sig ud og kan knyttes til rigtige personer, tickets og tidsrammer.

Udformet på denne måde forbliver en stjålet teknikeradgangskode alvorlig, men den ophører med at være en skeletnøgle for "hver kunde på én gang". Når du registrerer disse designvalg i dit ISMS og linker dem til A.5.17, kan du vise revisorer, forsikringsselskaber og krævende kunder, at du bevidst har konstrueret en nedskæring i eksplosionsradiusen i stedet for at håbe på, at der aldrig sker kompromis.

Hvad hører hjemme i en håndbog med håndbøger om håndbøger med forstærkede legitimationsoplysninger og hemmeligheder for en MSP?

En håndbog forklarer, hvordan du grupperer legitimationsoplysninger i niveauer, de minimumssikkerhedsforanstaltninger, hvert niveau skal have, og hvordan du kører og forbedrer disse sikkerhedsforanstaltninger over tid. Den erstatter "alle ved, at man skal være forsigtig" med "vi følger denne model hver dag, og disse optegnelser viser det".

Hvilke elementer er mest vigtige for en MSP med flere lejere?

For de fleste udbydere af administrerede tjenester omfatter en nyttig håndbog:

Ryd legitimationsniveauer: for eksempel glasbrudskonti, platformsomfattende administration i RMM og cloud, administration på lejerniveau, teknikerkonti, servicekonti og automatiseringshemmeligheder.
Grundlæggende sikkerhedsforanstaltninger pr. niveau: Forventninger til multifaktor-godkendelse, hvor hemmeligheder gemmes (hvælving vs. platform), maksimal levetid, rotationskadence, logføringsdybde og gennemgangsfrekvens.
Standard værktøjskombinationer: hvordan du bruger din identitetsudbyder, adgangskode- eller hemmelighedsboks, fjernadgangsstak og logføringsværktøjer sammen, så reglerne håndhæves uden at ingeniørerne forsinkes.
Håndtering af undtagelser og ældre versioner: hvordan du dokumenterer og inddæmmer ældre platforme, nicheleverandører eller nedarvede miljøer, der endnu ikke kan leve op til din ideelle standard.
En simpel forandringsplan: hvilke sikkerhedsforanstaltninger I vil stramme op i dette kvartal, i år og før større kontraktfornyelser eller platformændringer.

Når du modellerer denne playbook i ISMS.online som politikker, standarder, tilknyttede aktiver, risici og kontroller, holder den op med at være en del af en enkelt ledende ingeniørs notesbog. Den bliver noget, du kan lære nye medarbejdere, gennemgå med ledelsen og præsentere for revisorer eller virksomhedsrisikoteams som din klare, stabile tilgang til legitimationsoplysninger og hemmeligheder.

Hvordan bør en MSP håndtere servicekonti, API-nøgler og automatiseringshemmeligheder forskelligt?

Servicekonti og automatiseringsnøgler skal behandles som stærke identiteter med ejere, omfang og udløbsdato, ikke stille konfigurationsdetaljer, der forbliver uberørte, indtil noget går i stykker. De har ofte bred, langvarig adgang og ingen navngiven menneskelig identitet, hvilket gør dem attraktive for angribere og lette at overse, hvis du ikke administrerer dem med vilje.

Hvad indebærer god forvaltning af ikke-menneskelige identiteter for en MSP?

Effektiv ledelse hviler normalt på et par vaner:

Vedligeholdelse af en live lagerbeholdning: af servicekonti, API-nøgler og automatiseringshemmeligheder på tværs af RMM, backup, overvågning, cloudplatforme, leverandørportaler og interne værktøjer.
Tildeling af en ansvarlig ejer og formål: til hver ikke-menneskelig identitet, med dokumenterede minimumsprivilegier og en klar registrering af, hvor den bruges.
Centralisering af hemmelig opbevaring: i en kontrolleret hvælving eller platform, i stedet for at sprede værdier på tværs af scripts, tickets, delte mapper, wikier eller lokale konfigurationsfiler.
Definition og håndhævelse af rotationsudløsere: planlagte rotationer plus ændringer efter afgang af personale, leverandørhændelser, platformbrud eller større konfigurationsændringer.
Inkludering af ikke-menneskelige identiteter i anmeldelser og hændelser: Rutinemæssige adgangsgennemgange, hændelsesprioritering og analyse efter hændelser bør altid spørge "hvilke automatiseringer og integrationer kan blive påvirket eller misbrugt her?"

Når du administrerer ikke-menneskelige identiteter via dit ISMS med ensartede politikker, risici, kontroller og beviser, kan du vise, at A.5.17 dækker det stille automatiseringslag i din stak lige så grundigt som menneskelige administratorer. Det beroliger større kunder, der bekymrer sig mest om integrationer og scripts, der kan give bred, uset adgang, hvis de håndteres forkert.

Hvordan kan en MSP vise, at A.5.17 fungerer i virkeligheden, ikke kun på papiret?

Du viser, at A.5.17 er reel, ved at forbinde det, du siger i politikker, hvordan du har designet dit miljø, og hvad der rent faktisk sker i det daglige. Revisorer og virksomhedskunder leder efter en historie, de kan følge: "dette er vores politik, det er de kontroller og værktøjer, vi bruger, det er sådan, vi tester dem, og disse eksempler viser den seneste aktivitet".

Hvilke typer beviser overbeviser normalt revisorer og virksomhedskøbere?

Beviser, der typisk taler godt for A.5.17, inkluderer:

Politikker og detaljerede standarder: der beskriver, hvordan du udsteder, beskytter, roterer og tilbagekalder legitimationsoplysninger og hemmeligheder på tværs af interne og kundesystemer, som sprogingeniører kan følge.
Konfigurationseksport eller skærmbilleder: fra identitetsudbydere, vaults, værktøjer til privilegeret adgang og nøglehåndteringstjenester, der demonstrerer, at disse standarder håndhæves i virkelige omgivelser.
Aktivitetslogfiler og rapporter: viser privilegerede handlinger, hemmelige rotationer, adgangsgennemgange og hændelseshåndtering over tid, ikke kun for en enkelt uge.
Trænings- og anerkendelsesrapporter: for personale, der håndterer godkendelsesoplysninger med stor indflydelse, især dem med adgang til flere lejere.
Resultater fra interne revisioner og ledelsesevalueringer: hvor du har udfordret din egen tilgang, indsamlet resultater og registreret specifikke forbedringer.

Hvis du forbinder alt dette inde i ISMS.online som kontroller med kortlagte risici, ejere, handlinger og vedhæftet dokumentation, undgår du sidste-øjebliks-jagt på gamle sager og skærmbilleder. I stedet opretholder du en stabil "A.5.17-etage", som du kan præsentere bestyrelser, forsikringsselskaber og kunderisikoteams for, når de spørger, hvordan du administrerer adgang til dine egne og dine kunders ejendomme.

Når du kan vise ændringer, ikke kun politikker, holder folk op med at bekymre sig om, at din sikkerhed findes i slides i stedet for i systemer.

Hvordan kan ISMS.online hjælpe en MSP med at implementere A.5.17 uden at overbelaste ingeniører?

ISMS.online hjælper dig med at designe, drifte og dokumentere din A.5.17-tilgang i ét struktureret miljø i stedet for at sprede politikker på tværs af mapper og beviser på tværs af e-mailtråde og chathistorik. Det giver dig mulighed for først at fokusere på de mest effektive legitimationsoplysninger og hemmeligheder, hurtigt demonstrere fremskridt og derefter udvide dækningen i et tempo, dit team realistisk kan understøtte.

Hvad er fornuftige, friktionsfrie skridt i de næste halvfems dage?

Mange MSP'er gør synlige fremskridt på kort tid ved at:

Opbygning af en fokuseret lagerbeholdning: af deres mest kraftfulde administratorkonti, servicekonti og API-nøgler på tværs af kerneplatforme såsom RMM, PSA, cloudidentitet, backup og fjernadgang.
Aftale om ærlige grundlæggende politikker og standarder: for godkendelsesoplysninger, der afspejler, hvordan de fungerer i dag, og derefter gemmer dem i ISMS.online med navngivne ejere, gennemgangsdatoer og tilknyttede kontroller.
Indfangning af en håndfuld kernearbejdsgange: -for eksempel klargøring af administratorkonti, ændringer af rettigheder, tilbagekaldelse og brug af glasbrud - inde i ISMS.online og kobling af dem til tilhørende risici og beviser.
Samling af en startpakke med bevismateriale: der viser reel bevægelse i forhold til A.5.17, herunder mindst én adgangsgennemgang, én rotationsbegivenhed og én intern kontrol, klar til at orientere ledelsen og besvare vanskeligere kundespørgsmål.

Derfra kan du udvide dækningen på tværs af flere lejere og værktøjer, forfine din arkitektur i takt med at modenheden vokser, og integrere regelmæssige evalueringer uden at gøre hver forbedring til et større projekt. Hvis du ønsker legitimationsoplysninger og hemmeligheder, der understøtter vækst i stedet for lydløst at udvide din eksponering, er det en god måde at starte på at bruge et ISMS som ISMS.online til at gøre din første 90-dages plan synlig, anerkendt og opnåelig.