En leverandør sender sit ISO 27001-certifikat, og kundens sikkerhedsteam læser én linje af det: omfanget. Hvis den linje lyder "ledelsessystemet for informationssikkerhed hos Eksempel ApS på selskabets hjemsted", har certifikatet lige fortalt en køber, at det SaaS-produkt, der kører i en cloudregion, drevet af et team, der arbejder hjemmefra, måske er inden for det, og måske ikke. Siden den 15. juli 2024 har den læsning et reguleringsmæssigt grundlag for enhver finansiel kunde: litra b) i artikel 8, stk. 3, i delegeret forordning (EU) 2024/1773 lader kun en bank støtte sig til en certificering i stedet for at revidere sin leverandør, hvor certificeringens omfang dækker de systemer og nøglekontroller, banken har identificeret, og litra c) og d) kræver, at certifikatet er aktuelt og bliver ved med at dække de systemer i fremtidige versioner. Denne artikel forklarer, hvad omfangserklæringen er, hvad certifikatet skal vise, hvordan en køber læser begge dele, og hvad et softwarefirmas omfang bør sige. Den er ikke juridisk rådgivning, og den er ikke standarden; standarden er den tekst, man køber og læser.

Hvad afsnit 4.3 kræver

Afsnit 4.3 i ISO/IEC 27001:2022 kræver, at organisationen fastlægger grænserne for og anvendeligheden af sit ledelsessystem for informationssikkerhed for at fastsætte dets omfang, under hensyntagen til de eksterne og interne forhold i afsnit 4.1, de interesserede parters krav i afsnit 4.2 og grænsefladerne og afhængighederne mellem de aktiviteter, organisationen udfører, og de aktiviteter, andre organisationer udfører, og at den holder omfanget tilgængeligt som dokumenteret information. Tre ting følger af det. Omfanget er organisationens beslutning, ikke auditorens: et certificeringsorgan reviderer det, organisationen har erklæret, og et snævert omfang er et gyldigt omfang. Omfanget skal være skrevet ned og tilgængeligt, og derfor kan en køber bede om omfangsdokumentet og ikke kun om certifikatet. Og den tredje betragtning, grænseflader og afhængigheder, er den sætning, der afgør, hvordan et cloudhostet produkt beskrives: cloududbyderen er en anden organisation, dens aktiviteter ligger uden for omfanget, og grænsefladen til den ligger indenfor.

Hvad certifikatet viser

ISO/IEC 17021-1, den standard, akkrediteringsorganer holder certificeringsorganer op på, kræver, at certificeringsdokumentet identificerer kunden og de dækkede lokaliteter, standarden og dens udgave, certificeringens omfang, certificeringsorganet, datoerne for udstedelse og udløb og en entydig identifikation. De fleste certifikater nævner også det akkrediteringsorgan, hvis mærke de bærer, og den version af erklæringen om anvendelighed, der blev revideret op imod. To af de felter er dem, en køber tjekker først. Udgaven: certifikater efter ISO/IEC 27001:2013 er ikke længere gyldige, fordi den akkrediterede overgang til 2022-udgaven sluttede den 31. oktober 2025, og et certifikat, der stadig nævner 2013, er et certifikat, der er bortfaldet. Og lokaliteterne: et certifikat opregner de dækkede steder, og et produkt, der drives fra en cloudregion, drives ikke fra nogen af dem, medmindre omfanget siger hvordan.

Hvordan en køber afgør, om det er aktuelt

Akkrediteret certificering kører i en treårig cyklus. Certificeringsorganet udfører en overvågningsaudit mindst én gang pr. kalenderår, den første inden for 12 måneder efter certificeringsbeslutningen, og en recertificeringsaudit før certifikatets udløb. En køber, der anvender artikel 8, stk. 3, litra c), i den delegerede forordning, eller som blot gør sit arbejde, beder om datoen for den seneste overvågningsaudit og om, hvorvidt der er åbne afvigelser, for et certifikat er kun så aktuelt som sin seneste audit. Siden om certificeringsorganer nævner det nationale akkrediteringsregister for hver medlemsstat, hvor køberen bekræfter, at certificeringsorganet er akkrediteret specifikt til ISO 27001; akkreditering til ISO 9001 er ikke akkreditering til ISO 27001, og et certificeringsorgan, der ikke står i noget nationalt register, er ikke akkrediteret, uanset hvad dets hjemmeside siger.

