ISO 27001-krav 4.3 – Bestemmelse af ISMS'ens omfang

Sådan indstilles omfanget af ISMS

In-scope-aktiviteten vil være meget mere logisk at overveje, når du har afsluttet arbejdet for 4.1 og 4.2. Du vil sandsynligvis overveje organisationen, datterselskaber, divisioner, afdelinger, produkter, tjenester, fysiske lokationer, mobile medarbejdere, geografier, systemer og processer for dit omfang, da informationssikkerheden og risikovurderingsarbejdet vil følge de dele af din organisation, der har brug for at blive beskyttet.

Husk også at tænke over, hvad de magtfulde interessenter interesserede parter også vil forvente. Hvis du så på at udelade en del af organisationen uden for rammerne, hvad ville virkningen være for disse magtfulde interesserede parter? Ville du også skulle køre flere systemer og ende med at forvirre personalet om, hvad der var inden for og uden for scope i den måde, de arbejdede på?

Hvilke dele af virksomheden har brug for at skabe, få adgang til eller behandle de informationsaktiver, du ser som værdifulde? Disse ville næsten helt sikkert skulle være i omfang, hvis presset blev drevet eksternt af kunder for at tilfredsstille deres behov for informationssikkerhed. For eksempel kan du fokusere på din produktudvikling og levering, men du skal stadig se på mennesker, processer osv. omkring det også. Tænk også over, hvad du kan og ikke kan kontrollere eller påvirke.

Det kan være få minutter af indsats at få dette arbejde gjort, eller det kan tage betydeligt længere tid i en større virksomhed, hvor det kan være politisk og praktisk udfordrende at bestemme et kontrollerbart omfang. ISO-certificeringsorganer som UKAS presser også mere i retning af "hele organisationens"-omfang, og stærke kunder vil generelt også forvente det.

Sådan dokumenterer du 'uden for scope'

Du bør også omhyggeligt lægge mærke til områderne 'uden for anvendelsesområdet' for ISMS'et, pakket sammen med de vigtigste grænseflader og afhængigheder mellem aktiviteter udført af organisationen og aktiviteter, der udføres af andre organisationer. På et forenklet niveau, lad os forestille os, at du er en softwareudvikler og er afhængig af outsourcing af datacentret til hosting af tjenesten til kunder.

Du ville nok præcisere, at omfanget for din 4.3 er det, der er inden for din organisation for personerne og selve softwaren, men ville sætte grænserne og aktiviteterne i datacentret uden for dit kontrollerede omfang – du ville trods alt forvente, at de også vedligeholder deres eget betroede ISMS.

Det er det samme for fysisk ejendom – hvis der er en afhængighed af en udlejer for bestemt arbejde (f.eks. lastning, barrierer og receptionskontrol), der kan danne en grænse, hvor selve den fysiske placeringssikkerhed er uden for din kontrol, og du ville arbejde med din ISMS-aktivitet i den pågældende ejendom. Det forventes dog stadig, at du administrerer leverandøren som en del af dine leverandørpolitikker i bilag A 15 og sikrer, at deres praksis i det mindste opfyldte kravene til dit ISMS og risikovillighed, men det er til en anden gang.

Andre punkter at overveje

• Med udgangspunkt i ovenstående punkt, hvis du lod dele være uden for rækkevidde, hvad ville virkningen være for personalet? Ville noget af deres arbejde være inden for scope og noget uden for scope? Hvis det er tilfældet, er der yderligere risici og komplikationer, hvor de kan forvirre praksis (f.eks.), ikke beskytte arbejdet og forårsage mere trussel ved at følge to forskellige tilgange?
• Er der muligheder for at beskrive tingene anderledes, f.eks. behandle nogle satellitkontorer som tele-/fjernarbejdere, ikke som fysiske lokaler eller steder i omfang?
• At forenkle eller begrænse omfanget tidligt kunne give mening, hvis du effektivt kan segmentere informationsgrænserne og demonstrere, at risiciene bliver løst. Men hvis du har et mål om at tilføje noget senere, så husk, at en væsentlig ændring i omfang kan udløse et behov for endnu en revision, afhængigt af hvad, hvornår, hvordan og om drevet af interne mål eller eksternt pres.