ISO 27001-certificering: byg et ISMS, der holder

En kunde beder om jeres ISO 27001-certifikat. Den kommercielle frist er klar; implementeringsarbejdet er det måske ikke. Ledelsens første beslutning er, om man vil bygge et ledelsessystem for informationssikkerhed, som forretningen kan opretholde, eller organisere et midlertidigt projekt omkring en auditdato.

En brugbar certificeringsplan begynder med at definere det system, I har brug for at drive, og tilrettelægger derefter den evidens, der påviser det. Det betyder at beslutte, hvilke ydelser certifikatet skal dække, hvem der kan godkende risikobeslutninger, hvilke ressourcer kontrolejerne har brug for, og hvordan ledelsen vil vide, om kontrollerne virker.

Certifikatet er en vigtig leverance. Det varige forretningsaktiv er et ledelsessystem for informationssikkerhed, et ISMS, der forbliver nyttigt, når medarbejdere fratræder, leverandører skiftes, nye produkter lanceres, og kunderne stiller sværere spørgsmål.

Hvad en ISO 27001-certificering faktisk fastslår

ISO/IEC 27001 specificerer krav til at etablere, implementere, vedligeholde og løbende forbedre et ISMS. Formålet er at styre risici for informationens fortrolighed, integritet og tilgængelighed i organisationens kontekst.

Fortrolighed handler om upassende videregivelse, såsom at kundeposter bliver tilgængelige for uautoriserede brugere. Integritet handler om unøjagtige eller uautoriserede ændringer, såsom at nogen ændrer betalingsinstruktioner. Tilgængelighed handler om adgang, når der er behov for det, såsom at genoprette en vigtig tjeneste efter et infrastruktursvigt.

Certificeringen vedrører dette ledelsessystem inden for dets angivne scope. Den garanterer ikke, at alle produkter er fri for sårbarheder, at hændelser ikke kan indtræffe, eller at alle forretningsenheder er blevet vurderet. Et certifikat, der dækker én administreret tjeneste, bør ikke fremstilles som sikkerhed for et produkt, der intet har med den at gøre.

ISO og IEC udgiver standarden; de certificerer ikke jeres organisation. Et uafhængigt certificeringsorgan foretager vurderingen og træffer certificeringsbeslutningen. Af hensyn til kundernes tillid er det en praktisk anbefaling at vælge et organ, der er akkrediteret til den relevante ISMS-certificeringsaktivitet, og at bekræfte, at dets certificering vil opfylde køberens krav.

Skellet mellem overensstemmelse og certificering betyder også noget. En organisation kan implementere et ISMS, der opfylder standarden, uden at søge ekstern certificering. Certificering tilføjer en uafhængig vurdering og et formelt certifikat. At købe software, ansætte en kvalificeret implementeringsekspert eller gennemføre et kursus giver ikke organisationen en certificering.

Afgør, om certificering løser det forretningsmæssige problem

Certificering er særlig relevant, når indkøbskrav, kontraktlige forpligtelser, følsom information eller driftsmæssige afhængigheder berettiger uafhængig sikkerhed. Det er ikke en universel lovpligt for alle virksomheder.

Før I forpligter jer, så bed salgs- og kundeteams om at identificere det faktiske krav. Kræver køberen et certifikat før kontraktunderskrivelse, før adgang til produktion eller ved fornyelse? Skal det dække en navngiven tjeneste eller juridisk enhed? Vil køberen stadig kræve et sikkerhedsspørgeskema, testrapporter eller yderligere kontraktlige kontroller?

Svarene påvirker investeringsprioriteterne. Et certifikat kan understøtte indkøbsprocessen, men det fjerner ikke al due diligence. Undgå at budgettere med omsætning ud fra en antagelse om, at certificering automatisk afslutter enhver kundes sikkerhedsgennemgang.

Adskil certificering fra regulatorisk analyse. Et ISMS kan understøtte evidens og governance, der er relevant for andre forpligtelser, men certificering dokumenterer ikke overholdelse af GDPR eller NIS2. Disse regelsæt har deres egne regler for anvendelsesområde og deres egne pligter. NIS2 gennemføres via national lovgivning; pligterne efter GDPR afhænger af behandlingsaktiviteter og organisatoriske roller.

