Hvordan ISO 27001 A.5.36 beviser, at MSP'er følger sikkerhedsregler med reelle beviser

Hvorfor A.5.36 er vigtig for MSP'er, der leverer administrerede sikkerhedstjenester

A.5.36 er vigtig for udbydere af administrerede tjenester, fordi den tester, om dine sikkerhedsregler rent faktisk følges i live-drift, ikke bare nedskrives, og kræver bevis for, at dine medarbejdere og systemer følger disse regler i det daglige arbejde. Den lader dig ikke længere gemme dig bag et politikbibliotek; den forventer, at du beviser, at politikker, standarder og regler forstås, anvendes og korrigeres, når de ikke gør det, både på tværs af dit interne miljø og de tjenester, du kører for kunder, på tværs af mange værktøjer, teams og tidszoner.

Oplysningerne her er generelle og udgør ikke juridisk, lovgivningsmæssig eller certificeringsmæssig rådgivning. For beslutninger vedrørende din organisation bør du konsultere passende kvalificerede fagfolk og dit valgte certificeringsorgan.

På et overordnet niveau kræver ISO/IEC 27001:2022 kontrol A.5.36, at du gør tre ting:

Definer de informationssikkerhedspolitikker, regler og standarder, der gælder i din organisation.
Gennemgå regelmæssigt, om medarbejdere og aktiviteter overholder dem.
Reager, når de ikke gør det, og behold beviser for, at alt dette sker.

For de fleste organisationer er det udfordrende. For en MSP, der leverer administrerede sikkerhedstjenester, er det meget sværere. Du er ikke kun ansvarlig for dine egne medarbejdere og systemer; du opererer også i kundemiljøer, på kundedata, i henhold til kundepolitikker og sektorregler. Dine "regler og standarder" omfatter hurtigt:

Din egen informationssikkerhedspolitik og emnespecifikke standarder.
Kundens sikkerhedsplaner, klausuler om acceptabel brug og krav til datahåndtering.
Eksterne standarder, du forpligter dig til, såsom konfigurationsgrundlinjer eller branchekodekser.

Et flertal af respondenterne i ISMS.online-undersøgelsen om informationssikkerhedens tilstand i 2025 sagde, at de havde været påvirket af mindst én sikkerhedshændelse hos en tredjepart eller en leverandør i det seneste år.

Hvis du leverer tjenester som f.eks. et sikkerhedsoperationscenter (SOC), administreret detektion og respons, sårbarhedsstyring eller endpoint-styring, ser kunderne i stigende grad A.5.36 som deres krog til at spørge: "Hvordan ved vi, at I følger jeres egne regler og vores – og hvad sker der, hvis I ikke gør?"

Det er en af grundene til, at bestyrelser og investorer nu stiller strengere spørgsmål om MSP-styring. Brancheundersøgelser om ISO 27001 og bredere cyberrisiko bemærker også øget kontrol på bestyrelsesniveau med sikkerhed og styring, især omkring tredjepartsudbydere og outsourcingvirksomheder, hvilket afspejler et bredere skift i forventningerne til, hvordan risiko overvåges. En enkelt forkert afstemt regel i din SOC- eller fjernovervågnings- og styringsplatform (RMM) kan skade flere kunder på én gang, så de ønsker sikkerhed for, at dine dokumenterede kontroller stemmer overens med den operationelle virkelighed. Uafhængig analyse af cyberrobusthed og den menneskelige faktor fremhæver ligeledes, hvordan svagheder i delte platforme eller processer kan forstærke virkningen af individuelle fejl på tværs af mange organisationer, især hvor menneskelig adfærd og procesdisciplin er kritisk.

En platform som ISMS.online kan hjælpe ved at give dig ét sted at definere dine politikker og standarder, knytte dem til tjenester, tildele ansvarsområder og forbinde dem med reel dokumentation fra revisioner, evalueringer og operationelle værktøjer. Det fjerner ikke behovet for at udføre arbejdet, men det gør forholdet mellem "hvad vi siger" og "hvad vi kan bevise" synligt og håndterbart.

Compliance vinder tillid, når dine beviser viser, hvad der virkelig sker, ikke hvad du håber sker.

Hvad A.5.36 rent faktisk kræver i almindeligt sprog

A.5.36 kræver, at du holder sikkerhedsreglerne klare, kontrollerer, at folk følger dem, og løser problemer, når de ikke gør, og at du er i stand til at vise revisorer og kunder, at denne løkke fungerer i praksis gennem håndgribelige beviser, ikke blot intentioner. I praksis betyder det at vise, at overholdelse af din informationssikkerhedspolitik og emnespecifikke politikker, regler og standarder regelmæssigt gennemgås, og at manglende overholdelse håndteres passende som en del af en levende kontrolløkke, der forbinder regler, adfærd, kontroller og forbedringer.

For en MSP ser løkken typisk sådan ud:

Definere: Du opretholder et klart og aktuelt sæt regler, der gælder for personale, leverandører og, hvor det er relevant, kundemiljøer.
Kommunikere: Folk kender reglerne og anerkender dem gennem træning, briefinger og onboarding.
Monitor: Du bruger teknisk overvågning, proceskontroller og interne revisioner til at se, om disse regler bliver overholdt.
Svare: Når du konstaterer manglende overholdelse, registrerer du det, vurderer virkningen og træffer korrigerende eller disciplinære foranstaltninger, hvor det er relevant.
Forbedre: Du gennemgår mønstre for manglende overholdelse og justerer politikker, træning eller kontroller.

Revisorer forventer ikke perfektion. De forventer en kontrolleret, dokumenteret cyklus. Virksomhedskunder forventer det samme, især hvor din service er en del af deres kritiske infrastruktur eller lovgivningsmæssige omfang. A.5.36 er direkte knyttet til ISO 27001's Plan-Do-Check-Act-cyklus: Du planlægger reglerne, udfører kontroller, kontrollerer overholdelse og handler på det, du lærer.

Hvorfor kontrollen bider hårdere for MSP'er

A.5.36 er hårdere for MSP'er, fordi små svagheder i håndhævelsen af regler kan påvirke mange tjenester og kunder. Hvis den interne styring er løs, kan en enkelt svag standard eller undtagelse stille og roligt underminere flere administrerede sikkerhedstilbud på én gang.

For mange udbydere afslører A.5.36 en skjult uoverensstemmelse: salg og kontrakter lover ét niveau af kontrol, politikker beskriver et andet, og driften leverer noget helt andet. Fordi dine tjenester er multi-tenant og værktøjsdrevne, kan svagheder hurtigt sprede sig:

En slap administratorkontoregel i dit eget miljø kan svække alle de administrerede sikkerhedstjenester, du leverer.
En programrettelsesstandard, der anvendes inkonsistent på tværs af kunder, kan føre til gentagne resultater i kundeaudits.
En delt runbook, der ikke opdateres, når politikker ændres, kan stille og roligt miste overholdelsen af regler og standarder.

Omkring 41 % af organisationerne i ISMS.online-undersøgelsen fra 2025 nævnte håndtering af tredjepartsrisici og sporing af leverandørcompliance som en af deres største udfordringer inden for informationssikkerhed.

Kunder og tilsynsmyndigheder er i stigende grad opmærksomme på dette. De bruger spørgsmål, der er i overensstemmelse med A.5.36, til at undersøge, hvordan I styrer jeres personale og underleverandører, hvordan I overvåger overholdelse af regler i multi-tenant-værktøjer, og hvordan I håndterer undtagelser. Et overfladisk svar - vi har en politik, og vi uddanner personale - tilfredsstiller dem ikke længere.

Ved at behandle A.5.36 som en central MSP-styringskontrol i stedet for et snævert dokumentationskrav, får du mulighed for at afstemme løfter, politikker og praksis. Når du kan vise denne afstemning pålideligt, bliver det en differentiator i konkurrencedygtige bud, især for kunder, der ser deres MSP'er som en del af deres egen regulatoriske perimeter.

Book en demo

Problemet: Overholdelse af papirbaserede regler på tidspunktet for MSP'er

