PII:n käyttöoikeuksien hallinnointi ISO/IEC 27701:2025:n ja GDPR:n näkökulmasta

Ulkoisen auditoijan kysymys jäi ilmaan. Se kuulosti petollisen yksinkertaiselta.

“Voitteko näyttää tukitiiminne tuotannon PII:hin kohdistuvien käyttöoikeuksien katselmointilokin viimeiseltä vuosineljännekseltä?”

Anya, Medtelligencen tietoturvajohtaja, ymmärsi tämän olevan ratkaiseva hetki. Medtelligence on nopeasti kasvava health-tech-SaaS-palveluntarjoaja, joka toimii sairaaloiden henkilötietojen käsittelijänä ja käsittelee arkaluonteisia potilastietoja pilvialustalla. Yrityksellä oli vahva tunnistautuminen, määritellyt roolit ja kypsä tekninen tiimi. Auditoija ei kuitenkaan kysynyt, onko kirjautumissivua olemassa. Hän pyysi näyttöä siitä, että henkilötietoihin kohdistuvaa pääsyä hallinnoidaan koko elinkaaren ajan.

Hän halusi nähdä, ketkä voivat käyttää tuotannon PII:tä, miksi heillä on pääsy, milloin pääsy on hyväksytty, tarvitaanko sitä edelleen, kirjataanko tukitoiminta lokiin ja onko tarpeettomat käyttöoikeudet poistettu.

Anya avasi IAM-konsolin. Siellä oli tukiteknikoita, tietokannan ylläpitäjiä, integraatiopalvelutili, hallinnoitu palveluntarjoaja, kaksi hätätilanteisiin tarkoitettua break-glass-roolia sekä entinen sopimuskumppani, joka oli edelleen ryhmässä, koska offboarding-tiketti oli suljettu ennen käyttöoikeuden poistamista. HR-tiedot osoittivat henkilön lähteneen kuusi viikkoa aiemmin. Käyttöoikeuskatselmoinnin laskentataulukossa luki “odottaa”. SIEM:ssä oli lokit, mutta kukaan ei ollut kartoittanut, mitkä tapahtumat osoittivat pääsyn PII:hin.

Tässä kohtaa tietosuojan hallinnointi muuttuu todelliseksi.

GDPR:n mukaan henkilötietoja on käsiteltävä eheästi ja luottamuksellisesti sekä suojattava luvattomalta tai lainvastaiselta käsittelyltä, vahingossa tapahtuvalta häviämiseltä, tuhoutumiselta tai vahingoittumiselta asianmukaisin teknisin ja organisatorisin toimenpitein. GDPR tekee myös osoitusvelvollisuudesta nimenomaisen: rekisterinpitäjän on pystyttävä osoittamaan vaatimustenmukaisuus. ISO/IEC 27701:2025 muuttaa tämän osoitusvelvollisuuden henkilötietojen hallintajärjestelmäksi eli PIMS:ksi, jossa PII:hin kohdistuva pääsy ei ole tekninen jälkiajatus. Siitä tulee hallinnoitu elinkaari, joka kattaa roolit, henkilötietojen käsittelijät, pilvialustat, työntekijät, etuoikeutetut ylläpitäjät, lokit, katselmoinnit, sopimukset ja todentavan aineiston.

Monen organisaation puute ei ole pääsynhallinnan puuttuminen. Puute on siinä, ettei organisaatio pysty osoittamaan PII:n käyttöoikeuksien hallinnointia johdonmukaisesti ISO/IEC 27701:2025:n, GDPR:n, ISO/IEC 27001:2022:n, ISO/IEC 27002:2022:n, NIS2:n, DORA:n, NIST CSF 2.0:n ja COBIT 2019:n näkökulmista.

PII:n käyttöoikeuksien hallinnointi ei ole vain IAM

Perinteinen IAM-ohjelma kysyy: “Pääsevätkö oikeat käyttäjät oikeisiin järjestelmiin?”

Kypsä ISO/IEC 27701:2025 -standardin mukainen PIMS kysyy vaikeampia kysymyksiä:

• Mitkä järjestelmät käsittelevät PII:tä?
• Mitkä roolit tarvitsevat pääsyn mihinkin PII-luokkiin?
• Toimiiko organisaatio PII:n rekisterinpitäjänä, henkilötietojen käsittelijänä, yhteisrekisterinpitäjänä vai alikäsittelijänä?
• Onko pääsy rajattu käyttötarkoituksen, dokumentoidun liiketoimintatarpeen ja vähimmän oikeuden periaatteen mukaisesti?
• Kirjataanko etuoikeutetut toimet lokiin ja katselmoidaanko ne?
• Voiko organisaatio osoittaa, että henkilötietojen käsittelijöiden ja alikäsittelijöiden pääsyä hallitaan sopimuksellisesti?
• Sisältyvätkö pilvituen reitit, tenanttien eristäminen, viennit ja hallinnolliset toimet todentavaan aineistoon?
• Katselmoidaanko pääsypäätökset perehdytyksen, roolimuutoksen, poikkeaman, palvelussuhteen päättämisen ja olennaisen järjestelmämuutoksen jälkeen?