Én omfangserklæring, der dumper, og tre, der består

Den, der dumper: "Ledelsessystemet for informationssikkerhed hos Eksempel ApS, Eksempelvej 1." Den nævner intet produkt, ingen tjeneste, intet system og intet sted ud over et kontor. En finansiel kundes politik kan ikke knytte den til de systemer, kunden er afhængig af, så artikel 8, stk. 3, litra b), er ikke opfyldt, og revisionsklausulen bruges i stedet.

De tre, der består, er skrevet til et softwarefirma og er illustrationer, ikke skabeloner; certificeringsorganet afgør, om et omfang kan revideres.

For det første, ét produkt drevet hos en cloududbyder: "Udvikling, drift og support af Eksempel-lønplatformen, leveret som multi-tenant SaaS fra Eksempel Cloud-regioner i Unionen, herunder funktionerne kundesupport og hændelsesrespons, udført af medarbejdere, der arbejder fra Eksempel ApS' kontor og på afstand, i overensstemmelse med erklæringen om anvendelighed, version 4." Den nævner produktet, leveringsmodellen, regionerne, de understøttende funktioner, menneskene og versionen af erklæringen om anvendelighed.

For det andet, et firma med flere produkter, hvoraf kun ét sælges til regulerede kunder: "Design, udvikling, hosting og drift af Eksempel Ledger-tjenesten til kunder i den finansielle sektor, herunder den infrastruktur, den kører på hos Eksempel Cloud, og de processer for ændrings-, hændelses-, backup- og leverandørstyring, der understøtter den." De andre produkter ligger med vilje uden for omfanget, og erklæringen siger det ved at nævne ét.

For det tredje, et firma, hvis produkt installeres af kunderne: "Udvikling, udgivelse og vedligeholdelse af Eksempel-softwareproduktet, herunder build- og releasepipelinen, processen for håndtering af sårbarheder og den tekniske supporttjeneste, på Eksempel ApS' kontorer i Dublin og Lissabon og på afstand." Her ligger kundens egne systemer uden for omfanget, så omfanget nævner den pipeline og den supporttjeneste, kunden er afhængig af.

Hvor cloududbyderen hører til

En leverandør kan ikke tage sin cloududbyder ind i sit eget omfang, og behøver det ikke. Den tredje betragtning i afsnit 4.3 lægger grænsefladen indenfor: foranstaltningerne for leverandørforhold i bilag A, A.5.19 til A.5.21 (informationssikkerhed i leverandørforhold, leverandøraftaler, IKT-forsyningskæden), og overvågningen af leverandørtjenester, A.5.22, er de foranstaltninger, omfangserklæringen peger på, når den siger "leveret fra Eksempel Cloud-regioner". Udbyderens eget certifikat, dens dokumentation for delt ansvar og kontraktvilkårene er det bevis, de foranstaltninger frembringer. Det er også grunden til, at det register over oplysninger, en finansiel kunde indberetter, spørger om landene for lagring og behandling og om underleverandørkæden efter rang: kunden knytter registrets rækker til omfangserklæringens grænseflader, og et omfang, der nævner regionerne, gør den kobling mulig.

Hvad du bør gøre før den næste overvågningsaudit

Skriv omfanget om, så det nævner produktet, leveringsmodellen, de understøttende funktioner, lokaliteterne inklusive cloudregionerne og versionen af erklæringen om anvendelighed, og forelæg det omskrevne omfang for certificeringsorganet før den næste overvågningsaudit, for en ændring af omfanget er en ændring, det vurderer. Offentliggør omfangserklæringen ved siden af certifikatet frem for certifikatet alene. Hold den seneste rapport fra overvågningsauditten klar til at dele under en fortrolighedsaftale, for artiklen om DORA-due diligence viser, at certifikatet alene aldrig opfylder de otte betingelser. Og behandl omfangserklæringen som ledelsessystemets første dokument frem for certifikatets sidste linje: StandardOS holder den ved siden af erklæringen om anvendelighed og de foranstaltninger, de nævner, versioneret, så sætningen på certifikatet og systemet bag den siger det samme. Den gratis side skriver omfangserklæringen ud fra tolv svar, certifikatsætningen først. ISO 27001-hubben rummer resten.