Papirbaseret compliance på bestemte tidspunkter sikrer, at du består audits, samtidig med at den reelle risiko, omkostninger og stress mellem vurderingsdatoer stille og roligt øges. Vejledning fra europæiske cybersikkerhedsorganer om ISO 27001 advarer om, at tjeklistedrevne eller rent revisionsfokuserede tilgange har tendens til at efterlade resterende operationel risiko og belastning, fordi de ikke afspejler, hvordan systemer og tjenester opfører sig mellem formelle vurderinger. Den koncentrerer indsatsen i korte perioder i stedet for at opbygge rutinemæssige kontroller, der sporer compliance hele året rundt.

Hvis du er ærlig omkring, hvordan du håndterer A.5.36 i øjeblikket, er der en god chance for, at det meste af indsatsen sker i korte, intense perioder omkring eksterne revisioner, kundevurderinger eller større udbud af tilbud, snarere end som en del af den daglige drift.

Et typisk mønster ser sådan ud: Flere gange om året dropper dine sikkerheds- og driftsledere alt for at samle dokumentationspakker. De jagter eksporterbare rapporter fra ticketing, RMM og SIEM-værktøjer (sikkerhedsinformation og eventstyring), henter træningslogfiler fra HR-systemer og opretter skræddersyede slideshows til bestemte kunder. Uden for disse spidsbelastninger sker der kun lidt systematisk kontrol ud over, hvad individuelle ingeniører og ledere husker at gøre.

Denne tilgang har flere omkostninger. Den bruger tid, som kunne have været brugt på at forbedre kontrollen. Den afhænger i høj grad af et par nøglepersoner. Den skjuler reelle svagheder bag øjebliksbilleder, der ser acceptable ud på dagen. Den udsætter dig også for risikoen, hvis en kunde eller tilsynsmyndighed beder om bekræftelse med kort varsel.

Compliance, der først vågner op under revisionen, overser normalt, hvordan dine tjenester rent faktisk fungerer.

Hvor overholdelsen på et givet tidspunkt ikke fungerer

Punkt-i-tidsbeviser vil fortsat være en del af eksterne revisioner og due diligence-øvelser, men at stole på dem som din primære sikkerhedsmodel efterlader forudsigelige huller, og for MSP'er dukker tre svagheder op igen og igen. Det mest åbenlyse er, at overholdelse af punkt-i-tidsbeviser tillader regelbrud at gå uopdaget hen i lange perioder: hændelser og afvigelser involverer ofte kendte regler, der ikke blev fulgt, fordi der, selvom reglerne eksisterede, ikke var regelmæssige, risikobaserede kontroller.

Afhængighed af heltegerninger i sidste øjeblik og fragmenteret bevismateriale er en anden svaghed. Compliance afhænger af en håndfuld ingeniører og ledere, der gør det rigtige ud over deres normale arbejdsbyrde, uden strukturerede prompts eller kontroller. De trækker artefakter fra spredte værktøjer ind i hastigt samlede pakker. Når disse mennesker forlader stedet, bliver syge eller overbelastede, forringes kontrollerne stille og roligt, og den historie, du fortæller kunderne, bliver sværere at rekonstruere.

Hvis du opererer i stærkt regulerede sektorer, eller betjener kunder, der gør, kan disse svagheder bidrage til tabte handler, mere alvorlige revisionsresultater eller udvidede afhjælpningsplaner, især når de falder sammen med andre mangler i kontroldesign eller tilsyn. Selv på mindre regulerede markeder øger de chancerne for, at en kunde vil sætte spørgsmålstegn ved din professionalisme, hvis du har svært ved at demonstrere, hvordan du håndhæver dine egne regler.

Det er ubehageligt at erkende disse smerter, men det baner vejen for en anden måde at tænke på A.5.36: ikke som en lejlighedsvis forhindring, men som en løbende disciplin, der beskytter kunder og dit eget omdømme.

Skjulte omkostninger i mennesker, værktøjer og kundetillid

Skjulte omkostninger ved overholdelse af regler på et givet tidspunkt viser sig i mennesker, værktøjer og relationer. Teams oplever overholdelsesarbejde som uforudsigeligt pres i sidste øjeblik, hvilket underminerer moralen og forstærker opfattelsen af, at regler er en overhead snarere end en del af god ingeniør- og servicepraksis. Over tid fører denne opfattelse til udbrændthed og udskiftning i nøgleroller.

For eksempel rapporterer mange mellemstore MSP'er, at de bruger betydelig tid – ofte ugers arbejde – før en større udbudsanmodning eller kundeaudit på manuelt at samle logfiler, skærmbilleder og træningsregistreringer. Arbejdet er stressende, outputtet er svært at genbruge, og teamet kommer ud med en lille fornemmelse af, at noget er blevet forbedret i den måde, tjenesterne rent faktisk kører på.

Der er også en omkostning til værktøjer. MSP'er investerer kraftigt i automatisering af professionelle tjenester (PSA), RMM, SIEM, identitet og loggingplatforme. Hvis den dokumentation, du leverer til A.5.36, primært findes i regneark og skærmbilleder, får du ikke den fulde værdi af disse værktøjer. Du betaler måske endda to gange: én gang for værktøjerne og igen for den manuelle indsats for at udtrække og kombinere relevante oplysninger.

ISMS.online-undersøgelsen fra 2025 viser, at kunderne i stigende grad forventer, at deres leverandører overholder formelle rammer som ISO 27001, ISO 27701, GDPR, Cyber Essentials, SOC 2 og nye AI-standarder.

Endelig bemærker kunderne det. Sikkerhedsspørgeskemaer spørger nu ofte ikke kun "Har I en politik?", men også "Hvordan overvåger I overholdelsen af den?" og "Hvilke målinger sporer I?". Dækning i specialiserede sikkerheds- og styringspublikationer viser det samme mønster, hvor flere indkøbs- og risikoteams spørger, hvordan kontroller håndhæves og måles, i stedet for at stoppe ved simple ja/nej-spørgsmål om politikker. Hvis dine svar er vage, eller du ikke kan give eksempler uden ugers forberedelse, vil risiko- og indkøbsteams drage deres egne konklusioner om jeres modenhed.

At bevæge sig væk fra punkt-i-tids-tankegang betyder at acceptere, at nogle regler vil blive ufuldstændigt fulgt, men at insistere på, at afvigelser er synlige, forklarlige og bruges til at drive forbedringer i stedet for at være skjult indtil den næste revision. Det er dette skift, som løbende sikring er designet til at understøtte.

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

Reframing: Fra statisk compliance til løbende sikring

Ved at omformulere A.5.36 til et designproblem, forvandles det fra en årlig afkrydsningsfelt til en håndterbar del af, hvordan man driver MSP-operationer. I stedet for at spørge, hvordan man overlever den næste revision, spørger man, hvordan man indbygger et rimeligt niveau af løbende sikkerhed i det daglige arbejde.

Løbende sikring betyder ikke at overvåge alle regler i realtid på tværs af alle systemer. Det betyder at vælge fornuftige kadenser og mekanismer, så vigtige regler kontrolleres ofte nok, kontroller integreres i normale arbejdsgange og værktøjer, og beviser indsamles som et biprodukt af arbejdet snarere end som en separat rapporteringsøvelse.

Et stort flertal af organisationerne i ISMS.online-undersøgelsen om informationssikkerhedstilstanden i 2025 sagde, at hastigheden og omfanget af lovgivningsmæssige ændringer gør det sværere at opretholde overholdelse af regler.

Denne tankegang stemmer godt overens med, hvordan ISO 27001 selv er struktureret. Standarden beder dig allerede om at planlægge, drive, overvåge og forbedre dit ledelsessystem. A.5.36 fokuserer i denne cyklus på, om du følger dine egne regler og standarder, og om du reagerer, når du ikke gør.

En lille sammenligning gør skiftet tydeligere. Overholdelse af regler på tidspunkter koncentrerer indsatsen om et par stressende perioder og efterlader lange perioder med ringe synlighed. Løbende sikring spreder indsatsen ud, reducerer overraskelser og gør det lettere at opdage problemer tidligt. Tabellen nedenfor opsummerer de vigtigste forskelle.