Siksi PII:n suojaus ja käyttöoikeuksien hallinnointi muodostavat luontevan sillan ISO/IEC 27701:2025:n ja GDPR:n välille. GDPR antaa oikeudellisen osoitusvelvollisuuden kehyksen. ISO/IEC 27701:2025 operationalisoi tietosuojan hallinnan rekisterinpitäjille ja henkilötietojen käsittelijöille. ISO/IEC 27001:2022 tarjoaa ISMS:n riskienhallinnan moottorin. ISO/IEC 27002:2022 tarjoaa kontrolliarkkitehtuurin, mukaan lukien tietosuojan ja PII:n suojan, pääsynhallinnan, käyttöoikeudet, lokituksen, pilvipalvelut, toimittajasuhteet, luokittelun, poistamisen, maskauksen ja kryptografian.

Clarysecin Zenith Blueprint: An Auditor’s 30-Step Roadmap sijoittaa tämän Controls in Action -vaiheeseen. Vaiheessa 23, joka kattaa organisatoriset kontrollit 5.19–5.37, se kuvaa ISO/IEC 27002:2022 -standardin kontrollin 5.34, Privacy and Protection of PII, luottamuskysymyksenä eikä pelkkänä datakysymyksenä:

henkilöön yhdistettävissä oleva tieto ei ole vain yksi tietotyyppi muiden joukossa, vaan erittäin arkaluonteinen luottamuksen ilmentymä. Nimet, osoitteet, tunnisteet, terveystiedot ja taloudelliset tiedot kertovat tarinan oikeista ihmisistä.

Sama kohta antaa käytännön perustan: tietosuojan toteuttaminen alkaa tietoisuudesta dataan. Organisaation on tiedettävä, mitä PII:tä se kerää, missä se sijaitsee, miksi sitä käsitellään ja kuka voi käyttää sitä.

PII:n pääsynhallintaan kohdistuva vaatimusten paine

PII:n käyttöoikeuksien hallinnointi ei ole enää yhden viitekehyksen kysymys. Medtelligencen kaltaiset organisaatiot toimivat tietosuojasääntelyn, kyberturvallisuuslainsäädännön, operatiivisen häiriönsietokyvyn, asiakasvarmennuksen ja tietoturvasertifioinnin leikkauspisteessä.

GDPR:n Article 5 edellyttää henkilötietojen käsittelyä lainmukaisuuden, kohtuullisuuden, läpinäkyvyyden, käyttötarkoitussidonnaisuuden, tietojen minimoinnin, täsmällisyyden, säilytyksen rajoittamisen sekä eheyden ja luottamuksellisuuden periaatteiden mukaisesti. Article 5(2) tuo mukaan osoitusvelvollisuuden: rekisterinpitäjä vastaa vaatimustenmukaisuudesta ja sen osoittamisesta. Article 32 edellyttää tämän jälkeen asianmukaisia teknisiä ja organisatorisia toimenpiteitä käsittelyn turvallisuuden varmistamiseksi.

NIS2:n Article 21 edellyttää, että keskeiset ja tärkeät toimijat toteuttavat asianmukaiset ja oikeasuhteiset tekniset, operatiiviset ja organisatoriset kyberturvallisuuden riskienhallintatoimenpiteet. Sen vähimmäisalueisiin kuuluvat riskianalyysi, turvallisuuspolitiikat, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun turvallisuus, turvallinen hankinta ja kehittäminen, vaikuttavuuden arviointi, kyberhygienia ja koulutus, kryptografia, HR-turvallisuus, pääsynhallinta, omaisuudenhallinta sekä soveltuvin osin monivaiheinen tai jatkuva todennus ja turvallinen viestintä. Article 20 asettaa hallintoelimille vastuun kyberturvallisuuden riskienhallintatoimenpiteiden hyväksymisestä ja valvonnasta.

DORA:a sovelletaan 17. tammikuuta 2025 alkaen laajaan joukkoon finanssialan toimijoita, ja se luo alakohtaisen operatiivisen häiriönsietokyvyn järjestelmän. Se kattaa ICT-riskien hallinnan, merkittävien TVT-poikkeamien raportoinnin, digitaalisen operatiivisen häiriönsietokyvyn testauksen, tietojen jakamisen, ICT-kolmansien osapuolten riskit sekä sopimusjärjestelyt ICT-kolmansien osapuolten palveluntarjoajien kanssa. Finanssialan toimijoille ja niitä tukeville ICT-palveluntarjoajille pääsynhallinta ei ole vain tietosuojakysymys. Se on osa operatiivista häiriönsietokykyä.

ISO/IEC 27001:2022 liittää nämä velvoitteet riskiperusteiseen hallintajärjestelmään. Kohdat 6.1.1–6.1.3 edellyttävät, että organisaatiot käsittelevät riskejä ja mahdollisuuksia, määrittävät tietoturvariskien arviointiprosessin, tunnistavat luottamuksellisuuteen, eheyteen ja saatavuuteen kohdistuvat riskit, arvioivat riskit, valitsevat käsittelyvaihtoehdot, määrittävät kontrollit, vertaavat valittuja kontrolleja liitteeseen A, dokumentoivat soveltuvuuslausunnon, hankkivat riskinomistajan hyväksynnän ja hyväksyvät jäännösriskit. Kohdat 8.2 ja 8.3 edellyttävät riskien arviointeja suunnitelluin väliajoin tai merkittävän muutoksen jälkeen sekä riskienkäsittelysuunnitelman toteuttamista dokumentoiduin tuloksin.

