Správa a riadenie prístupu k PII podľa ISO 27701:2025 a GDPR

Otázka externého audítora zostala visieť vo vzduchu. Znela klamlivo jednoducho.

„Viete mi ukázať záznam z preskúmania prístupových práv vášho tímu podpory k produkčným PII za posledný štvrťrok?“

Pre Anyu, CISO v spoločnosti Medtelligence, rýchlo rastúcom poskytovateľovi health-tech SaaS, to bol moment pravdy. Medtelligence pôsobí ako sprostredkovateľ PII pre nemocnice a spracúva citlivé údaje pacientov na cloudovej platforme. Spoločnosť mala silnú autentifikáciu, definované roly a vyspelý vývojový tím. Audítor sa však nepýtal, či existuje prihlasovacia stránka. Žiadal dôkaz, že prístup k osobným údajom je riadený priebežne v čase.

Chcel vidieť, kto mohol pristupovať k produkčným PII, prečo mal prístup, kedy bol prístup schválený, či bol stále potrebný, či bola aktivita podpory logovaná a či boli nepotrebné oprávnenia odstránené.

Anya otvorila konzolu IAM. Boli v nej inžinieri podpory, správcovia databáz, integračný servisný účet, poskytovateľ riadených služieb, dve núdzové roly „break glass“ a bývalý zmluvný pracovník, ktorý bol stále členom skupiny, pretože offboardingový ticket bol uzavretý skôr, ako bolo oprávnenie odstránené. HR ukazovalo, že daná osoba odišla pred šiestimi týždňami. Tabuľka preskúmania prístupových práv mala stav „čaká na spracovanie“. SIEM obsahoval logy, ale nikto nemal zmapované, ktoré udalosti preukazujú prístup k PII.

Tu sa riadenie ochrany súkromia mení na realitu.

Podľa GDPR sa osobné údaje musia spracúvať s integritou a dôvernosťou a musia byť chránené pred neoprávneným alebo nezákonným spracúvaním, náhodnou stratou, zničením alebo poškodením prostredníctvom primeraných technických a organizačných opatrení. GDPR zároveň výslovne zavádza preukázateľnú zodpovednosť: prevádzkovateľ musí byť schopný preukázať súlad. ISO/IEC 27701:2025 premieňa túto preukázateľnú zodpovednosť na systém manažérstva informácií o ochrane súkromia, teda PIMS, v ktorom prístup k PII už nie je dodatočnou technickou otázkou. Stáva sa riadeným životným cyklom naprieč rolami, sprostredkovateľmi, cloudovými platformami, zamestnancami, privilegovanými administrátormi, logmi, preskúmaniami, zmluvami a dôkazmi.

Medzera v mnohých organizáciách nespočíva v tom, že by im chýbalo riadenie prístupu. Spočíva v tom, že nedokážu konzistentne preukázať správu a riadenie prístupu k PII naprieč ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 a COBIT 2019.

Správa a riadenie prístupu k PII nie je len IAM

Tradičný program IAM sa pýta: „Môžu správni používatelia pristupovať k správnym systémom?“

Vyspelý PIMS podľa ISO/IEC 27701:2025 kladie náročnejšie otázky:

• Ktoré systémy spracúvajú PII?
• Ktoré roly potrebujú prístup ku ktorým kategóriám PII?
• Vystupuje organizácia ako prevádzkovateľ PII, sprostredkovateľ PII, spoločný prevádzkovateľ alebo ďalší sprostredkovateľ?
• Je prístup obmedzený účelom, zdokumentovanou obchodnou potrebou a zásadou minimálnych oprávnení?
• Sú privilegované úkony logované a preskúmavané?
• Vie organizácia preukázať, že prístup sprostredkovateľov a ďalších sprostredkovateľov je zmluvne kontrolovaný?
• Sú do dôkazov zahrnuté cloudové cesty podpory, izolácia tenantov, exporty a administrátorské úkony?
• Sú rozhodnutia o prístupe preskúmavané po nástupe, zmene roly, incidente, offboardingu a podstatnej zmene systému?

Preto sú bezpečnosť PII a správa a riadenie prístupu prirodzeným prepojením medzi ISO/IEC 27701:2025 a GDPR. GDPR poskytuje rámec právnej preukázateľnej zodpovednosti. ISO/IEC 27701:2025 operacionalizuje riadenie ochrany súkromia pre prevádzkovateľov a sprostredkovateľov. ISO/IEC 27001:2022 poskytuje mechanizmus riadenia rizík ISMS. ISO/IEC 27002:2022 poskytuje architektúru kontrol vrátane ochrany súkromia a ochrany PII, riadenia prístupu, prístupových práv, logovania, cloudových služieb, vzťahov s dodávateľmi, klasifikácie, výmazu, maskovania a kryptografie.

Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap zaraďuje túto tému do fázy Controls in Action. V kroku 23, ktorý pokrýva organizačné opatrenia 5.19 až 5.37, opisuje kontrolu ISO/IEC 27002:2022 5.34, Privacy and Protection of PII, ako otázku dôvery, nie iba otázku údajov:

osobne identifikovateľné informácie nie sú len ďalším typom údajov, sú hlboko citlivým vyjadrením dôvery. Mená, adresy, identifikačné doklady, zdravotné záznamy, finančné údaje — tieto údaje rozprávajú príbeh o skutočných ľuďoch.

Tá istá pasáž poskytuje praktický základ: ochrana súkromia začína uvedomením si údajov. Organizácia musí vedieť, aké PII zhromažďuje, kde sa nachádzajú, prečo sa spracúvajú a kto k nim môže pristupovať.

Tlak na súlad za riadením prístupu k PII

Správa a riadenie prístupu k PII už nie je otázkou jedného rámca. Organizácie ako Medtelligence pôsobia na priesečníku regulácie ochrany súkromia, kybernetickej legislatívy, prevádzkovej odolnosti, uistenia zákazníkov a bezpečnostnej certifikácie.

GDPR Article 5 vyžaduje, aby sa osobné údaje spracúvali podľa zásad zákonnosti, spravodlivosti, transparentnosti, obmedzenia účelu, minimalizácie údajov, presnosti, minimalizácie uchovávania, integrity a dôvernosti. Article 5(2) zavádza preukázateľnú zodpovednosť: prevádzkovateľ zodpovedá za súlad a musí ho vedieť preukázať. Article 32 následne vyžaduje primerané technické a organizačné opatrenia na bezpečnosť spracúvania.

NIS2 Article 21 vyžaduje, aby základné a dôležité subjekty prijali primerané a proporcionálne technické, prevádzkové a organizačné opatrenia riadenia kybernetických rizík. Medzi minimálne oblasti patria analýza rizík, bezpečnostné politiky, riešenie incidentov, kontinuita činností, bezpečnosť dodávateľského reťazca, bezpečné obstarávanie a vývoj, posúdenie účinnosti, kybernetická hygiena a školenie, kryptografia, bezpečnosť HR, riadenie prístupu, správa aktív a podľa potreby viacfaktorová alebo priebežná autentifikácia a bezpečná komunikácia. Article 20 zároveň ukladá riadiacim orgánom zodpovednosť za schvaľovanie opatrení riadenia kybernetických rizík a dohľad nad nimi.

DORA sa uplatňuje od 17. januára 2025 na široký okruh finančných subjektov a vytvára sektorovo špecifický režim prevádzkovej odolnosti. Pokrýva riadenie rizík IKT, hlásenie závažných incidentov súvisiacich s IKT, testovanie digitálnej prevádzkovej odolnosti, výmenu informácií, riziko IKT tretích strán a zmluvné vzťahy s poskytovateľmi IKT služieb tretích strán. Pre finančné subjekty a poskytovateľov IKT služieb, ktorí ich podporujú, nie je riadenie prístupu iba otázkou ochrany súkromia. Je súčasťou prevádzkovej odolnosti.

ISO/IEC 27001:2022 prepája tieto povinnosti do systému riadenia založeného na riziku. Body 6.1.1 až 6.1.3 vyžadujú, aby organizácie riešili riziká a príležitosti, definovali proces posúdenia rizík informačnej bezpečnosti, identifikovali riziká pre dôvernosť, integritu a dostupnosť, hodnotili riziká, vyberali možnosti ošetrenia, určovali kontroly, porovnávali zvolené kontroly s Annex A, zdokumentovali vyhlásenie o aplikovateľnosti (SoA), získali schválenie vlastníka rizika a akceptovali zostatkové riziká. Body 8.2 a 8.3 vyžadujú posúdenia rizík v plánovaných intervaloch alebo po významnej zmene a implementáciu plánu ošetrenia rizík so zdokumentovanými výsledkami.

Pre správu a riadenie PII to znamená, že riadenie prístupu nie je izolované nastavenie IAM. Je to rozhodnutie o ošetrení rizík. Rola, ktorá môže exportovať mzdové záznamy, údaje pacientov, platobné údaje, doklady totožnosti, lokalizačné údaje alebo prepisy komunikácie zákazníckej podpory, musí byť odôvodnená v registri rizík, premietnutá do vyhlásenia o aplikovateľnosti (SoA), vynútená v IAM, logovaná v produkčnom prostredí, pravidelne preskúmavaná a odstránená, keď už nie je potrebná.