Dimension	Overholdelse af regler på tidspunktet	Løbende sikring
kadence	Toppe før revisioner og store spørgeskemaer	Regelmæssige, risikobaserede kontroller i løbet af året
Indsatsprofil	Manuelle, stressende udbrud	Mindre, forudsigelige aktiviteter i normale flow
Risikoeksponering	Huller mellem revisioner bliver let oversete	Afvigelser dukkede op og blev løst hurtigere
Beviskvalitet	Rekonstrueret fra spredte kilder	Genereret som en del af rutinearbejde og overvågning

Målet er ikke perfektion, men en simpel løkke, der fungerer det meste af tiden og kan forklares til revisorer, kunder og interne interessenter. Når du designer denne løkke omhyggeligt, reducerer du stress og får overholdelse af politikker til at føles som en del af at drive gode tjenester, ikke et ekstra projekt.

Hvordan løbende sikring ser ud i praksis

Løbende sikring forbinder dine regler, kontroller, beviser og beslutninger, så de forstærker hinanden. Hver del af løkken kan justeres, efterhånden som dine tjenester udvikler sig.

Et ligetil mønster bruger fire byggesten:

Indgange: Politikker, standarder og kundekrav, der definerer, hvordan tingene skal gøres.
Kontrolaktiviteter: Tekniske kontroller og proceduremæssige trin, der integrerer disse regler i det daglige arbejde.
Bevisgenstande: Logfiler, billetter, rapporter og godkendelser, der viser, hvad der rent faktisk skete.
Feedback loops: Governancefora, risikoregistre og ledelsesgennemgange, der bruger evidensen til at foretage ændringer.

For eksempel kan en regel om, at "alle ændringer med høj risiko skal godkendes af både en teknisk ejer og en kunderepræsentant", være indarbejdet i din arbejdsgang for ændringsstyring, håndhævet af dit ticketingsystem, dokumenteret af godkendelsesregistre og gennemgået med jævne mellemrum i en intern revision eller ledelsesgennemgang.

Du behøver ikke at sætte alle regler på en daglig overvågningsplan. En risikobaseret tilgang fungerer godt:

Regler med stor indflydelse (privilegeret adgang, produktionsændringer, håndtering af hændelser) kan kontrolleres løbende eller ugentligt.
Regler med mellemstor effekt (tidslinjer for patching, backuptests, færdiggørelse af træning) kan udtages månedligt eller kvartalsvis.
Regler med lav effekt kan overvåges gennem lejlighedsvise revisioner og under ledelsesgennemgange.

Det vigtige er, at du kan forklare din begrundelse og vise, at de valgte mekanismer rent faktisk fungerer i praksis. Når kunder eller revisorer spørger, hvorfor en regel kontrolleres månedligt i stedet for ugentligt, ønsker du et klart, risikobaseret svar.

Prioritering og tilpasning til ledelse

De fleste MSP'er kan ikke flytte alt til en løbende sikringsmodel på én gang, så prioritering er vigtig. Du vil gøre hurtigere fremskridt ved at fokusere på de regler, der ville forårsage mest skade, hvis de ignoreres, og opbygge tillid der først.

En pragmatisk tilgang er at:

Identificér de fem til ti regler, hvis manglende overholdelse ville skade kunderne eller din egen virksomhed mest.
Fokuser den indledende design- og automatiseringsindsats på disse regler.
Vælg overvågnings-, rapporterings- og eskaleringsprocesser, der er direkte knyttet til eksisterende styring.

For eksempel kan du starte med at:

Knyt regler for privilegeret adgang til dine identitets- og billetsystemer, så alle elevationer godkendes, logges og gennemgås.
Forbind patching-standarder med dit RMM-værktøj med dashboards, der viser overholdelse af regler på tværs af kunder og markerer undtagelser.
Rapportering af nøgletal – såsom antallet af politikovertrædelser og alderen på åbne undtagelser – i jeres ISMS-komité og ledelsesevalueringer.

Ved at gøre dette gør du A.5.36 til en del af din normale planlægning og tilsyn, i stedet for et separat sprog, som kun ISO-teamet taler. Medarbejdere og kunder ser derefter en ensartet historie: regler, kontroller, dokumentation og forbedringer, der alle er forbundet på en måde, der stemmer overens med Plan-Do-Check-Act-cyklussen.

Et praktisk A.5.36-rammeværk for MSP'er

Et praktisk A.5.36-rammeværk giver dig struktur for, hvordan regler, ejere, kontroller og reaktioner passer sammen på tværs af din MSP. Det forvandler spredte politikker og vaner til et klart kort over, hvem der er ansvarlig for hvad, hvordan compliance kontrolleres, og hvordan du reagerer, når tingene går galt.

Denne ramme bliver broen mellem overordnede politikker og de operationelle trin, som ingeniører og servicechefer følger. Den giver dig også en gentagelig måde at besvare kunde- og revisorspørgsmål på uden at skulle genopfinde forklaringer hver gang.

Opbygning af et MSP-specifikt A.5.36-kontrolrammeværk

Et MSP-specifikt A.5.36-rammeværk starter normalt med et simpelt register, der viser, hvordan vigtige regler anvendes, kontrolleres og dokumenteres i praksis. Hver post forbinder en regel med tjenester, ejere, overvågning og dokumentation.

Et nyttigt udgangspunkt er et register, der for hver vigtig regel registrerer:

Den politik eller standard, den stammer fra.
De tjenester og kundemiljøer, det gælder for.
Den kontrolindehaver, der er ansvarlig for håndhævelse.
Procesejeren, der er ansvarlig for design og effektivitet.
Overvågningsmekanismen og -frekvensen.
Beviskilderne, såsom rapporter eller sagstyper.
Undtagelsesprocessen, herunder godkendelses- og gennemgangsdatoer.

For MSP'er bør dette register eksplicit indeholde kundespecifikke krav, ikke blot jeres generiske virksomhedspolitikker. Hvis en større kunde kræver, at I opfylder bestemte logføringsstandarder eller regler for ændringskontrol, bør disse forpligtelser fremgå som regler i jeres rammeværk med ejere, kontroller og dokumentationskilder.

For eksempel kan en regel om "privilegeret adgang" registreres som stammer fra din adgangskontrolpolitik og en nøglekundeplan. Den kan gælde for SOC- og infrastrukturtjenester, være ejet af sikkerhedschefen, overvåges ugentligt via identitets- og ticketrapporter, dokumenteres ved adgangsgennemgange og ændringsgodkendelser og have tidsbegrænsede undtagelser godkendt af CISO'en.

Du behøver ikke hundredvis af poster. Start med de regler, der betyder mest for sikkerhed og garanti, især hvor dine kontrakter og markedsføringspåstande er stærkest. Med tiden kan du udvide registret efter behov, baseret på risiko og kundernes forventninger.

En ISMS-platform som ISMS.online kan yderligere styrke dette ved at føre registeret, forbinde regler med risici og kontroller og spore revisionsdatoer og ændringer. Denne fælles visning reducerer forvirring og gør det lettere at opretholde sammenhængen, efterhånden som dine tjenester udvikler sig.

Definition af omfang, ejerskab og kriterier for brud

To dele af rammeværket fortjener særlig opmærksomhed: ejerskab og hvad der tæller som et brud. Begge dele afgør, om dine regler forbliver teoretiske eller rent faktisk former adfærd.

Stærkt ejerskab betyder, at enhver væsentlig regel har:

A kontrolejer, ansvarlig for at sikre, at reglen følges på tværs af relevante tjenester.
A procesejer, ansvarlig for at holde kontroldesignet og overvågningsmetoden passende i takt med at teknologi, kunder og regler ændrer sig.

Lige så vigtigt er det tydeligt kriterier for brudDu har brug for en fælles metode til at skelne mellem:

Mindre afvigelser, der kan håndteres lokalt og registreres som en del af det normale arbejde.
Væsentlige brud, der bør logges som afvigelser, eskaleres og potentielt behandles som hændelser.