PII:n hallinnoinnissa tämä tarkoittaa, ettei pääsynhallinta ole erillinen IAM-asetus. Se on riskien käsittelyä koskeva päätös. Rooli, joka voi viedä palkkatietoja, potilastietoja, maksutietoja, henkilöllisyysasiakirjoja, sijaintitietoja tai asiakastuen keskustelulokeja, on perusteltava riskirekisterissä, kuvattava soveltuvuuslausunnossa, toteutettava IAM:ssä, kirjattava tuotannon lokiin, katselmoitava säännöllisesti ja poistettava, kun sitä ei enää tarvita.

Clarysecin kontrollimalli: tietosuojalupauksesta todentavaan aineistoon

Clarysec käsittelee PII:n käyttöoikeuksien hallinnointia näyttöketjuna. Ketju alkaa tietoaineistoinventaariosta ja roolien määrittelystä, etenee käyttöoikeuksien hyväksyntään ja toteutukseen ja päättyy seurantaan, katselmointiin, käyttöoikeuksien poistamiseen ja auditointivalmiisiin tallenteisiin.

Zenith Controls: The Cross-Compliance Guide sijoittaa aiheen ensisijaisesti kolmen ISO/IEC 27002:2022 -kontrollin ympärille:

Auditoijat hyväksyvät harvoin väitteen “käytämme IAM:ää” todentavaksi aineistoksi. He odottavat näkevänsä, miten IAM-päätökset liittyvät tietosuojavelvoitteisiin, järjestelmäomistajuuteen, tietojen luokitteluun, liiketoimintatarpeeseen, riskien käsittelyyn, käyttöoikeuskatselmointien tiheyteen, lokituksen soveltamisalaan ja toimittajasopimuksiin.

Clarysecin PII Security and Access Control Policy määrittää perustason PIMS-kielellä:

[Both] Järjestelmäomistajan / sovellusomistajan TULEE rajata pääsy PII:hin hyväksyttyihin rooleihin ja valtuutettuihin käyttäjiin, jotka on kirjattu REG02:een tai REG12:een tai jotka ovat niissä jäljitettävissä ennen pääsyn käyttöönottoa.

Kohdasta “4.2 Access control baseline”, politiikan lauseke 4.2.1.

Tunniste “[Both]” tarkoittaa, että kontrollia sovelletaan riippumatta siitä, toimiiko organisaatio PII:n rekisterinpitäjänä vai henkilötietojen käsittelijänä. Erottelulla on merkitystä. Rekisterinpitäjät epäonnistuvat usein käyttötarkoitukseen perustuvien pääsysääntöjen määrittämisessä. Henkilötietojen käsittelijät puolestaan epäonnistuvat usein osoittamaan, että pääsy on rajattu asiakkaan ohjeisiin, hyväksyttyihin tukireitteihin ja sopimuksellisesti valtuutettuun henkilöstöön.

Sama politiikka nostaa vaatimustasoa arkaluonteisen tai vaikutuksiltaan merkittävän PII:n osalta:

[Both] Järjestelmäomistajan / sovellusomistajan TULEE katselmoida vaikutuksiltaan merkittävää tai arkaluonteista PII:tä käsittelevien järjestelmien käyttöoikeudet vähintään neljännesvuosittain ja kirjata katselmoinnin tulos REG12:een.

Kohdasta “4.2 Access control baseline”, politiikan lauseke 4.2.3.

Tässä kohtaa PIMS:stä tulee auditoitavissa oleva järjestelmä. Käyttöoikeuskatselmointi ei ole vain esihenkilön sähköposti. Se on REG12:ssa oleva kirjaus, joka liittyy järjestelmään, tietoluokkaan, rooliin, omistajaan, katselmoinnin tulokseen ja korjaavaan toimenpiteeseen.

Politiikkaperusta: vähimmän oikeuden periaate, liiketoimintatarve ja oletusarvoinen esto

Tehokas hallinnointi alkaa sovellettavista säännöistä. Ennen kuin Anya pystyi näyttämään auditoijalle käyttöoikeuskatselmointilokin, hänen oli osoitettava, että käyttöoikeuskatselmointien vaatimus oli virallisesti vahvistettu.

Clarysecin pk-yrityksille suunnattu Access Control Policy - SME määrittää periaatteen:

Tämä politiikka toteuttaa vähimmän oikeuden periaatteen ja edellyttää, että pääsy rajataan vähimmäistasolle, joka tarvitaan työtehtävien suorittamiseen.

Kohdasta “Purpose”, politiikan lauseke 1.3.

Pk-yrityksille suunnattu Data Protection and Privacy Policy - SME liittää pääsyn liiketoimintatarpeeseen:

Käyttäjien pääsy henkilötietoihin on rajattava rooleihin, joilla on dokumentoitu liiketoimintatarve.

Kohdasta “Governance Requirements”, politiikan lauseke 5.3.2.

Suuremmissa organisaatioissa yritystason Data Protection and Privacy Policy ilmaisee kontrolliodotuksen järjestelmävaatimuksena:

Kaikkien järjestelmien tulee toteuttaa vähimmän oikeuden periaatteen mukainen pääsy oletusarvoisesti.

Kohdasta “Policy Implementation Requirements”, politiikan lauseke 6.3.1.