Ledelsens beslutningsgrundlag bør derfor identificere tre ting: den sikkerhed, kunderne har brug for, de informationsrisici, forretningen skal styre, og de løbende driftsomkostninger. Godkend programmet på det grundlag snarere end på et løfte om et certifikat til en vilkårlig dato.

Tegn et scope, som kunderne kan forstå

Scope beskriver ISMS'ets afgrænsning og anvendelighed. Det bør identificere de relevante ydelser, organisatoriske enheder, lokationer, personer, information, systemer og afhængigheder. Det skal også tage højde for grænseflader til aktiviteter uden for afgrænsningen.

Et snævert scope kan være passende, især ved en første implementering. Det skal stadig afspejle, hvad kunderne forventer, at certifikatet dækker. At udelade det team, der administrerer adgangen til produktion, fjerner ikke teamets indflydelse på en kundeydelse inden for scopet.

For en hostet applikation skal I undersøge hele tjenestekæden: udvikling, deployment, produktionsdrift, supportadgang, identitetsadministration, backups og væsentlige eksterne leverandører. Fælles HR- eller IT-processer kan påvirke sikkerheden, selv når scopet er centreret om et produkt og ikke hele virksomheden.

En praktisk scopebeskrivelse bør besvare:

• Hvilken juridisk enhed driver tjenesten?
• Hvilke kundevendte ydelser og hvilken information er omfattet?
• Hvilke lokationer og ordninger for fjernarbejde har betydning?
• Hvilke teams og fælles processer påvirker disse ydelser?
• Hvilke leverandører leverer infrastruktur eller håndterer relevant information?
• Hvad ligger uden for afgrænsningen, og hvordan styres grænsefladerne?

Test den foreslåede formulering med en kollega, der har kundekontakt. Hvis vedkommende ikke kan forklare, om kundens ydelse er omfattet, skal formuleringen forbedres.

Optimér ikke scopet alene for at nedbringe auditomkostningerne. En mindre afgrænsning kan skabe komplicerede grænseflader og lade det kommercielle krav stå ubesvaret. Omvendt kan det skabe unødvendig koordinering at inkludere alle koncernselskaber med det samme. Den rigtige afgrænsning er forsvarlig, forståelig og driftsmæssigt håndterbar.

Registrér begrundelsen og de udløsere, der giver anledning til at genoverveje den, såsom opkøb af en virksomhed, flytning af infrastruktur eller lancering af en væsentligt anderledes tjeneste. Scopet bør forblive en ledelsesbeslutning, ikke et glemt afsnit.

Giv programmet bemyndigelse, ikke kun en ejer

Udpeg en implementeringsansvarlig og en ansvarlig sponsor i ledelsen. De har forskellige ansvarsområder. Den implementeringsansvarlige koordinerer arbejdet og sikrer overblikket; sponsoren afklarer prioriteter, godkender ressourcer og sikrer, at sikkerhedsmålene passer til forretningsbeslutningerne.

Ejerskab af kontroller bør følge den driftsmæssige bemyndigelse. HR kan eje ansættelsesrelaterede procedurer, IT kan eje enhedsadministration, udvikling kan eje udviklingspraksis, og indkøb kan koordinere leverandørvurderinger. Compliance-ansvarlig bør ikke blive formelt ansvarlig for processer, vedkommende ikke kan ændre.

Definér, hvem der kan acceptere restrisiko og på hvilket niveau. En ydelsesejer kan anbefale at acceptere en begrænset driftsmæssig eksponering, mens en risiko, der påvirker vigtige kundeforpligtelser, kan kræve godkendelse fra direktionen. Registrér beslutningen, begrundelsen, betingelserne og datoen for gennemgang.

Ledelsen skal også beskytte kapaciteten til implementering. At tildele arbejde uden at give plads til det skaber forudsigelige forsinkelser. Bed ejerne om den nødvendige indsats, afhængigheder og afvejninger; godkend derefter en realistisk plan.

Ledelsens evaluering er der, hvor ledelsen vurderer systemet og træffer beslutninger om forbedringer, ændringer og ressourcer. Et underskrevet mødereferat uden meningsfulde beslutninger har ringe praktisk værdi. Evalueringen bør blotlægge uafklarede valg, ikke blot godkende et grønt dashboard.

