ISO 27001 bilag A: gør de 93 kontroller operationelle

Bilag A giver sikkerhedsteams et nyttigt referencesæt. Dets operationelle værdi kommer af at vise, hvorfor en kontrol finder anvendelse, hvordan den er implementeret, og hvilken dokumentation der understøtter den i jeres miljø. Et register med 93 grønne statusindikatorer er ikke nok, hvis ingen kan forklare, hvilke systemer indikatorerne dækker.

For en CTO er den praktiske udfordring at omsætte kontrollernes hensigt til ingeniør- og driftsarbejde uden at gøre ledelsessystemet for informationssikkerhed til et parallelt bureaukrati. Adgangsgennemgange bør bruge reelle rettighedsdata. Genopretningsplaner bør afspejle afhængighederne mellem tjenester. Leverandørvurderinger bør omhandle de tjenester, virksomheden faktisk bruger.

Denne guide forklarer, hvordan man vælger kontroller, fordeler ejerskab, definerer implementeringer og tester de påstande, der følger af dem. Gennemgangsfrekvenserne og implementeringseksemplerne nedenfor er praktiske anbefalinger, ikke universelle intervaller, som standarden foreskriver.

Forstå, hvad bilag A gør, og hvad det ikke gør

ISO/IEC 27001:2022 indeholder 93 kontroller i bilag A fordelt på fire temaer. Punkt 4–10 indeholder kravene til ledelsessystemet: organisationens kontekst, lederskab, planlægning, støtte, drift, evaluering af præstationer og forbedring. Bilag A understøtter valget af kontroller; det erstatter ikke disse krav eller jeres risikovurdering.

Skelnen har betydning under implementeringen. En backupkonfiguration kan understøtte en valgt kontrol, men den dokumenterer ikke, at I har defineret ISMS'ets omfang, vurderet risici, gennemført en intern audit eller afsluttet ledelsens evaluering. Det er separate aktiviteter med separat dokumentation.

Valget af kontroller er risikobaseret. Fastlæg de kontroller, der er nødvendige for at behandle jeres risici, og sammenlign dem derefter med bilag A for at kontrollere, at ingen nødvendige kontroller er udeladt. Yderligere kontroller uden for bilag A kan være nødvendige. Omvendt er en begrundet udeladelse mulig; der er ingen regel om, at alle organisationer skal udelade noget eller implementere præcis det samme udvalg.

ISO/IEC 27002:2022 giver implementeringsvejledning til kontrollerne. Dens attributter hjælper med at organisere dem efter kontroltype, informationssikkerhedsegenskab, cybersikkerhedskoncept, operationel kapabilitet og sikkerhedsdomæne. Det er nyttige filtreringshjælpemidler, ikke yderligere certificeringstjeklister. Se de licenserede standarder for den autoritative ordlyd.

Brug de fire temaer til at finde de rette ejere

Temaerne giver en navigationsstruktur, ikke fire uafhængige arbejdsspor. En fratrædelsesproces forbinder for eksempel ansættelsesmæssige ansvarsområder, identitetsadministration, returnering af udstyr og adgang til applikationer.

Organisatoriske kontroller: forbind styring med driftsbeslutninger

Disse kontroller omfatter politikker, ansvarsområder, funktionsadskillelse, aktiver, klassificering og håndtering af information, styring af adgang, leverandører, hændelser, kontinuitet, retlige forpligtelser og gennemgangsaktiviteter.

Begynd med at identificere, hvor beslutningerne træffes. Hvem godkender en ny cloudtjeneste? Hvem tildeler en informationsklassificering? Hvem afgør, om en indberettet hændelse er en sikkerhedshændelse? En politik bør gøre disse beslutninger gentagelige og tildele beføjelser i stedet for blot at udtrykke støtte til sikkerhed.

Leverandørsikkerhed kræver en tjenestespecifik dokumentationskæde: tjenestens forretningsmæssige formål, de oplysninger den håndterer, vurderede risici, kontraktlige ansvarsområder og løbende gennemgang. En leverandørs erklæringsrapport kan understøtte vurderingen, men dens omfang, periode og kundeansvar skal svare til jeres brug.