Erottelu on tärkeä. Pienempi yritys voi tarvita kevyen mutta nimenomaisen liiketoimintatarpeen kirjauksen. Suurempi organisaatio tarvitsee järjestelmätason toteutusta, säännöllistä katselmointia, tehtävien eriyttämistä, etuoikeutetun pääsyn hallinnointia ja todentavan aineiston säilyttämistä sisäistä tarkastusta, asiakasvarmennusta, viranomaistiedusteluja ja tietoturvaloukkausten tutkintaa varten.

PII:hin kohdistuvan pääsyn elinkaari: hyväksyntä, käyttö, katselmointi ja peruminen

Yleisin PII:hin kohdistuvan pääsyn epäonnistuminen ei liity alkuperäiseen hyväksyntään. Se liittyy käyttöoikeuden pysyvyyteen.

Zenith Blueprint selittää Controls in Action -vaiheen vaiheessa 22 ISO/IEC 27002:2022 -standardin kontrollin 5.18, Access Rights, näin:

Kontrolli 5.18 varmistaa, että käyttöoikeuksia ei ainoastaan myönnetä asianmukaisesti, vaan niitä myös katselmoidaan, mukautetaan ja perutaan hallitusti ja jäljitettävästi.

Se kuvaa tämän jälkeen tuttuja skenaarioita: uusi työntekijä saa käyttöoikeudet, vaihtaa roolia ja säilyttää vanhat oikeutensa; entinen ylläpitäjä lähtee, mutta token pysyy aktiivisena; sopimuskumppanin käyttäjätili vanhenee paperilla mutta ei IAM:ssä. Nämä ovat juuri niitä heikkouksia, joista tulee GDPR:n mukaisia tietoturvapoikkeamia, kun PII on mukana.

Clarysecin pk-yrityksille suunnattu User Account and Privilege Management Policy - SME määrittää perustason rytmin:

Kaikkien käyttäjätilien ja käyttöoikeuksien katselmointi on tehtävä kuuden kuukauden välein.

Kohdasta “Policy Implementation Requirements”, politiikan lauseke 6.4.1.

Yritysympäristöissä User Account and Privilege Management Policy tiukentaa toimintarytmiä:

IT Securityn on toteutettava kaikkien käyttäjätilien ja niihin liittyvien käyttöoikeuksien neljännesvuosittaiset katselmoinnit yhteistyössä osastojen esihenkilöiden kanssa.

Kohdasta “Policy Implementation Requirements”, politiikan lauseke 6.5.1.

Käytännöllisen PII:hin kohdistuvan pääsyn elinkaaren tulee sisältää seuraavat vaiheet:

1. Luokittele järjestelmä ja PII-luokat.
2. Määritä hyväksytyt roolit ja dokumentoitu liiketoimintatarve.
3. Kytke roolit käsittelyn tarkoituksiin.
4. Hyväksy pääsy ennen käyttöönottoa.
5. Toteuta vähimmän oikeuden periaate, tehtävien eriyttäminen ja vahva tunnistautuminen.
6. Kirjaa todennus-, pääsy-, vienti-, konfiguraatio- ja etuoikeutetut toimet lokiin.
7. Katselmoi pääsy riskiperusteisella rytmillä.
8. Poista pääsy roolimuutoksen, työsuhteen päättämisen, projektin päättymisen, sopimuksen päättymisen tai asiakkaan ohjeen perusteella.
9. Säilytä todentava aineisto PIMS-rekisterissä ja auditointijäljessä.

Tämä ei ole byrokratiaa. Näin organisaatio osoittaa, että PII:hin kohdistuvaa pääsyä hallitaan sisäänrakennetusti, oletusarvoisesti ja todentavan aineiston perusteella.

Käytännön esimerkki: neljännesvuosittainen PII:n käyttöoikeuskatselmointi

Anyan auditointi onnistui, kun hän siirsi keskustelun politiikkalauseista todentavaan aineistoon.

Ensin hän viittasi PII Security and Access Control Policy -politiikan lausekkeeseen 4.2.3, joka edellytti vaikutuksiltaan merkittävään tai arkaluonteiseen PII:hin kohdistuvan pääsyn neljännesvuosittaista katselmointia ja katselmoinnin tuloksen kirjaamista REG12:een.

Sen jälkeen hän kävi auditoijan kanssa läpi edellisen vuosineljänneksen:

• IT tuotti luettelon kaikista käyttäjistä, ryhmistä, etuoikeutetuista rooleista, palvelutileistä, toimittajatileistä, break-glass-rooleista ja tukioikeuksista tuotantotietokantaan, joka sisälsi potilastietoja.
• Luettelo lähetettiin sovellusomistajalle eli asiakaspalvelusta vastaavalle johtajalle, joka omisti tukitiimin operatiivisen tarpeen.
• Sovellusomistaja kävi luettelon rivi riviltä läpi nykyisen roolin, asiakastuen vastuun ja käsittelyn tarkoituksen perusteella.
• Kaksi tukihenkilöä, jotka olivat siirtyneet toisiin tiimeihin, merkittiin käyttöoikeuksien perumista varten.
• IT-palvelunhallintajärjestelmään luotiin tiketti, joka linkitettiin käyttöoikeuskatselmointiin, jolle määritettiin palvelutasosopimus ja joka suljettiin käyttöoikeuksien perumisen jälkeen.
• REG12 päivitettiin katselmointikirjauksella, hyväksyjällä, poikkeuksilla, korjaustoimenpiteen tiketillä, sulkemista koskevalla todentavalla aineistolla ja seuraavalla katselmointipäivällä.

