
En intern audit giver organisationen mulighed for at opdage, hvor dens ledelsessystem for informationssikkerhed (ISMS) afviger fra hensigterne. Det nyttige resultat er en underbygget vurdering og en klar forbedringsvej for hvert væsentligt fund – ikke blot en mappe med skærmbilleder, der er forberedt til certificeringen.
For en teknisk leder er det centrale spørgsmål, om systemet virker på tværs af reelle tjenester, mennesker og overdragelser. En politik kan være godkendt, mens implementeringen svigter. En audit bør afsløre den forskel uden at gøre enhver operationel ufuldkommenhed til et udokumenteret compliance-fund.
ISO/IEC 27001, afsnit 9.2, kræver interne audits med planlagte mellemrum for at vurdere, om organisationens egne krav til ISMS'et og standardens krav er opfyldt, og om ISMS'et er effektivt implementeret og vedligeholdt. Auditprogrammet skal tage hensyn til processernes betydning og resultaterne af tidligere audits, og auditorerne skal udvælges, så objektivitet og upartiskhed sikres.
En intern audit kan udføres af medarbejdere eller af en ekstern specialist, der er engageret til formålet. Den udsteder ikke et certifikat: Certificering er en særskilt vurdering foretaget af et uafhængigt certificeringsorgan. Interne audits forbliver en del af driften af ISMS'et efter certificeringen, ikke blot en forberedelse til den første vurdering.
ISO 27001 foreskriver ikke en universel årlig hyppighed for interne audits. Som en praktisk anbefaling bør I bruge en dokumenteret plan, der afspejler risiko, ændringer og tidligere fund, med hyppigere opmærksomhed på ustabile eller kritiske processer.
En enkelt audit behøver ikke at undersøge alt på én gang. Programmet bør dække det afgrænsede ISMS i løbet af den planlagte cyklus i stedet for gentagne gange kun at undersøge velkendte kontroller.
Dokumentér disse beslutninger, før der anmodes om dokumentation:
| Beslutning | Hvad der skal registreres |
|---|---|
| Kriterier | Relevante krav i ISO 27001, interne procedurer og gældende forpligtelser |
| Omfang | Tjenester, teams, lokationer, systemer og den undersøgte driftsperiode |
| Dækning | Krav til ledelsessystemet i afsnit 4–10 og kontroller, der er valgt gennem risikohåndteringen og anvendelseserklæringen (Statement of Applicability) |
| Ansvarsområder | Auditor, procesejere, specialistkontakter og modtagere af rapporten |
| Metoder | Interviews, gennemgang af registreringer, observation og tilgang til stikprøver |
Anneks A er ikke et krav om at implementere alle kontroller ens. Kontrollér, om beslutninger om relevans og udeladelser er begrundede, og test derefter de forpligtelser, organisationen faktisk har påtaget sig.
Vælg kompetente auditorer, der forstår både kravene til ledelsessystemet og de undersøgte kontroller. Undgå, at personer auditerer deres eget arbejde. I et lille udviklingsteam kan en ekstern auditor eller en reviewer fra en anden funktion løse konflikter, forudsat at vedkommende har tilstrækkelig kompetence og adgang til dokumentation.
Begynd med omfanget, risikovurderingen, risikohåndteringsplanen, anvendelseserklæringen, politikkerne, tidligere fund og relevante operationelle registreringer. De forklarer, hvad der bør ske, og hvor svigt ville have størst betydning.
Formulér derefter testbare spørgsmål. For privilegeret adgang skal I spørge, om godkendelser kommer før adgangen, om gennemgange dækker den relevante population af konti, og om tilbagekaldte rettigheder faktisk forsvinder. En underskrevet adgangspolitik fastslår hensigten; kontoeksporter, godkendelsesregistreringer og logs over fjernelser fastslår driften.
Udarbejd en stikprøveplan, der omfatter nylige ændringer, kritiske tjenester, tidligere svagheder og undtagelser. Registrér populationen, udvælgelsesmetoden, perioden og begrundelsen. Praktiske stikprøver behøver ikke at bruge én fast stikprøvestørrelse, men de skal kunne forklares. En håndfuld bekvemme skærmbilleder repræsenterer sjældent en hel driftsperiode.
Trianguler registreringer med interviews og observation. Hvis ejerne beskriver en manuel overdragelse, skal I undersøge gennemførte overdragelser. Hvis dokumentationen modsiger et interview, skal I undersøge sagen i stedet for at vælge den mest beroligende forklaring. Registrér begrænsninger, når et system ikke kan levere historisk dokumentation; udled ikke i stilhed tidligere præstationer af den aktuelle konfiguration.
Illustrative antagelser: En SaaS-virksomhed auditerer medarbejderfratrædelser over tre måneder. Dens procedure kræver, at adgangen fjernes senest på medarbejderens fratrædelsestidspunkt. HR-registreringerne viser 12 fratrædelser; auditoren undersøger alle tre privilegerede brugere og fire yderligere fratrædelser fra forskellige teams.
Auditoren sammenligner HR's tidsstempler for fratrædelse med begivenheder hos identitetsudbyderen, applikationskontienes status og offboardingsager. En tidligere udviklers konto hos identitetsudbyderen blev deaktiveret til tiden, men en separat administreret repositorykonto forblev aktiv i to dage.
Før fundet vurderes, skal det fastlægges, om kontoen kunne autentificere, hvilke rettigheder der stadig var tilbage, og om der fandtes en godkendt undtagelse. Interview HR og applikationsejeren for at forstå overdragelsen. Udvid testen til andre fratrædelser, der omfatter separat administrerede applikationer, hvis udeladelsen ser ud til at være systematisk.
Et fund, der kan forsvares, angiver den procedure, der er overtrådt, den observerede tilstand, understøttende registreringer, det berørte omfang og den mulige konsekvens. Det bør ikke påstå, at der har fundet uautoriseret adgang sted, medmindre dokumentationen understøtter den konklusion.
En afvigelse kræver dokumentation for, at et krav ikke er opfyldt. En forbedringsmulighed angiver en nyttig forbedring uden at påvise en overtrædelse. Et uafklaret spørgsmål forbliver åbent, indtil tilstrækkelig dokumentation understøtter en konklusion.
Brug ensartede klassifikationer, og prioritér fund efter eksponering, gentagelse og omfang. Lad ikke en alvorlighedsbetegnelse erstatte begrundelsen. Giv procesejerne mulighed for at rette faktuelle fejl, mens auditoren bevarer ansvaret for konklusionen.
Rapporten bør angive omfang, kriterier, metoder, begrænsninger, fund og den samlede vurdering, som det udførte arbejde understøtter.
En handlingsplan bør angive en ejer, en frist, en umiddelbar rettelse, grundårsagen og den ændring, der skal forhindre gentagelse. Fjernelse af repositorykontoen retter det konkrete tilfælde. Rettelse af den ufuldstændige applikationsfortegnelse og overdragelsen fra HR til IT håndterer processen.
Undgå at acceptere »menneskelig fejl« som den fulde grundårsag, når arbejdsgangen afhænger af hukommelse eller mangler ejerskab. Definér kriterier for effektivitet, før handlingen lukkes: For eksempel skal efterfølgende fratrædelser omfatte afstemte kontroller mod den relevante applikationsfortegnelse.
En afsluttet sag beviser udførelse, ikke nødvendigvis effektivitet. Efter implementeringen skal I undersøge en ny stikprøve og bevare resultatet af kontrollen. Genåbn handlingen, hvis den samme fejl gentager sig.
Rapportér tilbagevendende svagheder, forsinkede handlinger, ressourcebehov og væsentlige risikobeslutninger til den relevante ledelse. Resultaterne af interne audits er input til ledelsens evaluering efter ISO 27001; evalueringen er en særskilt aktivitet med andre påkrævede input, ikke blot et møde, hvor auditrapporten godkendes.
Secani forbinder krav, dokumentation, ejere, opgaver og beslutninger fra gennemgange, så vurdering og opfølgning forbliver i kontekst. Hold understøttende registreringer knyttet til de relevante kontroller, og bevar den menneskelige godkendelse af konklusioner om dokumentation. Brug vores guide til auditparathed til at organisere registreringerne før feltarbejdet.
Et praktisk næste skridt er at vælge én kritisk proces, udpege en upartisk auditor og nedskrive kriterierne og stikprøveplanen. Planlæg kontrollen af effektiviteten, når de korrigerende handlinger tildeles – ikke efter at alle anser dem for afsluttede.
Secani forbinder scopes, dokumentation, opgaver og AI-agenter i ét fælles arbejdsområde.
Forstå C5's omfang, rapporttyper, kundernes ansvar og den evidens, som cloududbydere skal holde sammenhængende.
Stil praktiske spørgsmål om kvalifikationer, brancheerfaring, forventninger til evidens, tidsplan, uafhængighed og de samlede omkostninger ved vurderingen.
Læs ISO-certifikater og SOC 2-rapporter i kontekst: scope, periode, undtagelser, kundens ansvar og evidens for afhjælpning.