Kontrolný model Clarysec: od prísľubu ochrany súkromia k dôkazom

Clarysec chápe správu a riadenie prístupu k PII ako dôkazový reťazec. Reťazec začína inventarizáciou údajov a definíciou rolí, pokračuje schválením a vynucovaním prístupu a končí monitorovaním, preskúmaním, zrušením prístupu a záznamami pripravenými na audit.

V Zenith Controls: The Cross-Compliance Guide sa táto téma sústreďuje najmä okolo troch kontrol ISO/IEC 27002:2022:

Audítori zriedkavo akceptujú tvrdenie „používame IAM“ ako dôkaz. Očakávajú, že uvidia, ako rozhodnutia v IAM nadväzujú na povinnosti ochrany súkromia, vlastníctvo systému, klasifikáciu údajov, obchodnú potrebu, ošetrenie rizík, periodicitu preskúmania prístupových práv, rozsah logovania a zmluvy s dodávateľmi.

Clarysec PII Security and Access Control Policy stanovuje základnú úroveň v jazyku PIMS:

[Obe roly] Vlastník systému / vlastník aplikácie MUSÍ obmedziť prístup k PII na schválené roly a oprávnených používateľov zaznamenaných alebo sledovateľných v REG02 alebo REG12 ešte pred povolením prístupu.

Zo sekcie „4.2 Referenčná úroveň riadenia prístupu“, ustanovenie politiky 4.2.1.

Označenie „[Obe roly]“ znamená, že kontrola sa uplatňuje bez ohľadu na to, či organizácia vystupuje ako prevádzkovateľ PII alebo sprostredkovateľ PII. Na tomto rozlíšení záleží. Prevádzkovatelia často nedefinujú pravidlá prístupu založené na účele. Sprostredkovatelia často nedokážu preukázať, že prístup je obmedzený na pokyny zákazníka, schválené cesty podpory a zmluvne oprávnený personál.

Tá istá politika zvyšuje požiadavku pri citlivých PII alebo PII s vysokým dopadom:

[Obe roly] Vlastník systému / vlastník aplikácie MUSÍ minimálne štvrťročne preskúmať používateľský prístup k systémom spracúvajúcim PII s vysokým dopadom alebo citlivé PII a zaznamenať výsledok preskúmania v REG12.

Zo sekcie „4.2 Referenčná úroveň riadenia prístupu“, ustanovenie politiky 4.2.3.

Tu sa PIMS stáva auditne overiteľným. Preskúmanie prístupových práv nie je iba e-mail manažéra. Je to záznam v REG12, previazaný so systémom, kategóriou údajov, rolou, vlastníkom, výsledkom preskúmania a nápravným opatrením.

Základ politiky: zásada minimálnych oprávnení, obchodná potreba a predvolené zamietnutie

Účinná správa a riadenie sa začína vynútiteľnými pravidlami. Skôr než Anya mohla audítorovi ukázať záznam z preskúmania prístupových práv, musela preukázať, že požiadavka na preskúmania prístupových práv bola formálne stanovená.

Clarysec SME Politika riadenia prístupu – SME stanovuje princíp:

Táto politika presadzuje zásadu minimálnych oprávnení a vyžaduje, aby bol prístup obmedzený na minimum nevyhnutné na výkon pracovných povinností.

Zo sekcie „Účel“, ustanovenie politiky 1.3.

SME Politika ochrany údajov a súkromia – SME prepája prístup s obchodnou potrebou:

Používateľský prístup k osobným údajom musí byť obmedzený na roly so zdokumentovanou obchodnou potrebou.

Zo sekcie „Požiadavky na správu a riadenie“, ustanovenie politiky 5.3.2.

Pre väčšie organizácie vyjadruje enterprise Politika ochrany údajov a súkromia očakávanie kontroly ako systémovú požiadavku:

Všetky systémy musia štandardne uplatňovať prístup podľa zásady minimálnych oprávnení.

Zo sekcie „Požiadavky na implementáciu politiky“, ustanovenie politiky 6.3.1.

Rozdiel je dôležitý. Menšia spoločnosť môže potrebovať jednoduchý, ale výslovný záznam obchodnej potreby. Enterprise prostredie potrebuje vynucovanie na úrovni systému, pravidelné preskúmania, oddelenie povinností, správu privilegovaného prístupu a dôkazy uchovávané pre interný audit, uistenie zákazníkov, preverenia regulátormi a vyšetrovanie porušenia ochrany osobných údajov.