Du kan ikke håndhæve det, du ikke har defineret som et brud. At definere tærskler på forhånd gør det nemmere at konfigurere værktøjer, såsom hvordan advarsler klassificeres og dirigeres, og at sikre, at disciplinære og kontraktlige foranstaltninger anvendes konsekvent og retfærdigt. Det gør det også nemmere at forbinde A.5.36 med dine hændelsesstyrings- og afvigelsesprocesser, så alvorlige brud følger den samme strukturerede proces som andre sikkerhedshændelser.

Et rammeværk som dette reducerer behovet for omarbejde under revision. Når revisorer eller kunder spørger: "Hvordan sikrer I, at denne regel følges?", kan I pege på en klar beskrivelse, der viser reglen, kontrollerne, overvågningen og beviserne, og derefter udtrække et par stikprøver for at demonstrere, at cyklussen fungerer.

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

Book din demo

Integrering af A.5.36 i ISMS, Governance og SOP'er

Ved at integrere A.5.36 i jeres ISMS, styringsstrukturer og standardprocedurer omdanner I rammer til praksis. Målet er at gøre overholdelse af politikker til en del af rutinemæssig beslutningstagning og servicelevering, ikke en isoleret overholdelsesaktivitet, der kun optræder før revisioner.

Mange af de nødvendige mekanismer findes allerede i en typisk ISO 27001-tilpasset MSP: risikoregistre, ændringsstyringsprocesser, hændelsesstyring, disciplinære procedurer, interne revisioner og ledelsesevalueringer. Opgaven er at forbinde A.5.36 eksplicit med disse mekanismer, så manglende overholdelse af regler håndteres som en førsteklasses risiko og ikke en eftertanke.

Sammenkobling af A.5.36 med risiko- og styringsprocesser

Ved at forbinde A.5.36 med eksisterende risiko- og styringsprocesser bliver det nemmere at styre manglende overholdelse konsekvent. I stedet for at oprette et separat spor, afdækker du politikbrud sammen med andre risici og kontrolproblemer.

Trin 1 – Integrer regelbrud i risikostyring

Tilføj typiske scenarier for "manglende overholdelse af politikker" til dit risikoregister, såsom manglende overholdelse af adgangskontrolregler eller ændringskontrolprocesser. Forbind dem med eksisterende risici – for eksempel databrud eller serviceafbrydelser – så du kan retfærdiggøre overvågnings- og afbødningsindsatser og sikre, at ejerskabet er klart.

Trin 2 – Gør A.5.36 til et tilbagevendende revisionstema

Sørg for, at interne revisioner og compliance-evalueringer regelmæssigt tester, om udvalgte regler følges. Udfør stikprøver af et lille antal regler hvert år, og kontroller, at dokumenterede kontroller, overvågning og beviser fungerer som beskrevet. Brug resultaterne til at fremme korrigerende handlinger og forbedringer, ikke kun til at mærke tidligere adfærd.

Trin 3 – Indfør metrikker i ledelsesevalueringer

Inkluder A.5.36-relaterede målinger – antal politikovertrædelser, undtagelsestendenser, gennemførelse af planlagte kontroller – som standardinput i ledelsens evalueringer. Diskuter, hvad de siger om kultur, kontroller og arbejdsbyrde, og beslut, hvor forbedringsindsatsen skal fokuseres. Ved konsekvent at gøre dette viser du revisorer og kunder, at manglende overholdelse aktivt styres.

Det er også vigtigt at sikre, at din ISMS-omfangserklæring og kontekstanalyse eksplicit inkluderer tjenester leveret til kunder og de værktøjer, der bruges til at levere dem. På den måde er der ingen tvetydighed om, hvorvidt A.5.36 gælder for platforme med flere lejere, kundemiljøer og underleverandørtjenester.

At gøre A.5.36 til en del af de daglige arbejdsgange

At gøre A.5.36 til en del af det daglige arbejde handler i sidste ende om at tilpasse runbooks og adfærd til frameworket, så compliance bliver en del af, "hvordan vi gør tingene her".

Nyttige teknikker omfatter:

Annotering af runbooks: Mærk trin i onboarding-, ændrings-, hændelses- og vedligeholdelses-runbooks, der eksisterer for at opfylde bestemte regler. Enkle identifikatorer, såsom regel-id'er eller politikreferencer, gør det nemmere at opretholde overensstemmelse, når politikker og standarder ændres.
Opdatering af formularer og arbejdsgange: Sørg for, at nøgleprocesser indsamler de oplysninger, du har brug for til A.5.36-dokumentation – såsom hvilken politik en afvigelse vedrører, hvilke korrigerende handlinger der blev truffet, og om der blev givet en undtagelse.
Rollebaseret træning: Gå ud over generiske kurser i "sikkerhedsbevidsthed". Giv kort, rollespecifik vejledning i, hvad A.5.36 betyder for ingeniører, servicechefer, account managers og salgsmedarbejdere. Vis dem, hvordan deres handlinger genererer eller forbruger bevismateriale, og hvordan det understøtter kunderne.

Med tiden føles compliance mindre som en ekstra opgave og mere som en del af, hvordan du leverer kvalitetstjenester. Det gør det også nemmere at automatisere kontroller og rapportering, fordi de nødvendige data allerede flyder gennem dine værktøjer på en struktureret måde.

En ISMS-platform kan hjælpe ved at huse rammeværket, forbinde regler med risici, kontroller, runbooks og beviser, og ved at skabe et fælles sted for afvigelser, korrigerende handlinger og ledelsesgennemgangsregistre. Denne delte kontekst reducerer risikoen for, at forskellige teams arbejder ud fra forskellige versioner af sandheden, og gør A.5.36 synlig for både tekniske og ikke-tekniske interessenter.

Værktøjer: Omdannelse af politikker til maskintjekbare regler (SIEM, RMM, ITSM)

At omdanne politikker til maskintjekbare regler betyder at udtrykke centrale dele af dit politiksæt som betingelser, som dine værktøjer kan overvåge og håndhæve, så du reducerer manuel kontrol og får stærkere sikkerhed for, at reglerne følges. Når du har klare regler, ejerskab og processer, kan du begynde at udtrykke nogle af disse regler som tekniske betingelser, som dine værktøjer kan kontrollere, så A.5.36 og din sikkerhedsdriftsstak forstærker hinanden og omdanner politikker til maskintjekbare signaler.

Målet er ikke at opbygge et separat "compliance-system", men at konfigurere de systemer, I allerede bruger – SIEM, RMM, identitetsplatforme, endpoint-administration og ticketing – så de producerer dokumentation og advarsler, der relaterer sig til jeres regler og standarder. Når det gøres ordentligt, reducerer dette den manuelle indsats og øger tilliden til, at reglerne rent faktisk håndhæves.

Udtryk af politikker som tekniske betingelser

Du udtrykker en politik som en teknisk betingelse ved at gå fra en regel i et letforståeligt sprog til specifikke signaler og kontroller i dine værktøjer. Mønsteret er simpelt, men det kræver disciplin at anvende det konsekvent.

For at oversætte politiktekst til noget, som værktøjer kan arbejde med, er det nyttigt at bruge et mønster, der bygger bro mellem sprog og konfiguration:

Start med en regelfor eksempel "alle administrerede slutpunkter skal køre godkendt slutpunktsbeskyttelse" eller "ingen delte administratorkonti er tilladt".
Identificer signaler: afgør hvilke logfiler, konfigurationsdata eller hændelser der skal vise, om reglen følges eller overtrædes.
Definer betingelser: skriv klare betingelser, der kan testes, såsom "agent til stede og rask" eller "mere end én person bruger den samme privilegerede konto".
Konfigurer kontrollerImplementer disse betingelser i dine overvågnings- og administrationsværktøjer med dashboards eller rapporter, der opsummerer overholdelse og fremhæver undtagelser.
Opret forbindelse til arbejdsgangeSend overtrædelser til billetkøer med passende kategorier, prioriteter og SLA'er, så de håndteres som ethvert andet operationelt problem.

