Správa a řízení přístupu k PII pro ISO 27701:2025 a GDPR

Otázka externího auditora zůstala viset ve vzduchu. Zdánlivě jednoduchá.

„Můžete mi ukázat záznam o přezkumu přístupových oprávnění vašeho týmu podpory k produkčním PII za poslední čtvrtletí?“

Pro Anyu, CISO ve společnosti Medtelligence, rychle rostoucím poskytovateli SaaS pro zdravotnictví, to byl okamžik pravdy. Medtelligence vystupuje jako zpracovatel PII pro nemocnice a zpracovává citlivá data pacientů v cloudové platformě. Společnost měla silnou autentizaci, definované role a vyspělý inženýrský tým. Auditor se ale neptal, zda existuje přihlašovací stránka. Požadoval důkaz, že přístup k osobním údajům je dlouhodobě řízen.

Chtěl vidět, kdo může přistupovat k produkčním PII, proč má přístup, kdy byl přístup schválen, zda je stále potřebný, zda je činnost podpory protokolována a zda byla nepotřebná oprávnění odebrána.

Anya otevřela konzoli IAM. Byli v ní pracovníci podpory, správci databází, integrační servisní účet, poskytovatel řízených služeb, dvě nouzové role typu „break-glass“ a bývalý dodavatel, který stále zůstával ve skupině, protože tiket k ukončení jeho přístupu byl uzavřen dříve, než bylo oprávnění skutečně odebráno. HR uvádělo, že dotyčná osoba odešla před šesti týdny. Tabulka přezkumu přístupových oprávnění uváděla „čeká na vyřízení“. SIEM obsahoval protokoly, ale nikdo nezmapoval, které události dokládají přístup k PII.

Tady se správa a řízení ochrany soukromí stává skutečnou provozní praxí.

Podle GDPR musí být osobní údaje zpracovávány způsobem zajišťujícím integritu a důvěrnost a musí být chráněny před neoprávněným nebo protiprávním zpracováním, náhodnou ztrátou, zničením nebo poškozením prostřednictvím vhodných technických a organizačních opatření. GDPR zároveň výslovně stanoví odpovědnost: správce musí být schopen soulad doložit. ISO/IEC 27701:2025 tuto odpovědnost převádí do systému řízení informací o soukromí, tedy PIMS, kde přístup k PII již není technickou dodatečnou úvahou. Stává se řízeným životním cyklem napříč rolemi, zpracovateli, cloudovými platformami, zaměstnanci, privilegovanými administrátory, protokoly, přezkumy, smlouvami a důkazy.

Mezera u mnoha organizací nespočívá v tom, že by neměly řízení přístupu. Spočívá v tom, že nedokážou konzistentně doložit správu a řízení přístupu k PII napříč 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 řízení přístupu k PII není jen IAM

Tradiční program IAM se ptá: „Mohou oprávnění uživatelé přistupovat ke správným systémům?“

Vyspělý PIMS podle ISO/IEC 27701:2025 klade náročnější otázky:

• Které systémy zpracovávají PII?
• Které role vyžadují přístup ke kterým kategoriím PII?
• Vystupuje organizace jako správce PII, zpracovatel, společný správce nebo dílčí zpracovatel?
• Je přístup omezen účelem, dokumentovanou obchodní potřebou a zásadou minimálních oprávnění?
• Jsou privilegované akce protokolovány a přezkoumávány?
• Může organizace doložit, že přístup zpracovatelů a dílčích zpracovatelů je smluvně řízen?
• Jsou do důkazů zahrnuty přístupové cesty cloudové podpory, izolace tenantů, exporty a administrátorské akce?
• Jsou rozhodnutí o přístupu přezkoumávána po onboardingu, změně role, incidentu, ukončení přístupu a významné změně systému?