Životný cyklus prístupu k PII: schválenie, používanie, preskúmanie, zrušenie

Najčastejším zlyhaním prístupu k PII nie je prvotné schválenie. Je ním pretrvávanie prístupu.

Zenith Blueprint vo fáze Controls in Action, krok 22, vysvetľuje kontrolu ISO/IEC 27002:2022 5.18, Access Rights, takto:

Kontrola 5.18 zabezpečuje, že prístupové práva sa nielen primerane udeľujú, ale aj preskúmavajú, upravujú a rušia kontrolovaným a sledovateľným spôsobom.

Následne opisuje známe scenáre: nový zamestnanec dostane prístup, zmení rolu a ponechá si staré oprávnenia; bývalý administrátor odíde, ale token zostane aktívny; účet dodávateľa vyprší na papieri, ale nie v IAM. Presne tieto slabiny sa pri PII menia na bezpečnostné incidenty podľa GDPR.

Clarysec SME Politika správy používateľských účtov a oprávnení – SME stanovuje základnú periodicitu:

Preskúmanie všetkých používateľských účtov a oprávnení sa musí vykonať každých šesť mesiacov.

Zo sekcie „Požiadavky na implementáciu politiky“, ustanovenie politiky 6.4.1.

Pre enterprise prostredia Politika správy používateľských účtov a oprávnení sprísňuje prevádzkový rytmus:

Štvrťročné preskúmania všetkých používateľských účtov a súvisiacich oprávnení musí vykonávať IT Security v spolupráci s vedúcimi oddelení.

Zo sekcie „Požiadavky na implementáciu politiky“, ustanovenie politiky 6.5.1.

Praktický životný cyklus prístupu k PII má zahŕňať:

1. Klasifikovať systém a kategórie PII.
2. Definovať schválené roly a zdokumentovanú obchodnú potrebu.
3. Namapovať roly na účely spracúvania.
4. Schváliť prístup pred jeho povolením.
5. Vynucovať zásadu minimálnych oprávnení, oddelenie povinností a silnú autentifikáciu.
6. Logovať autentifikáciu, prístup, export, konfiguráciu a privilegované úkony.
7. Preskúmavať prístup v periodicite určenej na základe rizika.
8. Odstrániť prístup pri zmene roly, ukončení pracovného alebo zmluvného vzťahu, uzavretí projektu, uplynutí zmluvy alebo na základe pokynu zákazníka.
9. Uchovávať dôkazy v registri PIMS a auditnej stope.

Toto nie je byrokracia. Je to spôsob, akým organizácia preukazuje, že prístup k PII je riadený už od návrhu, štandardne a na základe dôkazov.

Praktický príklad: štvrťročné preskúmanie prístupových práv k PII

Anyin audit uspel, keď presunula diskusiu od vyhlásení v politike k dôkazom.

Najprv citovala PII Security and Access Control Policy, ustanovenie 4.2.3, ktoré vyžadovalo štvrťročné preskúmanie prístupu k PII s vysokým dopadom alebo citlivým PII a zaznamenanie výsledku preskúmania v REG12.

Potom audítora previedla predchádzajúcim štvrťrokom:

• IT vygenerovalo zoznam všetkých používateľov, skupín, privilegovaných rolí, servisných účtov, dodávateľských účtov, rolí „break glass“ a oprávnení podpory pre produkčnú databázu obsahujúcu údaje pacientov.
• Zoznam bol zaslaný vlastníkovi aplikácie, vedúcemu zákazníckeho úspechu, ktorý vlastnil prevádzkovú potrebu tímu podpory.
• Vlastník aplikácie preskúmal zoznam riadok po riadku podľa aktuálnej roly, zodpovedností zákazníckej podpory a účelu spracúvania.
• Dvaja agenti podpory, ktorí prešli do iných tímov, boli označení na zrušenie prístupu.
• V systéme riadenia IT služieb bol vytvorený ticket, prepojený s preskúmaním prístupových práv, s priradenou SLA a uzavretý po zrušení prístupu.
• REG12 bol aktualizovaný o záznam preskúmania, schvaľovateľa, výnimky, ticket nápravy, dôkaz o uzavretí a dátum ďalšieho preskúmania.

Výsledkom bol uzavretý dôkazový reťazec. Anya nielen povedala, že Medtelligence používa zásadu minimálnych oprávnení. Ukázala požiadavku politiky, zodpovedného vlastníka, zoznam prístupov, rozhodnutie z preskúmania, nápravné opatrenie a dokončené zrušenie prístupu.