Overvej for eksempel reglen "alle administrerede slutpunkter skal køre godkendt slutpunktsbeskyttelse". Signalerne kan være agenttilstandsdata fra din RMM- og antiviruskonsol. Betingelsen er "agent installeret og rapporterer inden for de sidste 24 timer". Du konfigurerer kontroller og dashboards til at markere manglende eller forældede agenter og oprette tickets automatisk, så ikke-kompatible enheder er synlige, spores og afhjælpes.

Den samme logik gælder for procesbaserede regler. For eksempel kan en regel om, at "alle ændringer med høj risiko skal gennemgå en formel godkendelsesworkflow", kontrolleres ved at korrelere ændringssager med implementeringslogfiler og markere afvigelser.

Start med et lille antal regler med stor effekt, og juster tærsklerne omhyggeligt. Overfølsomme kontroller, der genererer konstante advarsler, vil hurtigt miste troværdighed og kan få sikkerheden til at se værre ud snarere end bedre.

Brug dine værktøjer til at registrere og håndhæve regler

Mange MSP'er har allerede de nødvendige værktøjer til at understøtte A.5.36; det, der normalt mangler, er den eksplicitte kortlægning fra regler til værktøjskonfiguration og rapporter, og disciplinen til at holde denne kortlægning opdateret.

Nyttige muligheder inkluderer:

Fjernovervågning og endpoint-styring: Brug disse til at håndhæve og rapportere om patchingstandarder, kryptering, implementering af endpoint-beskyttelse og lokale administratorrettigheder på tværs af kunder. Undtagelser bliver synlige, kvantificerede input til risiko- og styringsprocesser.
Sikkerhedsanalyse og logføring: Konfigurer korrelationsregler, der grupperer sandsynlige politikovertrædelser – såsom privilegeret adgang uden for åbningstid eller konfigurationsændringer uden tilhørende tickets – i fokuserede dashboards. Disse kan gennemgås i daglige eller ugentlige rutiner.
Identitets- og adgangsstyring: Brug gruppemedlemskab, politikker for betinget adgang og rollebaseret adgangskontrol til at håndhæve regler for, hvem der kan gøre hvad, hvor og hvornår. Logfiler og rapporter udgør derefter en del af dokumentationspakken for adgangskontrolrelaterede regler.
Billethåndtering og IT-servicestyring (ITSM): Sørg for, at sager, der repræsenterer manglende overholdelse, er mærket med den relevante regel, sporet frem til afslutning og opbevaret til analyse. Over tid skaber dette en struktureret historik over, hvordan regler anvendes og håndhæves.

Automatiseret håndhævelse – såsom blokering af handlinger, der overtræder centrale regler, eller karantæne af ikke-kompatible enheder – kan være effektiv for de områder med højest risiko. Når du implementerer sådanne kontroller, giver dokumentation af deres design, omfang og overvågning dig et stærkt materiale for både revisorer og kunder i henhold til A.5.36.

ISMS.online erstatter ikke disse operationelle værktøjer, men det kan placeres oven på dem, gemme reglerne, knytte dem til tjenester og kontroller og linke til rapporter, dashboards og tickets, der viser, hvordan de fungerer. Dette undgår behovet for at implementere overvågning igen, samtidig med at du får en sammenhængende compliance-historie, der forbinder teknologi og styring.

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

Book din demo

KPI'er, optegnelser og dokumentation for revisorer og virksomhedskunder

Et lille, veludvalgt sæt af målinger og optegnelser vil gøre mere for A.5.36-sikring end snesevis af løst relaterede diagrammer og skærmbilleder, fordi de rigtige målinger hjælper dig med at vise, at regler betyder noget, kontrolleres og fører til handling, når de ikke følges. Rådgivning om ISO 27001 og bredere cyberrisikostyring har også en tendens til at foretrække fokuserede, beslutningsrelevante målinger frem for store mængder ustruktureret data af netop denne grund, da denne kombination er lettere for bestyrelser, revisorer og kunder at fortolke.

Med formulerede regler og kontroller på plads kan du derefter forme de resulterende data til målinger og beviser, der tilfredsstiller to krævende målgrupper: certificeringsrevisorer og virksomhedskunder.

Næsten alle respondenter i ISMS.online-undersøgelsen i 2025 angav opnåelse eller opretholdelse af sikkerhedscertificeringer, såsom ISO 27001 eller SOC 2, som en topprioritet.

Målet er et slankt sæt af målinger og artefakter, der demonstrerer tre ting:

Du ved hvilke regler der er vigtige.
Du kontrollerer overholdelsen af dem.
Du handler på det, du finder, og du lærer.

De stærkeste garantihistorier er dem, du kan fortælle konsekvent, ikke dem, du genopfinder for hver kunde.

Design af et lean A.5.36-metriksæt

Et smalt A.5.36-målesæt fokuserer på en håndfuld indikatorer, der tydeligt beskriver risiko, adfærd og forbedring. For mange målinger udvander opmærksomheden og er svære at vedligeholde.

Du behøver ikke en lang liste af KPI'er. Et lille, omhyggeligt udvalgt sæt kan være mere effektivt og nemmere at vedligeholde, især når du skal forklare det gentagne gange til revisorer, bestyrelser og kunder.

Eksempler, der fungerer godt for MSP'er, inkluderer:

Politik og træningsdækning: Procentdel af medarbejdere og nøgleroller, der har anerkendt og gennemført træning i relevante politikker og standarder.
Overtrædelsesrater: Antal og alvorlighedsgrad af identificerede brud på centrale regler over en periode, opdelt efter tjeneste eller funktion.
Tid til afhjælpning: Gennemsnitlig tid fra opdagelse af et brud eller en manglende overensstemmelse til løsning.
Undtagelseslandskab: Antal godkendte undtagelser fra reglerne, deres alder og hvornår de skal gennemgås.
Overvågningsdækning: Andel af systemer eller kunder inden for området, der er dækket af definerede kontroller.

Disse målinger kan præsenteres forskelligt for forskellige målgrupper. Bestyrelser og ledere er opmærksomme på tendenser og forretningsmæssig indflydelse. Tekniske teams er opmærksomme på, hvor de skal fokusere indsatsen. Kunder er opmærksomme på sikkerheden for, at regler følges og forbedres over tid. Ved at forbinde målinger som f.eks. undtagelsesalder eller overvågning af dækning med kommercielle resultater – for eksempel hvordan de påvirker due diligence-resultater eller kontraktfornyelser – bliver deres relevans tydeligere.

Regelmæssige interne gennemgange af disse foranstaltninger hjælper med at identificere systemiske problemer, såsom gentagne brud på den samme regel eller bestemte tjenester, der har svært ved at overholde standarderne. Disse indsigter bør bidrage til målrettede forbedringer i træning, processer eller værktøjer.

Opbygning af genanvendelige bevispakker

Genanvendelige dokumentpakker giver dig mulighed for at reagere hurtigt og konsekvent på anmodninger om sikkerhed. I stedet for at sammensætte ad hoc-pakker under pres, opretholder du en central A.5.36-etage, der kan skræddersys til hver enkelt revisor eller kunde.

Både revisorer og kunder sætter pris på struktureret, genanvendeligt bevismateriale. I stedet for at starte forfra for hver vurdering, kan du udarbejde en A.5.36 "bevispakke", som du opdaterer med jævne mellemrum og skræddersyr til målgruppen.

En typisk pakke kan indeholde:

En kortfattet forklaring af, hvordan A.5.36 er implementeret i din MSP, med diagrammer, der viser rammeværket og nøgleprocesserne.
Uddrag fra jeres politik- og standardregister, der fremhæver regler, der gælder for de omfattede tjenester.
Eksempler på trænings- og bekræftelsesrapporter for relevante medarbejdere.
Udvalgte overvågningsrapporter, der viser kontrol i forhold til nøgleregler.
Et lille sæt redigerede sager, der viser, hvordan manglende overholdelse registreres og løses.
Resuméer af interne revisioner eller compliance-gennemgange, der testede A.5.36-relaterede kontroller.
Dokumentation for, at ledelsen har gennemgået metrikker for politikoverholdelse og truffet beslutninger om forbedringer.