Proto jsou zabezpečení PII a správa a řízení přístupu přirozeným mostem mezi ISO/IEC 27701:2025 a GDPR. GDPR poskytuje rámec právní odpovědnosti. ISO/IEC 27701:2025 převádí řízení ochrany soukromí pro správce a zpracovatele do provozní praxe. ISO/IEC 27001:2022 poskytuje mechanismus řízení rizik v ISMS. ISO/IEC 27002:2022 poskytuje architekturu opatření, včetně ochrany soukromí a ochrany PII, řízení přístupu, přístupových práv, protokolování, cloudových služeb, vztahů s dodavateli, klasifikace, výmazu, maskování a kryptografie.

Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap toto zařazuje do fáze Controls in Action. V kroku 23, který pokrývá organizační opatření 5.19 až 5.37, popisuje opatření ISO/IEC 27002:2022 5.34, Privacy and Protection of PII, jako otázku důvěry, nikoli pouze jako otázku dat:

osobně identifikovatelné údaje nejsou jen dalším typem dat, jsou hluboce citlivým vyjádřením důvěry. Jména, adresy, identifikační údaje, zdravotní záznamy, finanční údaje – tato data vyprávějí příběh skutečných lidí.

Tentýž text uvádí praktický základ: ochrana soukromí začíná znalostí dat. Organizace musí vědět, jaké PII shromažďuje, kde se nacházejí, proč jsou zpracovávány a kdo k nim může přistupovat.

Tlak na soulad v oblasti řízení přístupu k PII

Správa a řízení přístupu k PII již není otázkou jediného rámce. Organizace jako Medtelligence působí na průsečíku regulace ochrany osobních údajů, práva kybernetické bezpečnosti, provozní odolnosti, ujištění zákazníků a bezpečnostní certifikace.

GDPR článek 5 vyžaduje, aby osobní údaje byly zpracovávány podle zásad zákonnosti, korektnosti, transparentnosti, účelového omezení, minimalizace údajů, přesnosti, omezení uložení, integrity a důvěrnosti. Článek 5(2) zavádí odpovědnost: správce odpovídá za soulad a musí být schopen jej doložit. Článek 32 následně vyžaduje vhodná technická a organizační opatření pro zabezpečení zpracování.

NIS2 článek 21 vyžaduje, aby základní a důležité subjekty přijaly vhodná a přiměřená technická, provozní a organizační opatření k řízení rizik kybernetické bezpečnosti. Jeho minimální oblasti zahrnují analýzu rizik, bezpečnostní politiky, zvládání incidentů, kontinuitu činností, zabezpečení dodavatelského řetězce, bezpečné pořizování a vývoj, posouzení účinnosti, kybernetickou hygienu a školení, kryptografii, personální bezpečnost, řízení přístupu, správu aktiv a případně vícefaktorovou nebo průběžnou autentizaci a bezpečnou komunikaci. Článek 20 rovněž ukládá vedoucím orgánům odpovědnost za schvalování opatření k řízení rizik kybernetické bezpečnosti a dohled nad nimi.

DORA se od 17. ledna 2025 vztahuje na široký okruh finančních subjektů a vytváří odvětvový režim provozní odolnosti. Pokrývá řízení rizik v oblasti ICT, hlášení závažných incidentů souvisejících s ICT, testování digitální provozní odolnosti, sdílení informací, rizika třetích stran v oblasti ICT a smluvní ujednání s poskytovateli ICT služeb třetích stran. Pro finanční subjekty a poskytovatele ICT služeb, kteří je podporují, není řízení přístupu jen otázkou ochrany soukromí. Je součástí provozní odolnosti.

ISO/IEC 27001:2022 propojuje tyto povinnosti v systému řízení založeném na rizicích. Kapitoly 6.1.1 až 6.1.3 vyžadují, aby organizace řešily rizika a příležitosti, definovaly proces posuzování rizik bezpečnosti informací, identifikovaly rizika pro důvěrnost, integritu a dostupnost, hodnotily rizika, vybíraly možnosti ošetření, určovaly opatření, porovnávaly zvolená opatření s přílohou A, dokumentovaly Prohlášení o použitelnosti, získaly schválení vlastníka rizika a přijaly zbytková rizika. Kapitoly 8.2 a 8.3 vyžadují posouzení rizik v plánovaných intervalech nebo po významné změně a implementaci plánu ošetření rizik s dokumentovanými výsledky.

