⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

Upravljanje pristupom osobnim podacima (PII) za ISO 27701:2025 i GDPR

Igor Petreski
15 min read
Mapiranje upravljanja pristupom osobnim podacima (PII) kroz ISO 27701, GDPR, dobavljače u oblaku i revizijske dokaze

Pitanje vanjskog revizora ostalo je visjeti u zraku, naizgled jednostavno.

„Možete li mi pokazati zapisnik pregleda pristupa vašeg tima za podršku produkcijskim osobnim podacima (PII) za prošlo tromjesečje?”

Za Anyu, CISO u Medtelligenceu, brzorastućem SaaS pružatelju u području zdravstvene tehnologije, to je bio trenutak istine. Medtelligence djeluje kao izvršitelj obrade osobnih podataka (PII) za bolnice i obrađuje osjetljive podatke pacijenata na platformi u oblaku. Tvrtka je imala snažnu autentifikaciju, definirane uloge i zreo inženjerski tim. No revizor nije pitao postoji li stranica za prijavu. Tražio je dokaz da se pristupom osobnim podacima upravljalo tijekom vremena.

Želio je vidjeti tko je mogao pristupiti produkcijskim osobnim podacima (PII), zašto je imao pristup, kada je pristup odobren, je li i dalje bio potreban, je li aktivnost podrške bila evidentirana u dnevničkim zapisima i jesu li nepotrebna ovlaštenja uklonjena.

Anya je otvorila IAM konzolu. Ondje su bili inženjeri podrške, administratori baza podataka, integracijski servisni račun, pružatelj upravljanih usluga, dvije uloge za hitni pristup i bivši ugovorni suradnik koji je još uvijek bio u grupi jer je zahtjev za odlazak zatvoren prije uklanjanja ovlaštenja. HR evidencija pokazivala je da je osoba otišla prije šest tjedana. Proračunska tablica za pregled pristupa imala je status „Na čekanju”. SIEM je sadržavao dnevničke zapise, ali nitko nije mapirao koji događaji dokazuju pristup osobnim podacima (PII).

Tu upravljanje privatnošću postaje stvarno.

Prema GDPR-u, osobni podaci moraju se obrađivati uz cjelovitost i povjerljivost te moraju biti zaštićeni od neovlaštene ili nezakonite obrade, slučajnog gubitka, uništenja ili oštećenja primjenom odgovarajućih tehničkih i organizacijskih mjera. GDPR također izričito uvodi načelo odgovornosti: voditelj obrade mora moći dokazati usklađenost. ISO/IEC 27701:2025 tu odgovornost pretvara u sustav upravljanja osobnim podacima, odnosno PIMS, u kojem pristup osobnim podacima (PII) više nije naknadna tehnička misao. Postaje upravljani životni ciklus kroz uloge, izvršitelje obrade, platforme u oblaku, zaposlenike, administratore s povišenim ovlastima, dnevničke zapise, preglede, ugovore i dokaze.

Praznina u mnogim organizacijama nije u tome što nemaju kontrolu pristupa. Praznina je u tome što ne mogu dosljedno dokazati upravljanje pristupom osobnim podacima (PII) kroz ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 i COBIT 2019.

Upravljanje pristupom osobnim podacima (PII) nije samo IAM

Tradicionalni IAM program pita: „Mogu li pravi korisnici pristupiti pravim sustavima?”

Zreo ISO/IEC 27701:2025 PIMS postavlja zahtjevnija pitanja:

  • Koji sustavi obrađuju osobne podatke (PII)?
  • Koje uloge zahtijevaju pristup kojim kategorijama osobnih podataka (PII)?
  • Djeluje li organizacija kao voditelj obrade osobnih podataka (PII), izvršitelj obrade, zajednički voditelj obrade ili podizvršitelj obrade?
  • Je li pristup ograničen svrhom, dokumentiranom poslovnom potrebom i načelom najmanjih privilegija?
  • Evidentiraju li se i pregledavaju radnje s povišenim ovlastima?
  • Može li organizacija dokazati da je pristup izvršitelja obrade i podizvršitelja obrade ugovorno kontroliran?
  • Jesu li pristupni putovi podrške u oblaku, izolacija zakupaca, izvozi i administrativne radnje uključeni u dokaze?
  • Pregledavaju li se odluke o pristupu nakon onboardinga, promjene uloge, incidenta, odlaska i značajne promjene sustava?

Zato su sigurnost osobnih podataka (PII) i upravljanje kontrolom pristupa prirodan most između ISO/IEC 27701:2025 i GDPR-a. GDPR daje pravni okvir odgovornosti. ISO/IEC 27701:2025 operacionalizira upravljanje privatnošću za voditelje obrade i izvršitelje obrade. ISO/IEC 27001:2022 osigurava mehanizam za upravljanje rizicima u ISMS-u. ISO/IEC 27002:2022 osigurava arhitekturu kontrola, uključujući privatnost i zaštitu osobnih podataka (PII), kontrolu pristupa, prava pristupa, evidentiranje događaja, usluge u oblaku, odnose s dobavljačima, klasifikaciju, brisanje, maskiranje i kriptografiju.

Clarysecov Zenith Blueprint: revizorov plan provedbe u 30 koraka smješta ovo u fazu Kontrole u praksi. U koraku 23, koji obuhvaća organizacijske kontrole 5.19 do 5.37, opisuje kontrolu ISO/IEC 27002:2022 5.34, Privatnost i zaštita osobnih podataka (PII), kao pitanje povjerenja, a ne samo kao pitanje podataka:

osobni podaci koji omogućuju identifikaciju osobe nisu samo još jedna vrsta podataka, nego duboko osjetljiv izraz povjerenja. Imena, adrese, identifikacijski brojevi, zdravstveni zapisi, financijski podaci — ti podaci govore priču o stvarnim ljudima.

Isti odlomak daje praktični temelj: zaštita privatnosti počinje sviješću o podacima. Organizacija mora znati koje osobne podatke (PII) prikuplja, gdje se nalaze, zašto se obrađuju i tko im može pristupiti.

Pritisak usklađenosti iza kontrole pristupa osobnim podacima (PII)

Upravljanje pristupom osobnim podacima (PII) više nije pitanje jednog okvira. Organizacije poput Medtelligencea djeluju na sjecištu regulative o privatnosti, propisa o kibernetičkoj sigurnosti, operativne otpornosti, dokazivanja sigurnosti prema zahtjevima klijenata i sigurnosne certifikacije.

GDPR Article 5 zahtijeva da se osobni podaci obrađuju u skladu s načelima zakonitosti, poštenosti, transparentnosti, ograničavanja svrhe, smanjenja količine podataka, točnosti, ograničenja pohrane, cjelovitosti i povjerljivosti. Article 5(2) uvodi načelo odgovornosti: voditelj obrade odgovoran je za usklađenost i mora je moći dokazati. Article 32 zatim zahtijeva odgovarajuće tehničke i organizacijske mjere za sigurnost obrade.

NIS2 Article 21 zahtijeva da ključni i važni subjekti poduzmu odgovarajuće i razmjerne tehničke, operativne i organizacijske mjere upravljanja kibernetičkim rizicima. Njegova minimalna područja uključuju analizu rizika, sigurnosne politike, postupanje s incidentima, neprekidnost poslovanja, sigurnost opskrbnog lanca, sigurnu nabavu i razvoj, procjenu djelotvornosti, kibernetičku higijenu i osposobljavanje, kriptografiju, sigurnost ljudskih resursa, kontrolu pristupa, upravljanje imovinom te, prema potrebi, višefaktorsku ili kontinuiranu autentikaciju i sigurne komunikacije. Article 20 također stavlja odgovornost na upravljačka tijela za odobravanje i nadzor mjera upravljanja kibernetičkim rizicima.

DORA se primjenjuje od 17. siječnja 2025. na širok raspon financijskih subjekata i uspostavlja sektorski režim operativne otpornosti. Obuhvaća upravljanje IKT rizicima, prijavljivanje velikih incidenata povezanih s IKT-om, testiranje digitalne operativne otpornosti, razmjenu informacija, IKT rizik trećih strana i ugovorne aranžmane s pružateljima IKT usluga trećih strana. Za financijske subjekte i pružatelje IKT usluga koji ih podržavaju, kontrola pristupa nije samo pitanje privatnosti. Ona je dio operativne otpornosti.

ISO/IEC 27001:2022 povezuje te obveze u sustav upravljanja temeljen na riziku. Točke 6.1.1 do 6.1.3 zahtijevaju od organizacija da obrade rizike i prilike, definiraju proces procjene rizika informacijske sigurnosti, identificiraju rizike za povjerljivost, cjelovitost i dostupnost, vrednuju rizike, odaberu opcije obrade, utvrde kontrole, usporede odabrane kontrole s Annex A, dokumentiraju Izjavu o primjenjivosti, pribave odobrenje vlasnika rizika i prihvate preostale rizike. Točke 8.2 i 8.3 zahtijevaju procjene rizika u planiranim intervalima ili nakon značajne promjene te provedbu plana obrade rizika s dokumentiranim rezultatima.

Za upravljanje osobnim podacima (PII) to znači da kontrola pristupa nije izolirana IAM postavka. Ona je odluka o obradi rizika. Uloga koja može izvoziti evidencije plaća, podatke pacijenata, podatke o plaćanju, identifikacijske dokumente, lokacijske podatke ili transkripte korisničke podrške mora biti obrazložena u registru rizika, odražena u Izjavi o primjenjivosti, provedena u IAM-u, evidentirana u produkcijskom okruženju, periodično pregledana i uklonjena kada više nije potrebna.

Clarysecov model kontrola: od obećanja privatnosti do dokaza

Clarysec upravljanje pristupom osobnim podacima (PII) promatra kao lanac dokaza. Lanac počinje popisom podataka i definiranjem uloga, nastavlja se odobravanjem i provedbom pristupa, a završava nadzorom, pregledom, ukidanjem pristupa i zapisima spremnima za reviziju.

U Zenith Controls: vodič za mapiranje usklađenosti među okvirima, tema se ponajprije odnosi na tri kontrole ISO/IEC 27002:2022:

Kontrola ISO/IEC 27002:2022Clarysecovo tumačenje za upravljanje osobnim podacima (PII)Atributi kontrola u Zenith Controls
5.34 Privatnost i zaštita osobnih podataka (PII)Identificirati osobne podatke (PII), štititi ih tijekom njihova životnog ciklusa i uskladiti obradu s pravnim obvezama i obvezama privatnostipreventivne kontrole, povjerljivost, cjelovitost, dostupnost, identifikacija, zaštita, zaštita informacija, pravni poslovi i usklađenost
5.15 Kontrola pristupaUspostaviti pravila kontrole pristupa na temelju poslovnih i sigurnosnih zahtjeva, uključujući načelo najmanjih privilegija i pristup temeljen na ulogamapreventivne kontrole, povjerljivost, cjelovitost, dostupnost, zaštita, upravljanje identitetom i pristupom
5.18 Prava pristupaDodjeljivati, pregledavati, prilagođavati i ukidati prava pristupa kroz sljediv životni cikluspreventivne kontrole, povjerljivost, cjelovitost, dostupnost, zaštita, upravljanje identitetom i pristupom

