Izjava o primjenjivosti (SoA) u ISO 27001

Izjava o primjenjivosti, na engleskom Statement of Applicability ili SoA, jedan je od najvažnijih i ujedno jedini formalno obvezni dokument u ISO/IEC 27001 koji izrijekom popisuje sigurnosne kontrole. Norma u točki 6.1.3 traži da organizacija izradi Izjavu o primjenjivosti koja sadrži sve nužne kontrole, obrazloženje njihova uključenja, status provedbe i obrazloženje za svaku izostavljenu kontrolu iz Dodatka A.¹ Drugim riječima, SoA je jedino mjesto na kojem tvrtka službeno izjavljuje koje kontrole primjenjuje, koje ne, i zašto. Ako taj dokument ne postoji ili je nepotpun, sustav upravljanja sigurnošću informacija nije usklađen s normom, bez obzira na to koliko je tehničkih kontrola stvarno uvedeno.

Za reguliranu tvrtku u financijama, zdravstvu, kritičnoj infrastrukturi ili SaaS-u SoA nije birokratski privjesak certifikaciji. To je dokument koji povezuje procjenu rizika sa stvarnim odlukama o zaštiti i pokazuje da izbor kontrola nije proizvoljan. Revizor ga gleda među prvima jer iz njega u nekoliko minuta vidi je li sustav utemeljen na riziku ili je netko prepisao tuđi popis. Kupci, partneri i regulatori sve češće traže uvid u SoA prije nego što povjere podatke. Ovaj tekst objašnjava što SoA mora sadržavati, kako se gradi iz procjene rizika i plana tretmana, kako izgleda jedan redak u praksi, zašto je revizoru prva stanica i koje greške najčešće ruše vjerodostojnost cijelog sustava.

Ovo je dio našeg pregleda sigurnosnog programa. Izradu SoA, procjene rizika i prateće dokumentacije vodimo kroz upravljanje, rizik i usklađenost.

Što je SoA i zašto je središnji dokument

SoA je most između rizika i kontrola. Procjena rizika kaže čemu je tvrtka izložena i koji su rizici neprihvatljivi. Dodatak A norme ISO/IEC 27001:2022 nudi katalog od 93 kontrole raspoređene u četiri skupine: organizacijske, kadrovske, fizičke i tehnološke.¹ SoA spaja to dvoje. Za svaku od tih kontrola bilježi je li primjenjiva na konkretnu tvrtku, je li već uvedena i koje je obrazloženje. Tako dokument pokazuje da odabir kontrola proizlazi iz rizika, a ne iz nagađanja ili kopiranja.

Središnji je jer je jedini dokument koji daje cjelovitu sliku opsega zaštite na jednom mjestu. Politike opisuju namjere, procjena rizika opisuje prijetnje, a plan tretmana opisuje što ćete poduzeti. SoA je rezultat svega toga, sažet u tablicu koja jasno kaže što vrijedi, a što ne. Zato se na njega oslanjaju i interna revizija i vanjski certifikacijski auditor i svaki kupac koji želi razumjeti vašu razinu zaštite bez čitanja desetaka dokumenata. SoA je ujedno dio šireg sustava upravljanja sigurnošću informacija, koji povezuje sve te elemente u jednu upravljivu cjelinu.

Što SoA mora sadržavati

Norma propisuje minimalni sadržaj. Za svaku kontrolu iz Dodatka A, SoA mora navesti popis svih kontrola, podatak je li kontrola primjenjiva, obrazloženje njezina uključenja ili isključenja te status provedbe.¹ U praksi to znači da nijednu od kontrola ne smijete preskočiti bez izričite odluke. Ako kontrolu izostavljate, morate napisati zašto, a ne samo prešutjeti je.

Detaljan opis same kontrole, njezinu svrhu i smjernice za provedbu daje ISO/IEC 27002:2022, prateća norma koja proširuje svaku stavku Dodatka A.² SoA se na taj opis oslanja, ali ga ne ponavlja. Dobra Izjava o primjenjivosti za svaki redak povezuje kontrolu s rizikom ili obvezom koja je opravdava i s dokazom da je provedena, na primjer s nazivom politike, sustava ili postupka. Time SoA postaje upotrebljiva karta cijelog sustava, a ne puki popis kvačica.

Kako se SoA gradi iz procjene rizika i plana tretmana

SoA nije prvi dokument koji nastaje, nego rezultat lanca koraka. Najčešća greška je krenuti od popisa kontrola i naknadno tražiti rizike koji ih opravdavaju. Ispravan smjer je obrnut. Polazi se od rizika, biraju se kontrole koje ga smanjuju, a SoA samo bilježi te odluke. Sljedeći koraci pokazuju kako od procjene rizika doći do uredne Izjave o primjenjivosti.

1. 01
   Provedite procjenu rizika

   Identificirajte imovinu, prijetnje i ranjivosti te procijenite vjerojatnost i učinak. Rezultat je popis rizika rangiranih po ozbiljnosti.
2. 02
   Izradite plan tretmana rizika

   Za svaki neprihvatljiv rizik odlučite hoćete li ga smanjiti, prenijeti, izbjeći ili prihvatiti, i kojim kontrolama.
3. 03
   Povežite kontrole s Dodatkom A

   Kontrole iz plana tretmana preslikajte na kontrole iz Dodatka A i provjerite je li ijedna nužna kontrola izostala.