Pro správu a řízení PII to znamená, že řízení přístupu není izolované nastavení IAM. Je to rozhodnutí o ošetření rizik. Role, která může exportovat mzdové záznamy, data pacientů, platební údaje, doklady totožnosti, lokalizační údaje nebo přepisy zákaznické podpory, musí být odůvodněna v registru rizik, promítnuta do Prohlášení o použitelnosti, vynucována v IAM, protokolována v produkčním prostředí, pravidelně přezkoumávána a odebrána, jakmile již není potřebná.

Model opatření Clarysec: od příslibu ochrany soukromí k důkazům

Clarysec pojímá správu a řízení přístupu k PII jako řetězec důkazů. Řetězec začíná inventářem dat a definicí rolí, pokračuje schvalováním a vynucováním přístupu a končí monitorováním, přezkumem, odebráním přístupu a záznamy připravenými pro audit.

V Zenith Controls: The Cross-Compliance Guide je toto téma soustředěno především kolem tří opatření ISO/IEC 27002:2022:

Auditoři jen zřídka přijmou tvrzení „používáme IAM“ jako důkaz. Očekávají, že uvidí, jak se rozhodnutí v IAM vážou na povinnosti v oblasti ochrany soukromí, vlastnictví systému, klasifikaci dat, obchodní potřebu, ošetření rizik, četnost přezkumů přístupových oprávnění, rozsah protokolování a smlouvy s dodavateli.

Clarysec PII Security and Access Control Policy stanovuje základní soubor požadavků jazykem PIMS:

[Oba] Vlastník systému / vlastník aplikace MUSÍ před povolením přístupu omezit přístup k PII na schválené role a autorizované uživatele zaznamenané nebo dohledatelné v REG02 nebo REG12.

Ze sekce „4.2 Základní požadavky na řízení přístupu“, ustanovení politiky 4.2.1.

Značka „[Oba]“ znamená, že se opatření uplatní bez ohledu na to, zda organizace vystupuje jako správce PII nebo zpracovatel PII. Na tomto rozlišení záleží. Správci často nedokážou definovat pravidla přístupu podle účelu. Zpracovatelé často nedokážou prokázat, že přístup je omezen na pokyny zákazníka, schválené cesty podpory a smluvně oprávněný personál.

Tatáž politika zpřísňuje požadavek u citlivých PII nebo PII s vysokým dopadem:

[Oba] Vlastník systému / vlastník aplikace MUSÍ alespoň čtvrtletně přezkoumávat přístup uživatelů k systémům zpracovávajícím PII s vysokým dopadem nebo citlivé PII a zaznamenat výsledek přezkumu v REG12.

Ze sekce „4.2 Základní požadavky na řízení přístupu“, ustanovení politiky 4.2.3.

Tady se PIMS stává auditovatelným. Přezkum přístupových oprávnění není jen e-mail od manažera. Je to záznam v REG12 navázaný na systém, kategorii dat, roli, vlastníka, výsledek přezkumu a nápravné opatření.

Základ politik: minimální oprávnění, obchodní potřeba a implicitní zamítnutí

Účinná správa začíná vymahatelnými pravidly. Než mohla Anya auditorovi ukázat záznam o přezkumu přístupových oprávnění, musela doložit, že požadavek na přezkumy přístupových oprávnění byl formálně stanoven.

Clarysec SME Access Control Policy - SME stanovuje princip:

Tato politika prosazuje zásadu minimálních oprávnění a vyžaduje, aby byl přístup omezen na minimum nezbytné k plnění pracovních úkolů.

Ze sekce „Účel“, ustanovení politiky 1.3.

SME Data Protection and Privacy Policy - SME váže přístup na obchodní potřebu:

Přístup uživatelů k osobním údajům musí být omezen na role s dokumentovanou obchodní potřebou.

Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.3.2.

U větších organizací vyjadřuje enterprise Data Protection and Privacy Policy očekávání vůči opatření jako systémový požadavek:

Všechny systémy musí ve výchozím stavu vynucovat přístup podle zásady minimálních oprávnění.

Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.3.1.