Revizori rijetko prihvaćaju „koristimo IAM” kao dokaz. Očekuju vidjeti kako se IAM odluke povezuju s obvezama privatnosti, vlasništvom nad sustavom, klasifikacijom podataka, poslovnom potrebom, obradom rizika, učestalošću pregleda pristupa, opsegom evidentiranja događaja i ugovorima s dobavljačima.

Clarysecova Politika sigurnosti osobnih podataka (PII) i kontrole pristupa postavlja polaznu osnovu PIMS jezikom:

[Obje uloge] Vlasnik sustava / vlasnik aplikacije MORA ograničiti pristup osobnim podacima (PII) na odobrene uloge i ovlaštene korisnike koji su zabilježeni ili sljedivi u REG02 ili REG12 prije omogućavanja pristupa.

Iz odjeljka „4.2 Polazna osnova kontrole pristupa”, točka politike 4.2.1.

Oznaka „[Obje uloge]” znači da se kontrola primjenjuje bez obzira na to djeluje li organizacija kao voditelj obrade osobnih podataka (PII) ili izvršitelj obrade osobnih podataka (PII). Ta je razlika važna. Voditelji obrade često ne uspijevaju definirati pravila pristupa temeljena na svrsi. Izvršitelji obrade često ne uspijevaju dokazati da je pristup ograničen na upute klijenta, odobrene putove podrške i ugovorno ovlašteno osoblje.

Ista politika podiže kriterij za osjetljive osobne podatke ili osobne podatke (PII) visokog utjecaja:

[Obje uloge] Vlasnik sustava / vlasnik aplikacije MORA najmanje tromjesečno pregledati korisnički pristup sustavima koji obrađuju osobne podatke (PII) visokog utjecaja ili osjetljive osobne podatke (PII) i zabilježiti ishod pregleda u REG12.

Iz odjeljka „4.2 Polazna osnova kontrole pristupa”, točka politike 4.2.3.

Tu PIMS postaje provjerljiv u reviziji. Pregled pristupa nije samo e-poruka rukovoditelja. To je zapis u REG12, povezan sa sustavom, kategorijom podataka, ulogom, vlasnikom, ishodom pregleda i korektivnom radnjom.

Temelj politike: načelo najmanjih privilegija, poslovna potreba i zadana zabrana

Učinkovito upravljanje počinje provedivim pravilima. Prije nego što je Anya revizoru mogla pokazati zapisnik pregleda pristupa, morala je pokazati da je zahtjev za pregledima pristupa formalno uspostavljen.

Clarysecova SME Politika kontrole pristupa - SME postavlja načelo:

Ova politika provodi načelo najmanjih privilegija i zahtijeva da pristup bude ograničen na najmanju mjeru potrebnu za obavljanje radnih zadataka.

Iz odjeljka „Svrha”, točka politike 1.3.

SME Politika zaštite podataka i privatnosti - SME povezuje pristup s poslovnom potrebom:

Korisnički pristup osobnim podacima mora biti ograničen na uloge s dokumentiranom poslovnom potrebom

Iz odjeljka „Upravljački zahtjevi”, točka politike 5.3.2.

Za veće organizacije, korporativna Politika zaštite podataka i privatnosti izražava očekivanje kontrole kao zahtjev na razini sustava:

Svi sustavi moraju prema zadanim postavkama provoditi pristup prema načelu najmanjih privilegija.

Iz odjeljka „Zahtjevi za provedbu politike”, točka politike 6.3.1.

Razlika je važna. Manjoj organizaciji može biti dovoljan jednostavan, ali izričit zapis poslovne potrebe. Korporacija treba provedbu na razini sustava, periodične preglede, razdvajanje dužnosti, upravljanje privilegiranim pristupom i dokaze sačuvane za internu reviziju, dokazivanje sigurnosti prema zahtjevima klijenata, upite regulatornih tijela i istragu povrede.

Životni ciklus pristupa osobnim podacima (PII): odobrenje, uporaba, pregled, ukidanje

Najčešći propust u pristupu osobnim podacima (PII) nije početno odobrenje. To je zadržavanje pristupa.

Zenith Blueprint, u fazi Kontrole u praksi, korak 22, ovako objašnjava kontrolu ISO/IEC 27002:2022 5.18, Prava pristupa:

Kontrola 5.18 osigurava da se prava pristupa ne samo pravilno dodjeljuju, nego i pregledavaju, prilagođavaju i ukidaju na kontroliran i sljediv način.

Zatim opisuje poznate scenarije: novi zaposlenik dobije pristup, promijeni ulogu i zadrži stara ovlaštenja; bivši administrator ode, ali token ostane aktivan; račun ugovornog suradnika istekne na papiru, ali ne i u IAM-u. Upravo su to slabosti koje postaju sigurnosni incidenti prema GDPR-u kada su uključeni osobni podaci (PII).

Clarysecova SME Politika upravljanja korisničkim računima i privilegijama - SME postavlja polaznu učestalost:

Pregled svih korisničkih računa i privilegija mora se provoditi svakih šest mjeseci.

Iz odjeljka „Zahtjevi za provedbu politike”, točka politike 6.4.1.

Za korporativna okruženja, Politika upravljanja korisničkim računima i privilegijama pooštrava operativni ritam:

IT sigurnost mora provoditi tromjesečne preglede svih korisničkih računa i povezanih privilegija u suradnji s rukovoditeljima odjela.

Iz odjeljka „Zahtjevi za provedbu politike”, točka politike 6.5.1.

Praktičan životni ciklus pristupa osobnim podacima (PII) trebao bi uključivati:

  1. Klasificirati sustav i kategorije osobnih podataka (PII).
  2. Definirati odobrene uloge i dokumentiranu poslovnu potrebu.
  3. Mapirati uloge na svrhe obrade.
  4. Odobriti pristup prije omogućavanja.
  5. Provesti načelo najmanjih privilegija, razdvajanje dužnosti i snažnu autentifikaciju.
  6. Evidentirati autentifikaciju, pristup, izvoz, konfiguraciju i radnje s povišenim ovlastima.
  7. Pregledavati pristup prema učestalosti temeljenoj na riziku.
  8. Ukloniti pristup pri promjeni uloge, prestanku radnog odnosa, zatvaranju projekta, isteku ugovora ili uputi klijenta.
  9. Sačuvati dokaze u PIMS registru i revizijskom tragu.

To nije birokracija. To je način na koji organizacija dokazuje da je pristup osobnim podacima (PII) kontroliran u samoj arhitekturi, prema zadanim postavkama i dokazima.

Praktičan primjer: tromjesečni pregled pristupa osobnim podacima (PII)

Anyina revizija uspjela je kada je razgovor premjestila s izjava iz politika na dokaze.

Najprije se pozvala na Politiku sigurnosti osobnih podataka (PII) i kontrole pristupa, točku 4.2.3, koja zahtijeva tromjesečni pregled pristupa osobnim podacima (PII) visokog utjecaja ili osjetljivim osobnim podacima (PII) i evidentiranje ishoda pregleda u REG12.

Zatim je revizoru prikazala prethodno tromjesečje:

  • IT je generirao popis svih korisnika, grupa, uloga s povišenim ovlastima, servisnih računa, računa dobavljača, uloga za hitni pristup i ovlaštenja podrške za produkcijsku bazu podataka koja sadrži podatke pacijenata.
  • Popis je poslan vlasniku aplikacije, voditelju korisničke podrške, koji je bio odgovoran za operativnu potrebu tima za podršku.
  • Vlasnik aplikacije pregledao je popis redak po redak u odnosu na trenutačnu ulogu, odgovornost za korisničku podršku i svrhu obrade.
  • Dva agenta podrške koji su premješteni u druge timove označena su za ukidanje pristupa.
  • U sustavu za upravljanje IT uslugama izrađen je servisni zahtjev, povezan s pregledom pristupa, dodijeljen mu je SLA i zatvoren je nakon ukidanja pristupa.
  • REG12 je ažuriran zapisom pregleda, odobravateljem, iznimkama, zahtjevom za korektivnu radnju, dokazima o zatvaranju i datumom sljedećeg pregleda.

Rezultat je bio zatvoreni lanac dokaza. Anya nije samo rekla da Medtelligence primjenjuje načelo najmanjih privilegija. Pokazala je zahtjev iz politike, odgovornog vlasnika, popis pristupa, odluku pregleda, korektivnu radnju i dovršeno ukidanje pristupa.

To je razlika između kontrole pristupa i upravljanja pristupom.

Pristup dobavljača i izvršitelja obrade: slijepa točka u PIMS revizijama

Mnogi rizici neovlaštenog pristupa ulaze kroz podršku, izdvajanje poslova vanjskim izvođačima, integracijske partnere, pružatelje upravljanih usluga i podizvršitelje obrade. Izvršitelj obrade može imati udaljeni pristup produkcijskim podacima klijenta. Pružatelj usluga u oblaku može osiguravati pristupne putove podrške. Podizvršitelj obrade može održavati indeks pretraživanja koji sadrži identifikatore klijenata. Pružatelj upravljanih sigurnosnih usluga može pristupati dnevničkim zapisima koji sadrže osobne podatke.

Prema GDPR-u, voditelji obrade moraju koristiti izvršitelje obrade koji pružaju dostatna jamstva. Prema ISO/IEC 27701:2025, upravljanje izvršiteljima obrade i podizvršiteljima obrade mora se provoditi kroz dokumentirane upute, ugovorne kontrole, jamstva i nadzor. ISO/IEC 27002:2022 to podržava kontrolama odnosa s dobavljačima, uključujući 5.19 Informacijska sigurnost u odnosima s dobavljačima, 5.20 Uređivanje informacijske sigurnosti u ugovorima s dobavljačima i 5.21 Upravljanje informacijskom sigurnošću u IKT opskrbnom lancu.

Zenith Blueprint, faza Kontrole u praksi, korak 23, sažima područja dokaza u ugovorima s dobavljačima, uključujući:

✓ odgovornosti za kontrolu pristupa, kao što su tko može pristupiti vašim podacima, kako se upravlja vjerodajnicama i koje je praćenje uspostavljeno;

Uključuje i obveze povjerljivosti, tehničke i organizacijske mjere, rokove za prijavu incidenta, prava na reviziju, kontrole podizvođača i deaktivaciju računa na kraju ugovora.

Clarysecova Politika upravljanja privatnošću izvršitelja obrade, podizvršitelja obrade i trećih strana pretvara to u PIMS dokaze na strani voditelja obrade:

[Voditelj obrade] Voditelj privatnosti / Voditelj PIMS-a MORA prije odobrenja provjeriti da polja ugovornih kontrola izvršitelja obrade u REG08 obuhvaćaju opseg obrade, trajanje, svrhu, kategorije osobnih podataka (PII), kategorije ispitanika, povjerljivost, sigurnost, odobravanje podizvršitelja obrade, pomoć, reviziju ili jamstvo, povrat, brisanje i prestanak.

