Ocena tveganj za zasebnost za ISO 27701 in GDPR
Ponedeljkov jutranji sestanek je bil Marii, vodji informacijske varnosti v hitro rastočem podjetju s področja zdravstvenih tehnologij, dobro znan.
Generalni direktor je želel preprosto nadzorno ploščo, ki bi prikazovala izpostavljenost tveganjem po GDPR, preden podjetje uvede platformo za analitiko pacientov, podprto z umetno inteligenco. Novi vodja zasebnosti, David, je imel evidenco dejavnosti obdelave (Record of Processing Activities, RoPA) s 50 zavihki. Inženirska ekipa je zavarovala okolje v oblaku. Produktna ekipa je bila pripravljena na objavo. Dobavitelj je svoj nabor podobdelovalcev opisal kot »primeren za velika podjetja«.
Toda razpravo je ustavilo eno vprašanje.
»Kakšno je naše dejansko tveganje in ali lahko poslovnim strankam dokažemo, da ga obvladujemo?«
RoPA je prikazoval, kaj podjetje obdeluje. Register varnostnih tveganj je prikazoval infrastrukturna tveganja. Nekaj DPIA je bilo v ločenih dokumentih. Pregledi dobaviteljev so bili shranjeni v nabavnih mapah. Nihče pa ni mogel prikazati ene same sledljive verige odločitev od dejavnosti obdelave do tveganja za zasebnost, odločitve o DPIA, načrta obravnave tveganja, preslikave kontrol, odobritve preostalega tveganja in datuma pregleda.
To je vrzel, s katero se srečujejo številne organizacije pri prehodu na ISO/IEC 27701:2025 in pri dokazovanju odgovornosti po GDPR. Imajo obvestila o zasebnosti, vprašalnike za dobavitelje, vnose v RoPA, zemljevide podatkovnih tokov, predloge DPIA in kontrole ISO/IEC 27001:2022. Pogosto pa jim manjka operativna plast, ki vse to poveže.
Zrel sistem upravljanja informacij o zasebnosti oziroma PIMS ocene tveganj za zasebnost ne obravnava kot stranskega pravnega dokumenta. Obravnava jo kot ponovljiv delovni proces odločanja: identificirati obdelavo, preveriti tveganje, odločiti, ali je potrebna DPIA, izbrati kontrole, dodeliti lastnike, odobriti preostalo tveganje, spremljati sprožilce in hraniti dokazila.
Tu Clarysecovi paketi politik, Zenith Blueprint in Zenith Controls ekipam pomagajo preiti od nepovezanih preglednic do zagovorljivega mehanizma za obvladovanje tveganj za zasebnost.
Ocena tveganj za zasebnost je manjkajoča operativna plast
Odgovornost po GDPR se pogosto zoži na »imeti dokumentacijo«. Dokumentacija je pomembna, vendar gre Article 5(2) dlje. Upravljavec je odgovoren za skladnost z načeli iz Article 5(1) in jo mora biti sposoben dokazati, vključno z zakonitostjo, poštenostjo, preglednostjo, omejitvijo namena, najmanjšim obsegom podatkov, točnostjo, omejitvijo hrambe, celovitostjo in zaupnostjo.
To zahteva več kot RoPA. Organizacija mora biti sposobna pojasniti, zakaj je določena dejavnost obdelave sprejemljiva, katera tveganja povzroča posameznikom, katere kontrole ta tveganja zmanjšujejo, kdo je lastnik odločitve in kdaj je treba odločitev pregledati.
ISO/IEC 27701:2025 to pričakovanje krepi z vključitvijo upravljanja zasebnosti v upravljan PIMS. V praksi mora ocena tveganj za zasebnost povezati šest operativnih objektov:
- Popis obdelave osebno določljivih podatkov oziroma RoPA.
- Dokumentacijo pravne podlage in namena.
- Preverjanje tveganj za zasebnost in odločanje o DPIA.
- Obravnavo tveganj in izbor kontrol.
- Upravljanje dobaviteljev, obdelovalcev in podobdelovalcev.
- Dokazila, hranjena v ISMS in PIMS.
Clarysec to povezavo izrecno določa. V Enterprise Politiki ocenjevanja tveganj za zasebnost in DPIA se sprožilec pojavi pred začetkom obdelave:
[Oba] Lastnik procesa / lastnik poslovnega področja MORA sprožiti preverjanje tveganj za zasebnost v REG04, preden se začne nova ali bistveno spremenjena obdelava osebno določljivih podatkov, zabeležena v REG02.
Enaka disciplina v predhodni fazi je določena v Enterprise Politiki popisa obdelav osebno določljivih podatkov in pravne podlage:
[Oba] Lastnik procesa / lastnik poslovnega področja MORA sprožiti preverjanje tveganj za zasebnost in DPIA v REG04, preden se nadaljuje nova ali bistveno spremenjena obdelava osebno določljivih podatkov.
S tem se prepreči pogost vzorec neuspeha: produkt je uveden, RoPA se posodobi pozneje, vprašanje DPIA pride prepozno, register tveganj pa nikoli ne prejme scenarija tveganja za zasebnost.
Za upravljavce to podpira disciplino pravne podlage po GDPR Article 6, vgrajeno in privzeto varstvo podatkov po Article 25, varnost obdelave po Article 32 ter odgovornost po Article 5. Za obdelovalce podpira dokumentirana navodila, zagotavljanje zaupanja naročnikom, pogodbene meje in preglednost podobdelovalcev.
Začnite z dejanskim stanjem obdelave, ne s prazno predlogo
Ocena tveganj za zasebnost odpove, kadar se začne s praznim obrazcem in brez operativnega konteksta. Prvo vprašanje ne bi smelo biti: »Ali potrebujemo DPIA?« Prvo vprašanje bi moralo biti: »Katera obdelava se dejansko spreminja?«
Za organizacijo SaaS, finančnotehnološko ali zdravstvenotehnološko organizacijo lahko sprememba vključuje:
- Novo kategorijo podatkov, kot so vedenjski podatki o uporabi, zdravstveni podatki, biometrični signali ali metapodatki plačil.
- Nov namen, kot so ocenjevanje goljufij, analitika pacientov, podpora s pomočjo umetne inteligence, napovedovanje odhoda strank ali personalizacija.
- Novega prejemnika, obdelovalca ali podobdelovalca.
- Nov podporni delovni proces ali čezmejno pot dostopa.
- Nov rok hrambe.
- Nov model, algoritem ali avtomatizirano priporočilo.
- Novo skupino posameznikov, na katere se nanašajo podatki, kot so mladoletniki, zaposleni, pacienti ali finančno ranljivi posamezniki.
Opredelitve v GDPR so široke. Osebni podatki vključujejo identifikatorje, spletne identifikatorje, podatke o lokaciji in dejavnike, povezane z identiteto. Obdelava vključuje zbiranje, hrambo, priklic, uporabo, razkritje, omejitev, izbris in uničenje. Kršitev varnosti osebnih podatkov vključuje nenamerno ali nezakonito uničenje, izgubo, spremembo, nepooblaščeno razkritje ali dostop.
To pomeni, da mora delovni proces za tveganja za zasebnost zajeti več kot zgolj vprašanje, ali je podatkovna baza šifrirana. Zajeti mora, zakaj obdelava obstaja, ali je namen združljiv, ali je pravna podlaga veljavna, ali so vključeni podatki posebnih vrst, ali lahko posamezniki razumejo obdelavo in ali so zaščitni ukrepi sorazmerni.
Za manjše ekipe SME Politika varstva podatkov in zasebnosti določa izhodišče v točki 5.2.1:
Koordinator za zasebnost mora vzdrževati register vseh dejavnosti obdelave osebnih podatkov, vključno s kategorijami podatkov, namenom, pravno podlago in roki hrambe.
Ta register ni birokracija. Je vhodni model za oceno tveganj za zasebnost. Brez kategorij podatkov, namena, pravne podlage in rokov hrambe ocena ne more zanesljivo ovrednotiti omejitve namena, najmanjšega obsega podatkov, omejitve hrambe, preglednosti ali poštenosti.
Ista SME politika v točki 7.1.1 določa tudi pregled tveganj kot ponavljajočo se obveznost:
Koordinator za zasebnost mora vsako leto in ob večjih spremembah sistemov oceniti tveganja za zasebnost.
Za podjetja je periodika upravljanja strožja. Enterprise Politika varstva podatkov in zasebnosti določa:
Registri tveganj za zasebnost se vodijo znotraj ISMS in jih najmanj četrtletno pregledata pooblaščena oseba za varstvo podatkov (DPO) in vodja informacijske varnosti.
Tu integracija ISO/IEC 27701:2025 in ISO/IEC 27001:2022 postane praktična. Tveganja za zasebnost niso zakopana v pravnih mapah. Pregledujejo se skupaj z varnostnimi tveganji, tveganji dobaviteljev, incidenti, ugotovitvami presoj, načrti obravnave tveganj in poročanjem vodstvu.
Clarysecov delovni proces od REG02 do REG04
Najučinkovitejši proces ocenjevanja tveganj za zasebnost je dovolj preprost za lastnike poslovnih področij in dovolj strog za presojevalce. Clarysecov model uporablja REG02 kot popis obdelave osebno določljivih podatkov, REG04 pa kot zapis ocene tveganj za zasebnost in DPIA.
| Točka delovnega procesa | Praktično vprašanje | Ustvarjena dokazila | Lastnik |
|---|---|---|---|
| Vnos obdelave v REG02 | Kateri osebno določljivi podatki se obdelujejo, za kateri namen, kdo jih obdeluje in na kateri pravni podlagi? | Zapis v popisu dejavnosti obdelave, pravna podlaga, kategorije podatkov, rok hrambe | Lastnik procesa |
| Preverjanje v REG04 | Ali dejavnost ustvarja povišano tveganje za posameznike ali sproži merila za DPIA? | Odločitev o preverjanju zasebnosti, utemeljitev, datum pregleda | Vodja zasebnosti ali vodja PIMS |
| Odločitev o DPIA | Ali je pred začetkom ali spremembo obdelave zahtevana celovita DPIA? | Zapis DPIA ali dokumentirana utemeljitev, da DPIA ni potrebna | DPO ali vodja zasebnosti |
| Obravnava tveganja | Katere kontrole zmanjšajo tveganje na sprejemljivo raven? | Načrt obravnave tveganja, preslikava kontrol, roki za izvedbo | Lastnik tveganja |
| Odobritev preostalega tveganja | Kdo sprejme preostalo visoko tveganje in pod katerimi pogoji? | Zapis odobritve, utemeljitev sprejema | Najvišje vodstvo, kjer je zahtevano |
| Sprožilec pregleda | Katere spremembe ponovno odprejo oceno? | Datum pregleda, sprožilci sprememb, dokazila spremljanja | Lastnik procesa in vodja zasebnosti |
Politika ocenjevanja tveganj za zasebnost in DPIA določa najmanjša dokazila, ki morajo obstajati, preden se REG04 lahko zapre:
[Oba] Vodja zasebnosti / vodja PIMS MORA pred zaprtjem zagotoviti, da vsaka ocena REG04 zabeleži oceno tveganja, odločitev o obravnavi, lastnika, rok za izvedbo, preostalo tveganje, status odobritve in datum pregleda.
Ta stavek je operativno ogrodje. Ocena tveganj za zasebnost ni zaključena zato, ker je nekdo v polje za komentar zapisal »nizko tveganje«. Zaključena je, ko zapis vključuje oceno, odločitev o obravnavi, lastnika, rok za izvedbo, preostalo tveganje, status odobritve in datum pregleda.
Za SME je ista disciplina prilagojena obsegu. SME Politika upravljanja tveganj določa:
Vsak vnos tveganja mora vključevati: opis, verjetnost, vpliv, oceno, lastnika in načrt obravnave tveganja.
Načelo je sorazmernost, ne neformalnost. Manjše organizacije lahko uporabljajo preprostejši register, vendar vsako tveganje še vedno potrebuje opis, oceno, lastnika in načrt obravnave tveganja.
Za zasebnost uporabite mehanizem obvladovanja tveganj ISO/IEC 27001:2022
Tveganje za zasebnost ne sme obstajati zunaj organizacijske metode upravljanja tveganj. ISO/IEC 27001:2022 že zagotavlja mehanizem sistema upravljanja: kontekst, zainteresirane strani, obseg, vodenje, oceno tveganj, obravnavo tveganj, operativni nadzor, dokumentirane informacije, vrednotenje uspešnosti in nenehno izboljševanje.
Točke 4.1 do 4.4 zahtevajo, da organizacija razume notranja in zunanja vprašanja, zahteve zainteresiranih strani, obseg ISMS in procese ISMS. Pri zasebnosti zainteresirane strani vključujejo stranke, posameznike, na katere se nanašajo podatki, zaposlene, regulatorje, obdelovalce, podobdelovalce, nadzorne organe, nadzornike finančnega sektorja, kjer je relevantno, in pogodbene naročnike.
Točka 6.1.2 zahteva proces ocenjevanja tveganj informacijske varnosti. Točka 6.1.3 zahteva obravnavo tveganj informacijske varnosti, vključno z izbiro kontrol, pripravo izjave o uporabnosti, oblikovanjem načrta obravnave tveganj ter pridobitvijo odobritve lastnika tveganja za načrt in preostala tveganja. Točki 8.2 in 8.3 zahtevata izvajanje ocen tveganj informacijske varnosti in obravnav tveganj v načrtovanih intervalih ali ob pomembnih spremembah, ob hrambi dokumentiranih rezultatov.
Clarysecova Enterprise Politika upravljanja tveganj se s to strukturo usklajuje v točki 5.1:
Formalni proces upravljanja tveganj se vzdržuje v skladu z ISO/IEC 27005 in ISO 31000 ter zajema identifikacijo tveganj, analizo, vrednotenje, obravnavo, spremljanje in komuniciranje.
Pri zasebnosti morajo merila tveganja vključevati vpliv na posameznike, ne le vpliva na poslovanje. Nizka finančna izguba je lahko še vedno visok vpliv na zasebnost, če obdelava vključuje podatke posebnih vrst, ranljive posameznike, profiliranje, nepreglednost, nezakonito hrambo, nezmožnost uveljavljanja pravic ali nepremoženjsko škodo.
Clarysecov Zenith Blueprint: 30-koračni časovni načrt presojevalca to pojasnjuje v fazi upravljanja tveganj, korak 10:
Pri opredelitvi vpliva je smiselno ravni povezati z obsegom vašega poslovanja. Na primer: »Večji finančni vpliv = izguba > 100.000 USD« (prilagodite svojemu kontekstu). Upoštevajte tudi regulativni vpliv: na primer, kršitev varnosti osebnih podatkov je lahko zaradi glob po GDPR in zahtev glede obveščanja samodejno ocenjena kot »večja« ali »huda«, tudi če neposredna finančna izguba ni jasna.
Ta usmeritev je posebej pomembna za analitiko z umetno inteligenco, zdravstvene podatke, finančno profiliranje, spremljanje zaposlenih in ocenjevanje strank. Škoda je lahko pravna, ugledna, diskriminatorna, operativna, pogodbena ali osebna.
Praktičen primer: analitika pacientov z umetno inteligenco
Vrnimo se k Marii in Davidu. Njuna zdravstvenotehnološka platforma bo obdelovala posebne vrste zdravstvenih podatkov po GDPR Article 9. Uporabljala bo zgodovino pacientov, podatke o pregledih, zapise zdravnikov in izhode modela za ustvarjanje vpogledov v tveganja.
Z uporabo Zenith Blueprint začneta s korakom 9, identifikacijo sredstev, groženj in ranljivosti:
Za vsako sredstvo zabeležite ključne podatke: ime/opis, lastnik, lokacija in razvrstitev (občutljivost). Sredstvo je lahko na primer »podatkovna baza strank – lastnik je oddelek IT – gostuje v AWS – vsebuje osebne in finančne podatke (visoka občutljivost)«.
Isti korak doda vidik zasebnosti:
Zagotovite, da so sredstva z osebnimi podatki označena (zaradi relevantnosti za GDPR), ključna sredstva storitev pa zabeležena (zaradi morebitne uporabljivosti NIS2, če delujete v reguliranem sektorju).
Mariina ekipa identificira platformo za analitiko pacientov z umetno inteligenco, podatkovno bazo pacientov, podatkovno skladišče, cevovod za učenje modela, nadzorno ploščo za zdravnike, shrambo v oblaku, ponudnika identitet, revizijske dnevnike, platformo za podporne zahtevke in analitično orodje tretje osebe. Vsako sredstvo dobi lastnika, lokacijo, razvrstitev in povezavo z osebno določljivimi podatki.
Nato opredelijo scenarije tveganj. Eden je nepooblaščen dostop do zdravstvenih zapisov. Drugi je nenamerno razkritje prek analitičnih izvozov. Tretji je pristranskost modela umetne inteligence zaradi neuravnoteženih učnih podatkov, ki povzroči nepošteno ali diskriminatorno ocenjevanje tveganja pri pacientih.
Korak 11 v Zenith Blueprint pojasnjuje vlogo registra tveganj:
Register tveganj je običajno preglednica (naša predloga »Risk Register and SoA Builder.xlsx« ima temu namenjen zavihek). Deluje kot osrednja evidenca tveganj.
Vnos tveganja za zasebnost za scenarij pristranskosti modela umetne inteligence je lahko videti tako:
| Polje | Vnos | Referenca Clarysec |
|---|---|---|
| ID tveganja | PRV-004 | Zenith Blueprint, korak 11 |
| Sredstvo | Platforma za analitiko pacientov z umetno inteligenco | Zenith Blueprint, korak 9 |
| Grožnja | Pristranskost modela umetne inteligence zaradi neuravnoteženih učnih podatkov | Zenith Blueprint, korak 9 |
| Ranljivost | Pomanjkanje formalne validacije modela in testiranja poštenosti | Zenith Blueprint, korak 9 |
| Opis tveganja | Model bi lahko ustvaril diskriminatorne ocene tveganja za paciente, kar bi lahko povzročilo nepošteno obravnavo in poseg v pravice posameznikov, na katere se nanašajo podatki | Risk Management Policy SME, točka 5.1.2 |
| Verjetnost | Verjetno, 4 od 5 | Zenith Blueprint, korak 10 |
| Vpliv | Velik, 4 od 5, zaradi podatkov posebnih vrst in možne škode za posameznike | Zenith Blueprint, korak 10 |
| Ocena tveganja | 16, visoko | Zenith Blueprint, korak 10 |
| Lastnik tveganja | Vodja podatkovne znanosti | Zenith Blueprint, korak 11 |
| Načrt obravnave tveganja | Uvesti validacijo modela, testiranje poštenosti, ponovno učenje na reprezentativnih podatkih, pregled pojasnljivosti, pregled DPO in dokončanje DPIA | Risk Management Policy SME, točka 5.1.2 |
Ta vnos naredi tisto, česar stara preglednica ni mogla. Dejavnost obdelave poveže s sredstvom, grožnjo, ranljivostjo, tveganjem za posameznike, lastnikom, oceno, načrtom obravnave tveganja in revizijsko sledjo dokazil.
Ker je obdelava visoko tvegana in vključuje podatke posebnih vrst, DPIA ni ločena naknadna misel. Postane poglobljena faza presoje za tveganje, ki je že evidentirano v sistemu. Enterprise Politika varstva podatkov in zasebnosti določa:
Vse pomembne spremembe sistemov ali procesov, ki vključujejo osebno določljive podatke (PII), zahtevajo dokumentirano oceno učinka v zvezi z varstvom podatkov (DPIA), ki jo pregleda pooblaščena oseba za varstvo podatkov (DPO).
Za visoko preostalo tveganje upravljavca Politika ocenjevanja tveganj za zasebnost in DPIA dodaja:
[Upravljavec] Najvišje vodstvo MORA odobriti sprejem visokega preostalega tveganja za zasebnost v REG04, preden se visoko tvegana obdelava upravljavca začne ali nadaljuje.
Odločitev o uvedbi ima zdaj sledljivost: kaj se je spremenilo, kaj je bilo ocenjeno, katera tveganja so bila identificirana, katere kontrole so bile izbrane, kdo je lastnik obravnave, kdo je odobril preostalo tveganje in kdaj bo odločitev pregledana.
Od tveganj do kontrol z Zenith Controls
Ocena tveganj za zasebnost je pomembna le, če vodi do odločitev o kontrolah. Clarysecov Zenith Controls: vodnik za navzkrižno skladnost je vodnik za navzkrižno skladnost, ki preslika kontrole ISO/IEC 27001:2022 in ISO/IEC 27002:2022 na povezane zahteve v različnih okvirih. Ne gre za ločen nabor kontrol. Ekipam pomaga razumeti, kako dokazila o kontrolah podpirajo več obveznosti.
Za oceno tveganj za zasebnost Zenith Controls izpostavlja tri ključne kontrole ISO/IEC 27002:2022:
| Kontrola ISO/IEC 27002:2022 | Zakaj je pomembna za oceno tveganj za zasebnost | Primer dokazil |
|---|---|---|
| 5.34 Zasebnost in varstvo osebno določljivih podatkov | Zasidra upravljanje zasebnosti, pravne zahteve, varstvo posameznikov, na katere se nanašajo podatki, in zaščitne ukrepe | Postopki PIMS, zapisi DPIA, pravila ravnanja z osebno določljivimi podatki, obvestila o zasebnosti |
| 5.9 Popis informacij in drugih povezanih sredstev | Zagotavlja, da organizacija ve, katera informacijska sredstva obstajajo, kdo je njihov lastnik, kje so in kako občutljiva so | Evidenca sredstev, reference RoPA, zapisi razvrščanja |
| 5.19 Informacijska varnost v odnosih z dobavitelji | Razširi tveganje za zasebnost na obdelovalce, podobdelovalce, oblačne platforme, dobavitelje analitike in ponudnike podpore | Ocene dobaviteljev, pogodbe, zapisi spremljanja, izhodni načrti |
Kontrola 5.34 podpira tudi GDPR Article 25 in Article 32, ukrepe za obvladovanje tveganj kibernetske varnosti po NIS2 Article 21, pričakovanja DORA glede upravljanja tveganj IKT ter rezultate NIST CSF 2.0, kot je GV.OC-03 za pravne, regulativne, pogodbene, zasebnostne in civilnopravne obveznosti, ter PR.DS-01 za varovanje podatkov v mirovanju.
Korak 13 v Zenith Blueprint te odločitve poveže z izjavo o uporabnosti:
Navzkrižno sklicevanje na predpise: če so določene kontrole uvedene posebej zaradi skladnosti z GDPR, NIS2 ali DORA, lahko to navedete bodisi v registru tveganj (kot del utemeljitve vpliva tveganja) bodisi v opombah SoA.
Tako ugotovitev s področja zasebnosti postane odločitev o kontrolah ISMS in PIMS, ne zgolj pravni komentar.
Tveganje dobavitelja in obdelovalca je treba oceniti pred odobritvijo
Veliko neuspehov pri zasebnosti se začne pri upravljanju dobaviteljev. Obdelovalec doda novega podobdelovalca. Dobavitelj podpore pridobi dostop do produkcije. Analitična platforma začne hraniti dogodkovne podatke v novi regiji. Nabava podpiše pogodbo, preden funkcija zasebnosti prepozna tveganje.
Clarysecova Enterprise Politika upravljanja zasebnosti pri obdelovalcih, podobdelovalcih in tretjih osebah to preprečuje s povezovanjem pregleda dobavitelja, REG04 in registra tretjih oseb:
[Oba] Vodja zasebnosti / vodja PIMS MORA sprožiti preverjanje tveganj za zasebnost in DPIA v REG04 za visoko tvegana razmerja z obdelovalci in bistvene spremembe obdelave pri tretji osebi pred odobritvijo, pri čemer mora biti referenca REG04 zabeležena v REG08.
Za SME Politika varnosti tretjih oseb in dobaviteljev določa zahtevo za pregled pred začetkom sodelovanja:
Pred začetkom sodelovanja je treba vsakega dobavitelja pregledati glede morebitnih tveganj. Ta pregled mora vključevati:
Operativno sporočilo je jasno. Tveganje dobavitelja se oceni pred odobritvijo, ne po podpisu.
To podpira tudi NIS2 in DORA. NIS2 Article 21 zahteva varnost dobavne verige kot del ukrepov za obvladovanje tveganj kibernetske varnosti. DORA Articles 28 to 30 zahtevajo, da finančni subjekti upravljajo tveganje tretjih ponudnikov IKT, izvajajo predpogodbene presoje, vzdržujejo pogodbene zaščitne ukrepe, razumejo tveganje podizvajanja, spremljajo odvisnosti in načrtujejo izhode za kritične ali pomembne funkcije.
Če dobavitelj obdeluje osebno določljive podatke ali podpira za zasebnost kritično obdelavo, mora zapis tveganja za zasebnost prikazati dobavitelja, vlogo pri obdelavi, lokacijo podatkov, odvisnost od podobdelovalcev, pogodbene zaščitne ukrepe, zaveze glede incidentov, pravila hrambe, pristop spremljanja in izhodni načrt.
En delovni proces, več rezultatov skladnosti
Prednost integriranega delovnega procesa PIMS je, da ista dokazila podpirajo več okvirov brez podvajanja dela.
| Področje obveznosti | Kaj mora prikazati delovni proces za tveganja za zasebnost | Sidro Clarysec |
|---|---|---|
| Odgovornost po GDPR | Namen obdelave, pravna podlaga, kategorije podatkov, tveganje za posameznike, odločitev o DPIA, kontrole, odobritev preostalega tveganja | REG02, REG04, Data Protection and Privacy Policy |
| ISO/IEC 27701:2025 PIMS | Upravljanje zasebnosti, prilagojeno vlogam, za kontekst upravljavca, obdelovalca, skupnega upravljavca in podobdelovalca | Privacy Risk Assessment and DPIA Policy |
| ISO/IEC 27001:2022 ISMS | Merila tveganja, ocena tveganja, načrt obravnave tveganja, izjava o uporabnosti, hranjena dokazila | Risk Management Policy, Risk Register and SoA Builder |
| NIS2 | Upravljanje tveganj kibernetske varnosti, varnost dobavne verige, obravnavanje incidentov, odgovornost vodstva | Preslikave Zenith Controls na 5.34, 5.9, 5.19 in povezane kontrole iz Priloge A |
| DORA | Upravljanje tveganj IKT, register tretjih oseb, mapiranje kritičnih odvisnosti, proces incidentov, načrtovanje izhoda | Processor, Subprocessor and Third-Party Privacy Management Policy |
| NIST CSF 2.0 | Trenutni in ciljni profili, rezultati upravljanja, register tveganj ali POA&M, rezultati tveganj dobaviteljev | Koraki upravljanja tveganj v Zenith Blueprint |
| COBIT 19 in zagotovila ISACA | Lastništvo upravljanja, zasnova kontrol, spremljanje uspešnosti, poročanje vodstvu, odprava ugotovitev | Četrtletni pregled in dokazila notranje presoje zasebnosti |
NIST CSF 2.0 je posebej uporaben za komuniciranje z izvršnim vodstvom. Njegova funkcija GOVERN zajema organizacijski kontekst, strategijo upravljanja tveganj, politiko, vloge, nadzor in tveganje dobavne verige. Njegovi organizacijski profili pomagajo trenutne in ciljne rezultate prevesti v prednostno razvrščen akcijski načrt, kot je register tveganj ali načrt ukrepov in mejnikov.
Za organizacije, za katere veljajo NIS2, DORA ali sektorska pravila, dokazila o tveganjih za zasebnost podpirajo tudi upravljanje kibernetske varnosti, nadzor nad dobavitelji, pripravljenost na incidente in poročanje o odpornosti.
Obravnava tveganj za zasebnost je širša od šifriranja
Šifriranje je pomembno, vendar ne more odpraviti neveljavne pravne podlage, prekomernega zbiranja, nerazkritega profiliranja, nepoštene obdelave, nezakonite hrambe ali obdelovalca, ki deluje zunaj navodil.
SME Politika varstva podatkov in zasebnosti določa:
Za zmanjšanje identificiranih tveganj je treba uvesti kontrole, vključno s šifriranjem, anonimizacijo, varnim odstranjevanjem in omejitvami dostopa.
To so dobri primeri, vendar mora obravnava ustrezati scenariju. Načrt obravnave tveganja za zasebnost lahko vključuje zožitev namena obdelave, odstranitev nepotrebnih kategorij podatkov, agregiranje ali psevdonimizacijo podatkov, posodobitev obvestil, spremembo pravne podlage, kjer je ustrezno, omejitev hrambe, omejitev dostopa, dodajanje beleženja, posodobitev pogodb, dokončanje DPIA, odložitev uvedbe ali zavrnitev obdelave, ki ostaja nesprejemljiva.
Enterprise Politika upravljanja tveganj krepi načrtovanje obravnave za tveganja nad pragom tolerance:
Vsa tveganja, razvrščena nad raven tolerance, morajo imeti povezan načrt obravnave tveganja, ki določa:
V praksi to pomeni, da visokega tveganja za zasebnost ni mogoče sprejeti z molkom. Treba ga je obravnavati, prenesti, kjer je ustrezno, se mu izogniti ali ga formalno sprejeti s strani ustreznega nosilca odgovornosti.
Sprožilci pregleda ohranjajo oceno aktualno
Ocena tveganj za zasebnost, ki se nikoli več ne pregleda, postane zastarelo dokazilo. Točki 8.2 in 8.3 ISO/IEC 27001:2022 zahtevata oceno tveganj in obravnavo tveganj v načrtovanih intervalih ali ob pomembnih spremembah. Odgovornost po GDPR zahteva aktualne odločitve. ISO/IEC 27701:2025 temelji na spremljanju in nenehnem izboljševanju.
Oceno REG04 je treba ponovno odpreti, kadar se spremeni namen, dodajo nove kategorije podatkov, začnejo obdelovati podatki posebnih vrst, se spremeni pravna podlaga, se spremeni obdelovalec ali podobdelovalec, se shramba premakne v novo regijo, se spremenijo roki hrambe, se spremeni logika profiliranja, pride do kršitve ali skorajšnjega incidenta, se spremenijo pogodbe s strankami ali začne veljati nova obveznost po NIS2, DORA ali sektorskem predpisu.
Procesi incidentov morajo povratno napajati delovni proces za tveganja za zasebnost. NIS2 Article 23 določa fazno poročanje o pomembnih incidentih. DORA Articles 17 to 20 zahtevajo evidentiranje, razvrščanje, eskalacijo, komuniciranje, analizo temeljnega vzroka in izboljšave za incidente, povezane z IKT. Sprožijo se lahko tudi obveznosti po GDPR glede kršitve varnosti osebnih podatkov. Če incident razkrije šibke kontrole dostopa, prekomerno hrambo, nejasno obveščanje dobavitelja ali slaba navodila upravljavca, je treba REG04 posodobiti.
Kaj bodo presojevalci pričakovali
Močan delovni proces za tveganja za zasebnost mora vzdržati več vidikov zagotovil.
| Vidik presojevalca | Verjetna zahteva za dokazila | Kako je videti dobra praksa |
|---|---|---|
| Presojevalec ISO/IEC 27001:2022 | Obseg ISMS, metoda tveganj, register tveganj, SoA, načrti obravnave tveganj, operativna dokazila | Tveganja za zasebnost uporabljajo odobrena merila, so povezana s kontrolami iz Priloge A, imajo lastnike in se pregledajo po spremembah |
| Presojevalec ISO/IEC 27701:2025 PIMS | Popis osebno določljivih podatkov, kontekst vlog, preverjanje zasebnosti, zapisi DPIA, dokazila upravljavca in obdelovalca | REG02 in REG04 prikazujeta, kako se obdelava preveri, oceni, obravnava, odobri in pregleda |
| Pregledovalec, osredotočen na GDPR | Pravna podlaga, preglednost, utemeljitev DPIA, pogodbe z obdelovalci, odločitve o kršitvah, vpliv na pravice posameznikov, na katere se nanašajo podatki | Organizacija lahko dokaže zakonito, pošteno, potrebno, sorazmerno in nadzorovano obdelavo |
| Ocenjevalec NIST CSF | Trenutni in ciljni profili, rezultati upravljanja, register tveganj, rezultati tveganj dobaviteljev | Tveganja za zasebnost in kibernetska tveganja se komunicirajo v jeziku korporativnega tveganja in prek prednostno razvrščenih načrtov |
| Ekipa za zagotovila DORA | Okvir upravljanja IKT-tveganj, register tretjih oseb, mapiranje kritičnih funkcij, proces incidentov, izhodne strategije | Zasebnostno relevantne odvisnosti IKT so vidne, pogodbeno urejene, spremljane, testirane in povezane z odpornostjo |
| Presojevalec COBIT 19 ali ISACA | Lastništvo upravljanja, zasnova kontrol, poročanje, odprava ugotovitev | Odločitve o tveganjih za zasebnost so v lasti poslovnih področij in organov upravljanja, ne skrite v pravnih ali IT silosih |
Enterprise Politika varstva podatkov in zasebnosti zahteva tudi dejavnost notranje presoje:
Notranja presoja skladnosti zasebnosti se izvede letno ali ob večjih organizacijskih oziroma regulativnih spremembah. Obseg presoje mora vključevati:
To ustvari povratno zanko za vodstvo. Ali so zapisi REG02 popolni? Ali se preverjanja REG04 izvajajo pravočasno? Ali se DPIA izvajajo, kadar so zahtevane? Ali so visoka preostala tveganja odobrena? Ali so spremembe dobaviteljev zajete? Ali so načrti obravnave tveganj zaprti? Ali so obvestila usklajena z dejansko obdelavo?
Kontrolni seznam za naslednji sestanek o spremembi zasebnosti
Ta kontrolni seznam uporabite, preden gre nova dejavnost obdelave, funkcionalnost produkta, dobavitelj, model ali podporni delovni proces v produkcijo.
| Vprašanje | Če je odgovor da, zabeležite to |
|---|---|
| Ali gre za novo ali bistveno spremenjeno obdelavo osebno določljivih podatkov? | Odprite ali posodobite REG02 in sprožite preverjanje REG04 |
| Ali se spremenijo namen, pravna podlaga, kategorija podatkov, hramba ali prejemnik? | Posodobite popis dejavnosti obdelave in dokazila o pravni podlagi |
| Ali bi obdelava lahko ustvarila povišano tveganje za posameznike? | Ocenite inherentno tveganje za zasebnost in dokumentirajte utemeljitev |
| Ali so vključeni profiliranje, obsežno spremljanje, podatki posebnih vrst ali ranljivi posamezniki? | Ocenite, ali je zahtevana DPIA |
| Ali je vključen nov obdelovalec, podobdelovalec, storitev v oblaku ali dobavitelj podpore? | Sprožite pregled zasebnosti in varnosti dobavitelja |
| Ali so pred uvedbo zahtevane kontrole? | Ustvarite načrt obravnave tveganja z lastnikom in rokom za izvedbo |
| Ali preostalo tveganje ostaja nad toleranco? | Eskalirajte za odobritev, preden se obdelava začne ali nadaljuje |
| Ali se bodo spremenila obvestila o zasebnosti, pogodbe ali navodila upravljavca? | Dodelite pravne posodobitve in posodobitve za stranke |
| Kaj bo sprožilo ponovno presojo? | Določite datum pregleda in sprožilce sprememb v REG04 |
Ta kontrolni seznam ni nadomestilo za politiko. Je praktičen način za operacionalizacijo politike na sestankih produktnih, nabavnih, inženirskih, skladnostnih, pravnih in vodstvenih ekip.
Spremenite odgovornost za zasebnost v delujoč sistem
ISO/IEC 27701:2025 in odgovornost po GDPR zahtevata več kot dokumente. Zahtevata delujoč sistem, ki povezuje zapise obdelave, pravno podlago, tveganje za zasebnost, odločitve o DPIA, dobavitelje, kontrole, lastnike, odobritve in dokazila.
Začnite s fazo upravljanja tveganj v Zenith Blueprint, zlasti s koraki 9 do 13. Uporabite Risk Register and SoA Builder za povezovanje sredstev, groženj, ranljivosti, tveganj za zasebnost, odločitev o obravnavi in sklicev na kontrole. Nato uporabite Zenith Controls za preslikavo varstva osebno določljivih podatkov, evidenc sredstev in varnosti dobaviteljev v pričakovanja glede zagotovil po GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 in COBIT 19.
Uskladite operativne politike, zaradi katerih je delovni proces izvršljiv: Politika ocenjevanja tveganj za zasebnost in DPIA, Politika popisa obdelav osebno določljivih podatkov in pravne podlage, Politika upravljanja zasebnosti pri obdelovalcih, podobdelovalcih in tretjih osebah, Politika upravljanja tveganj in Politika varstva podatkov in zasebnosti. Manjše ekipe lahko uporabijo tudi Clarysecove politike za SME, večje organizacije pa lahko upravljanje strukturirajo s politikami Enterprise.
Če vaša ekipa uvaja novo obdelavo, spreminja dobavitelje, se pripravlja na ISO/IEC 27701:2025 ali želi dokazila o odgovornosti po GDPR narediti ponovljiva, začnite z eno živo dejavnostjo obdelave. Odprite REG02, izvedite preverjanje REG04, preslikajte tveganja na kontrole, dodelite lastnike obravnave tveganj in preglejte preostalo tveganje z ustreznim odločevalcem.
Prav ta enotni delovni proces je točka, kjer upravljanje zasebnosti postane operativno.
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