Forstå kravene, før I køber en tjekliste

Kravene i punkt 4–10 i ISO/IEC 27001 udgør kernen i ledelsessystemet. De kan ikke udelades, når man påberåber sig overensstemmelse. Deres praktiske resultater er adskilt fra implementeringen af de enkelte sikkerhedskontroller.

Anneks A i 2022-udgaven indeholder 93 referencekontroller: 37 organisatoriske, otte personrelaterede, 14 fysiske og 34 teknologiske kontroller. Anvendeligheden er risikobaseret; der findes ikke et universelt antal, som alle virksomheder bør implementere.

Fastlæg de kontroller, der er nødvendige for risikohåndteringen, og sammenlign dem derefter med Anneks A for at kontrollere, at nødvendige kontroller ikke er blevet overset. Kontroller kan også komme fra kontraktlige krav, andre kilder eller jeres eget design. Anneks A er hverken en erstatning for risikovurdering eller et udtømmende katalog over alle tænkelige sikkerhedsforanstaltninger.

Anvendelseserklæringen (Statement of Applicability, SoA) registrerer de nødvendige kontroller, begrundelsen for at medtage dem, deres implementeringsstatus og begrundelsen for at udelade kontroller fra Anneks A. Bevar tilstrækkelig sporbarhed til at kunne forklare, hvordan disse beslutninger hænger sammen med risikohåndteringen og andre krav.

ISO 27002 giver vejledning om informationssikkerhedskontroller; ISO 27001 leverer de certificerbare krav til ledelsessystemet. Brug vejledningen til at forstå mulighederne for implementering, men tilpas procedurerne til jeres organisation i stedet for at importere en driftsmodel, I ikke kan opretholde.

Byg risikohåndteringen, før I samler evidens

Begynd med en gentagelig metode til risikovurdering. Definér, hvordan risici identificeres, hvordan sandsynlighed og konsekvenser vurderes, hvordan resultaterne sammenlignes, og hvilke kriterier der afgør, hvad der er acceptabelt. Konsekvent fortolkning betyder mere end en kompliceret scoringsformel.

Beskriv risici som scenarier. „Cloudrisiko“ er for vagt til at understøtte en beslutning. „En administratorkonto bliver kompromitteret og brugt til at eksportere kundeposter“ identificerer en hændelse, berørt information og en forretningsmæssig konsekvens.

Inddrag de mennesker, der forstår tjenesten. De kan forklare eksisterende sikringsforanstaltninger, supportadgang, leverandørafhængigheder, begrænsninger i genoprettelsen og omveje, som et generisk risikobibliotek kan overse. For en praktisk struktur for posterne, se vores guide til et operationelt risikoregister.

Registrér for hver betydelig risiko ejeren, vurderingen, de nuværende kontroller, beslutningen om håndtering, det tilsigtede resultat og vurderingen af restrisikoen. Mulige tilgange til håndtering omfatter at reducere eksponeringen, at undgå en aktivitet, at dele aspekter af risikoen eller at acceptere den efter definerede kriterier. Forsikring eller outsourcing fjerner ikke alle konsekvenser eller alt ansvar.

Omsæt håndteringen til arbejde med klart ansvar. „Forbedr adgangssikkerheden“ er ikke en eksekverbar plan. Angiv de berørte systemer, den nødvendige ændring, ejeren, kriterierne for afslutning, og hvordan effektiviteten skal evalueres.

Hold disse registreringer adskilt:

De bør stemme overens uden at blive kopier af hinanden. Hvis en håndtering afhænger af overvågning af leverandører, men den tilhørende kontrol er udeladt uden forklaring, så løs uoverensstemmelsen før forberedelsen til audit.

Gennemgå risici med planlagte intervaller, og når der sker væsentlige ændringer. En ny supportleverandør, udvidet dataindsamling, en hændelse eller en større arkitekturændring kan gøre en tidligere beslutning forældet.

Gør kontrollerne til en del af den almindelige drift

En politik angiver forventninger; en procedure forklarer, hvordan arbejdet foregår; driftsregistreringer påviser, hvad der faktisk skete. Forberedelsen til certificering har brug for alle tre, hvor de er relevante.

