Klasifikacija podataka za ISO 27001, GDPR, NIS2 i DORA
Revizijski trenutak 2026.: „Pokažite mi dokaze”
Veljača je 2026., a tromjesečna sjednica upravnog odbora u brzorastućem fintech SaaS društvu ne odvija se onako glatko kako je CISO očekivao.
Društvo je nedavno steklo certifikaciju prema ISO/IEC 27001:2022. Ima MFA, zaštitu krajnjih uređaja, skeniranja ranjivosti, preglede pristupa, postupke odgovora na incidente i dotjerano izvješće o spremnosti za DORA. Zatim CEO postavlja pitanje koje mijenja tijek sastanka.
„Naš vodeći investitor pita kako možemo dokazati da se financijski podaci klijenata dosljedno štite u AWS-u, Azureu, našoj SaaS platformi za podršku i analitičkom skladištu. Ako revizor uzme jednu datoteku iz objektne pohrane, a drugu iz mape za suradnju, kako znamo da se njima upravlja prema istim pravilima?”
CISO otvara registar imovine. U njemu su navedene baze podataka, računi u oblaku, aplikacije, SaaS platforme i lokacije pohrane. No polje klasifikacije nije potpuno. Nekoliko mapa imenovano je prema odjelu, a ne prema osjetljivosti. Izvozi podataka o klijentima nalaze se uz interne izvještajne datoteke. Neke proračunske tablice podrške sadržavaju identifikatore klijenata, reference plaćanja i bilješke o predmetima, ali označene su kao „interno”. DLP pravila postoje, ali aktiviraju se samo na očite obrasce. Politika korištenja oblaka navodi da osobni podaci iz EU moraju ostati u odobrenim regijama, ali tim ne može dokazati da se pravila rezidentnosti provode na temelju metapodataka klasifikacije.
Zatim voditelj usklađenosti dodaje regulatorni aspekt: „Hoće li ovo zadovoljiti GDPR Article 32, NIS2 Article 21 i dokaze za DORA IKT rizike?”
Iskren odgovor glasi: još ne.
To je praznina s kojom se 2026. suočavaju mnoge organizacije. Imaju sigurnosne kontrole, ali nemaju upravljački sloj koji svakoj kontroli govori što treba štititi, koliko snažno to treba štititi i kako to dokazati. Taj upravljački sloj čine klasifikacija podataka i označavanje informacija.
U terminima ISO/IEC 27001:2022, klasifikacija i označavanje nisu kozmetičke prakse upravljanja dokumentima. One su praktična poveznica između procjene rizika, kontrole pristupa, šifriranja, zadržavanja podataka, DLP-a, rezidentnosti u oblaku, dubinske analize dobavljača, praćenja i prijavljivanja incidenata. U Clarysecovu modelu implementacije nalaze se u središtu dokaznog lanca ISMS-a: evidentirati imovinu, dodijeliti vlasnika, klasificirati je, označiti je, primijeniti pravila postupanja, pratiti iznimke i revizorima pokazati sljedivost.
Zašto su klasifikacija i označavanje sada kontrole na razini odbora
Regulatori i klijenti sve češće očekuju da organizacije pokažu kako su sigurnosne mjere primjerene osjetljivosti podataka, kritičnosti usluge i poslovnom učinku otkaza.
GDPR to izričito zahtijeva kroz načelo odgovornosti. Article 5 zahtijeva da se osobni podaci obrađuju zakonito, pošteno i transparentno, da budu ograničeni na ono što je nužno, da se čuvaju samo onoliko dugo koliko je potrebno i da budu zaštićeni primjerenim tehničkim i organizacijskim mjerama. Voditelj obrade također mora moći dokazati usklađenost. GDPR Article 32 teško je dokaziv ako organizacija ne zna koji sustavi obrađuju osobne podatke, koji su podaci visokorizični ili pripadaju posebnim kategorijama, gdje su pohranjeni i koje se zaštitne mjere primjenjuju.
NIS2 podiže zahtjeve upravljanja. Article 20 zahtijeva da upravljačka tijela ključnih i važnih subjekata odobre mjere upravljanja kibernetičkim rizicima, nadziru njihovu provedbu i prolaze osposobljavanje. Article 21 zahtijeva primjerene i razmjerne tehničke, operativne i organizacijske mjere, uključujući analizu rizika, sigurnosne politike, postupanje s incidentima, neprekidnost poslovanja, sigurnost opskrbnog lanca, sigurnost pri nabavi i razvoju, procjenu učinkovitosti, kibernetičku higijenu, osposobljavanje, kriptografiju, sigurnost ljudskih resursa, kontrolu pristupa i upravljanje imovinom. Klasifikacija nije zasebna kontrolna točka na tom popisu. Ona je sustav odlučivanja koji te mjere čini razmjernima.
DORA primjenjuje istu logiku na financijske subjekte i fintech ekosustave. Od 17. siječnja 2025. DORA zahtijeva dokumentirani okvir upravljanja IKT rizicima, odgovornost upravljačkog tijela, politike za povjerljivost, cjelovitost, dostupnost i autentičnost, klasifikaciju incidenata, testiranje otpornosti i upravljanje rizikom IKT trećih strana. Za financijske subjekte regulirane DORA-om, DORA može djelovati kao sektorski poseban pravni akt Unije umjesto preklapajućih obveza upravljanja rizicima i izvješćivanja prema NIS2, ali očekivanje u pogledu dokaza ostaje isto: pokazati kako se kritične informacije i IKT imovina identificiraju, štite, testiraju, prate i upravljaju.
ISO/IEC 27001:2022 dobro je prilagođen kao operativni sustav za takve dokaze. Točke 4.1 do 4.4 zahtijevaju da organizacija razumije unutarnja i vanjska pitanja, zahtjeve zainteresiranih strana, regulatorne i ugovorne obveze te sučelja s drugim organizacijama. Točke 6.1.1 do 6.1.3 zahtijevaju procjenu rizika, obradu rizika, odabir kontrola, Izjavu o primjenjivosti i čuvanje dokaza. ISO/IEC 27001:2022
Ako GDPR, NIS2 i DORA pitaju: „Zašto ste primijenili ove mjere?”, ISO/IEC 27001:2022 pomaže odgovoriti: „Zato što su nas ova imovina, vrste podataka, rizici, obveze i odluke o obradi rizika doveli do toga.”
Klasifikacija je odluka o riziku. Označavanje je operativni signal.
Clarysec razdvaja klasifikaciju i označavanje jer to čine i revizori.
Klasifikacija je čin odlučivanja o osjetljivosti, vrijednosti i kritičnosti informacija. Označavanje je čin kojim ta odluka postaje vidljiva, trajna i provediva u svakodnevnom radu.
Clarysecova Politika klasifikacije podataka i označavanja - SME jasno navodi svrhu:
Ova politika definira kako se sve informacije kojima organizacija rukuje moraju klasificirati i označiti kako bi se njihova povjerljivost, cjelovitost i dostupnost održale tijekom cijelog životnog ciklusa.
Ista Politika klasifikacije podataka i označavanja - SME zahtijeva od organizacija da:
Zahtijevaju da svaki podatkovni resurs bude klasificiran prema svojoj osjetljivosti i odgovarajuće označen kako bi se usmjerilo pravilno postupanje, pohrana i pristup.
Za poslovna okruženja, Clarysecova P13 Politika klasifikacije podataka i označavanja definira minimalni model klasifikacije:
Organizacija mora održavati standardiziranu klasifikacijsku shemu s jasno definiranim razinama. Najmanje se moraju koristiti sljedeće klasifikacijske razine: 5.1.1 Javno: informacije namijenjene otvorenoj objavi i neograničenoj distribuciji 5.1.2 Interno: nejavne poslovne informacije koje nisu namijenjene vanjskoj objavi 5.1.3 Povjerljivo: osjetljivi poslovni, ugovorni ili klijentski podaci koji zahtijevaju strogu kontrolu pristupa 5.1.4 Ograničeno (ili vrlo povjerljivo): kritične ili regulirane informacije kod kojih bi neovlašteno otkrivanje moglo prouzročiti značajnu štetu ili pravnu odgovornost
Ta je razlika važna. Klasifikacija „Povjerljivo” može zahtijevati šifriranje, pristup temeljen na ulogama i ugovorne zaštitne mjere. Klasifikacija „Ograničeno” može aktivirati MFA, odobrenje CISO-a za vanjsko dijeljenje, pojačano zapisivanje događaja, strože upravljanje zadržavanjem, razdvajanje i prioritetnu eskalaciju incidenta.
Politika za poslovna okruženja izričita je u pogledu operativnog označavanja:
Svi informacijski resursi moraju biti označeni na način koji je: 6.2.1.1 Trajan: nije ga lako ukloniti ili zaobići 6.2.1.2 Vidljiv: jasan korisnicima u trenutku uporabe 6.2.1.3 Strojno čitljiv: gdje je moguće, mora biti podržano označavanje temeljeno na metapodacima
Strojno čitljive oznake mjesto su na kojem program sazrijeva od podizanja svijesti do provedbe. Ako su oznake temeljene na metapodacima, platforme u oblaku, DLP sustavi, pristupnici e-pošte, alati za identitet, SIEM pravila, CASB platforme i mehanizmi zadržavanja mogu po njima postupati. Ako su oznake samo podnožje dokumenta, mogu pomoći korisnicima, ali ne mogu pouzdano provoditi pravila u velikom opsegu.
Gdje klasifikacija pripada u Clarysecovu planu implementacije
Clarysecov Zenith Blueprint: revizorov plan od 30 koraka smješta klasifikaciju rano u životni ciklus upravljanja rizicima, a ne nakon implementacije tehnologije. U fazi upravljanja rizicima, korak 9, „Identifikacija imovine, prijetnji i ranjivosti”, plan usmjerava timove da popišu informacijske resurse i zabilježe vlasnika, lokaciju i klasifikaciju.
Time se sprječava čest neuspjeh: postojanje popisa imovine u oblaku, ali ne i popisa informacija. Baza podataka, SaaS instanca ili podatkovno skladište tehnološka su imovina. Evidencije klijenata, dosjei zaposlenika, zapisi plaćanja, skupovi podataka za treniranje modela, prijepisi podrške i dokazi o incidentima unutar njih informacijski su resursi. Klasifikacija se nalazi na toj informacijskoj razini.
Smjernice Zenith Blueprinta za ISO/IEC 27002:2022 kontrolu 5.12, Klasifikacija informacija, objašnjavaju načelo:
Svaka kontrola informacijske sigurnosti ikad napisana, ograničenje pristupa, šifriranje, sigurnosna kopija, praćenje ili zbrinjavanje, pretpostavlja jedno: da organizacija zna što štiti. Kontrola 5.12 zahtijeva da se informacije klasificiraju na temelju svoje vrijednosti, osjetljivosti i kritičnosti, čime se postavlja temelj za sve kasnije odluke unutar ISMS-a.
Za ISO/IEC 27002:2022 kontrolu 5.13, Označavanje informacija, isti plan pretvara klasifikaciju u svakodnevno ponašanje:
Označavanje je način na koji apstraktnu politiku pretvarate u operativnu stvarnost. To je trenutak u kojem korisnik, kada vidi dokument, e-poštu, polje baze podataka ili tiskano izvješće, može na prvi pogled razumjeti: što je ta informacija, koliko je osjetljiva i kako se s njom mora postupati.
Završna poveznica u planu pojavljuje se u koraku 13, „Planiranje obrade rizika i Izjava o primjenjivosti”. Zenith Blueprint opisuje SoA kao most između rizika, obrada i kontrola. Tu klasifikacija postaje revizijska sljedivost. Scenarij rizika kao što je „neovlašteno otkrivanje financijskih podataka klijenata iz dijeljene pohrane u oblaku” može se mapirati na klasifikaciju, označavanje, kontrolu pristupa, šifriranje, zapisivanje događaja, DLP, korištenje usluga u oblaku, zahtjeve dobavljača i odgovor na incidente.
Odnosi kontrola koje revizori očekuju vidjeti
U Clarysecovu Zenith Controls: vodič za višestruku usklađenost, ISO/IEC 27002:2022 kontrola 5.12, Klasifikacija informacija, mapirana je kao preventivna kontrola koja podržava povjerljivost, cjelovitost i dostupnost. Povezana je s konceptom kibernetičke sigurnosti Identify, operativnom sposobnošću zaštite informacija i domenama sigurnosti Protection and Defense.
Za ISO/IEC 27002:2022 kontrolu 5.13, Označavanje informacija, Zenith Controls mapira kontrolu kao preventivnu, usmjerenu na Protect, s istim svojstvima informacijske sigurnosti i operativnom sposobnošću zaštite informacija.
Ključni je uvid da klasifikacija i označavanje nisu izolirani. One okolne kontrole čine dokazivima.
| Područje kontrole ISO/IEC 27002:2022 | Zašto ovisi o klasifikaciji ili označavanju | Dokazi koje revizor može zatražiti |
|---|---|---|
| 5.9 Popis informacija i druge povezane imovine | Metapodaci klasifikacije trebaju biti osnovno polje u popisu imovine | Registar imovine koji prikazuje vlasnika, lokaciju, status životnog ciklusa i klasifikaciju |
| 5.12 Klasifikacija informacija | Definira osjetljivost, vrijednost i kritičnost | Odobrena klasifikacijska shema, kriteriji, primjeri i zapisi pregleda |
| 5.13 Označavanje informacija | Čini klasifikaciju vidljivom i provedivom | Konfiguracija oznaka, uzorci označenih datoteka, oznake e-pošte, SaaS oznake i upute korisnicima |
| 5.14 Prijenos informacija | Određuje jesu li za vanjsko dijeljenje potrebni šifriranje ili odobrenje | Pravila prijenosa prema klasifikaciji, odobreni kanali i zapisi o iznimkama |
| 5.15 Kontrola pristupa | Ovlaštenja pristupa trebaju slijediti granice klasifikacije | Matrica uloga, pregledi pristupa, pravila privilegiranog pristupa i povijest odobrenja |
| 5.25 Procjena i odluka o događajima informacijske sigurnosti | Ozbiljnost incidenta djelomično ovisi o osjetljivosti zahvaćenih podataka | Kriteriji trijaže incidenata koji koriste klasifikaciju i kritičnost usluge |
| 5.34 Privatnost i zaštita osobnih podataka (PII) | Kategorije osobnih podataka zahtijevaju postupanje specifično za privatnost | Registar osobnih podataka (PII), mapiranje pravne osnove, pravila zadržavanja i kontrole izvršitelja obrade |
| 8.15 Zapisivanje događaja | Pristup podacima razine Ograničeno zahtijeva snažniju sljedivost | Dnevnički zapisi pristupa podacima, postavke zadržavanja zapisa i dokazi pregleda |
| 8.16 Aktivnosti praćenja | Prioritet praćenja mijenja se kada se pristupa podacima razine Ograničeno | SIEM slučajevi uporabe, pragovi upozorenja i zapisi o eskalaciji |
Zenith Controls mapira kontrolu 5.12 na GDPR Article 32 i Recital 83, NIS2 Article 21(2)(a) i 21(2)(f), ISO/IEC 27701 Annex B, NIST SP 800-53 MP-3 i PM-11, FIPS 199 i NIST SP 800-60 te COBIT 2019 DSS06.06 i APO13.01. Kontrolu 5.13 mapira na GDPR Article 32, NIS2 Article 21(2)(a) i 21(2)(f), DORA Article 9(1) i 9(2), NIST SP 800-53 MP-3 i COBIT 2019 DSS06.06.
To znači da jedan skup dokaza može odgovoriti na više pitanja o osiguranju usklađenosti.
| Pokretač usklađenosti | Doprinos klasifikacije i označavanja | Praktični dokaz |
|---|---|---|
| GDPR Article 32 | Pokazuje koji osobni podaci zahtijevaju zaštitne mjere za povjerljivost, cjelovitost, dostupnost i otpornost | Klasifikacija osobnih podataka (PII), pravila šifriranja, ograničenja pristupa, mapiranje zadržavanja i kriteriji trijaže povrede |
| NIS2 Article 21 | Podržava analizu rizika, sigurnosne politike, procjenu učinkovitosti, kontrolu pristupa, upravljanje imovinom i razmjerne mjere | Politika odobrena od uprave, popis imovine, osposobljavanje, metrike pregleda i testirana pravila postupanja |
| DORA upravljanje IKT rizicima | Podržava identifikaciju i zaštitu informacija i IKT imovine, klasifikaciju incidenata i rizik IKT trećih strana | Registar IKT imovine, kritičnost podataka, zahtjevi ugovora s dobavljačima, opseg testiranja i kriteriji ozbiljnosti incidenta |
| NIST CSF 2.0 | Podržava ishode GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND i RECOVER | Trenutačni i ciljni profili s prazninama klasifikacije i prioritetnim korektivnim radnjama |
| COBIT 2019 | Podržava upravljačke i procesne kontrole za sigurnost, postupanje s podacima i rad kontrola | Ciljevi kontrola, vlasništvo nad procesima, testiranje osiguranja i upravljanje iznimkama |
Registar imovine mjesto je na kojem klasifikacija postaje dokaz
Mnogi programi klasifikacije ne uspijevaju jer klasifikacijska shema postoji samo u politici. Clarysecov pristup počinje s popisom imovine.
Clarysecova P12 Politika upravljanja imovinom zahtijeva da popis imovine uključuje razinu klasifikacije kao minimalno polje:
Popis imovine mora sadržavati najmanje: 5.3.1 ID imovine, kategoriju i vrstu 5.3.2 Serijski broj ili jedinstvenu oznaku (za fizičku imovinu) 5.3.3 Verziju softvera ili licencni ključ (za softversku imovinu) 5.3.4 Vlasnika imovine 5.3.5 Razinu klasifikacije (Javno, Interno, Povjerljivo, Ograničeno) 5.3.6 Lokaciju (fizičku, virtualnu, u oblaku) 5.3.7 Status životnog ciklusa (aktivno, u održavanju, povučeno iz uporabe)
To je izravno usklađeno s planiranjem rizika prema ISO/IEC 27001:2022. Ako ne možete identificirati informacijski resurs, vlasnika, lokaciju i klasifikaciju, ne možete dosljedno procijeniti vjerojatnost, učinak, prioritet obrade ni preostali rizik. Također ne možete pouzdano odlučiti utječu li dobavljački aranžman, usluga u oblaku ili SaaS integracija na regulirane informacije.
Za GDPR to podržava odgovornost. Evidencije aktivnosti obrade iz Article 30 i sigurnosne mjere iz Article 32 uvjerljivije su kada registar imovine identificira gdje se osobni podaci obrađuju i kako su zaštićeni. Za DORA isti registar podržava kritičnost IKT imovine i usluga, opseg testiranja otpornosti i analizu ovisnosti o trećim stranama. Za NIS2 podržava analizu rizika, kontrolu pristupa i upravljanje imovinom.
| Polje | Primjer unosa |
|---|---|
| Naziv imovine | Baza podataka za obračun klijentima |
| Vlasnik imovine | Voditelj platformskog inženjeringa |
| Poslovni proces | Obračun pretplata i izdavanje računa |
| Lokacija | EU regija u oblaku, upravljana usluga baze podataka |
| Klasifikacija | Ograničeno |
| Kategorije podataka | Identifikatori klijenata, podaci kontakt osobe za obračun, reference transakcija |
| Relevantnost za GDPR | Osobni podaci, konteksti voditelja obrade i izvršitelja obrade |
| Kritičnost | Podržava prihodne operacije i korisničku podršku |
| Ključne kontrole | MFA, šifriranje u mirovanju, šifriranje u prijenosu, odobrenje privilegiranog pristupa, revizijsko bilježenje, testiranje sigurnosnih kopija |
| Ovisnost o dobavljaču | Pružatelj baze podataka u oblaku, izvršitelj plaćanja |
| Učestalost pregleda | Tromjesečni pregled pristupa, godišnji pregled klasifikacije, pregled nakon promjene sustava |
Ovakav zapis mijenja ton revizije. Umjesto izjave „Vjerujemo da su osjetljivi podaci zaštićeni”, organizacija može pokazati koji su to podaci, tko ih posjeduje, zašto su Ograničeni, koje se kontrole primjenjuju i kada su te kontrole zadnji put pregledane.
Oznake moraju pokretati pravila postupanja u oblaku i SaaS-u
Većina osjetljivih podataka danas prolazi kroz platforme u oblaku, SaaS aplikacije, analitičke podatkovne tokove i alate za suradnju. Politika koja korisnicima kaže da „pažljivo postupaju s povjerljivim podacima” nije dovoljna.
Clarysecova P27 Politika korištenja usluga u oblaku izravno povezuje korištenje oblaka s klasifikacijom i rezidentnošću podataka:
Klasifikacija i rezidentnost podataka 6.6.1 Nijedan podatak ne smije se premjestiti na platformu u oblaku bez klasifikacije u skladu s Politikom klasifikacije podataka i označavanja (P13). 6.6.2 Zahtjevi rezidentnosti podataka moraju se ugovorno provoditi (npr. pohrana samo u EU za podatke regulirane GDPR-om). 6.6.3 Prekogranični prijenosi podataka moraju biti u skladu s GDPR Chapter V i, gdje je primjenjivo, DORA Article 28.
To je važno jer rizik oblaka često ulazi kroz praktičnost. Tim izvozi skup podataka u novi analitički alat. Prodaja sinkronizira popise klijenata s platformom za automatizaciju. Razvojni inženjer kopira produkcijske podatke u testno okruženje. Bez klasifikacije i označavanja, te radnje možda neće pokrenuti pravni pregled, sigurnosno odobrenje ili provjere dobavljača.
Politika klasifikacije podataka i označavanja - SME manjim organizacijama daje jednostavan obrazac implementacije:
Dijeljene mape ili diskovi u oblaku moraju koristiti nazive mapa ili oznake koje označavaju klasifikaciju (npr. „/Clients_Confidential”).
U zrelijim okruženjima nazive mapa treba nadopuniti strojno čitljivim oznakama, politikama uvjetnog pristupa, blokadama vanjskog dijeljenja, šifriranjem, oznakama zadržavanja, DLP pravilima i zapisivanjem događaja. Cilj nije samo označiti informacije. Cilj je učiniti oznaku provedivom.
Oznaka „Ograničeno” može aktivirati blokade vanjskog dijeljenja, šifriranje u mirovanju i prijenosu, MFA, ograničenja preuzimanja na neupravljanim uređajima, zadržavanje revizijskih zapisa, SIEM upozorenja, pravila zadržavanja, ograničenja lokacije dobavljača i eskalaciju ozbiljnosti incidenta.
P13 Politika klasifikacije podataka i označavanja postavlja polaznu osnovu:
Sve postupanje s podacima, prijenos, pristup, pohrana i zbrinjavanje informacija moraju biti usklađeni s njihovom razinom klasifikacije. Najmanje: 6.3.1.1 Javno: može se slobodno otkrivati; nije potrebno posebno postupanje 6.3.1.2 Interno: dijeli se unutar organizacije; pohranjuje se u sigurnim internim sustavima 6.3.1.3 Povjerljivo: 6.3.1.3.1 pristup je ograničen samo na ovlašteno osoblje 6.3.1.3.2 mora biti šifrirano u prijenosu i mirovanju 6.3.1.3.3 može se dijeliti eksterno samo na temelju NDA-a ili ekvivalentnih ugovornih zaštitnih mjera 6.3.1.4 Ograničeno: 6.3.1.4.1 primjenjuju se najviši sigurnosni zahtjevi 6.3.1.4.2 zahtijevaju se snažne kontrole pristupa, višefaktorska autentifikacija (MFA) i revizijsko bilježenje 6.3.1.4.3 fizičko i logičko razdvajanje gdje je izvedivo 6.3.1.4.4 vanjsko dijeljenje zabranjeno je bez odobrenja CISO-a
Svaka oznaka ima ponašanje. Svako ponašanje ima kontrolu. Svaka kontrola ima dokaz.
Praktičan primjer provedbe
Zamislite fintech analitičara koji izrađuje Q3_2026_Customer_Churn_Analysis.xlsx. Proračunska tablica sadržava ID-jeve klijenata, volumene transakcija i prediktivno bodovanje odljeva.
Analitičar je klasificira kao Povjerljivo jer sadržava podatke o klijentima i stratešku analizu. Koristeći alat društva za zaštitu informacija, analitičar primjenjuje oznaku Povjerljivo. Budući da je oznaka trajna, vidljiva i strojno čitljiva, kontrole se automatski aktiviraju.
Datoteka je šifrirana u mirovanju na uređaju i u pohrani u oblaku. Vidljivo zaglavlje označava je kao Povjerljivo. Kada je analitičar pokuša sinkronizirati s osobnim diskom u oblaku, DLP pravilo blokira radnju i bilježi pokušaj. Kada je analitičar pokuša poslati e-poštom na vanjsku domenu koja nije partnerska, pristupnik e-pošte stavlja poruku u karantenu i upozorava sigurnosne operacije. Ako se datoteka kasnije reklasificira kao Ograničeno jer sadržava regulirane podatke o financijskim transakcijama, vanjsko dijeljenje se onemogućuje osim ako CISO ili vlasnik podataka ne odobri iznimku.
To je dokaz koji je CEO tražio. Sljediv je, automatiziran i povezan s politikom koju je odobrio odbor. Također je usklađen s P27 Politikom korištenja usluga u oblaku, jer nijedno premještanje u oblak nije dopušteno bez klasifikacije, a prekogranični prijenosi moraju ispunjavati GDPR Chapter V i, gdje je primjenjivo, DORA Article 28.
Izradite matricu klasifikacije i kontrola u jednom tjednu
Cjelovit program zahtijeva vrijeme, ali usmjereni sprint može stvoriti okosnicu dokaza prije revizije, pregleda klijenta ili regulatorne procjene.
1. dan: Potvrdite klasifikacijsku shemu
Počnite s četiri razine: Javno, Interno, Povjerljivo i Ograničeno. Koristite P13 Politiku klasifikacije podataka i označavanja kao polaznu osnovu. Definirajte kriterije koristeći poslovni učinak, pravni učinak, ugovornu osjetljivost, rizik osobnih podataka, kritičnost usluge i financijsku štetu.
| Klasifikacija | Tipični primjeri | Logika rizika |
|---|---|---|
| Javno | Odobreni marketinški sadržaj, priopćenja za medije, oglasi za posao | Namijenjeno neograničenoj distribuciji |
| Interno | Interni postupci, projektne bilješke, interne objave | Nejavne poslovne informacije |
| Povjerljivo | Ugovori s klijentima, HR dosjei, nejavno financijsko izvještavanje | Osjetljivi poslovni, ugovorni ili klijentski podaci |
| Ograničeno | Posebne kategorije osobnih podataka, podaci o plaćanju, autentifikacijske tajne, produkcijske baze podataka klijenata | Kritične ili regulirane informacije sa značajnim pravnim ili poslovnim učinkom |
2. dan: Odaberite deset kritičnih informacijskih resursa
Koristite Zenith Blueprint korak 9. Uključite bazu podataka klijenata, sustav za prijave podrške, HR platformu, pružatelja identiteta, izvoz plaćanja, podatkovno skladište, spremnik objektne pohrane, mapu za izvještavanje odbora, repozitorij izvornog koda i repozitorij dokaza o incidentima. Zabilježite vlasnika, lokaciju, klasifikaciju i relevantnost za GDPR.
3. dan: Mapirajte pravila postupanja
Definirajte zahtjeve postupanja za pristup, pohranu, prijenos, praćenje i zbrinjavanje.
| Klasifikacija | Pristup | Pohrana | Prijenos | Praćenje | Zbrinjavanje |
|---|---|---|---|---|---|
| Javno | Otvorene ili odobrene uloge za objavu | Odobreni javni kanali | Nema posebnog ograničenja nakon odobrenja | Osnovno praćenje cjelovitosti | Standardno brisanje |
| Interno | Zaposlenici i odobreni vanjski suradnici | Upravljani sustavi | Interni kanali | Standardni dnevnički zapisi pristupa | Standardni raspored zadržavanja |
| Povjerljivo | Pristup prema načelu nužnog poznavanja | Odobreni sigurni repozitoriji | Šifriranje i NDA ili ugovorne zaštitne mjere | Pregled pristupa i DLP upozorenja | Sigurno brisanje |
| Ograničeno | Načelo najmanjih privilegija uz MFA i odobrenje vlasnika | Odvojeni ili sigurnosno očvrsnuti sustavi | Vanjsko dijeljenje zabranjeno osim ako je odobreno | Pojačano revizijsko bilježenje i SIEM upozoravanje | Provjereno sigurno uništenje |
4. dan: Konfigurirajte jedan tehnički put provedbe
Odaberite jednu platformu, primjerice repozitorij dokumenata u oblaku, sustav e-pošte ili uslugu objektne pohrane. Implementirajte vidljive i strojno čitljive oznake. Konfigurirajte jedno pravilo za Povjerljive podatke i jedno pravilo za Ograničene podatke. Primjerice, zahtijevajte šifriranje za Povjerljivu vanjsku e-poštu i blokirajte vanjsko dijeljenje Ograničenih datoteka.
5. dan: Ažurirajte registar rizika i SoA
Koristite Zenith Blueprint korak 13. Dodajte kontrole klasifikacije i označavanja u Izjavu o primjenjivosti. Povežite ih s rizicima kao što su neovlašteno otkrivanje, pogrešna konfiguracija oblaka, prekomjerna izloženost dobavljaču, neuspjeh zadržavanja podataka i nedovoljno prijavljivanje incidenata.
6. dan: Testirajte kontrolu
Izradite testnu datoteku označenu kao Ograničeno. Pokušajte je podijeliti eksterno s neupravljanog uređaja. Potvrdite blokira li alat, upozorava, bilježi ili eskalira. Snimite zaslone, dnevničke zapise i dokaze iz prijave. Ako kontrola ne uspije, evidentirajte iznimku i plan korektivnih radnji.
7. dan: Osposobite korisnike prve linije
Osposobljavanje treba biti specifično za ulogu. Razvojni inženjeri trebaju znati kada se produkcijski podaci ne smiju koristiti u testnim okruženjima. HR treba razumjeti zašto su dosjei zaposlenika Povjerljivi ili Ograničeni. Prodaja treba znati zašto se izvozi podataka o klijentima ne smiju učitavati u neodobrene SaaS alate. Izvršni rukovoditelji trebaju razumjeti zašto materijali za odbor, dokumentacija o akvizicijama i podaci investitora zahtijevaju strože postupanje.
Ovaj sprint ne dovršava cijeli program, ali stvara okosnicu dokaza: politiku, popis imovine, oznake, pravila postupanja, tehničku provedbu, sljedivost rizika i osposobljavanje.
Kako će revizori testirati klasifikaciju i označavanje
Revizori rijetko testiraju klasifikaciju izolirano. Oni slijede podatke.
Revizor ISO/IEC 27001:2022 povezat će klasifikaciju s opsegom ISMS-a, zahtjevima zainteresiranih strana, pravnim i ugovornim obvezama, procjenom rizika i Izjavom o primjenjivosti. Očekivat će dokaze za ISO/IEC 27002:2022 kontrole 5.9, 5.12, 5.13, 5.14, 5.15, 5.34 i relevantne tehničke kontrole. Tipični dokazi uključuju odobrene politike, zapise iz popisa imovine, unose u registar rizika, označene uzorke, pravila postupanja, preglede pristupa, nalaze interne revizije i korektivne radnje.
Pregled prema GDPR-u usredotočit će se na osobne podatke. Pitat će jesu li osobni podaci identificirani, razlikuju li se podaci posebne kategorije, jesu li pravila zadržavanja usklađena sa svrhom i jesu li sigurnosne mjere iz Article 32 primjerene. Klasifikacija pomaže odvojiti uobičajene poslovne informacije od osobnih podataka, osjetljivih osobnih podataka, povjerljivih klijentskih podataka i reguliranih zapisa. Označavanje pomaže operativnim timovima izbjeći slučajno otkrivanje, prekomjerno zadržavanje i neovlašteni prijenos.
Procjenitelj prema NIST CSF 2.0 vjerojatno će klasifikaciju promatrati kroz GOVERN, IDENTIFY i PROTECT. Može pitati definiraju li trenutačni i ciljni profili otkrivanje osjetljivih podataka, funkcionira li provedba oznaka kroz SaaS i sustave u oblaku, postupaju li dobavljači s podacima prema klasifikaciji i prilagođavaju li se prioriteti praćenja na temelju osjetljivosti.
Revizor prema COBIT 2019 ili ISACA pristupu naglasit će upravljačke ciljeve, vlasništvo nad procesima, dizajn kontrola i operativnu učinkovitost. Zenith Controls mapira kontrolu popisa imovine 5.9 na COBIT 2019 BAI09.01, BAI09.02 i DSS05.04 te upućuje na ISACA ITAF 2204 i 2301. Za klasifikaciju, Zenith Controls mapira kontrolu 5.12 na COBIT 2019 DSS06.06 i APO13.01, dok označavanje mapira na DSS06.06. Revizor će pitati tko je vlasnik procesa, kako se iznimke odobravaju, prati li se učinkovitost i prima li uprava izvješća.
Pregled usmjeren na DORA pitat će koji informacijski resursi podržavaju ključne ili važne funkcije, koji su podaci Ograničeni, koji IKT pružatelji trećih strana pohranjuju ili prenose te podatke, definiraju li ugovori lokacije i sigurnosne mjere, je li testiranje obuhvatilo kritične podatke i klasificiraju li se incidenti djelomično prema gubitku podataka kroz dostupnost, autentičnost, cjelovitost i povjerljivost.
Ako odgovori dolaze iz jednog modela dokaza o imovini i dobavljačima vođenog klasifikacijom, revizije postaju brže, dosljednije i dokazivije.
Česti obrasci neuspjeha
Neuspjesi klasifikacije obično nastaju zato što organizacije tretiraju oznake kao alate za podizanje svijesti umjesto kao signale za kontrolu.
Prvo, klasificiraju dokumente, ali ne i baze podataka, API-je, dnevničke zapise, sigurnosne kopije, izvoze ili SaaS zapise. Osjetljivi podaci u dnevničkom zapisu za otklanjanje pogrešaka mogu biti jednako štetni kao osjetljivi podaci u proračunskoj tablici.
Drugo, označavaju informacije, ali oznake ne povezuju s kontrolom pristupa. Oznaka Ograničeno uz otvoren pristup dokazuje da je organizacija znala za osjetljivost i nije provela pravilo postupanja.
Treće, migracije u oblak događaju se prije klasifikacije. Timovi premještaju podatke u nove SaaS alate bez potvrde rezidentnosti, uvjeta dobavljača, pristupa podizvršitelja obrade, zahtjeva prekograničnog prijenosa ili prava na brisanje. P27 Politika korištenja usluga u oblaku to izravno uređuje zabranom premještanja na platforme u oblaku bez klasifikacije.
Četvrto, planovi odgovora na incidente zanemaruju klasifikaciju. Ako kriteriji ozbiljnosti ne uključuju osjetljivost podataka, timovi za incidente gube vrijeme otkrivajući što je zahvaćeno tijekom krize. Analiza povrede prema GDPR-u, postupanje s incidentima prema NIS2 i klasifikacija incidenata prema DORA-i imaju koristi od brzog podatkovnog konteksta.
Peto, SoA ne objašnjava zašto su kontrole klasifikacije i označavanja primjenjive. Organizacija je možda implementirala oznake, ali SoA ih ne povezuje s GDPR Article 32, NIS2 Article 21, DORA IKT rizikom, ugovorima s klijentima ili konkretnim scenarijima rizika.
Izvješćivanje uprave: učinite klasifikaciju vidljivom
NIS2 i DORA čine kibernetičku sigurnost pitanjem odgovornosti uprave. ISO/IEC 27001:2022 također zahtijeva predanost vodstva, usklađenost politike, resurse, uloge i izvješćivanje o učinkovitosti. Metrike klasifikacije stoga trebaju biti dio preispitivanja od strane uprave.
Korisne metrike uključuju:
- Postotak kritičnih informacijskih resursa s dodijeljenim vlasnicima.
- Postotak imovine s odobrenom klasifikacijom.
- Broj Ograničenih resursa bez pojačanog zapisivanja događaja.
- Broj Povjerljivih ili Ograničenih repozitorija s omogućenim vanjskim dijeljenjem.
- Postotak dobavljača koji obrađuju Povjerljive ili Ograničene podatke s ažuriranim ugovornim odredbama.
- Broj iznimaka klasifikacije i zakašnjelih korektivnih radnji.
- DLP incidenti prema oznaci.
- Dovršenost pregleda pristupa za Ograničene resurse.
- Lokacije pohrane u oblaku za podatke regulirane GDPR-om.
- Vježbe odgovora na incidente koje su koristile kriterije ozbiljnosti temeljene na klasifikaciji.
Te metrike podržavaju preispitivanje od strane uprave prema ISO/IEC 27001:2022, nadzor uprave prema NIS2, izvješćivanje o upravljanju prema DORA-i i programe dokazivanja sigurnosti prema zahtjevima klijenata. Također čine klasifikaciju razumljivom izvršnim rukovoditeljima. Vodstvo može djelovati brže kada vidi da više Ograničenih repozitorija nema testiran oporavak ili da kritični dobavljači obrađuju podatke klijenata bez potvrđene pohrane u EU.
Od politike do dokaza
Clarysecov obrazac implementacije vođen je dokazima:
- Definirajte klasifikacijsku shemu u P13 Politici klasifikacije podataka i označavanja ili započnite s Politikom klasifikacije podataka i označavanja - SME.
- Dodajte klasifikaciju u popis imovine koristeći P12 Politiku upravljanja imovinom.
- Primijenite ograničenja oblaka i zahtjeve rezidentnosti kroz P27 Politiku korištenja usluga u oblaku.
- Koristite Zenith Blueprint korak 9 za identifikaciju informacijskih resursa, vlasnika, lokacija i osjetljivosti.
- Koristite Zenith Blueprint korak 13 za mapiranje rizika na kontrole u SoA.
- Koristite Zenith Blueprint korak 22 za implementaciju ISO/IEC 27002:2022 kontrola 5.12 i 5.13 u svakodnevnom radu.
- Koristite Zenith Controls za mapiranje istih dokaza na GDPR, NIS2, DORA, NIST CSF, COBIT 2019 i prateće standarde.
- Testirajte provedbu oznaka, ograničenja pristupa, zapisivanje događaja, DLP i trijažu incidenata.
- Izvješćujte upravu o učinkovitosti klasifikacije.
- Pregledajte klasifikaciju nakon većih promjena sustava, procesa, dobavljača ili propisa.
To funkcionira zato što klasifikacija postaje zajednički jezik između poslovne vrijednosti, pravne obveze, tehničke kontrole i revizijskih dokaza.
Ako se vaša organizacija priprema za certifikaciju prema ISO/IEC 27001:2022, dokazivanje usklađenosti s GDPR-om, spremnost za NIS2, DORA dubinsku analizu od strane klijenta ili kombiniranu reviziju usklađenosti, počnite s jednim pitanjem:
Možete li za svaki kritični informacijski resurs pokazati što je, tko ga posjeduje, gdje se nalazi, kako je klasificiran, kako je označen, tko mu može pristupiti, kako je zaštićen, koliko se dugo zadržava, koji ga dobavljač dodiruje i što se događa ako bude izložen?
Ako odgovor još nije potvrdan, Clarysec vam može pomoći brzo i dokazivo izgraditi dokazni lanac.
Koristite Politiku klasifikacije podataka i označavanja - SME, P13 Politiku klasifikacije podataka i označavanja, P12 Politiku upravljanja imovinom, P27 Politiku korištenja usluga u oblaku, Zenith Blueprint: revizorov plan od 30 koraka i Zenith Controls: vodič za višestruku usklađenost kako biste klasifikaciju pretvorili iz statične politike u operativni sloj kontrola za GDPR Article 32, upravljanje kibernetičkim rizicima prema NIS2 i dokaze za DORA IKT rizike.
Najbolje vrijeme za klasifikaciju podataka bilo je prije nego što je stigao revizijski zahtjev. Sljedeće najbolje vrijeme je prije sljedeće migracije u oblak, uvođenja dobavljača, upitnika klijenta ili incidenta.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