For kunder kan du yderligere anonymisere og skræddersy dette materiale med fokus på de regler og tjenester, der er relevante for dem, og på hvordan din MSP-dækkende styring understøtter deres specifikke krav. Et anonymiseret eksempel fra en lignende kunde – såsom en mellemstor MSP med SOC og administrerede detektions- og responstjenester – kan hjælpe med at illustrere, hvordan dit framework fungerer i praksis, uden at afsløre fortrolige detaljer.

ISMS.online hjælper dig ved at give dig mulighed for at gemme kontrolbeskrivelser, linke dem til dokumentationsregistre, spore gennemgangsdatoer og eksportere ensartede visninger efter behov. Det understøtter også din egen interne sikring, fordi du med et hurtigt overblik kan se, hvilke regler der har opdateret dokumentation, og hvilke der skal lægges vægt på inden den næste revision eller kundegennemgang.

Book en demo med ISMS.online i dag

ISMS.online giver din MSP en praktisk måde at forvandle A.5.36 fra en papirøvelse til en synlig, håndterbar kontrol på tværs af dine tjenester. Det hjælper dig med at gå fra punkt-i-tid, personafhængig compliance til løbende sikring, der matcher, hvordan du allerede driver sikkerhedsoperationer.

I praksis betyder det, at du kan:

Hold jeres politikker og standarder samlet ét sted, knyttet til tjenester, risici og ISO 27001-kontroller.
Tildel klart ejerskab for regler og kontroller med opgaver og arbejdsgange, der sporer gennemgange og forbedringer.
Forbind regler med virkelige beviser såsom revisioner, overvågningsrapporter og tickets, uden at duplikere driftsdata.
Opbyg og vedligehold genanvendelige dokumentationspakker til revisorer og kunder, hvilket reducerer forberedelsestiden og stressen.
Støt ledelsesgennemgange og bestyrelsesrapportering med opdaterede oversigter over politikoverholdelsesmålinger og afvigelser.

At se dette i konteksten af dine egne tjenester er langt mere kraftfuldt end at læse om det i abstrakt form. En demo giver dig mulighed for at gennemgå dine A.5.36-udfordringer, se hvordan de passer ind i platformen, og udforske, hvordan en mere kontinuerlig, værktøjsbaseret revisionsmodel ville se ud for din organisation.

Hvis du leder sikkerhed, drift eller compliance i en MSP og har brug for at styrke, hvordan du demonstrerer A.5.36 til revisorer og virksomhedskunder, er booking af en demo et praktisk næste skridt. Det giver dig mulighed for at teste, om ISMS.online kan hjælpe dig med at vise – ikke bare sige – at du overholder dine politikker, regler og standarder for informationssikkerhed på tværs af alle de administrerede tjenester, du leverer.

Ofte stillede spørgsmål

Hvad kræver ISO 27001:2022 A.5.36 egentlig af en MSP i det daglige?

A.5.36 forventer, at din MSP beviser, at folk rent faktisk følger dine sikkerhedsregler i det daglige arbejde, og at du rutinemæssigt opdager, vurderer og afhjælper manglende overholdelse på tværs af din egen ejendom, din værktøjskæde og dine kunders miljøer.

Hvor optræder A.5.36 i en rigtig MSP?

For en administreret serviceudbyder har denne kontrol tre funktioner på én gang:

Dit indre miljø

Dette er alt, hvad dit team bruger til at køre og understøtte tjenester:

Adgang til PSA-, RMM-, SIEM-, backup-, identitets- og billetplatforme.
Bærbare computere, servere, VPN'er og SaaS, der bruges af ingeniører og backoffice-personale.
Hvordan folk håndterer kundedata i e-mail, chat, dokumentation og skærmdeling.

Her spørger A.5.36: Har I klare regler for, hvordan personalet får adgang til og beskytter denne ejendom, forstår de dem, og kan I vise, hvordan I kontrollerer og forbedrer dem over tid?

Den multi-tenant service stak, du driver

Dette er det delte værktøjslag, du driver på vegne af mange kunder:

RMM, EDR, SIEM, identitet, cloud-administrationskonsoller, backupplatforme og ticketing.
Regler for MFA på konsoller, design af administratorroller, brug af breakglass-konti, leverandøradgang og godkendelse af ændringer.
Afstemning mellem dit servicekatalog, dine runbooks og hvad der rent faktisk sker med billetter og ændringer uden for åbningstid.

Her er forventningen enkel: dokumenterede regler, klare ejere, definerede gennemgangskadenser og dokumentation for, at undtagelser registreres, vurderes og enten lukkes eller accepteres som risici.

Kundemiljøer inden for rammerne

Dette er den infrastruktur og de cloud-arbejdsbelastninger, du administrerer under kontrakt:

Enheder, netværk, lejere, abonnementer og sikkerhedskontroller, du er ansvarlig for.
SLA'er og runbooks, der definerer, hvad "sikker nok" betyder for hver tjeneste.
Dokumentation for, at patching, overvågning, backuptjek, adgangsgennemgang og hændelseshåndtering matcher det, I har lovet.

På tværs af disse tre lag leder revisorer, cyberforsikringsselskaber og virksomhedskøbere i virkeligheden efter tre ting:

MSP-specifikke regler: der omhandler fjernadgang, værktøjer til flere lejere, håndtering af kundedata og brug af underleverandører.
Bevis for, at folk følger disse regler: – træning, politikbekræftelser, eksempler på bearbejdede tickets og runbooks, adgangsgennemgangsregistre.
En sporbar løkke: viser, at når regler brydes, logger du det, vurderer risikoen, handler og justerer kontroller eller træning.

Når du kan forklare den løkke i et letforståeligt sprog og bakke den op med et lille, velvalgt sæt eksempler, bliver A.5.36 en måde at vise kunderne, at du driver din MSP med disciplin, snarere end blot endnu et afkrydsningsfelt på listen i bilag A.

Hvordan kan en MSP skifte fra årlig "papirbaseret compliance" til løbende sikring uden at brænde folk ud?

Du skifter til løbende sikring ved at bevæge dig væk fra en årlig kamp og i stedet integrere mindre, risikobaserede kontroller i de værktøjer og arbejdsgange, dine teams allerede bruger, så nyttig dokumentation automatisk dukker op, mens de udfører deres arbejde.

Hvordan ser løbende sikring ud i en MSP?

En praktisk model hviler normalt på tre træk.

Brug risikobaserede kadencer i stedet for flade tjeklister

Ikke alle regler fortjener ugentlig opmærksomhed:

Domæner med stor effekt: – privilegeret adgang, ændringer med høj risiko, sikkerhedskopier til nøglelejere, overvågning af dækning – begrundelse kontinuerlig, daglig eller ugentlig checks.
Domæner med mellemstor effekt: – overholdelse af patches, konfigurationsgrundlinjer, gennemførelse af sikkerhedstræning – tilpasning månedligt eller kvartalsvis cyklusser.
Områder med lavere effekt: – nogle fysiske kontroller eller nicheværktøjer – kan samples i interne revisioner og stikprøvekontroller.

Dette viser, at du bruger A.5.36-indsatsen der, hvor kundens risiko og tillid kræver det, ikke kun hvor en skabelon sagde "månedligt".

Indbyg tjek i de værktøjer, dine teams allerede bruger

Løbende sikring gælder kun, hvis kontrol er en del af det normale arbejde:

Ændringsgodkendelser, administratorbrug uden for åbningstid og undtagelser håndhæves via arbejdsgange for billetter med obligatoriske felter og godkendelser.
Baseline- og patchregler håndhæves og rapporteres i RMM og værktøjer til endpoint-sikkerhed, ikke kopieret til regneark.
Administrator- og identitetshændelser – nye privilegerede roller, MFA-ændringer, risikable logins – spores via revisionslogfiler og SIEM-regler indstillet på et lille antal meningsfulde mønstre.