En adgangspolitik bør for eksempel være forbundet med en implementeret proces for tiltrædelse og fratrædelse, stikprøver af adgangsændringer og en gennemgang af undtagelser. Et politikdokument alene lader størstedelen af den historie stå ubevist.

Byg processen op omkring de faktiske ansvarsområder. Identificér, hvem der anmoder om adgang, hvem der godkender den, hvem der tildeler den, hvad der sker, når nogens rolle ændres, og hvordan konti fjernes. Medtag servicekonti og eksterne brugere, hvor de påvirker scopet.

Anvend samme tankegang på andre vigtige processer:

• Leverandørvurdering bør forbinde tjenestens kritikalitet, adgang til information, kontraktlige forventninger, resultater af gennemgange og uafklarede bekymringer.
• Hændelseshåndtering bør forbinde rapporteringsveje, ansvar for reaktion, eskalering, genoprettelse og erfaringer.
• Backup og genoprettelse bør forbinde forretningsbehov, beskyttede systemer, gendannelsesprocedurer, testresultater og opfølgende arbejde.
• Ændringsstyring bør forbinde godkendelse, test, deploymentregistreringer, nødændringer og undtagelser.

Fysiske og personrelaterede kontroller betyder stadig noget i en cloudbaseret organisation. Fjernarbejde, beskyttelse af enheder, fortrolige samtaler, ændringer i ansættelsesforhold og bevidsthed kan ikke afvises, fordi serverne er outsourcet.

Fastsæt kontrolfrekvenser efter risiko og driftsbehov. Kopiér ikke et løfte om kvartalsvise gennemgange ind i en politik, medmindre ejeren kan gennemføre dem og bevare registreringerne. En politik, der beskriver en proces, som ingen følger, skaber en unødvendig kløft mellem hensigt og implementering.

Design evidens til inspektion, ikke til volumen

God evidens besvarer et defineret spørgsmål om et krav eller en kontrol. En stor mappe med skærmbilleder er ikke i sig selv stærkere end et mindre, velforklaret sæt pålidelige registreringer.

Angiv for hver vigtig kontrol kildesystem, ejer, indsamlingsmetode, dækning, forventet frekvens og gennemgåer. Skeln mellem evidens for design og evidens for drift. En identitetskonfiguration kan vise, at multifaktorautentificering er slået til; godkendelsesregistreringer og adgangsgennemgange påviser andre aspekter af adgangsstyringen.

Evidens bør gøre sin betydning tydelig:

• Hvilken ydelse, hvilket system eller hvilken population dækker den?
• Hvornår blev den produceret, og hvilken periode repræsenterer den?
• Er den fuldstændig nok til det spørgsmål, der vurderes?
• Hvem har gennemgået den, og hvilke undtagelser blev identificeret?
• Hvilken opfølgning førte disse undtagelser til?

Bevar også mislykkede resultater. En mislykket gendannelsestest med dokumenteret undersøgelse, afhjælpning og en vellykket gentest kan påvise, at overvågning og forbedring fungerer. At slette ubekvemme resultater skader registreringens anvendelighed.

Beskyt evidens som information i sig selv. Eksporter kan indeholde medarbejderoplysninger, kundeidentifikatorer eller følsomme konfigurationer. Begræns adgangen, minimér unødvendigt indhold, og fastlæg opbevaring ud fra relevante forpligtelser og forretningsbehov. Tilrettelæg kontrolleret adgang for auditorer i stedet for at distribuere brede arkiver ukritisk.

Brug intern audit og ledelsens evaluering til at teste paratheden

Intern audit vurderer, om ISMS'et er i overensstemmelse med de gældende krav og effektivt implementeret og vedligeholdt. Den bør dække ledelsessystemet, ikke blot kontrollere tekniske indstillinger.

Planlæg auditens scope, kriterier, metoder og rapportering. Vælg kompetente auditorer, og bevar objektivitet og upartiskhed. En lille organisation kan bruge ekstern støtte eller passende tværfunktionelle ordninger i stedet for at bede én person om at evaluere alt sit eget arbejde.

Brugbar audittest følger en registrering gennem processen. Vælg en medarbejders fratrædelse, og kontrollér underretning, fjernelse af konti, håndtering af udstyr og undtagelser. Vælg en leverandør, og undersøg, om dens risikovurdering svarer til dens faktiske adgang. Vælg en håndteringshandling, og verificér, om den erklærede afslutning har driftsmæssig opbakning.