Hændelsesstyring kræver ligeledes mere end en liste over nødkontakter. Definer indberetningsveje, vurderingskriterier, beføjelser til at reagere, håndtering af beviser og læringsaktiviteter. Registrer øvelser eller faktiske reaktioner, herunder opfølgende handlinger og ejere.

Personrelaterede kontroller: gør ansættelseshændelser til pålidelige udløsere

De otte personrelaterede kontroller omhandler screening, ansættelsesvilkår, awareness og uddannelse, disciplinære processer, ansvar efter ændringer i ansættelsen, fortrolighed, fjernarbejde og indberetning af hændelser.

Indbyg dem i de eksisterende ansættelsesprocesser. En nyansat har brug for passende forpligtelser, adgang og instruktion. En medarbejder, der skifter rolle, har brug for, at rettighederne revurderes, ikke blot udvides. En fratrædende medarbejder kræver fjernelse af adgang, returnering af aktiver og klarhed om fortsatte fortrolighedsforpligtelser.

Ejerskabet går ofte på tværs af teams. HR kan igangsætte en fratrædelse, identitetsadministratorer deaktiverer den centrale konto, applikationsejere fjerner lokalt administreret adgang, og en leder bekræfter, at det er gennemført. Hvis hele processen tildeles sikkerhed, skjules disse afhængigheder.

Nyttig dokumentation omfatter godkendte registreringer i arbejdsgangen, gennemført uddannelse og forsinket opfølgning, accepterede vilkår og stikprøver af ansættelsesændringer. Begræns adgangen til følsom HR-dokumentation; en kontrolbedømmer har ikke automatisk brug for fulde personalesager.

Fysiske kontroller: dokumenter jeres egen afgrænsning og leverandørens

Fysiske kontroller omhandler lokaler, adgang, overvågning, miljømæssige trusler, sikre områder, skriveborde og skærme, udstyr, medier, forsyninger, kabelføring, vedligeholdelse og bortskaffelse.

En cloud-first organisation skal stadig tage stilling til fysisk sikkerhed. En del af implementeringen kan leveres af en cloudleverandør, mens adgang til kontoret og medarbejdernes enheder forbliver organisationens eget ansvar. Registrer denne fordeling i stedet for automatisk at udelade hele temaet.

For jeres egne lokationer skal det identificeres, hvem der kan komme ind, hvordan adgang ændres, hvor følsomt udstyr står, og hvordan besøgende håndteres. For enheder, der bruges eksternt, skal der defineres ordninger for opbevaring, transport, reparation og bortskaffelse, der passer til deres risici.

Dokumentation kan omfatte registreringer af adgangsautorisation, procedurer for besøgende, udstyrsfortegnelser og registreringer af bortskaffelse. Leverandørdokumentation bør forklare, hvilke faciliteter og tjenester der er dækket; den bør ikke betragtes som bevis for kontrollerne på jeres kontor eller bærbare computere.

Teknologiske kontroller: definer dækningen, før I vælger værktøjer

Det teknologiske tema omfatter endpoints, privilegeret adgang, autentificering, adgang til kildekode, kapacitet, malware, sårbarheder, konfigurationer, datahåndtering, backups, robusthed, logning, overvågning, netværk, kryptografi, udvikling og ændringsstyring.

Begynd med systemdækningen. En identitetspolitik er ufuldstændig, hvis produktionsadgang, servicekonti eller en separat administreret applikation falder uden for implementeringen. En logningsplatform er ufuldstændig, hvis kritiske hændelser aldrig når frem til den, eller ingen reagerer på alarmer.

For softwareudvikling skal krav og designbeslutninger forbindes med kodegennemgang, sikkerhedstest, adskillelse af miljøer, håndtering af testdata og godkendelse af releases. Trusselsmodellering kan hjælpe med at identificere sikkerhedskrav før implementeringen. Testdybden bør følge risiko og forpligtelser; ISO 27001 pålægger ikke en universel tidsplan for penetrationstest.

For kryptografi skal data i hvile skelnes fra data under overførsel, og nøgleejerskab, adgang, genopretning, rotation og tilbagekaldelse skal dokumenteres. »Kryptering aktiveret« efterlader vigtige implementeringsspørgsmål ubesvarede.