To je rozdiel medzi riadením prístupu a správou a riadením prístupov.

Prístup dodávateľov a sprostredkovateľov: slepé miesto v auditoch PIMS

Mnohé riziká neoprávneného prístupu vstupujú cez podporu, outsourcing, integračných partnerov, poskytovateľov riadených služieb a ďalších sprostredkovateľov. Sprostredkovateľ môže mať vzdialený prístup k produkčným údajom zákazníka. Cloudový poskytovateľ môže poskytovať cesty prístupu podpory. Ďalší sprostredkovateľ môže udržiavať vyhľadávací index obsahujúci identifikátory zákazníkov. Poskytovateľ riadených bezpečnostných služieb môže pristupovať k logom obsahujúcim osobné údaje.

Podľa GDPR musia prevádzkovatelia využívať sprostredkovateľov, ktorí poskytujú dostatočné záruky. Podľa ISO/IEC 27701:2025 musí byť správa a riadenie sprostredkovateľov a ďalších sprostredkovateľov operacionalizované prostredníctvom zdokumentovaných pokynov, zmluvných kontrol, uistenia a monitorovania. ISO/IEC 27002:2022 to podporuje kontrolami vzťahov s dodávateľmi vrátane 5.19 Information security in supplier relationships, 5.20 Addressing information security within supplier agreements a 5.21 Managing information security in the ICT supply chain.

Zenith Blueprint, fáza Controls in Action, krok 23, sumarizuje oblasti dôkazov k dodávateľským zmluvám vrátane:

✓ zodpovedností v oblasti riadenia prístupu, napríklad kto môže pristupovať k vašim údajom, ako sa spravujú prihlasovacie údaje a aké monitorovanie je zavedené;

Zahŕňa aj povinnosti zachovávať dôvernosť, technické a organizačné opatrenia, lehoty nahlasovania incidentov, práva na audit, kontroly subdodávateľov a deaktiváciu účtov po ukončení zmluvy.

Clarysec Processor, Subprocessor and Third-Party Privacy Management Policy premieňa túto požiadavku na dôkazy PIMS na strane prevádzkovateľa:

[Prevádzkovateľ] Vedúci ochrany súkromia / manažér PIMS MUSÍ pred schválením overiť, že polia zmluvných kontrol sprostredkovateľa v REG08 pokrývajú rozsah spracúvania, trvanie, účel, kategórie PII, kategórie dotknutých osôb, dôvernosť, bezpečnosť, schválenie ďalšieho sprostredkovateľa, súčinnosť, audit alebo uistenie, vrátenie, výmaz a ukončenie.

Zo sekcie „4.3 Zmluvné kontroly a kontroly zdokumentovaných pokynov“, ustanovenie politiky 4.3.2.

Prístup dodávateľov je priamo riadený aj v SME a enterprise dodávateľských politikách Clarysec. SME Politika bezpečnosti tretích strán a dodávateľov – SME uvádza:

Dodávatelia musia mať udelený prístup iba k minimálnym systémom a údajom potrebným na výkon ich funkcie.

Zo sekcie „Požiadavky na implementáciu politiky“, ustanovenie politiky 6.2.1.

Enterprise Politika bezpečnosti tretích strán a dodávateľov pridáva RBAC, preskúmanie a zásadu minimálnych oprávnení:

Personál dodávateľa musí podliehať riadeniu prístupu na základe rolí (RBAC), pravidelným preskúmaniam prístupových práv a uplatňovaniu zásady minimálnych oprávnení.

Zo sekcie „Požiadavky na implementáciu politiky“, ustanovenie politiky 6.3.1.

Ak sa prístup dodávateľa môže dostať k PII, patrí do PIMS. Mal by sa objaviť v zmluvných kontrolách, schváleniach prístupu, skupinách IAM, rozsahu logovania, záznamoch preskúmania, záznamoch offboardingu, playbookoch incidentov a auditných dôkazoch.

Cloudový prístup k PII: zdieľaná zodpovednosť nie je zdieľaná preukázateľná zodpovednosť

Správa a riadenie cloudového prístupu k PII je oblasť, v ktorej organizácie často preceňujú poskytovateľa a podceňujú vlastné povinnosti. Cloudový poskytovateľ môže zabezpečovať infraštruktúru, ale zákazník stále riadi identity, roly, konfiguráciu tenanta, prístup podpory, logy, nastavenia šifrovania, oprávnenia na export a pripravenosť reakcie na incidenty.

Zenith Blueprint, fáza Controls in Action, krok 23, to vo svojom usmernení ku cloudovým službám formuluje priamo:

Cloudoví poskytovatelia zabezpečujú infraštruktúru, ale vy naďalej nesiete preukázateľnú zodpovednosť za svoje údaje, svoje konfigurácie, svoje politiky prístupu a svoju pripravenosť reakcie na incidenty.

Zároveň upozorňuje:

V cloude je viditeľnosť čiastočná, pokiaľ nie je zámerne navrhnutá. Musíte nakonfigurovať logovanie, vynútiť šifrovanie, definovať roly identít a monitorovať aktivitu prostredníctvom natívnych nástrojov alebo integrácií tretích strán. To nie je úloha infraštruktúry, ale požiadavka ISMS.

Clarysec Politika používania cloudových služieb premieňa túto zásadu na enterprise požiadavku prístupu:

Všetky cloudové služby musia vynucovať riadenie prístupu založené na identite v súlade so zásadou minimálnych oprávnení.

Zo sekcie „Požiadavky na implementáciu politiky“, ustanovenie politiky 6.2.1.

Pre organizácie vystupujúce ako sprostredkovatelia v cloudových prostrediach definuje Clarysec Cloud PII Processor Policy špecifickejšiu povinnosť preskúmania v PIMS:

[Sprostredkovateľ] Vedúci informačnej bezpečnosti MUSÍ minimálne štvrťročne preskúmať privilegovaný cloudový prístup, prístup podpory, prístup zákazníkov k PII a pokrytie logovaním v REG12.

Zo sekcie „4.2 Cloudová konfigurácia, izolácia tenantov, prístup a logovanie“, ustanovenie politiky 4.2.4.

Toto ustanovenie je osobitne relevantné pre SaaS spoločnosti, platformy prevádzkované v cloude, riadené dátové služby a B2B sprostredkovateľov.

Správa a riadenie cloudového prístupu k PII nie je úplná, pokiaľ sa cloud-native logy, politiky IAM, servisné účty, privilegované roly, nástroje zákazníckej podpory, kľúče API a funkcie exportu údajov nepreskúmavajú spoločne.

Logovanie a monitorovanie: pamäť správy a riadenia PII

Program riadenia prístupu v PIMS bez logov je prísľub bez pamäti.

PII Security and Access Control Policy vyžaduje definovanie rozsahu logovania pred použitím v produkčnom prostredí alebo pred podstatnou zmenou:

[Obe roly] Vlastník systému / vlastník aplikácie MUSÍ pred použitím v produkčnom prostredí alebo pred podstatnou zmenou definovať v REG12 rozsah logovania PII pre udalosti autentifikácie, udalosti prístupu, privilegované úkony, aktivitu exportu PII a podstatné konfiguračné zmeny.

Zo sekcie „4.6 Logovanie a monitorovanie“, ustanovenie politiky 4.6.1.

SME Politika logovania a monitorovania – SME výslovne uvádza obsah prístupových logov:

Prístupové logy: prístup k súborom (najmä pri citlivých alebo osobných údajoch), zmeny oprávnení, používanie zdieľaných zdrojov

Zo sekcie „Požiadavky na správu a riadenie“, ustanovenie politiky 5.4.3.

Enterprise Politika logovania a monitorovania sa zameriava na použiteľnosť pri audite:

Register auditnej stopy ISMS musí zaznamenávať dostupnosť logovaných údajov pre audity, vyšetrovania a regulačné preskúmania.

Zo sekcie „Požiadavky na správu a riadenie“, ustanovenie politiky 5.4.

Je to kritické, pretože dôkazy ochrany súkromia musia často odpovedať na otázky založené na udalostiach:

• Kto pristupoval k PII?
• Bol prístup oprávnený?
• Bol prístup prepojený s ticketom podpory, právnou požiadavkou, prevádzkovou úlohou alebo pokynom zákazníka?
• Boli údaje exportované, kopírované, zmenené alebo vymazané?
• Bol použitý privilegovaný prístup?
• Boli oprávnenia zmenené pred prístupom alebo po ňom?
• Naznačovala aktivita bezpečnostný incident alebo porušenie ochrany osobných údajov?

Logy nie sú len pre SOC. Sú dôkazmi PIMS, dôkazmi uistenia zákazníkov, dôkazmi uistenia sprostredkovateľov a dôkazmi reakcie na incidenty.

Mapovanie súladu naprieč rámcami: jeden model prístupu, viacero pohľadov

Slabina v preskúmaniach prístupových práv k PII nikdy nie je iba jedným zistením. Môže sa zmeniť na problém preukázateľnej zodpovednosti podľa GDPR, slabinu PIMS podľa ISO/IEC 27701:2025, nezhodu podľa ISO/IEC 27001:2022, zlyhanie správy a riadenia podľa NIS2, obavu týkajúcu sa odolnosti podľa DORA, medzeru v správe a riadení podľa NIST CSF 2.0 alebo problém zrelosti procesu podľa COBIT 2019.