Registrér fund præcist, herunder kravet, den observerede evidens og manglen. Reducér ikke auditten til en procentsats for færdiggørelse, der skjuler manglende ledelsesprocesser.

Ledelsens evaluering tager derefter stilling til de påkrævede input, herunder præstationer, auditresultater, ændringer, status for risikovurdering og risikohåndtering samt muligheder for forbedring. Forbered et kortfattet beslutningsmateriale med de understøttende registreringer tilgængelige. Forklar, hvor ledelsen skal vælge mellem afhjælpning, yderligere ressourcer, ændrede mål eller godkendt accept af risiko.

For afvigelser skal den umiddelbare korrektion adskilles fra den korrigerende handling. At deaktivere en overset konto korrigerer det umiddelbare problem. At reparere underretningsprocessen og kontrollere efterfølgende fratrædelser adresserer gentagelsen. Registrér årsagen, handlingen, ejeren og evalueringen af effektiviteten.

Forstå trin 1, trin 2 og certificeringsbeslutningen

En første certificering omfatter normalt to audittrin. Aftal ordningerne, de forventede registreringer og forventningerne til parathed med certificeringsorganet tidligt nok til at kunne planlægge ordentligt.

Trin 1 undersøger parathed, scope og dokumentationen af ledelsessystemet. Det hjælper organet med at forstå organisationen og vurdere paratheden til trin 2. Forvent, at sammenhængen mellem scope, risikovurdering, håndtering, anvendelseserklæringen og ledelsesprocesserne bliver undersøgt nøje. Løs de identificerede bekymringer i stedet for at behandle trin 1 som en administrativ booking.

Trin 2 vurderer implementering og effektivitet. Auditorerne bruger interviews, observation og stikprøver af registreringer til at teste, om ISMS'et fungerer som beskrevet. Medarbejderne bør kunne forklare deres faktiske ansvarsområder, ikke fremsige indøvede svar.

Hold anmodningerne organiseret under auditten. Udpeg en koordinator, registrér anmodninger, identificér den rette ejer, og lever relevant evidens med kontekst. Hvis noget mangler, så forklar situationen præcist. Opret ikke registreringer bagudrettet, der fejlagtigt antyder, at en proces har fundet sted.

En afvigelse betyder, at et krav ikke er opfyldt. Større fund påvirker ledelsessystemets evne til at opnå de tilsigtede resultater; mindre fund har ikke den virkning. Klassifikationen afhænger af konteksten, så en enkelt manglende registrering kan ikke på forhånd tildeles en universel betegnelse.

Certificeringsorganet fastlægger uafhængigt fund, krævede svar, ordninger for verifikation og certificeringsbeslutningen. Bekræft dets frister og krav til opfølgning på forhånd. En auditors anbefaling er ikke i sig selv et udstedt certifikat, og uafklarede fund kan forsinke beslutningen.

Efter certificeringen omfatter en typisk cyklus overvågningsaudits i de mellemliggende år og gencertificering, før det treårige certifikat udløber. Bekræft det konkrete auditprogram og betingelserne med jeres organ. Overvågning er ikke en tilladelse til at sætte ISMS'et på pause mellem besøgene.

Planlæg tidsplan og budget omkring afhængigheder

Varigheden afhænger af modenhed, scope, uafklarede risici, tilgængelighed af evidens, intern kapacitet og auditorernes planlægning. Der findes ingen universel periode med driftsevidens for ISO 27001, der automatisk gør enhver organisation parat.

Spørg certificeringsorganet, hvad det har brug for at tage stikprøver af i jeres situation. En proces, der udføres månedligt, producerer registreringer anderledes end en årlig øvelse. Vent ikke, til auditten er booket, med at opdage, at en vigtig kontrol aldrig er blevet udført.

Adskil det arbejde, I kan fremskynde – indsamling, koordinering, udarbejdelse af udkast og forberedelse af gennemgange – fra det arbejde, der kræver implementering og påvist drift. Parallelisér uafhængige opgaver, men bevar afhængighederne: En anvendelseserklæring kan ikke færdiggøres troværdigt uden begrundelsen for valget af kontroller, og effektiviteten kan ikke evalueres alene ud fra en foreslået politik.