Hvad ændrede sig i 2022, og hvor skal man lede efter mangler

Udgaven fra 2013 havde 114 kontroller i 14 domæner. Udgaven fra 2022 omorganiserede dem til 93 kontroller i fire temaer, herunder 11 nye kontroller. Et lavere antal betyder ikke mindre sikkerhedsarbejde: Konsolidering kan samle flere operationelle ansvarsområder under én reference.

Når et ældre register opdateres, skal de underliggende implementeringer og dokumentationen bevares i stedet for blot at udskifte identifikatorer. Kontroller, om den nye gruppering ændrer dækning, ejerskab eller de test, der skal understøtte jeres status.

Overgangsfristen for akkrediteret certificering efter ISO/IEC 27001:2013 var den 31. oktober 2025. Disse certifikater er ikke længere gyldige; en opdatering af kontrolregistret alene etablerer ikke certificering efter 2022-udgaven.

Det følgende er praktiske udgangspunkter for de 11 nye kontroller, ikke gengivelser af deres autoritative tekst.

Undgå at behandle dem som elleve automatiske produktkøb. Trusselsefterretninger kræver for eksempel analyse og handling, ikke blot et abonnement på et feed. Sletning af data kræver en forståelse af kopier, backups og opbevaringsforpligtelser, ikke blot en sletteknap. Overvågning kræver en operationel reaktionsvej.

Registrer anvendelighed og implementering hver for sig

Jeres anvendelseserklæring (Statement of Applicability, SoA) bør identificere nødvendige kontroller, forklare hvorfor de er medtaget, registrere om de er implementeret, og begrunde udeladelser af kontroller i bilag A. Disse krav hører under bestemmelserne om risikobehandling i ISO/IEC 27001.

At bruge alle 93 referencer som gennemgangsindeks er en praktisk måde at gøre sammenligningen efterprøvbar på. Medtag også eventuelle yderligere nødvendige kontroller. SoA'en er ikke risikoregistret, behandlingsplanen eller dokumentationsarkivet, selvom den bør forbindes med hver af dem, hvor det er relevant.

Registrer for hver kontrol, der finder anvendelse:

• De risici eller forpligtelser, der begrunder, at den er medtaget.
• Relevante systemer, lokationer, oplysninger og processer.
• Den faktiske implementering og den ansvarlige ejer.
• Understøttende dokumentation og dens gennemgangsperiode.
• Afhængigheder, undtagelser og uafsluttet arbejde.
• Næste gennemgangsdato eller hændelsesudløser.

Hold anvendelighed adskilt fra leverancestatus. »Finder anvendelse, delvist implementeret« er en ærlig og nyttig registrering. »Finder ikke anvendelse, fordi vi ikke har købt et værktøj« er ikke en begrundelse for anvendelighed.

En udeladelse bør beskrive de faktiske forhold i omfanget, der gør kontrollen unødvendig, og være i overensstemmelse med risikovurderingen. »Vi udvikler ikke software« kræver nærmere granskning, hvis en underleverandør udvikler jeres kundeportal. Outsourcing ændrer implementerings- og dokumentationsvejen; den fjerner ikke automatisk risikoen.

Ved distribuerede implementeringer skal fordelingen registreres. En kontrol for fysisk beskyttelse kan afhænge af hostingfaciliteter drevet af en leverandør, adgang til kontoret administreret af virksomheden og medarbejdernes håndtering af enheder. Én ejer kan bevare ansvaret for den samlede påstand, mens forskellige teams udfører aktiviteterne.

En brugbar implementeringserklæring er specifik nok til at kunne testes: »Produktionsadministratorer får navngiven, godkendt adgang via identitetstjenesten; nødadgang logges og gennemgås separat.« »Adgang styres sikkert« kan ikke vejlede en udvikler eller en bedømmer.

Test påstanden bag statussen

En politik beskriver den tilsigtede adfærd. Den kan demonstrere design og godkendelse, men kan ikke alene demonstrere drift. Opbyg en dokumentationskæde fra kravet til den implementerede mekanisme og derefter til et observeret resultat.