Iz odjeljka „4.3 Ugovorne kontrole i kontrole dokumentiranih uputa”, točka politike 4.3.2.

Pristup dobavljača također je izravno kontroliran u Clarysecovim SME i korporativnim politikama za dobavljače. SME Politika sigurnosti trećih strana i dobavljača - SME navodi:

Dobavljačima se smije dodijeliti pristup samo minimalnom skupu sustava i podataka potrebnih za obavljanje njihove funkcije.

Iz odjeljka „Zahtjevi za provedbu politike”, točka politike 6.2.1.

Korporativna Politika sigurnosti trećih strana i dobavljača dodaje RBAC, pregled i načelo najmanjih privilegija:

Osoblje dobavljača mora podlijegati kontroli pristupa na temelju uloga (RBAC), periodičnim pregledima pristupa i provedbi načela najmanjih privilegija.

Iz odjeljka „Zahtjevi za provedbu politike”, točka politike 6.3.1.

Ako pristup dobavljača može dosegnuti osobne podatke (PII), pripada u PIMS. Trebao bi biti vidljiv u ugovornim kontrolama, odobrenjima pristupa, IAM grupama, opsegu evidentiranja događaja, zapisima pregleda, zapisima postupka odlaska, operativnim uputama za incidente i revizijskim dokazima.

Pristup osobnim podacima (PII) u oblaku: podijeljena odgovornost nije podijeljena odgovornost za dokazivanje

Upravljanje pristupom osobnim podacima (PII) u oblaku područje je u kojem organizacije često precjenjuju pružatelja usluga i podcjenjuju vlastite odgovornosti. Pružatelj usluga u oblaku može osiguravati infrastrukturu, ali klijent i dalje upravlja identitetima, ulogama, konfiguracijom zakupca, pristupom podrške, dnevničkim zapisima, postavkama šifriranja, ovlaštenjima za izvoz i spremnošću za odgovor na incidente.

Zenith Blueprint, faza Kontrole u praksi, korak 23, to izravno navodi u smjernicama za usluge u oblaku:

Pružatelji usluga u oblaku osiguravaju infrastrukturu, ali vi ste i dalje odgovorni za svoje podatke, svoje konfiguracije, svoje politike pristupa i svoju spremnost za odgovor na incidente.

Također upozorava:

U oblaku je vidljivost djelomična osim ako se namjerno ne projektira. Morate konfigurirati evidentiranje događaja, provoditi šifriranje, definirati uloge identiteta i pratiti aktivnosti putem izvornih alata ili integracija trećih strana. To nije infrastrukturni zadatak, nego zahtjev ISMS-a.

Clarysecova Politika korištenja usluga u oblaku pretvara to u korporativni zahtjev za pristup:

Sve usluge u oblaku moraju provoditi kontrolu pristupa temeljenu na identitetu, usklađenu s načelom najmanjih privilegija.

Iz odjeljka „Zahtjevi za provedbu politike”, točka politike 6.2.1.

Za organizacije koje djeluju kao izvršitelji obrade u okruženjima oblaka, Clarysecova Politika izvršitelja obrade osobnih podataka (PII) u oblaku definira konkretniju PIMS obvezu pregleda:

[Izvršitelj obrade] Voditelj informacijske sigurnosti MORA najmanje tromjesečno u REG12 pregledati privilegirani pristup oblaku, pristup podrške, pristup osobnim podacima (PII) klijenta i obuhvat evidentiranja događaja.

Iz odjeljka „4.2 Konfiguracija oblaka, izolacija zakupaca, pristup i evidentiranje događaja”, točka politike 4.2.4.

Ta je točka posebno relevantna za SaaS društva, platforme hostirane u oblaku, upravljane podatkovne usluge i B2B izvršitelje obrade.

Područje pristupa osobnim podacima (PII) u oblakuŠto provjeritiTipični dokazi
Privilegirani pristup oblakuAdministratorske uloge su odobrene, ograničene, nadzirane i pregledaneIAM izvoz, odobrenje privilegiranog pristupa, zapis pregleda
Pristup podrškeOsoblje podrške može pristupiti osobnim podacima (PII) klijenta samo kroz odobrene radne tokoveDnevnički zapisi pristupa podrške, veza sa servisnim zahtjevom, zapis upute klijenta
Pristup osobnim podacima (PII) klijentaPristup se mapira na zakupca, ulogu, svrhu i poslovnu potrebuREG12 zapis, matrica uloga, odobrenje vlasnika sustava
Obuhvat evidentiranja događajaObuhvaćeni su događaji autentifikacije, pristupa, izvoza, radnji s povišenim ovlastima i konfiguracijeOpseg evidentiranja događaja, SIEM upit, registar revizijskog traga

Upravljanje pristupom osobnim podacima (PII) u oblaku nije potpuno ako se izvorni dnevnički zapisi oblaka, IAM politike, servisni računi, uloge s povišenim ovlastima, alati korisničke podrške, API ključevi i funkcije izvoza podataka ne pregledavaju zajedno.

Evidentiranje događaja i nadzor: memorija upravljanja osobnim podacima (PII)

PIMS program kontrole pristupa bez dnevničkih zapisa obećanje je bez memorije.

Politika sigurnosti osobnih podataka (PII) i kontrole pristupa zahtijeva opseg evidentiranja događaja prije produkcijske uporabe ili značajne promjene:

[Obje uloge] Vlasnik sustava / vlasnik aplikacije MORA definirati opseg evidentiranja događaja za osobne podatke (PII) za događaje autentifikacije, događaje pristupa, radnje s povišenim ovlastima, aktivnosti izvoza osobnih podataka (PII) i značajne promjene konfiguracije u REG12 prije produkcijske uporabe ili značajne promjene.

Iz odjeljka „4.6 Evidentiranje događaja i nadzor”, točka politike 4.6.1.

SME Politika evidentiranja događaja i nadzora - SME izričito navodi sadržaj zapisa pristupa:

Zapisi pristupa: pristup datotekama (osobito za osjetljive ili osobne podatke), promjene ovlaštenja, uporaba dijeljenih resursa

Iz odjeljka „Upravljački zahtjevi”, točka politike 5.4.3.

Korporativna Politika evidentiranja događaja i nadzora usmjerena je na upotrebljivost u reviziji:

Registar revizijskog traga ISMS-a mora evidentirati dostupnost podataka iz dnevničkih zapisa za revizije, istrage i regulatorne preglede.

Iz odjeljka „Upravljački zahtjevi”, točka politike 5.4.

To je ključno jer dokazi o privatnosti često moraju odgovoriti na pitanja temeljena na događajima:

  • Tko je pristupio osobnim podacima (PII)?
  • Je li pristup bio ovlašten?
  • Je li pristup bio povezan sa servisnim zahtjevom podrške, pravnim zahtjevom, operativnim zadatkom ili uputom klijenta?
  • Jesu li podaci izvezeni, kopirani, izmijenjeni ili izbrisani?
  • Je li korišten privilegirani pristup?
  • Jesu li ovlaštenja promijenjena prije ili nakon pristupa?
  • Je li aktivnost upućivala na sigurnosni incident ili povredu osobnih podataka?

Dnevnički zapisi nisu samo za SOC. Oni su PIMS dokazi, dokazi za dokazivanje sigurnosti prema zahtjevima klijenata, dokazi o jamstvima izvršitelja obrade i dokazi za odgovor na incidente.

Mapiranje usklađenosti među okvirima: jedan model pristupa, više perspektiva

Slabost u pregledima pristupa osobnim podacima (PII) nikada nije samo jedan nalaz. Može postati problem načela odgovornosti prema GDPR-u, slabost PIMS-a prema ISO/IEC 27701:2025, nesukladnost prema ISO/IEC 27001:2022, propust u upravljanju prema NIS2, pitanje otpornosti prema DORA-i, praznina u upravljanju prema NIST CSF 2.0 ili pitanje zrelosti procesa prema COBIT 2019.

Perspektiva okviraŠto će revizor vjerojatno pitatiClarysecova sidrišna točka dokaza
GDPRMožete li dokazati cjelovitost, povjerljivost, načelo odgovornosti i zaštitu od neovlaštene obrade?Matrica uloga za osobne podatke (PII), REG12 pregled pristupa, opseg evidentiranja događaja, trag istrage povrede
ISO/IEC 27701:2025Jesu li obveze pristupa voditelja obrade i izvršitelja obrade ugrađene u PIMS?PIMS oznake uloga, Politika sigurnosti osobnih podataka (PII) i kontrole pristupa, REG08 kontrole izvršitelja obrade
ISO/IEC 27001:2022Je li rizik pristupa osobnim podacima (PII) procijenjen, obrađen, uključen u SoA, operativno proveden i vrednovan?Procjena rizika, plan obrade rizika, SoA, zapisi o implementaciji kontrole pristupa
NIS2Upravlja li rukovodstvo kontrolom pristupa, sigurnošću ljudskih resursa, upravljanjem imovinom, sigurnošću dobavljača, osposobljavanjem i postupanjem s incidentima?Dokazi o odobrenju upravnog odbora, kontrole pristupa dobavljača, zapisi o osposobljavanju, operativne upute za incidente
DORAJesu li IKT kontrole pristupa, IKT rizici trećih strana, evidentiranje događaja, revizija, testiranje i korektivne radnje dio operativne otpornosti?Okvir IKT rizika, pregledi pristupa oblaku, izvješće interne revizije, alat za praćenje korektivnih radnji
NIST CSF 2.0Jesu li obveze privatnosti i kibernetičke sigurnosti upravljane, resursno podržane, komunicirane i pregledavane?Registar upravljanja, zapisi pregleda politike, mapiranje apetita za rizik, stavke rizika dobavljača
COBIT 2019Je li upravljanje pristupom kontrolirano kao ponovljiv upravljački proces s odgovornostima i metrikama?RACI, KPI procesa, učestalost pregleda, izvješćivanje o iznimkama, korektivne radnje

Detaljnije mapiranje kontrola pokazuje kako jedan proces upravljanja pristupom osobnim podacima (PII) podržava više zahtjeva:

Zahtjev kontroleISO/IEC 27001:2022 i ISO/IEC 27002:2022GDPRNIS2DORA
Redoviti pregled pristupa osobnim podacima (PII)ISO/IEC 27001:2022 točke 8.1, 9.1, Annex A 5.18 Prava pristupaArticle 5(1)(f), Article 32Article 21(2)(i)Article 6, Article 9
Evidentiranje događaja pristupa osobnim podacima (PII)Annex A 8.15 Evidentiranje događaja, Annex A 8.16 Aktivnosti nadzoraArticle 32Article 21(2)(b), Article 21(2)(i)Article 10
Upravljanje pristupom dobavljačaAnnex A 5.19, 5.20, 5.21Article 28Article 21(3)Article 28, Article 30
Upravljanje pristupom i konfiguracijom u oblakuAnnex A 5.23 Informacijska sigurnost za korištenje usluga u oblaku, Annex A 8.3 Ograničenje pristupa informacijamaArticle 32Article 21(2)(e), Article 21(2)(i)Article 6, Article 9, Article 28
Odabir kontrola i dokazi temeljeni na rizikuTočke 6.1.1, 6.1.2, 6.1.3, 8.2, 8.3Article 5(2), Article 24Article 20, Article 21Article 5, Article 6