Brug paratheds-gates i stedet for én optimistisk slutdato:

Budgettér med intern indsats, afhjælpning, værktøjer, træning, valgfri rådgivning og ekstern vurdering. Medtag overvågningsaudits, gencertificering og løbende vedligeholdelse, ikke kun fakturaen for den første audit.

Bed certificeringsorganerne om at forklare deres antagelser om personale, lokationer, aktiviteter, kompleksitet og auditordninger. Sammenlign hele cyklussen og gebyrer for opfølgning. Undgå at behandle et lavt første tilbud som den fulde omkostning ved at drive et certificeret ISMS.

Gennemregnet eksempel: én tjeneste, én bæredygtig plan

Forestil dig, som illustration, en virksomhed med 30 medarbejdere, der driver en hostet tjeneste til deling af dokumenter. Antag, at den allerede har identitetsstyring, godkendelser af deployments og backups, men at leverandørgennemgange og registreringer af adgangsgennemgange er inkonsekvente. Den potentielle kunde ønsker sikkerhed for den hostede tjeneste, herunder supportadgang.

Ledelsen afgrænser scopet til tjenesten og de understøttende udviklings-, drifts- og supportprocesser. Den registrerer grænsefladerne til HR og fælles IT i stedet for at udelade deres sikkerhedsmæssige betydning. Den administrerende direktør er sponsor for programmet; en implementeringsansvarlig koordinerer det; driftsledere ejer kontrollerne.

Teamet identificerer et scenarie, hvor for brede supportrettigheder eksponerer kundernes dokumenter. Håndteringen omfatter begrænsede supportroller, godkendt midlertidig rettighedsforøgelse, adgangsgennemgange og overvågning, der passer til tjenesten. Anvendelseserklæringen registrerer de nødvendige kontroller og deres implementeringsstatus.

Adgangsejeren indsamler derefter en rollekonfiguration, stikprøver af godkendelsesregistreringer, en gennemført gennemgang og evidens for, at for brede rettigheder, der blev opdaget under gennemgangen, er fjernet. Disse registreringer fastslår mere end blot eksistensen af en adgangspolitik.

Under den interne audit findes en fratrådt ekstern konsulent med en aktiv konto. Teamet deaktiverer den, undersøger den manglende underretning fra HR til IT, tilføjer et eksplicit trin for fratrædelse af eksterne konsulenter og kontrollerer senere fratrædelser for at evaluere effektiviteten. Ledelsens evaluering tager stilling til fundet, de resterende risici og de ressourcer, der er nødvendige til løbende gennemgange.

Alene til budgetplanlægning: Antag, at otte bidragydere hver bruger to timer om ugen i tolv uger. Det giver 192 interne timer, før specialiseret afhjælpning og deltagelse i audit. Det er en illustrativ kapacitetsberegning, ikke et markedsestimat eller et løfte om certificering.

Læren er ledelsesmæssig: Tildel arbejdet til mennesker med bemyndigelse, reservér kapacitet, og lad paratheden afhænge af evidens. Eksisterende tekniske sikringsforanstaltninger mindsker en del af implementeringsarbejdet, men de erstatter ikke risikobeslutninger, intern audit eller ledelsens evaluering.

Automatisér gentageligt arbejde, og bevar den faglige vurdering

Automatisering kan understøtte opdatering af fortegnelser, indsamling af evidens, påmindelser, tekniske kontroller og rapportering. Prioritér tilbagevendende arbejde med pålidelige kildedata og en klar gennemgåer frem for at automatisere en uklar proces.

En automatiseret kontrol kræver defineret dækning og fejlhåndtering. Hvis en forbindelse holder op med at indsamle registreringer, skal man skelne mellem „intet problem fundet“ og „ingen aktuelle data“. Bekræft, at kilden dækker de relevante systemer, konti eller lokationer, før I forlader jer på resultatet.

Hold den menneskelige vurdering eksplicit for accept af risiko, kontrollers anvendelighed, konklusioner om evidens og ledelsesbeslutninger. En konfigurationskontrol kan vise, at kryptering er slået til; den fastslår ikke, at nøgleadgang, genoprettelse og ekstraordinære dataveje styres hensigtsmæssigt.