For adgangsstyring skal godkendte regler sammenlignes med faktiske brugerrettigheder og registreringer af fratrædelser. Medtag privilegerede identiteter, ikke-menneskelige konti og applikationer uden for den centrale identitetsstyring, hvor det er relevant. Registrer populationen, stikprøven og undtagelserne i stedet for at præsentere et enkelt belejligt skærmbillede.

For backups skal konfigurationen og et resultat af en genetablering undersøges. Et vellykket backupjob beviser mindre end en vellykket genopretning af brugbare oplysninger. Kontroller rettigheder, afhængigheder og genopretningsmål; en gendannet database uden dens krypteringsnøgler genopretter måske ikke tjenesten.

For leverandørsikkerhed skal vurderingen forbindes med den konkrete tjeneste og de kontraktlige ansvarsområder. Gennemgå, om dokumentationen dækker den tjeneste, I bruger, og om de identificerede ansvarsområder på kundesiden er implementeret.

En praktisk testregistrering bør indeholde det forventede resultat, metoden, omfanget, dokumentationens dato, bedømmeren, resultatet og den opfølgende beslutning. Skeln mellem:

• Design: Den foreslåede mekanisme adresserer den identificerede risiko.
• Implementering: Mekanismen findes i hele det angivne omfang.
• Drift: Registreringer viser, at den har fungeret i den relevante periode.
• Effektivitet: Test viser, at den opnår det tilsigtede resultat.

Dokumentation kan omfatte konfigurationer, eksporter, sager, kontrakter, interviews og fysiske observationer. Vælg dokumentation, der understøtter den faktiske påstand. En konfigurationseksport kan vise de aktuelle indstillinger; historiske sager kan vise, om undtagelser er blevet håndteret over tid.

Bevar oprindelsen: kildesystem, indsamlingsdato, dækket periode og eventuel filtrering. Beskyt dokumentation, der indeholder hemmeligheder eller personoplysninger, gennem adgangsbegrænsninger og passende redigering. Indsamling af dokumentation bør ikke skabe et nyt ukontrolleret arkiv af følsomme data.

Gennemgået eksempel: gør en fratrædelsesproces efterprøvbar

Forestil jer en SaaS-virksomhed med 45 ansatte, ét kontor, cloudhosting, centralt administreret identitet og to applikationer med lokale konti. Det er antagelser for eksemplets skyld, ikke resultater fra Secanis kunder.

Risikoen er fortsat adgang til kunde- eller virksomhedsoplysninger efter fratrædelse. Relevante kontroller omfatter ansvarsområder ved ændringer i ansættelsen, identitetsstyring, adgangsrettigheder og returnering af aktiver. Teknisk autentificering og adgangsbegrænsninger understøtter også implementeringen.

Virksomheden registrerer kontrollen som gældende. HR ejer udløseren for fratrædelsen; IT ejer identitets- og enhedshandlingerne; hver applikationsejer ejer fjernelsen af lokale konti. Medarbejderens leder bekræfter det krævede tidspunkt for fratrædelsen. Sikkerhedsejeren gennemgår processen og uafklarede undtagelser.

Implementeringen omfatter en autoriseret fratrædelsessag, planlagt deaktivering af den centrale konto, tilbagekaldelse af sessioner, hvor det understøttes, fjernelse af lokale konti, returnering af aktiver og kontrol af loginoplysninger, som personen havde kontrol over. Delte hemmeligheder ændres, hvor det er nødvendigt; personlige konti overdrages ikke uden videre til en efterfølger.

Dokumentationspakken forbinder den godkendte procedure, fratrædelsessagen, registreringerne af kontohandlinger, bekræftelserne fra de lokale applikationer og registreringen af udstyr. Hvert element understøtter en defineret del af påstanden.

Under en eksempelgennemgang undersøger teamet fire fratrædelser. De centrale konti blev deaktiveret som planlagt, men én lokal applikation bevarede adgangen i to dage. Kontrollen erklæres ikke fuldt effektiv alene på grundlag af dokumentationen for den centrale identitet.