Målet er, at jeres ISMS og ethvert Annex L-tilpasset IMS bruger disse eksisterende signaler i stedet for at skabe et parallelt univers af manuelle logfiler, som ingen har tillid til.

Lad beviser være et biprodukt af gode handlinger

Når checks overføres til dine platforme:

Billetter, dashboards, rapporter, ændringsregistreringer og gennemgangsnotater bliver automatisk bevis i A.5.36.
Din ISO- eller sikkerhedschef holder op med at være en "bevisjæger" og bliver en kontrol-tuner, bruger denne strøm til at justere tærskler, kadencer og træning.

Hvis dit team allerede frygter ugerne før overvågningsrevisioner eller store kundeanmeldelser, kan du placere løbende sikring som en måde at gøre livet roligere og mere professionelt, ikke blot som endnu et lag af compliance-administration. ISMS.online er designet til at ligge oven på denne model ved at forbinde risici, politikker, interne revisioner og korrigerende handlinger ét sted, så løbende kontroller i dine værktøjer naturligt forsyner dit informationssikkerhedsstyringssystem.

Hvilke konkrete kontroller og optegnelser bør en MSP fokusere på først i forbindelse med A.5.36?

Du behøver ikke en væg af mapper. Du har brug for et lille, disciplineret sæt kontroller og optegnelser, der beviser, at der findes regler omkring højrisikoområder, at de anvendes i praksis og korrigeres, når de ikke gør.

Hvilke domæner er normalt mest betydningsfulde i forbindelse med revisioner og due diligence?

Fem områder bærer typisk størst vægt for en MSP.

1. Privilegeret og fjernadgang

Dette er normalt det første sted, revisorer og kunder kigger.

Definere: hvem der kan have administratorkonti, hvilke MFA- og enhedsstandarder der gælder, hvordan delte legitimationsoplysninger undgås, og hvordan nødadgang anmodes om og tilbagekaldes.
Holde: eksport af medlemskab af administratorgrupper, korte referater af adgangsgennemgang og et par redigerede supportsager, der viser åben og lukket nødadgang.

2. Programrettelser og konfiguration

Dette viser, om du kan udføre grundlæggende hygiejne i stor skala.

Definere: Minimumsopdateringscyklusser efter systemtype, basiskonfigurationer for endpoints, servere og cloud, og hvordan undtagelser håndteres.
Holde: Programrettelses- og sårbarhedsrapporter med klart omfang og datoer, plus tickets, hvor der blev fundet, risikovurderet og rettet afvigelser fra baseline.

3. Højrisiko forandringsledelse

Det er her, mange alvorlige hændelser starter.

Definere: hvilke ændringer kræver formel godkendelse (f.eks. firewallregler, identitetsændringer, backuppolitikker), hvem godkender, og hvad der skal registreres.
Holde: et lille sæt fuldt udfyldte ændringssedler, der viser processen fra anmodning til godkendelse og, hvor det er nødvendigt, gennemgang efter implementeringen.

4. Logførings- og overvågningsdækning

Det beviser, at du bemærker og handler, når noget går galt.

Definere: hvilke hændelser der skal logges for din egen ejendom og for administrerede tjenester, hvor logfilerne placeres, hvor længe du opbevarer dem, og hvilke advarsler der er vigtige.
Holde: enkle dækningsdiagrammer eller opsummeringer, eksempel på advarsler og opfølgende supportsager, der viser, hvordan problemet blev undersøgt og lukket.

5. Undtagelser og manglende overholdelse

Det er her, A.5.36 virkelig viser, om du tager reglerne alvorligt.

Definere: hvordan undtagelser rejses, godkendes, tidsbegrænses og gennemgås, og hvordan gentagen manglende overholdelse eskaleres.
Holde: en levende undtagelseslog, der er knyttet til dit risikoregister, og et par tilfælde, hvor du ikke blot løste det umiddelbare problem, men også ændrede en skabelon, opdaterede en runbook eller justerede træningen.

Når du samler disse i en kompakt A.5.36 "bevispakke" og holder den opdateret, kan du hurtigt svare revisorer, cyberforsikringsselskaber og virksomhedsindkøbsteams uden at opfinde nyt bevismateriale hver gang. I ISMS.online kan denne pakke placeres sammen med dine relevante politikker, risici, interne revisioner og ledelsesgennemgange, så dit team altid ved, hvor de skal henvende sig, når nogen spørger: "Vis mig, hvordan I ved, at jeres politikker følges."

Hvordan bør en MSP integrere A.5.36 i sit ISMS og IMS, så det overlever personaleændringer?

A.5.36 varer længere end én enkelt ISO-lead, når du behandler det som en del af din governance-rytme og ikke som et sideprojekt. Det betyder, at overholdelse af politikker skal integreres i risikostyring, intern revision, håndtering af hændelser og ændringer samt ledelsesgennemgang, så det regelmæssigt diskuteres og handles på.

Hvordan ser det ud i en bilag L-tilpasset havsplan?

Tre designvalg gør en mærkbar forskel.

1. Behandl brudmønstre som risici, ikke støj

I stedet for at behandle gentagne politikbrud som "irriterende engangsforeteelser":

Registrer tilbagevendende temaer – ikke-administrerede administratorkonti, ikke-godkendte ændringer, gentagne forsinkelser i rettelser, fejl i sikkerhedskopiering – i din risikoregister med eksplicit kunde- og forretningsmæssig indflydelse.
Vurder dem som enhver anden ISO 27001-risiko: sandsynlighed, effekt og kontroleffektivitet, så "vi slap afsted med det" ikke er målestokken.
I et bilag L-tilpasset IMS skal disse risici forbindes med relaterede klausuler i kvalitets-, servicestyrings- eller forretningskontinuitetsstandarder, så den samme svaghed ikke stille og roligt underminerer flere certifikater.

2. Sæt A.5.36 på dagsordenen for ledelsens gennemgang og intern revision

Overholdelse af politikker bør være et fast emne, ikke bare et bilag.

I ledelsesevalueringer skal du inkludere simple, trendbaserede indikatorer: antal og alvorlighed af politikbrud, aldring af undtagelser, forsinkede kontroltjek og interne revisionsresultater relateret til ikke-overholdte regler.
Brug interne revisioner til at eksempler på rigtige tjenester, værktøjer og kunder og tjek om reglerne reelt anvendes der, ikke kun på dine mest modne konti.
Omdan output fra gennemgange til sporede handlinger: hvem ejer en løsning, hvornår den forfalder, hvordan fremskridt kontrolleres, og hvordan succes måles.

ISMS.online understøtter dette mønster ved at give dig skabeloner til ledelsesgennemgang, tilknyttede risici, interne revisioner og korrigerende handlinger samlet ét sted, så du kan vise hele processen fra problem til forbedring.

3. Knyt SOP'er og runbooks direkte til kontroller og kontrakter

Ingeniører skal se, hvordan deres trin stemmer overens med forpligtelser.

Angiv onboarding-, ændrings-, hændelses- og vedligeholdelsestrin med den politik, det bilag A-kontrolpunkt eller den kontraktklausul, de opfylder.
Opdater formularer, så de indsamler de data, du senere vil være afhængig af: hvilken regel der gjaldt, hvem der godkendte, hvilken lejer der blev påvirket, og hvad der blev gjort for at forhindre gentagelse.
Afspejl disse forventninger i rollebaseret træning, så medarbejderne forstår, hvorfor bestemte felter og godkendelser er obligatoriske og ikke "ekstra administration".

Når denne struktur findes i dit ISMS og ethvert bredere IMS – i stedet for spredt ud over dokumenter og folks hoveder – bliver A.5.36 til "hvordan vi driver MSP'en", ikke "hvad vi støver af for revisoren". Hvis du bruger ISMS.online, kan du gøre disse forbindelser eksplicitte gennem sammenkædet arbejde, risikoregistreringer, interne revisioner og ledelsesevalueringer, hvilket hjælper dig med at vise kontinuitet, selv når rollerne ændrer sig.

Hvordan kan SIEM, RMM og billetværktøjer blive praktiske håndhævelsesmotorer for politiske regler?