Podrobnejší kontrolný crosswalk ukazuje, ako jeden proces správy a riadenia prístupu k PII podporuje viaceré požiadavky:

Hodnota Zenith Controls spočíva v tom, že tímy môžu tieto pohľady mapovať späť na rovnaké dôkazy ku kontrolám namiesto udržiavania oddelených síl súladu.

Vykonajte 45-minútový dôkazový sprint prístupu k PII

Užitočným spôsobom, ako otestovať pripravenosť, je vybrať jeden systém s vysokým dopadom, napríklad platformu zákazníckej podpory, HR systém, platobný portál, pacientsky portál, dátové jazero alebo produkčnú databázu SaaS, a vykonať cielený dôkazový sprint.

Krok 1: Definujte kontext spracúvania PII

Zaznamenajte do REG12:

• Názov systému a vlastník
• Kategórie PII
• Kategórie dotknutých osôb
• Rola prevádzkovateľa alebo sprostredkovateľa
• Účel spracúvania
• Indikátor PII s vysokým dopadom alebo citlivých PII
• Závislosti od cloudu, dodávateľov a ďalších sprostredkovateľov

Ak systém zahŕňa sprostredkovateľa, overte polia zmluvných kontrol REG08 podľa Processor, Subprocessor and Third-Party Privacy Management Policy. Schválenie má pokrývať rozsah spracúvania, trvanie, účel, kategórie PII, kategórie dotknutých osôb, dôvernosť, bezpečnosť, schválenie ďalšieho sprostredkovateľa, súčinnosť, audit alebo uistenie, vrátenie, výmaz a ukončenie.

Krok 2: Získajte zoznam prístupov

Exportujte všetkých používateľov, skupiny, privilegované roly, servisné účty, roly podpory, účty „break glass“, kľúče API a dodávateľské účty. Porovnajte každé oprávnenie so schválenými rolami.

Krok 3: Potvrďte zásadu minimálnych oprávnení a zosúladenie s účelom

Použite základnú úroveň z PII Security and Access Control Policy: prístup musí byť pred povolením obmedzený na schválené roly a oprávnených používateľov zaznamenaných alebo sledovateľných v REG02 alebo REG12. Ak používateľa nemožno vystopovať k role, účelu a schváleniu, zistenie nie je „chýbajúca dokumentácia“. Zistenie znie „prístup k PII nie je preukázateľne oprávnený“.

Krok 4: Overte rozsah logovania

Potvrďte, že logy zachytávajú autentifikáciu, udalosti prístupu, privilegované úkony, aktivitu exportu PII a podstatné konfiguračné zmeny. Následne potvrďte, kde sú logy uložené, ako dlho sa uchovávajú, kto k nim môže pristupovať a či sú zaznamenané v registri auditnej stopy ISMS pre audity, vyšetrovania a regulačné preskúmania.

Krok 5: Uzavrite cyklus

Pre každú výnimku zaznamenajte vlastníka rizika, okamžité opatrenie na obmedzenie dopadu, trvalú nápravu, cieľový dátum, požadované dôkazy, rozhodnutie o zostatkovom riziku a to, či je potrebné posúdenie porušenia ochrany osobných údajov.

Toto jedno cvičenie zvyčajne odhalí skutočnú zrelosť správy a riadenia prístupu k PII. Silné organizácie vedia odpovedať rýchlo. Slabé organizácie zistia, že politika ochrany súkromia, konfigurácia IAM, zmluvy so sprostredkovateľmi, cloudové logovanie a auditné dôkazy nie sú prepojené.

Bežné auditné zistenia v správe a riadení prístupu k PII

Väčšina zistení je predvídateľná. Vznikajú vtedy, keď ochrana súkromia, bezpečnosť, právne oddelenie, IT a dodávatelia riadia každý inú časť príbehu, ale nikto nevlastní celý životný cyklus prístupu k PII.

Bežné zistenia zahŕňajú:

• Systémy s PII nie sú úplne uvedené v evidencii PIMS.
• Prístupové roly sú definované technicky, ale nie sú namapované na účely spracúvania.
• Citlivé PII sú dostupné cez široké prevádzkové skupiny.
• Štvrťročné preskúmania pokrývajú zamestnancov, ale nie servisné účty, kľúče API alebo používateľov dodávateľov.
• Cloudový prístup podpory je možný, ale nie je preskúmavaný ako prístup k PII.
• Logy existujú, ale nepreukazujú prístup k PII, export ani privilegovanú aktivitu.
• Zmluvy so sprostredkovateľmi obsahujú všeobecné doložky dôvernosti, ale nie konkrétne kontroly riadenia prístupu, auditu, ďalšieho sprostredkovateľa, vrátenia, výmazu alebo ukončenia.
• Bývalí zamestnanci alebo zmluvní pracovníci si ponechávajú prístup cez zdieľané skupiny alebo nespravované tokeny.
• Prístup k dátovému skladu je širší ako prístup k zdrojovej aplikácii.
• Účty „break glass“ existujú bez preskúmania po použití.
• Vydávanie sa zákazníckej podpory za používateľa nie je logované s kontextom ticketu.
• Vyhlásenie o aplikovateľnosti obsahuje kontroly prístupu, ale dôkazy neukazujú implementáciu špecifickú pre PII.

Každé z týchto zistení sa môže podľa rozsahu zmeniť na problém preukázateľnej zodpovednosti podľa GDPR, problém uistenia zákazníkov, slabinu správy a riadenia podľa NIS2 alebo DORA alebo nezhodu podľa ISO/IEC 27001:2022.

Ako vyzerá dobrý stav

Vyspelý prevádzkový model sa nespolieha na heroické štvrťročné čistenia. Vkladá správu a riadenie prístupu k PII do bežnej prevádzky.

Po prvé, organizácia má povedomie o údajoch. Vie, kde PII existujú, prečo sa spracúvajú, ktorá rola PIMS sa uplatňuje a ktoré systémy, dodávatelia, cloudové služby, logy, zálohy a exporty patria do rozsahu.

Po druhé, prístup je založený na rolách a zosúladený s účelom. Oprávnenia sú definované schválenými rolami, zdokumentovanou obchodnou potrebou, účelom spracúvania a zásadou minimálnych oprávnení.

Po tretie, kontroly sú technicky vynucované. IAM, RBAC, správa privilegovaných prístupov, MFA, podmienený prístup, kontroly tenantov, šifrovanie a oddelenie prostredí vynucujú očakávania politiky.

Po štvrté, monitorovanie je zámerné. Organizácia dokáže zrekonštruovať autentifikáciu, prístup, export, privilegované úkony, prístup podpory a konfiguračné zmeny ovplyvňujúce PII.

Po piate, preskúmania sú založené na riziku a zdokumentované. PII s vysokým dopadom majú minimálne štvrťročné preskúmanie. Prístup dodávateľov a cloudovej podpory je zahrnutý. Výnimky sa sledujú až do uzavretia.

Po šieste, dôkazy sú opätovne použiteľné. Tie isté záznamy podporujú preukázateľnú zodpovednosť podľa GDPR, prevádzku PIMS podľa ISO/IEC 27701:2025, ošetrenie rizík podľa ISO/IEC 27001:2022, opatrenia riadenia rizík podľa NIS2, správu a riadenie rizík IKT podľa DORA, výsledky GOVERN podľa NIST CSF 2.0 a uistenie manažmentu podľa COBIT 2019.

Toto je rozdiel medzi riadením prístupu ako nastavením a správou a riadením prístupov ako systémom.

Premeňte prístup k PII na dôkazy pripravené na audit

Ak by váš ďalší audit, zákaznícke preskúmanie alebo preverenie regulátorom začalo zajtra otázkou „ukážte mi, kto môže pristupovať k PII“, pripravil by váš tím dôkazy v priebehu minút, alebo by začal zosúlaďovať tabuľkové prehľady?

Clarysec vám môže pomôcť túto medzeru uzavrieť.

Začnite s PII Security and Access Control Policy, zosúlaďte povinnosti sprostredkovateľov a cloudové povinnosti prostredníctvom Processor, Subprocessor and Third-Party Privacy Management Policy a Cloud PII Processor Policy, potom použite Zenith Blueprint: An Auditor’s 30-Step Roadmap na implementáciu kontrol v správnom poradí. Napokon použite Zenith Controls: The Cross-Compliance Guide na mapovanie dôkazov o prístupe k PII naprieč ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 a COBIT 2019.

Najrýchlejší praktický ďalší krok je jednoduchý: vyberte jeden systém PII s vysokým dopadom, vyplňte REG12, exportujte zoznam prístupov, overte rozsah logovania a vykonajte preskúmanie v štýle štvrťročného cyklu. Po jednom sedení budete vedieť, či je vaša správa a riadenie prístupu k PII pripravená na audit, alebo iba pripravená v politike.