4. 04
   Prođite svih 93 kontrole

   Za svaku kontrolu Dodatka A odlučite je li primjenjiva i napišite obrazloženje uključenja ili isključenja.
5. 05
   Unesite status provedbe

   Označite je li svaka primjenjiva kontrola uvedena, djelomično uvedena ili planirana, s realnim rokom.
6. 06
   Povežite sa dokazima

   Uz svaku uvedenu kontrolu navedite politiku, postupak ili sustav koji dokazuje da stvarno postoji.

Veza s planom tretmana je presudna. Plan tretmana rizika i SoA moraju govoriti isto. Ako plan kaže da rizik smanjujete enkripcijom, a SoA tvrdi da kontrola kriptografije nije primjenjiva, dokumenti si proturječe i revizor to odmah primijeti. Zato se ta dva dokumenta uvijek izrađuju zajedno i provjeravaju jedan uz drugi. Više o samom procesu naći ćete u tekstu o procjeni rizika.

Kako izgleda jedan redak SoA u praksi

Apstraktni opis najbolje se razumije na primjeru. Sljedeća tablica prikazuje kako izgledaju tipični retci SoA, uključujući jednu primjenjivu i jednu isključenu kontrolu. Obrazloženje je kratko, ali konkretno, jer revizor traži vezu s rizikom ili poslovnom stvarnošću, a ne općenitu frazu.

Iz takvog retka revizor vidi tri stvari odjednom: da je odluka utemeljena na riziku, da postoji konkretan dokaz i da status odgovara stvarnosti. Redak A.8.27 pokazuje ispravan način isključenja, gdje obrazloženje navodi konkretan poslovni razlog. Redak A.7.4 pokazuje pošteno priznanje da kontrola još nije potpuna, s rokom, što je daleko bolje od lažne tvrdnje da je uvedena.

Zašto je SoA revizoru prva stanica

SoA daje revizoru kartu cijelog sustava na jednom mjestu. U nekoliko minuta vidi koje su kontrole odabrane, zašto, jesu li uvedene i postoji li za to dokaz. Iz toga odmah procjenjuje je li sustav utemeljen na stvarnom riziku ili je netko prepisao generički popis. SoA zato određuje smjer cijele revizije. Revizor iz njega bira uzorak kontrola koje će dublje provjeriti na licu mjesta.

To znači da je SoA ujedno i najveća prilika i najveći rizik. Točan i obrazložen dokument vodi revizora kroz sustav glatko i gradi povjerenje. Nedosljedan dokument radi suprotno. Kontrola označena kao uvedena koju u praksi nitko ne provodi prva je stvar koju će revizor uzeti u uzorak, a nesklad između SoA i stvarnosti potkopava povjerenje u svaku drugu tvrdnju u dokumentu. Jednom kad revizor uhvati jedan netočan redak, svaki ostali postaje sumnjiv.

SoA nije papir koji popunjavate za revizora. To je iskaz onoga što stvarno radite, a revizor samo provjerava je li istinit.

Česte greške koje ruše SoA

Tri greške najčešće obaraju vjerodostojnost Izjave o primjenjivosti. Prva je isključenje kontrole bez obrazloženja. Norma izričito traži obrazloženje za svaku izostavljenu kontrolu, pa prazno polje ili fraza poput nije primjenjivo bez razloga znače nesukladnost.¹ Isključiti kontrolu smijete, ali samo uz konkretan poslovni razlog, na primjer da tvrtka ne razvija softver ili nema vlastite podatkovne centre.

Druga greška je SoA koja ne odgovara stvarnom stanju. Dokument tvrdi da je kontrola uvedena, a u praksi je nema, ili obrnuto, kontrola postoji ali nije popisana. Treća je kopiranje tuđe SoA ili predloška s interneta. Takav dokument navodi kontrole koje se ne odnose na vašu tvrtku i izostavlja rizike koji su za vas stvarni. Revizor prepoznaje generičku SoA gotovo odmah, jer obrazloženja ne spominju ništa specifično za poslovanje. SoA mora izrasti iz vaše procjene rizika, ne iz tuđe.

Održavanje SoA kao živog dokumenta

SoA nije dokument koji se izradi jednom i zaboravi do sljedeće revizije. To je živi dokument koji prati promjene u tvrtki. Kad uvedete novi sustav, otvorite razvoj softvera, promijenite dobavljača kritične usluge ili kad procjena rizika otkrije novi rizik, SoA se mora ažurirati. Status kontrola koje su bile planirane mijenja se u uvedene kad ih stvarno provedete. Kontrola koja je bila neprimjenjiva može postati primjenjiva kad se poslovanje promijeni.

Praktično pravilo je da SoA prolazi reviziju barem jednom godišnje, u sklopu redovite ocjene sustava, te uvijek nakon veće promjene ili incidenta. Tvrtka koja održava SoA usklađenu sa stvarnošću ne samo da lakše prolazi reviziju, nego ima i jasan, ažuran pregled vlastite zaštite. Tvrtka koja je pusti da zastari ulazi u svaku reviziju s dokumentom koji vara, što je gore nego da ga nema.

Kako Raptoric pomaže

Pomažemo izraditi i održavati SoA koja je točna, obrazložena i izrasla iz vaše procjene rizika i plana tretmana, povezanu sa stvarnim dokazima, kroz upravljanje, rizik i usklađenost. Vodimo i cijeli sustav upravljanja sigurnošću informacija te pripremu za certifikaciju prema ISO 27001 u Hrvatskoj. Dogovorite uvodni razgovor.