Applikationsejeren fjerner kontoen, vurderer, om der har fundet adgang sted, og registrerer resultatet. Teamet tilføjer applikationen til tjeklisten for fratrædelser og tildeler et afstemningstrin. Behandlingshandlingen får en ejer og en frist; en senere test kontrollerer, at den reviderede arbejdsgang virker.

Eksemplet viser, hvorfor dokumentationen skal følge afhængighederne. Fire systemer, der siger »færdig«, dokumenterer ikke, at opgaven er færdig, hvis et femte system aldrig blev medtaget.

Hold kontrollerne operationelle mellem gennemgangene

Kontroller ændrer sig, når systemer, leverandører, personer og forretningskrav ændrer sig. Fastsæt udløsere for gennemgang ved væsentlige releases, nye tjenester, ændringer af kontorer, hændelser og ændrede forpligtelser ud over de planlagte gennemgange.

Brug en frekvens, der passer til foranderlighed og risiko. Undtagelser for privilegeret adgang kan kræve hurtig gennemgang, mens en stabil politik kan have en længere cyklus suppleret med ændringsudløsere. Det er ledelsesvalg, ikke universelle frekvenser i bilag A.

Følg et lille antal nyttige indikatorer: forsinket afhjælpning, udækkede systemer, uafklarede undtagelser i dokumentationen og mislykkede kontroltest. Hold dem adskilt fra antallet af dokumenter. Et stort dokumentationsbibliotek kan stadig efterlade et kritisk produktionsmiljø utestet.

Intern audit giver en separat evaluering af ISMS'et; rutinemæssige gennemgange foretaget af kontrolejerne erstatter den ikke. Ledelsens evaluering kræver ligeledes ledelsesbeslutninger om præstationer, ændringer, ressourcer og forbedringer, ikke blot et udfyldt kontrolregneark. Certificering foretages af et uafhængigt certificeringsorgan, ikke af ISO eller en softwareleverandør.

Almindelige fejl omfatter at tildele alt til sikkerhed, kopiere en anden organisations udeladelser, forlade sig på leverandørcertifikater uden at kontrollere omfanget og lukke fund, når en politik ændres, i stedet for når den reviderede proces er testet.

Begynd med én tjeneste og en fuldstændig dokumentationskæde

Vælg en repræsentativ tjeneste, og følg dens systemer, udbydere, oplysninger og operationelle ejere. Vælg et lille sæt relaterede kontroller, for eksempel adgang, ændringsstyring, logning og genopretning, og gør hver implementering efterprøvbar, før registret udvides.

Secani understøtter denne arbejdsgang ved at modellere systemer og afhængigheder, forbinde dokumentation med krav, kontroller og beslutninger og følge mangler som opgaver. Tildel en ejer og en bedømmer, vedhæft eksisterende registreringer, og bevar kommentarer og godkendelser fra gennemgangen. Behandl AI-understøttede mappinger eller resuméer som udkast: Valider kilderne, og hold den menneskelige godkendelse eksplicit. Struktureret auditparathed forklarer den underliggende dokumentationsmodel.

Den første leverance bør være en sammenhængende kæde fra risiko til kontrol, implementering, dokumentation, testresultat og opfølgende beslutning. Den kæde kan derefter gentages i resten af omfanget uden at opfinde en ny proces for hver reference i bilag A.

Praktiske spørgsmål

Kan én registrering understøtte flere kontroller?

Ja. En fratrædelsessag kan understøtte flere relaterede kontroller. Forklar for hver kontrol, hvilken påstand registreringen understøtter; delt dokumentation gør ikke kontrollerne identiske.

Skal hver kontrol have sin egen politik?

Nej. Organiser politikker og procedurer omkring forståelige driftsprocesser. Ét dokument kan omfatte flere kontroller, forudsat at ansvarsområder og implementering forbliver klare.

Hvor bør den autoritative liste over kontroller komme fra?

Brug den licenserede ISO/IEC 27001-standard for ordlyden i bilag A og ISO/IEC 27002 for implementeringsvejledning. Operationelle resuméer er nyttige navigationshjælpemidler, ikke en erstatning for standarderne.