Rozdíl je důležitý. Menší společnost může potřebovat lehký, ale výslovný záznam obchodní potřeby. Enterprise organizace potřebuje vynucování na úrovni systémů, pravidelný přezkum, oddělení povinností, správu privilegovaných přístupů a důkazy uchovávané pro interní audit, ujištění zákazníků, regulační šetření a vyšetřování porušení zabezpečení.

Životní cyklus přístupu k PII: schválení, používání, přezkum, odebrání

Nejčastějším selháním přístupu k PII není počáteční schválení. Je jím přetrvávání přístupu.

Zenith Blueprint ve fázi Controls in Action, kroku 22, vysvětluje opatření ISO/IEC 27002:2022 5.18, Access Rights, takto:

Opatření 5.18 zajišťuje, že přístupová práva jsou nejen řádně udělována, ale také přezkoumávána, upravována a odebírána řízeným a dohledatelným způsobem.

Následně popisuje známé scénáře: nově nastupující zaměstnanec získá přístup, změní roli a ponechá si stará oprávnění; bývalý administrátor odejde, ale token zůstane aktivní; účet dodavatele vyprší na papíře, nikoli však v IAM. Právě tyto slabiny se při zapojení PII mění na bezpečnostní incidenty podle GDPR.

Clarysec SME User Account and Privilege Management Policy - SME stanovuje základní periodicitu:

Přezkum všech uživatelských účtů a oprávnění musí být proveden každých šest měsíců.

Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.4.1.

Pro enterprise prostředí User Account and Privilege Management Policy zpřísňuje provozní rytmus:

IT Security musí ve spolupráci s vedoucími oddělení provádět čtvrtletní přezkumy všech uživatelských účtů a souvisejících oprávnění.

Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.5.1.

Praktický životní cyklus přístupu k PII má zahrnovat:

1. Klasifikaci systému a kategorií PII.
2. Definici schválených rolí a dokumentované obchodní potřeby.
3. Mapování rolí na účely zpracování.
4. Schválení přístupu před jeho povolením.
5. Vynucování zásady minimálních oprávnění, oddělení povinností a silné autentizace.
6. Protokolování autentizace, přístupu, exportu, konfigurace a privilegovaných akcí.
7. Přezkum přístupů v periodicitě založené na riziku.
8. Odebrání přístupu při změně role, ukončení pracovního poměru, uzavření projektu, skončení smlouvy nebo na základě pokynu zákazníka.
9. Uchování důkazů v registru PIMS a auditní stopě.

To není byrokracie. Tak organizace dokládá, že přístup k PII je řízen již od návrhu, ve výchozím nastavení a na základě důkazů.

Praktický příklad: čtvrtletní přezkum přístupu k PII

Audit u Anyi uspěl ve chvíli, kdy přesunula diskusi od prohlášení v politikách k důkazům.

Nejprve odkázala na PII Security and Access Control Policy, ustanovení 4.2.3, které vyžadovalo čtvrtletní přezkum přístupů k PII s vysokým dopadem nebo citlivým PII a zaznamenání výsledku přezkumu v REG12.

Poté auditora provedla předchozím čtvrtletím:

• IT vygenerovalo seznam všech uživatelů, skupin, privilegovaných rolí, servisních účtů, účtů dodavatelů, rolí typu „break-glass“ a oprávnění podpory pro produkční databázi obsahující data pacientů.
• Seznam byl předán vlastníkovi aplikace, řediteli zákaznického úspěchu, který odpovídal za provozní potřebu týmu podpory.
• Vlastník aplikace seznam položku po položce přezkoumal vůči aktuální roli, odpovědnostem v zákaznické podpoře a účelu zpracování.
• Dva pracovníci podpory, kteří přešli do jiných týmů, byli označeni k odebrání přístupu.
• V systému řízení IT služeb byl vytvořen tiket propojený s přezkumem přístupových oprávnění, s přiřazenou SLA, a po odebrání přístupu byl uzavřen.
• REG12 byl aktualizován o záznam přezkumu, schvalovatele, výjimky, tiket nápravy, důkazy o uzavření a datum příštího přezkumu.

Výsledkem byl uzavřený řetězec důkazů. Anya pouze netvrdila, že Medtelligence používá zásadu minimálních oprávnění. Ukázala požadavek politiky, odpovědného vlastníka, seznam přístupů, rozhodnutí z přezkumu, nápravné opatření a dokončené odebrání přístupu.