På samme måde kan automatisering af arbejdsgange organisere anmodninger og fund fra den interne audit, men den leverer ikke auditkompetence eller uafhængighed. AI-genererede resuméer og mappings bør forblive udkast, indtil en gennemgåer har kontrolleret kilderne og godkendt konklusionerne.

Mål både effektivitet og virkning: tid brugt på at forberede evidens, forsinkede korrigerende handlinger, ufuldstændig dækning, gentagne fejl og den tid, det tager at løse vigtige undtagelser. Vores guide til ISMS-målinger forklarer, hvordan målinger gøres nyttige for ledelsesbeslutninger.

Hold ejerskabet aktivt efter certificeringen

Fastlæg vedligeholdelseskalenderen, før certifikatet kommer. Praktiske anbefalinger omfatter regelmæssige kontroller hos ejerne, risikogennemgange udløst af væsentlige ændringer, planlagte evalueringer af kontroller, interne audits, ledelsens evalueringer og forberedelse til eksterne vurderinger. Vælg frekvenser ud fra processen og risikoen i stedet for at gøre alle aktiviteter månedlige.

Fordel ansvaret på ny, når medarbejdere skifter stilling eller fratræder. Gennemgå scope og kontrollers anvendelighed, når forretningen ændrer sig. Følg tilbagevendende undtagelser: Gentagne forsinkede fjernelser af adgang tyder på et procesproblem, selv om hver enkelt sag til sidst bliver lukket.

Secani understøtter denne arbejdsgang ved at forbinde krav, kontroller, evidens, ejere, opgaver og beslutninger fra gennemgange i et fælles workspace. Begynd med én repræsentativ tjeneste, modellér dens systemer og afhængigheder, knyt eksisterende evidens til det, den beviser, og gør mangler til tildelte opgaver. Gennemgå AI-understøttede forslag i forhold til deres kilder, og bevar menneskelige godkendelser og beslutningshistorik. Det hjælper teamet med at fastholde det, det lærer under certificeringen, efterhånden som systemerne ændrer sig; certificeringen forbliver det uafhængige organs beslutning.

Spørgsmål, der ændrer implementeringsplanen

Kræver ISO 27001 en penetrationstest?

Der findes ikke noget universelt punkt i ISO 27001, der kræver, at alle organisationer gennemfører en penetrationstest. Den nødvendige test afhænger af risikohåndtering, gældende kontroller, tjenestens karakteristika og kontraktlige krav. Hvor test er nødvendig, så definér dækning, afhjælpning og gentest i stedet for blot at gemme en rapport.

Bør vi i stedet gå efter SOC 2?

Spørg, hvad kunderne kræver, og hvilket scope de forventer. SOC 2 giver en erklæringsrapport; ISO 27001 giver en certificering af ledelsessystemet. Noget af driftsevidensen kan muligvis genbruges, men ingen af dem kan automatisk omsættes til den anden. Evaluer de separate krav, før I forpligter jer til begge.

Har vi brug for en ekstern konsulent?

Ikke nødvendigvis. Ekstern hjælp kan afhjælpe behov for fortolkning, kapacitet eller specialviden. Bevar det interne ejerskab, og sørg for, at procedurerne forbliver brugbare, når samarbejdet ophører. En persons certificering som implementeringsekspert eller auditor certificerer ikke vedkommendes arbejdsgiver.

Begynd med en beslutning og et evidensspor

Godkend et kort implementeringscharter, der angiver det kommercielle behov, det tilsigtede scope, sponsoren, den implementeringsansvarlige, kontrolejerne, kapaciteten og paratheds-gates. Tag derefter én vigtig tjeneste, og følg en kontrol fra krav til risikohåndtering, implementering, evidens og gennemgang.

Den første sporing vil afsløre uklart ansvar og manglende registreringer, før de mangedobles. Brug vores ISO 27001-tjekliste til at organisere det resterende arbejde, og hold samtidig kravene til ledelsessystemet og kontrollernes anvendelighed adskilt.

Et varigt ISMS gør sikkerhedsbeslutninger inspicerbare og gentagelige. Certificeringen anerkender systemet inden for dets scope; ledelsen holder det i drift, efter at auditteamet er gået.