Vrijednost Zenith Controls jest u tome što timovi mogu mapirati te perspektive natrag na iste dokaze o kontrolama, umjesto da održavaju odvojene silose usklađenosti.

Provedite 45-minutni sprint dokaza o pristupu osobnim podacima (PII)

Korisno je spremnost testirati odabirom jednog sustava visokog utjecaja, primjerice platforme korisničke podrške, HR sustava, portala za plaćanje, portala za pacijente, podatkovnog jezera ili SaaS produkcijske baze podataka, i provedbom usmjerenog sprinta dokaza.

Korak 1: Definirajte kontekst obrade osobnih podataka (PII)

Zabilježite u REG12:

  • Naziv sustava i vlasnika
  • Kategorije osobnih podataka (PII)
  • Kategorije ispitanika
  • Uloga voditelja obrade ili izvršitelja obrade
  • Svrha obrade
  • Pokazatelj osobnih podataka (PII) visokog utjecaja ili osjetljivih osobnih podataka (PII)
  • Ovisnosti o oblaku, dobavljačima i podizvršiteljima obrade

Ako sustav uključuje izvršitelja obrade, provjerite polja ugovornih kontrola u REG08 primjenom Politike upravljanja privatnošću izvršitelja obrade, podizvršitelja obrade i trećih strana. Odobrenje treba obuhvatiti opseg obrade, trajanje, svrhu, kategorije osobnih podataka (PII), kategorije ispitanika, povjerljivost, sigurnost, odobravanje podizvršitelja obrade, pomoć, reviziju ili jamstvo, povrat, brisanje i prestanak.

Korak 2: Izvezite popis pristupa

Izvezite sve korisnike, grupe, uloge s povišenim ovlastima, servisne račune, uloge podrške, račune za hitni pristup, API ključeve i račune dobavljača. Usporedite svako ovlaštenje s odobrenim ulogama.

Status pristupaZnačenjeNeposredna radnja
Odobren i potrebanPristup se mapira na ulogu, svrhu i poslovnu potrebuZadržati i zabilježiti dokaz
Odobren, ali prekomjeranKorisnik ima više pristupa nego što je potrebnoSmanjiti ovlaštenja i dokumentirati promjenu
Nepoznata poslovna potrebaNe postoji jasna svrha ili odobrenjeObustaviti ili eskalirati radi provjere vlasnika
Napušteni korisnički računRačun nije povezan s aktivnim korisnikom ili vlasnikomOnemogućiti i istražiti
Pristup dobavljača ili podizvršitelja obradeVanjska strana može pristupiti osobnim podacima (PII)Provjeriti ugovor, odobrenje, evidentiranje događaja i pregled
Privilegirani ili hitni pristupPostoji pristup s povišenim ovlastimaPotvrditi odobrenje, MFA, nadzor i pregled nakon uporabe
Servisni račun koji zahtijeva provjeruNeljudski račun ima pristup osobnim podacima (PII)Potvrditi vlasnika, svrhu, rotaciju tajni i evidentiranje događaja

Korak 3: Potvrdite načelo najmanjih privilegija i usklađenost sa svrhom

Primijenite polaznu osnovu iz Politike sigurnosti osobnih podataka (PII) i kontrole pristupa: pristup mora biti ograničen na odobrene uloge i ovlaštene korisnike koji su zabilježeni ili sljedivi u REG02 ili REG12 prije omogućavanja. Ako korisnika nije moguće povezati s ulogom, svrhom i odobrenjem, nalaz nije „nedostaje dokumentacija”. Nalaz je „pristup osobnim podacima (PII) nije dokazivo ovlašten”.

Korak 4: Provjerite opseg evidentiranja događaja

Potvrdite da dnevnički zapisi obuhvaćaju autentifikaciju, događaje pristupa, radnje s povišenim ovlastima, aktivnosti izvoza osobnih podataka (PII) i značajne promjene konfiguracije. Zatim potvrdite gdje se dnevnički zapisi pohranjuju, koliko se dugo zadržavaju, tko im može pristupiti i jesu li evidentirani u Registru revizijskog traga ISMS-a za revizije, istrage i regulatorne preglede.

Korak 5: Zatvorite petlju

Za svaku iznimku zabilježite vlasnika rizika, neposrednu radnju ograničavanja, trajnu korektivnu radnju, ciljni datum, potrebne dokaze, odluku o preostalom riziku i je li potrebna procjena povrede.

Ova jedna vježba obično otkriva stvarnu zrelost upravljanja pristupom osobnim podacima (PII). Snažne organizacije odgovaraju brzo. Slabe organizacije otkriju da su politika privatnosti, IAM konfiguracija, ugovori s izvršiteljima obrade, evidentiranje događaja u oblaku i revizijski dokazi nepovezani.

Uobičajeni revizijski nalazi u upravljanju pristupom osobnim podacima (PII)

Većina nalaza je predvidljiva. Nastaju kada privatnost, sigurnost, pravni poslovi, IT i dobavljači svaki kontroliraju dio priče, ali nitko ne posjeduje cjelovit životni ciklus pristupa osobnim podacima (PII).