Tuloksena oli suljettu näyttöketju. Anya ei vain sanonut, että Medtelligence käyttää vähimmän oikeuden periaatetta. Hän näytti politiikkavaatimuksen, vastuullisen omistajan, käyttöoikeusluettelon, katselmointipäätöksen, korjaavan toimenpiteen ja toteutetun käyttöoikeuksien perumisen.

Tämä on pääsynhallinnan ja käyttöoikeuksien hallinnoinnin ero.

Toimittajien ja henkilötietojen käsittelijöiden pääsy: PIMS-auditointien sokea piste

Monet luvattoman pääsyn riskit tulevat tuen, ulkoistuksen, integraatiokumppanien, hallinnoitujen palveluntarjoajien ja alikäsittelijöiden kautta. Henkilötietojen käsittelijällä voi olla etäkäyttö asiakkaan tuotantodataan. Pilvipalveluntarjoaja voi tarjota tukipääsyn reittejä. Alikäsittelijä voi ylläpitää hakuindeksiä, joka sisältää asiakastunnisteita. Hallinnoitu tietoturvapalveluntarjoaja voi päästä lokeihin, jotka sisältävät henkilötietoja.

GDPR:n mukaan rekisterinpitäjien on käytettävä henkilötietojen käsittelijöitä, jotka antavat riittävät takeet. ISO/IEC 27701:2025:n mukaan henkilötietojen käsittelijöiden ja alikäsittelijöiden hallinnointi on operationalisoitava dokumentoitujen ohjeiden, sopimuskontrollien, varmentamisen ja seurannan kautta. ISO/IEC 27002:2022 tukee tätä toimittajasuhteiden kontrolleilla, mukaan lukien 5.19 Information security in supplier relationships, 5.20 Addressing information security within supplier agreements ja 5.21 Managing information security in the ICT supply chain.

Zenith Blueprint tiivistää Controls in Action -vaiheen vaiheessa 23 toimittajasopimusten todentavan aineiston alueita muun muassa seuraavasti:

✓ Pääsynhallinnan vastuut, kuten kuka voi käyttää dataanne, miten tunnistetietoja hallitaan ja millainen seuranta on käytössä;

Siihen sisältyvät myös luottamuksellisuusvelvoitteet, tekniset ja organisatoriset toimenpiteet, poikkeamien ilmoitusmääräajat, auditointioikeus, alihankkijakontrollit ja sopimuksen päättymiseen liittyvä käyttäjätilien deaktivointi.

Clarysecin Processor, Subprocessor and Third-Party Privacy Management Policy muuntaa tämän rekisterinpitäjäpuolen PIMS-näytöksi:

[Controller] Tietosuojavastaavan / PIMS-päällikön TULEE ennen hyväksyntää varmistaa, että REG08:n henkilötietojen käsittelijän sopimuskontrollikentät kattavat käsittelyn soveltamisalan, keston, tarkoituksen, PII-luokat, rekisteröityjen luokat, luottamuksellisuuden, turvallisuuden, alikäsittelijän valtuutuksen, avustamisen, auditoinnin tai varmentamisen, palautuksen, poistamisen ja päättämisen.

Kohdasta “4.3 Contract and documented instruction controls”, politiikan lauseke 4.3.2.

Toimittajien pääsyä hallitaan suoraan myös Clarysecin pk-yritysten ja yritystason toimittajapolitiikoissa. Pk-yrityksille suunnattu Third-Party and Supplier Security Policy - SME toteaa:

Toimittajille on myönnettävä pääsy vain niihin vähimmäisjärjestelmiin ja tietoihin, joita heidän tehtävänsä suorittaminen edellyttää.

Kohdasta “Policy Implementation Requirements”, politiikan lauseke 6.2.1.

Yritystason Third party and supplier security policy lisää RBAC:n, katselmoinnin ja vähimmän oikeuden periaatteen:

Toimittajan henkilöstöön on sovellettava roolipohjaista käyttöoikeuksien hallintaa (RBAC), säännöllisiä käyttöoikeuskatselmointeja ja vähimmän oikeuden periaatteen toteuttamista.

Kohdasta “Policy Implementation Requirements”, politiikan lauseke 6.3.1.

Jos toimittajan pääsy voi ulottua PII:hin, se kuuluu PIMS:iin. Sen tulee näkyä sopimuskontrolleissa, käyttöoikeushyväksynnöissä, IAM-ryhmissä, lokituksen soveltamisalassa, katselmointitallenteissa, offboarding-tallenteissa, poikkeamien toimintapelikirjoissa ja auditointinäytössä.

PII:n pääsy pilvessä: jaettu vastuu ei ole jaettua osoitusvelvollisuutta

PII:n käyttöoikeuksien hallinnointi pilvessä on alue, jolla organisaatiot usein yliarvioivat palveluntarjoajan roolin ja aliarvioivat oman vastuunsa. Pilvipalveluntarjoaja voi suojata infrastruktuurin, mutta asiakas hallinnoi edelleen identiteettejä, rooleja, tenantin konfiguraatiota, tukipääsyä, lokeja, salausasetuksia, vientioikeuksia ja valmiutta reagoida tietoturvapoikkeamiin.

Zenith Blueprint toteaa tämän suoraan Controls in Action -vaiheen vaiheessa 23 pilvipalveluohjeistuksessaan:

Pilvipalveluntarjoajat suojaavat infrastruktuurin, mutta te olette edelleen osoitusvelvollisia datastanne, konfiguraatioistanne, pääsypolitiikoistanne ja valmiudestanne reagoida tietoturvapoikkeamiin.

Se myös varoittaa:

Pilvessä näkyvyys on osittaista, ellei sitä rakenneta tarkoituksellisesti. Lokitus on määritettävä, salaus on toteutettava, identiteettiroolit on määriteltävä ja toimintaa on seurattava natiivien työkalujen tai kolmannen osapuolen integraatioiden kautta. Tämä ei ole infrastruktuuritehtävä, vaan ISMS-vaatimus.

Clarysecin Cloud Usage Policy muuttaa tämän yritystason pääsyvaatimukseksi:

Kaikkien pilvipalvelujen on toteutettava identiteettipohjainen pääsynhallinta, joka on linjassa vähimmän oikeuden periaatteen kanssa.

Kohdasta “Policy Implementation Requirements”, politiikan lauseke 6.2.1.

Pilviympäristöissä henkilötietojen käsittelijöinä toimiville organisaatioille Clarysecin Cloud PII Processor Policy määrittää tarkemman PIMS-katselmointivelvoitteen:

[Processor] Tietoturvavastaavan TULEE katselmoida etuoikeutettu pilvipääsy, tukipääsy, asiakkaan PII:hin kohdistuva pääsy ja lokituksen kattavuus REG12:ssa vähintään neljännesvuosittain.

Kohdasta “4.2 Cloud Configuration, Tenant Isolation, Access and Logging”, politiikan lauseke 4.2.4.

Tämä lauseke on erityisen olennainen SaaS-yrityksille, pilvipalvelussa ylläpidetyille alustoille, hallinnoiduille datapalveluille ja B2B-henkilötietojen käsittelijöille.

PII:n pilvipääsyn hallinnointi ei ole valmis, ellei pilvinatiiveja lokeja, IAM-politiikkoja, palvelutilejä, etuoikeutettuja rooleja, asiakastuen työkaluja, API-avaimia ja datan vientitoimintoja katselmoida yhdessä.

Lokitus ja seuranta: PII:n hallinnoinnin muisti

PIMS-pääsynhallintaohjelma ilman lokeja on lupaus ilman muistia.

PII Security and Access Control Policy edellyttää lokituksen soveltamisalan määrittämistä ennen tuotantokäyttöä tai olennaista muutosta:

[Both] Järjestelmäomistajan / sovellusomistajan TULEE määrittää REG12:ssa PII:n lokituksen soveltamisala todennustapahtumille, pääsytapahtumille, etuoikeutetuille toimille, PII:n vientitoiminnalle ja olennaisille konfiguraatiomuutoksille ennen tuotantokäyttöä tai olennaista muutosta.

Kohdasta “4.6 Logging and monitoring”, politiikan lauseke 4.6.1.

Pk-yrityksille suunnattu Logging and Monitoring Policy - SME tekee käyttölokien sisällöstä nimenomaisen:

Käyttölokit: tiedostojen käyttö, erityisesti arkaluonteisten tietojen tai henkilötietojen osalta, käyttöoikeusmuutokset ja jaettujen resurssien käyttö

Kohdasta “Governance Requirements”, politiikan lauseke 5.4.3.

Yritystason Logging and Monitoring Policy keskittyy auditoinnin käytettävyyteen:

ISMS Audit Trail Register -rekisteriin on kirjattava lokitietojen saatavuus auditointeja, tutkintoja ja sääntelytarkasteluja varten.

Kohdasta “Governance Requirements”, politiikan lauseke 5.4.

Tämä on kriittistä, koska tietosuojan todentavan aineiston on usein vastattava tapahtumapohjaisiin kysymyksiin:

• Kuka käytti PII:tä?
• Oliko pääsy valtuutettu?
• Liittyikö pääsy tukitikettiin, oikeudelliseen pyyntöön, operatiiviseen tehtävään tai asiakkaan ohjeeseen?
• Vietiinkö, kopioitiinko, muutettiinko tai poistettiinko dataa?
• Käytettiinkö etuoikeutettua pääsyä?
• Muutettiinko käyttöoikeuksia ennen pääsyä tai sen jälkeen?
• Viittasiko toiminta tietoturvapoikkeamaan tai henkilötietojen tietoturvaloukkaukseen?

Lokit eivät ole vain SOC:ia varten. Ne ovat PIMS-näyttöä, asiakasvarmennuksen todentavaa aineistoa, henkilötietojen käsittelijöiden varmentamisen todentavaa aineistoa ja tietoturvapoikkeamiin reagoinnin todentavaa aineistoa.

Vastaavuuskartoitus: yksi pääsymalli, monta näkökulmaa

PII:n käyttöoikeuskatselmointien heikkous ei ole koskaan vain yksi havainto. Siitä voi tulla GDPR:n osoitusvelvollisuusongelma, ISO/IEC 27701:2025 -standardin mukainen PIMS-heikkous, ISO/IEC 27001:2022 -poikkeama, NIS2:n hallinnointivirhe, DORA:n häiriönsietokykyyn liittyvä huoli, NIST CSF 2.0:n hallinnointiaukko tai COBIT 2019:n prosessikypsyyden ongelma.