To je rozdíl mezi řízením přístupu a správou přístupu.

Přístup dodavatelů a zpracovatelů: slepé místo auditů PIMS

Mnoho rizik neoprávněného přístupu přichází přes podporu, outsourcing, integrační partnery, poskytovatele řízených služeb a dílčí zpracovatele. Zpracovatel může mít vzdálený přístup k produkčním datům zákazníků. Cloudový poskytovatel může poskytovat přístupové cesty podpory. Dílčí zpracovatel může udržovat vyhledávací index obsahující identifikátory zákazníků. Poskytovatel řízených bezpečnostních služeb může přistupovat k protokolům obsahujícím osobní údaje.

Podle GDPR musí správci využívat zpracovatele, kteří poskytují dostatečné záruky. Podle ISO/IEC 27701:2025 musí být správa a řízení zpracovatelů a dílčích zpracovatelů převedena do provozní praxe prostřednictvím dokumentovaných pokynů, smluvních opatření, ujištění a monitorování. ISO/IEC 27002:2022 to podporuje prostřednictvím opatření pro vztahy s dodavateli, včetně 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áze Controls in Action, krok 23, shrnuje oblasti důkazů ve smlouvách s dodavateli mimo jiné takto:

✓ Odpovědnosti za řízení přístupu, například kdo může přistupovat k vašim datům, jak jsou spravovány přihlašovací údaje a jaké monitorování je zavedeno;

Zahrnuje také povinnosti zachování důvěrnosti, technická a organizační opatření, lhůty pro hlášení incidentů, právo na audit, kontrolu subdodavatelů a deaktivaci účtů při ukončení smlouvy.

Clarysec Processor, Subprocessor and Third-Party Privacy Management Policy převádí tyto požadavky na důkazy PIMS na straně správce:

[Správce] Vedoucí ochrany soukromí / manažer PIMS MUSÍ před schválením ověřit, že pole smluvních opatření zpracovatele v REG08 pokrývají rozsah zpracování, dobu trvání, účel, kategorie PII, kategorie subjektů PII, důvěrnost, bezpečnost, schválení dílčího zpracovatele, součinnost, audit nebo ujištění, vrácení, výmaz a ukončení.

Ze sekce „4.3 Smluvní a dokumentované pokyny“, ustanovení politiky 4.3.2.

Přístup dodavatelů je přímo řízen také v SME a enterprise dodavatelských politikách Clarysec. SME Third-Party and Supplier Security Policy - SME uvádí:

Dodavatelům musí být udělen přístup pouze k minimálním systémům a datům nezbytným k výkonu jejich funkce.

Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.2.1.

Enterprise Third party and supplier security policy doplňuje RBAC, přezkum a zásadu minimálních oprávnění:

Personál dodavatelů musí podléhat řízení přístupu založenému na rolích (RBAC), pravidelným přezkumům přístupových oprávnění a vynucování zásady minimálních oprávnění.

Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.3.1.

Pokud může přístup dodavatele dosáhnout na PII, patří do PIMS. Má se objevit ve smluvních opatřeních, schváleních přístupu, skupinách IAM, rozsahu protokolování, záznamech přezkumu, záznamech o ukončení přístupu, playboocích incidentů a auditních důkazech.

Přístup k PII v cloudu: sdílená odpovědnost neznamená sdílenou odpovědnost za doložení souladu

Správa a řízení přístupu k PII v cloudu je oblastí, kde organizace často přeceňují poskytovatele a podceňují vlastní odpovědnosti. Cloudový poskytovatel může zabezpečovat infrastrukturu, ale zákazník stále řídí identity, role, konfiguraci tenantů, přístup podpory, protokoly, nastavení šifrování, oprávnění k exportu a připravenost na reakci na incidenty.

Zenith Blueprint, fáze Controls in Action, krok 23, to ve svých pokynech ke cloudovým službám uvádí přímo:

Cloudoví poskytovatelé zabezpečují infrastrukturu, ale vy stále odpovídáte za svá data, své konfigurace, své přístupové politiky a svou připravenost na reakci na incidenty.