Uobičajeni nalazi uključuju:

  • PII sustavi nisu u cijelosti navedeni u PIMS popisu.
  • Uloge pristupa definirane su tehnički, ali nisu mapirane na svrhe obrade.
  • Osjetljivi osobni podaci (PII) dostupni su kroz široke operativne grupe.
  • Tromjesečni pregledi obuhvaćaju zaposlenike, ali ne i servisne račune, API ključeve ili korisnike dobavljača.
  • Pristup podrške u oblaku moguć je, ali se ne pregledava kao pristup osobnim podacima (PII).
  • Dnevnički zapisi postoje, ali ne dokazuju pristup osobnim podacima (PII), izvoz ili aktivnost s povišenim ovlastima.
  • Ugovori s izvršiteljima obrade uključuju generičke odredbe o povjerljivosti, ali ne i konkretne kontrole pristupa, revizije, podizvršitelja obrade, povrata, brisanja ili prestanka.
  • Bivši zaposlenici ili ugovorni suradnici zadržavaju pristup kroz dijeljene grupe ili neupravljane tokene.
  • Pristup skladištu podataka širi je od pristupa izvornoj aplikaciji.
  • Računi za hitni pristup postoje bez pregleda nakon uporabe.
  • Pristup korisničke podrške u ime korisnika nije evidentiran u dnevničkim zapisima s kontekstom servisnog zahtjeva.
  • Izjava o primjenjivosti uključuje kontrole pristupa, ali dokazi ne pokazuju implementaciju specifičnu za osobne podatke (PII).

Svaki od tih nalaza može postati problem načela odgovornosti prema GDPR-u, pitanje dokazivanja sigurnosti prema zahtjevima klijenata, slabost upravljanja prema NIS2 ili DORA-i ili nesukladnost prema ISO/IEC 27001:2022, ovisno o opsegu.

Kako izgleda dobar model

Zreo operativni model ne oslanja se na herojska tromjesečna čišćenja. On ugrađuje upravljanje pristupom osobnim podacima (PII) u redovno poslovanje.

Prvo, organizacija ima svijest o podacima. Zna gdje postoje osobni podaci (PII), zašto se obrađuju, koja se PIMS uloga primjenjuje i koji su sustavi, dobavljači, usluge u oblaku, dnevnički zapisi, sigurnosne kopije i izvozi u opsegu.

Drugo, pristup je temeljen na ulogama i usklađen sa svrhom. Ovlaštenja su definirana odobrenim ulogama, dokumentiranom poslovnom potrebom, svrhom obrade i načelom najmanjih privilegija.

Treće, kontrole se tehnički provode. IAM, RBAC, upravljanje privilegiranim pristupom, MFA, uvjetni pristup, kontrole zakupaca, šifriranje i razdvajanje okruženja provode očekivanja politike.

Četvrto, nadzor je namjerno projektiran. Organizacija može rekonstruirati autentifikaciju, pristup, izvoz, radnje s povišenim ovlastima, pristup podrške i promjene konfiguracije koje utječu na osobne podatke (PII).

Peto, pregledi su temeljeni na riziku i dokumentirani. Osobni podaci (PII) visokog utjecaja pregledavaju se najmanje tromjesečno. Uključeni su pristup dobavljača i pristup podrške u oblaku. Iznimke se prate do zatvaranja.

Šesto, dokazi su ponovno upotrebljivi. Isti zapisi podržavaju načelo odgovornosti prema GDPR-u, rad PIMS-a prema ISO/IEC 27701:2025, obradu rizika prema ISO/IEC 27001:2022, mjere upravljanja rizicima prema NIS2, upravljanje IKT rizicima prema DORA-i, ishode GOVERN prema NIST CSF 2.0 i upravljačko osiguranje prema COBIT 2019.

To je razlika između kontrole pristupa kao postavke i upravljanja pristupom kao sustava.

Pretvorite pristup osobnim podacima (PII) u dokaze spremne za reviziju

Ako bi vaša sljedeća revizija, pregled klijenta ili upit regulatornog tijela sutra počeli pitanjem „pokažite mi tko može pristupiti osobnim podacima (PII)”, bi li vaš tim dostavio dokaze u nekoliko minuta ili bi počeo usklađivati proračunske tablice?

Clarysec vam može pomoći zatvoriti tu prazninu.

Počnite s Politikom sigurnosti osobnih podataka (PII) i kontrole pristupa, uskladite obveze izvršitelja obrade i obveze u oblaku kroz Politiku upravljanja privatnošću izvršitelja obrade, podizvršitelja obrade i trećih strana i Politiku izvršitelja obrade osobnih podataka (PII) u oblaku, zatim upotrijebite Zenith Blueprint: revizorov plan provedbe u 30 koraka za implementaciju kontrola pravim redoslijedom. Na kraju, upotrijebite Zenith Controls: vodič za mapiranje usklađenosti među okvirima za mapiranje dokaza o pristupu osobnim podacima (PII) kroz ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 i COBIT 2019.

Najbrži praktični sljedeći korak jednostavan je: odaberite jedan PII sustav visokog utjecaja, popunite REG12, izvezite popis pristupa, provjerite opseg evidentiranja događaja i provedite pregled u stilu tromjesečnog pregleda. U jednoj sesiji znat ćete je li vaše upravljanje pristupom osobnim podacima (PII) spremno za reviziju ili samo spremno na razini politike.

Frequently Asked Questions

About the Author

Igor Petreski

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

Share this article

Related Articles