Du forvandler eksisterende platforme til håndhævelsesmotorer ved at oversætte et lille sæt vigtige regler til forhold, som disse værktøjer kan kontrollere automatisk, og ved at sikre, at enhver fejl bliver en klar, handlingsrettet sag med ejerskab og en feedbackvej til dit ISMS.

Hvilket mønster kan en MSP følge for at gøre regler maskintjekkelige?

Et simpelt mønster med seks trin fungerer på tværs af de fleste domæner.

1. Skriv reglen, så både et menneske og et værktøj kan anvende den

For eksempel:

"Alle administrerede Windows-servere skal installere kritiske sikkerhedsopdateringer inden for 14 dage efter udgivelsen, medmindre der findes en godkendt undtagelse."
"Hver kundelejer skal have mindst to navngivne globale administratorer, begge beskyttet af MFA og betinget adgang."

Undgå tvetydige sætninger som "hvor det er muligt", hvis du ønsker værktøjer til at hjælpe.

2. Afgør hvilke signaler der beviser, at reglen er korrekt eller forkert

Se hvad dine systemer allerede kan se:

RMM- eller sårbarhedsscannerpatchdata.
CMDB- eller aktivbeholdningsindhold.
Katalog- og SaaS-administratorroller, login og konfigurationslogfiler.
Billetter og undtagelser i din servicedesk.

Disse signaler definerer, hvad der kan kontrolleres automatisk.

3. Omdan reglen til konkrete, testbare betingelser

eksempler:

"Hver server inden for området vises i opgørelsen, har en aktuel agent og viser ingen kritiske, ikke-opdaterede sårbarheder, der er ældre end 14 dage."
"Enhver server med en forsinket patch har enten en åben, godkendt undtagelse eller en afhjælpningsticket med en ejer og SLA."
"Hver lejer har mindst to unikke globale administratorer med MFA håndhævet; ingen generiske konti har administratorroller."

Dette trin skaber broen mellem politikord og værktøjslogik.

4. Byg dashboards, forespørgsler og regler i dine værktøjer

Implementer disse betingelser på dine platforme:

Dashboards i RMM og sårbarhedsværktøjer, der afdækker ikke-kompatible aktiver og giver teams mulighed for at gå i dybden.
SIEM-korrelationsregler eller planlagte rapporter, der fremhæver politikrelevante anomalier, såsom nye privilegerede konti uden MFA eller store ændringer uden for ændringsvinduer.
Arbejdsgange for billetbehandling, der håndhæver godkendelser og registrerer de rigtige felter, når bestemte kategorier hæves.

Nu handler "kontrol af overholdelse" om at se på livevisninger, ikke at sammensætte ad hoc-regneark.

5. Omdan fejl til meningsfulde sager

Når noget ikke består testen, bør det oprette en sag, som nogen kan reagere på:

Mærk billetter med den regel og kontrol, de vedrører (for eksempel "ISO 27001 A.5.36 – privilegeret adgang").
Inkluder kontekst: kundenavn, aktiv-ID, alvorlighedsgrad, hvor længe bruddet har været og links til eventuelle relaterede undtagelser.
Sæt realistiske SLA'er og ejere, så disse billetter ikke begraves under støj af lav værdi.

Det er den del, A.5.36 er interesseret i: Du opdager ikke kun brud på dine egne regler, du retter dem også på en kontrolleret måde.

6. Gem tilstrækkelig historik til at vise tendenser og læring

Beviser for, at kontroller fungerer, kommer fra historien:

Gem dashboards, rapporter og tickets længe nok til at vise forbedringer eller tilbagevendende temaer og til at understøtte interne revisioner.
Brug en håndfuld velvalgte cases – inklusive mindst ét ubehageligt eksempel – i ledelsesvurderinger, leverandørdue diligence og kundemøder for at vise, at brud på politikker fører til handling og læring.

Over tid opbygger dette mønster et katalog af maskintjekkelige regler, der dækker privilegeret adgang, backupverifikation, EDR-implementering, logdækning og mere. ISMS.online hjælper ved at forbinde disse kontroller og deres beviser tilbage til dine politikker, risici og Annex A-kontroller, så du kan præsentere dem som en del af et sammenhængende informationssikkerhedsstyringssystem, ikke en bunke af usammenhængende skærmbilleder.

Hvordan kan en MSP forvandle ISO 27001 A.5.36 til en klar kommerciel fordel med ISMS.online?

Du forvandler A.5.36 til en kommerciel fordel ved roligt at kunne lede revisorer og kunder fra "her er reglen" til "sådan håndhæver vi den, og hvad vi gør, når den ikke overholdes" – og ved at gøre det fra et enkelt, struktureret miljø, kan du genbruge den på tværs af revisioner, udbud og evalueringer. ISMS.online er bygget til at være det miljø.

Hvordan ser det ud i revisioner, udbudsanmodninger og kundeanmeldelser?

Tre vaner får konsekvent MSP'er til at skille sig ud.

Brug én kortlagt visning fra regel til tjeneste til bevismateriale

I stedet for at jonglere med mapper og regneark, når nogen nævner A.5.36:

Vedligehold en enkelt, struktureret register af politikker, standarder og servicespecifikke regler i ISMS.online, med navngivne ejere, omfang og tilknyttede evidenskilder.
Forbind hver regel med relevante kontroller, risici, interne revisioner og korrigerende handlinger i bilag A ved hjælp af tilknyttet arbejde.
Når en revisor eller virksomhedskunde spørger, skal du åbne kortet og derefter klikke på et par live-eksempler – få adgang til anmeldelser, ændringssager, bekræftelser på træning – for at vise vejen fra skriftlig regel til faktisk adfærd.

Dette niveau af sporbarhed får dig til at ligne en MSP, der kører på et rigtigt ISMS, ikke kun på gode intentioner.

Vis, hvordan du reagerer, når regler brydes

Købere ønsker i stigende grad at forstå, hvordan du opfører dig på dårlige dage:

Brug ISMS.online til at føre en struktureret log over politikbrud og undtagelser med felter for påvirkning, rodårsag, ejer, behandling og lukning.
Medbring et par omhyggeligt redigerede cases til møder for at vise, hvordan problemer blev opdaget, hvad I gjorde med det samme, og hvordan I styrkede kontrollen eller træningen bagefter.

Håndteret godt opbygger disse eksempler tillid; de viser, at du behandler A.5.36 som en levende disciplin, ikke et marketingslogan.

Genbrug dit A.5.36-arbejde på tværs af frameworks og kunder

Fordi ISMS.online understøtter ISO 27001 og Annex L-tilpassede integrerede ledelsessystemer, spiller hver forbedring, du foretager til A.5.36, en dobbelt rolle:

Andre rammer og regler: – SOC 2, NIS 2, DORA eller sektorspecifikke standarder stiller ofte lignende spørgsmål om, hvordan du følger dine egne regler; du kan svare ud fra de samme linkede registre.
Udbudsanmodninger og cyberforsikring: – sikkerhedsspørgeskemaer, der undersøger overholdelse af politikker, kan ofte besvares ved at eksportere eller opsummere din eksisterende ISMS.online-dokumentation.
Kundeanmeldelser og QBR'er: – du kan genbruge dele af din A.5.36-evidenspakke til at vise, hvordan du beskytter hver kundes miljø over tid, ikke kun ved certificeringsmilepæle.

Hvis du ønsker at blive set som den MSP, der "faktisk kan vise, hvordan de arbejder", giver det mening at give dit team en platform, der er designet til det niveau af gennemsigtighed. At undersøge, hvordan ISMS.online kan understøtte din A.5.36-tilgang – sammen med dit bredere informationssikkerhedsstyringssystem og ethvert integreret styringssystem i Annex L-stil – er en praktisk måde at gå fra grundlæggende certificering til en mere forsvarlig, kommerciel historie om, hvordan du driver sikkerhed for dig selv og dine kunder.

A.5.36 Overholdelse af politikker, regler og standarder for informationssikkerhed – MSP Assurance