Zároveň upozorňuje:

V cloudu je viditelnost jen částečná, pokud není záměrně navržena. Musíte nakonfigurovat protokolování, vynucovat šifrování, definovat role identit a monitorovat aktivitu pomocí nativních nástrojů nebo integrací třetích stran. To není úloha infrastruktury, ale požadavek ISMS.

Clarysec Cloud Usage Policy tento požadavek převádí na enterprise požadavek na přístup:

Všechny cloudové služby musí vynucovat řízení přístupu založené na identitě v souladu se zásadou minimálních oprávnění.

Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.2.1.

Pro organizace vystupující jako zpracovatelé v cloudových prostředích definuje Clarysec Cloud PII Processor Policy konkrétnější povinnost přezkumu v PIMS:

[Zpracovatel] Vedoucí informační bezpečnosti MUSÍ alespoň čtvrtletně přezkoumat privilegovaný cloudový přístup, přístup podpory, přístup k PII zákazníků a pokrytí protokolováním v REG12.

Ze sekce „4.2 Konfigurace cloudu, izolace tenantů, přístup a protokolování“, ustanovení politiky 4.2.4.

Toto ustanovení je zvlášť relevantní pro společnosti poskytující SaaS, platformy hostované v cloudu, spravované datové služby a B2B zpracovatele.

Správa a řízení přístupu k PII v cloudu není úplná, pokud nejsou společně přezkoumány cloud-native protokoly, politiky IAM, servisní účty, privilegované role, nástroje zákaznické podpory, API klíče a funkce exportu dat.

Protokolování a monitorování: paměť správy a řízení PII

Program řízení přístupu v PIMS bez protokolů je příslib bez paměti.

PII Security and Access Control Policy vyžaduje definování rozsahu protokolování před produkčním používáním nebo významnou změnou:

[Oba] Vlastník systému / vlastník aplikace MUSÍ v REG12 definovat rozsah protokolování PII pro události autentizace, události přístupu, privilegované akce, aktivitu exportu PII a významné změny konfigurace před produkčním používáním nebo významnou změnou.

Ze sekce „4.6 Protokolování a monitorování“, ustanovení politiky 4.6.1.

SME Logging and Monitoring Policy - SME výslovně vymezuje obsah protokolů přístupu:

Protokoly přístupu: přístup k souborům (zejména u citlivých nebo osobních údajů), změny oprávnění, využívání sdílených zdrojů

Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.4.3.

Enterprise Logging and Monitoring Policy se zaměřuje na použitelnost pro audit:

Registr auditní stopy ISMS musí zaznamenávat dostupnost dat z protokolů pro audity, vyšetřování a regulační přezkumy.

Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.4.

To je zásadní, protože důkazy k ochraně soukromí musí často odpovídat na otázky založené na událostech:

• Kdo přistoupil k PII?
• Byl přístup autorizovaný?
• Byl přístup propojen s tiketem podpory, právní žádostí, provozní úlohou nebo pokynem zákazníka?
• Byla data exportována, kopírována, změněna nebo smazána?
• Byl použit privilegovaný přístup?
• Byla oprávnění změněna před přístupem nebo po něm?
• Naznačovala aktivita bezpečnostní incident nebo porušení zabezpečení osobních údajů?

Protokoly nejsou určeny jen pro SOC. Jsou důkazy PIMS, důkazy pro ujištění zákazníků, důkazy pro ujištění o zpracovatelích a důkazy pro reakci na incidenty.

Mapování souladu napříč rámci: jeden model přístupu, více pohledů

Slabina v přezkumech přístupů k PII není nikdy jen jedním zjištěním. Může se stát problémem odpovědnosti podle GDPR, slabinou PIMS podle ISO/IEC 27701:2025, neshodou podle ISO/IEC 27001:2022, selháním správy a řízení podle NIS2, rizikem odolnosti podle DORA, mezerou ve správě podle NIST CSF 2.0 nebo problémem vyspělosti procesu podle COBIT 2019.

Podrobnější mapování opatření napříč rámci ukazuje, jak jeden proces správy a řízení přístupu k PII podporuje více požadavků:

Hodnota Zenith Controls spočívá v tom, že týmy mohou tyto pohledy mapovat zpět na stejné důkazy o opatřeních, místo aby udržovaly oddělená sila souladu.

Proveďte 45minutový sprint důkazů o přístupu k PII

Užitečný způsob, jak ověřit připravenost, je vybrat jeden systém s vysokým dopadem, například platformu zákaznické podpory, HR systém, platební portál, portál pro pacienty, datové jezero nebo produkční databázi SaaS, a provést cílený důkazní sprint.

Krok 1: Definujte kontext zpracování PII

Zaznamenejte do REG12:

• Název a vlastníka systému
• Kategorie PII
• Kategorie subjektů PII
• Roli správce nebo zpracovatele
• Účel zpracování
• Indikátor PII s vysokým dopadem nebo citlivých PII
• Závislosti na cloudu, dodavatelích a dílčích zpracovatelích

Pokud systém zahrnuje zpracovatele, ověřte pole smluvních opatření v REG08 pomocí Processor, Subprocessor and Third-Party Privacy Management Policy. Schválení má pokrývat rozsah zpracování, dobu trvání, účel, kategorie PII, kategorie subjektů PII, důvěrnost, bezpečnost, schválení dílčího zpracovatele, součinnost, audit nebo ujištění, vrácení, výmaz a ukončení.

Krok 2: Získejte seznam přístupů

Exportujte všechny uživatele, skupiny, privilegované role, servisní účty, role podpory, účty typu „break-glass“, API klíče a účty dodavatelů. Porovnejte každé oprávnění se schválenými rolemi.

Krok 3: Potvrďte minimální oprávnění a sladění s účelem

Použijte základní požadavek PII Security and Access Control Policy: přístup musí být před povolením omezen na schválené role a autorizované uživatele zaznamenané nebo dohledatelné v REG02 nebo REG12. Pokud uživatele nelze dohledat k roli, účelu a schválení, zjištění nezní „chybí dokumentace“. Zjištění zní „přístup k PII není prokazatelně autorizován“.

Krok 4: Ověřte rozsah protokolování

Potvrďte, že protokoly zachycují autentizaci, události přístupu, privilegované akce, aktivitu exportu PII a významné změny konfigurace. Poté potvrďte, kde jsou protokoly uloženy, jak dlouho jsou uchovávány, kdo k nim může přistupovat a zda jsou zaznamenány v registru auditní stopy ISMS pro audity, vyšetřování a regulační přezkumy.

Krok 5: Uzavřete smyčku

U každé výjimky zaznamenejte vlastníka rizika, okamžité opatření k omezení dopadu, trvalou nápravu, cílové datum, požadované důkazy, rozhodnutí o zbytkovém riziku a informaci, zda je nutné posouzení porušení zabezpečení osobních údajů.

Toto jediné cvičení obvykle odhalí skutečnou vyspělost správy a řízení přístupu k PII. Silné organizace dokážou odpovědět rychle. Slabé organizace zjistí, že politika ochrany soukromí, konfigurace IAM, smlouvy se zpracovateli, cloudové protokolování a auditní důkazy nejsou propojeny.

Častá auditní zjištění ve správě a řízení přístupu k PII

Většina zjištění je předvídatelná. Vznikají tehdy, když ochrana soukromí, bezpečnost, právní oddělení, IT a dodavatelé ovládají každý jen část příběhu, ale nikdo nevlastní celý životní cyklus přístupu k PII.

Mezi častá zjištění patří:

• Systémy PII nejsou úplně uvedeny v evidenci PIMS.
• Přístupové role jsou definovány technicky, ale nejsou mapovány na účely zpracování.
• Citlivé PII jsou dostupné prostřednictvím širokých provozních skupin.
• Čtvrtletní přezkumy pokrývají zaměstnance, ale nikoli servisní účty, API klíče nebo uživatele dodavatelů.
• Přístup cloudové podpory je možný, ale není přezkoumáván jako přístup k PII.
• Protokoly existují, ale nedokládají přístup k PII, export ani privilegovanou aktivitu.
• Smlouvy se zpracovateli obsahují obecné doložky o důvěrnosti, ale nikoli konkrétní opatření pro řízení přístupu, audit, dílčí zpracovatele, vrácení, výmaz nebo ukončení.
• Bývalí zaměstnanci nebo dodavatelé si zachovávají přístup prostřednictvím sdílených skupin nebo nespravovaných tokenů.
• Přístup k datovému skladu je širší než přístup ke zdrojové aplikaci.
• Účty typu „break-glass“ existují bez přezkumu po použití.
• Vydávání se za zákazníka ze strany zákaznické podpory není protokolováno s kontextem tiketu.
• Prohlášení o použitelnosti zahrnuje opatření řízení přístupu, ale důkazy neukazují implementaci specifickou pro PII.

Každé z těchto zjištění se může stát problémem odpovědnosti podle GDPR, otázkou ujištění zákazníků, slabinou správy podle NIS2 nebo DORA, případně neshodou podle ISO/IEC 27001:2022, v závislosti na rozsahu.

Jak vypadá dobrý stav

Vyspělý provozní model nespoléhá na hrdinské čtvrtletní úklidy. Začleňuje správu a řízení přístupu k PII do běžného provozu.

Zaprvé má organizace povědomí o datech. Ví, kde PII existují, proč jsou zpracovávány, která role PIMS se uplatní a které systémy, dodavatelé, cloudové služby, protokoly, zálohy a exporty jsou v rozsahu.

Zadruhé je přístup založený na rolích a sladěný s účelem. Oprávnění jsou definována schválenými rolemi, dokumentovanou obchodní potřebou, účelem zpracování a zásadou minimálních oprávnění.

Zatřetí jsou opatření technicky vynucována. IAM, RBAC, správa privilegovaných přístupů (PAM), MFA, podmíněný přístup, opatření pro tenanty, šifrování a oddělení prostředí vynucují očekávání politik.

Začtvrté je monitorování záměrně navrženo. Organizace dokáže rekonstruovat autentizaci, přístup, export, privilegované akce, přístup podpory a konfigurační změny ovlivňující PII.

Zapáté jsou přezkumy založené na riziku a dokumentované. PII s vysokým dopadem podléhají alespoň čtvrtletnímu přezkumu. Přístup dodavatelů a cloudové podpory je zahrnut. Výjimky jsou sledovány až do uzavření.

Zašesté jsou důkazy opakovaně použitelné. Stejné záznamy podporují odpovědnost podle GDPR, provoz PIMS podle ISO/IEC 27701:2025, ošetření rizik podle ISO/IEC 27001:2022, opatření k řízení rizik podle NIS2, řízení rizik ICT podle DORA, výsledky GOVERN podle NIST CSF 2.0 a manažerské ujištění podle COBIT 2019.

To je rozdíl mezi řízením přístupu jako nastavením a správou přístupu jako systémem.

Přeměňte přístup k PII na důkazy připravené pro audit

Kdyby váš příští audit, zákaznický přezkum nebo regulační šetření začaly zítra otázkou „ukažte mi, kdo může přistupovat k PII“, dokázal by váš tým předložit důkazy během minut, nebo by začal párovat tabulky?

Clarysec vám může pomoci tuto mezeru uzavřít.

Začněte s PII Security and Access Control Policy, slaďte povinnosti zpracovatelů a cloudu prostřednictvím Processor, Subprocessor and Third-Party Privacy Management Policy a Cloud PII Processor Policy, poté použijte Zenith Blueprint: An Auditor’s 30-Step Roadmap k implementaci opatření ve správném pořadí. Nakonec použijte Zenith Controls: The Cross-Compliance Guide k mapování důkazů o přístupu k PII napříč ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 a COBIT 2019.

Nejrychlejší praktický další krok je jednoduchý: vyberte jeden systém PII s vysokým dopadem, vyplňte REG12, exportujte seznam přístupů, ověřte rozsah protokolování a proveďte přezkum ve stylu čtvrtletního přezkumu. Během jedné pracovní relace zjistíte, zda je vaše správa a řízení přístupu k PII připravena pro audit, nebo pouze připravena na úrovni politik.