Yksityiskohtaisempi kontrollien vastaavuustaulukko osoittaa, miten yksi PII:n käyttöoikeuksien hallinnointiprosessi tukee useita vaatimuksia:

Zenith Controls -oppaan arvo on siinä, että tiimit voivat kytkeä nämä näkökulmat samaan kontrollinäyttöön sen sijaan, että ylläpidettäisiin erillisiä vaatimustenmukaisuussiiloja.

Toteuta 45 minuutin PII:n pääsyn todentavan aineiston sprintti

Hyvä tapa testata valmiutta on valita yksi vaikutuksiltaan merkittävä järjestelmä, kuten asiakastukialusta, HR-järjestelmä, maksuportaali, potilasportaali, data lake tai SaaS-tuotantotietokanta, ja toteuttaa kohdennettu näyttösprintti.

Vaihe 1: Määritä PII:n käsittelyn toimintaympäristö

Kirjaa REG12:een:

• Järjestelmän nimi ja omistaja
• PII-luokat
• Rekisteröityjen luokat
• Rekisterinpitäjän tai henkilötietojen käsittelijän rooli
• Käsittelyn tarkoitus
• Vaikutuksiltaan merkittävän tai arkaluonteisen PII:n indikaattori
• Pilvi-, toimittaja- ja alikäsittelijäriippuvuudet

Jos järjestelmään liittyy henkilötietojen käsittelijä, tarkista REG08:n sopimuskontrollikentät Processor, Subprocessor and Third-Party Privacy Management Policy -politiikan mukaisesti. Hyväksynnän tulee kattaa käsittelyn soveltamisala, kesto, tarkoitus, PII-luokat, rekisteröityjen luokat, luottamuksellisuus, turvallisuus, alikäsittelijän valtuutus, avustaminen, auditointi tai varmentaminen, palautus, poistaminen ja päättäminen.

Vaihe 2: Vie käyttöoikeusluettelo

Vie kaikki käyttäjät, ryhmät, etuoikeutetut roolit, palvelutilit, tukiroolit, break-glass-tilit, API-avaimet ja toimittajatilit. Vertaa jokaista käyttöoikeutta hyväksyttyihin rooleihin.

Vaihe 3: Vahvista vähimmän oikeuden periaate ja käyttötarkoituksenmukaisuus

Käytä PII Security and Access Control Policy -politiikan perustasoa: pääsy on rajattava hyväksyttyihin rooleihin ja valtuutettuihin käyttäjiin, jotka on kirjattu REG02:een tai REG12:een tai jotka ovat niissä jäljitettävissä ennen käyttöönottoa. Jos käyttäjää ei voida jäljittää rooliin, tarkoitukseen ja hyväksyntään, havainto ei ole “dokumentaatio puuttuu”. Havainto on “PII:hin kohdistuvaa pääsyä ei voida osoittaa valtuutetuksi”.

Vaihe 4: Tarkista lokituksen soveltamisala

Varmista, että lokit kattavat todennuksen, pääsytapahtumat, etuoikeutetut toimet, PII:n vientitoiminnan ja olennaiset konfiguraatiomuutokset. Varmista sen jälkeen, missä lokit säilytetään, kuinka kauan niitä säilytetään, kuka voi käyttää niitä ja onko ne kirjattu ISMS Audit Trail Register -rekisteriin auditointeja, tutkintoja ja sääntelytarkasteluja varten.

Vaihe 5: Sulje ketju

Kirjaa jokaisesta poikkeuksesta riskinomistaja, välitön rajaamistoimi, pysyvä korjaava toimenpide, tavoitepäivä, tarvittava todentava aineisto, jäännösriskipäätös ja se, tarvitaanko tietoturvaloukkauksen arviointi.

Tämä yksittäinen harjoitus paljastaa yleensä PII:n käyttöoikeuksien hallinnoinnin todellisen kypsyyden. Vahvat organisaatiot pystyvät vastaamaan nopeasti. Heikot organisaatiot huomaavat, että tietosuojapolitiikka, IAM-konfiguraatio, henkilötietojen käsittelijöiden sopimukset, pilvilokitus ja auditointinäyttö ovat irrallaan toisistaan.

Yleiset auditointihavainnot PII:n käyttöoikeuksien hallinnoinnissa

Useimmat havainnot ovat ennakoitavissa. Ne syntyvät, kun tietosuoja, tietoturva, lakiasiat, IT ja toimittajat hallitsevat kukin omaa osuuttaan kokonaisuudesta, mutta kukaan ei omista koko PII:hin kohdistuvan pääsyn elinkaarta.

Yleisiä havaintoja ovat:

• PII:tä käsitteleviä järjestelmiä ei ole listattu kattavasti PIMS-inventaarioon.
• Pääsyroolit on määritetty teknisesti, mutta niitä ei ole kytketty käsittelyn tarkoituksiin.
• Arkaluonteinen PII on käytettävissä laajojen operatiivisten ryhmien kautta.
• Neljännesvuosittaiset katselmoinnit kattavat työntekijät mutta eivät palvelutilejä, API-avaimia tai toimittajien käyttäjiä.
• Pilvituen pääsy on mahdollinen, mutta sitä ei katselmoida PII:hin kohdistuvana pääsynä.
• Lokit ovat olemassa, mutta ne eivät osoita PII:n käyttöä, vientiä tai etuoikeutettua toimintaa.
• Henkilötietojen käsittelijöiden sopimukset sisältävät yleisiä luottamuksellisuuslausekkeita mutta eivät erityisiä pääsynhallintaa, auditointia, alikäsittelijöitä, palautusta, poistamista tai päättämistä koskevia kontrolleja.
• Entiset työntekijät tai sopimuskumppanit säilyttävät pääsyn jaettujen ryhmien tai hallitsemattomien tokenien kautta.
• Tietovaraston pääsy on laajempi kuin lähdesovelluksen pääsy.
• Break-glass-tilit ovat olemassa ilman käytön jälkeistä katselmointia.
• Asiakastuen impersonointi ei kirjaudu lokiin tikettikontekstin kanssa.
• Soveltuvuuslausunto sisältää pääsynhallintakontrollit, mutta todentava aineisto ei osoita PII-kohtaista toteutusta.

Jokainen näistä havainnoista voi soveltamisalasta riippuen muuttua GDPR:n osoitusvelvollisuusongelmaksi, asiakasvarmennusasiaksi, NIS2:n tai DORA:n hallinnointiheikkoudeksi tai ISO/IEC 27001:2022 -poikkeamaksi.

Miltä hyvä näyttää

Kypsä toimintamalli ei perustu sankarillisiin neljännesvuosittaisiin siivouksiin. Se sisällyttää PII:n käyttöoikeuksien hallinnoinnin normaaliin toimintaan.

Ensinnäkin organisaatiolla on tietoisuus datasta. Se tietää, missä PII:tä on, miksi sitä käsitellään, mikä PIMS-rooli soveltuu sekä mitkä järjestelmät, toimittajat, pilvipalvelut, lokit, varmuuskopiot ja viennit kuuluvat soveltamisalaan.

Toiseksi pääsy on roolipohjaista ja käyttötarkoituksen mukaista. Oikeudet määritetään hyväksyttyjen roolien, dokumentoidun liiketoimintatarpeen, käsittelyn tarkoituksen ja vähimmän oikeuden periaatteen perusteella.

Kolmanneksi kontrollit toteutetaan teknisesti. IAM, RBAC, etuoikeutetun pääsyn hallinta, MFA, ehdollinen pääsy, tenanttikontrollit, salaus ja ympäristöjen eriyttäminen toteuttavat politiikan odotukset.

Neljänneksi seuranta on tarkoituksellista. Organisaatio pystyy rekonstruoimaan PII:hin vaikuttavat todennukset, pääsyt, viennit, etuoikeutetut toimet, tukipääsyn ja konfiguraatiomuutokset.

Viidenneksi katselmoinnit ovat riskiperusteisia ja dokumentoituja. Vaikutuksiltaan merkittävää PII:tä katselmoidaan vähintään neljännesvuosittain. Toimittajien ja pilvituen pääsy sisällytetään katselmointiin. Poikkeukset seurataan sulkemiseen asti.

Kuudenneksi todentava aineisto on uudelleenkäytettävää. Samat tallenteet tukevat GDPR:n osoitusvelvollisuutta, ISO/IEC 27701:2025 -standardin mukaista PIMS-toimintaa, ISO/IEC 27001:2022 -standardin mukaista riskien käsittelyä, NIS2:n riskienhallintatoimenpiteitä, DORA:n ICT-riskien hallinnointia, NIST CSF 2.0 GOVERN -tuloksia ja COBIT 2019 -johtamisen varmentamista.

Tämä on asetuksena olevan pääsynhallinnan ja järjestelmänä toimivan käyttöoikeuksien hallinnoinnin ero.

Muuta PII:hin kohdistuva pääsy auditointivalmiiksi todentavaksi aineistoksi

Jos seuraava auditointi, asiakaskatselmointi tai viranomaistiedustelu alkaisi huomenna kysymyksellä “näyttäkää, kuka voi käyttää PII:tä”, tuottaisiko tiiminne todentavan aineiston minuuteissa vai alkaisiko se täsmäyttää laskentataulukoita?

Clarysec voi auttaa kuromaan tämän aukon umpeen.

Aloita PII Security and Access Control Policy -politiikasta, sovita henkilötietojen käsittelijän ja pilven velvoitteet yhteen Processor, Subprocessor and Third-Party Privacy Management Policy -politiikan ja Cloud PII Processor Policy -politiikan avulla ja käytä sitten Zenith Blueprint: An Auditor’s 30-Step Roadmap -opasta kontrollien toteuttamiseen oikeassa järjestyksessä. Käytä lopuksi Zenith Controls: The Cross-Compliance Guide -opasta PII:hin kohdistuvan pääsyn todentavan aineiston kartoittamiseen ISO/IEC 27701:2025:n, GDPR:n, ISO/IEC 27001:2022:n, ISO/IEC 27002:2022:n, NIS2:n, DORA:n, NIST CSF 2.0:n ja COBIT 2019:n vaatimuksiin.

Nopein käytännön seuraava askel on yksinkertainen: valitse yksi vaikutuksiltaan merkittävä PII-järjestelmä, täytä REG12, vie käyttöoikeusluettelo, tarkista lokituksen soveltamisala ja toteuta neljännesvuosittaista katselmointia vastaava läpikäynti. Yhdessä istunnossa tiedätte, onko PII:n käyttöoikeuksien hallinnointinne valmis auditointiin vai ainoastaan politiikkatasolla valmis.