ISO 27701 -hallintakeinojen soveltuvuus GDPR-roolien perusteella

On tiistaiaamu kello 08.40, ja Maria, nopeasti kasvavan terveysteknologia-alan SaaS-yrityksen tietoturvajohtaja, katsoo neljää asiakkaalta saapunutta sähköpostia. Ne näyttävät lähes samanlaisilta, mutta tarkoittavat hyvin eri asioita.

Yksi suuryritysasiakas pyytää todentavaa aineistoa siitä, että yritys voi toimia GDPR:n mukaisena henkilötietojen käsittelijänä Article 28:n nojalla. Toinen kysyy, onko alusta myös rekisterinpitäjä telemetrian ja tuoteanalytiikan osalta. Kolmas pyytää ajantasaista alikäsittelijäluetteloa ja näyttöä siitä, että tietojenkäsittelysopimuksen ehdot on ketjutettu eteenpäin. Neljäs, DORA-toimittajakatselmuksiin valmistautuva fintech-asiakas, kysyy, onko samat tietosuojan hallintakeinot kartoitettu toiminnan häiriönsietokykyyn, poikkeamien ilmoittamiseen ja ICT-kolmansien osapuolten riskiin.

Marian yritys ei ole huolimaton. Sillä on ISO/IEC 27001:2022 -standardin mukaisesti rakennettu ISMS, tietosuojapolitiikat, käsittelyrekisteri, MFA, salaus, käyttöoikeuskatselmoinnit ja sisäänrakennetun tietosuojan koulutus. Pyyntö kuitenkin nostaa esiin vaikeamman kysymyksen, jota auditoijat ja asiakkaat tosiasiassa testaavat:

Voiko yritys osoittaa, että oikeat ISO 27701 PIMS -hallintakeinot soveltuvat oikeaan GDPR-rooliin ja oikeaan käsittelytoimeen, oikealla omistajalla, todentavalla aineistolla ja perustelulla?

Tässä moni tietosuojaohjelma epäonnistuu. ISO 27701:tä käsitellään tarkistuslistana, vaikka sertifiointielimet, asiakasauditoijat ja tietosuojavastaavat odottavat perusteltua päätöstä hallintakeinojen soveltuvuudesta. Vastaus ei ole ”meillä on tietosuojakontrollit”. Vastaus on: ”tässä käsittelytoimessa olemme rekisterinpitäjä, henkilötietojen käsittelijä, yhteisrekisterinpitäjä tai alikäsittelijä, ja tässä on perustelu sille, miksi nämä hallintakeinot soveltuvat tai eivät sovellu”.

Miksi ISO 27701 -hallintakeinojen soveltuvuus on puuttuva PIMS-kerros

GDPR-roolit perustuvat päätösvaltaan. Rekisterinpitäjä määrittää käsittelyn tarkoitukset ja keinot. Henkilötietojen käsittelijä toimii rekisterinpitäjän lukuun. Yhteisrekisterinpitäjät määrittävät tarkoitukset ja keinot yhdessä. Alikäsittelijä on henkilötietojen käsittelijän käyttämä taho, joka käsittelee henkilötietoja edelleen myöhemmässä ketjun vaiheessa.

Todellisissa SaaS-ympäristöissä nämä roolit pysyvät harvoin selkeinä yritystasolla. Marian organisaatio on henkilötietojen käsittelijä isännöidessään asiakkaiden hyvinvointidataa, rekisterinpitäjä työntekijöiden palkanlaskennan ja markkinointikontaktien osalta, mahdollinen rekisterinpitäjä tuotetelemetrian osalta käsittelyn tarkoituksesta ja sopimusehdoista riippuen sekä yhteisrekisterinpitäjä yhteisbrändätyssä kampanjassa. Jos suurempi hallinnoitu palveluntarjoaja jälleenmyy hänen alustansa, yrityksestä voi tulla myös alikäsittelijä kyseisessä ketjussa.

ISO 27701 -hallintakeinojen soveltuvuuden määrittäminen on menettely, joka estää roolien typistymisen epämääräisiksi väitteiksi. Se kysyy:

• Mikä käsittelytoimi kuuluu soveltamisalaan?
• Mikä GDPR-rooli organisaatiolla on kyseisessä toimessa?
• Mitkä PIMS-hallintakeinot soveltuvat kyseisen roolin vuoksi?
• Mitkä hallintakeinot rajataan pois ja miksi?
• Mikä todentava aineisto osoittaa toteutuksen?
• Mikä laki-, sopimus-, riski- tai soveltamisalavaatimus ohjasi päätöstä?

Clarysecin Privacy Information Management System Policy määrittää rooliluokituksen lähtökohdaksi:

”[Molemmat roolit] Prosessin omistajan / liiketoimintavastaavan TULEE luokitella organisaation PIMS-rooli jokaiselle henkilötietojen käsittelytoimelle REG02:ssa ennen käsittelytoimen aloittamista.”

Kohdasta ”PIMS-roolin määrittäminen”, politiikan lauseke 4.2.1.

Sama politiikka kytkee roolipäätöksen hallintakeinojen soveltuvuuteen:

”[Molemmat roolit] Tietosuojavastaavan / PIMS-päällikön TULEE ylläpitää REG03:a siten, että se sisältää mukaan otetut hallintakeinot, poissuljetut hallintakeinot, toteutuksen tilan ja perustelut vuosittain sekä 30 päivän kuluessa jokaisesta tietosuojariskien käsittelyn muutoksesta.”

Kohdasta ”Tietosuojapolitiikka, tavoitteet ja hallintakeinojen soveltuvuus”, politiikan lauseke 4.3.3.

REG02 vastaa siihen, mitä käsittelyä on olemassa ja mikä rooli siihen soveltuu. REG03 vastaa siihen, mitkä hallintakeinot soveltuvat, mikä on rajattu pois, mitä todentavaa aineistoa on olemassa ja miksi päätös on puolustettavissa.

Rakenna PIMS ISO/IEC 27001:2022 SoA -logiikan varaan

Roolipohjainen PIMS toimii parhaiten, kun se rakennetaan kypsän ISMS:n varaan. ISO/IEC 27001:2022 edellyttää jo soveltamisalan määrittämistä, sidosryhmäanalyysiä, riskien arviointia, riskien käsittelyä, hallintakeinojen valintaa ja soveltuvuuslausuntoa. ISO 27701 laajentaa tämän hallintajärjestelmälogiikan tietosuojaan.

Clarysecin Information Security Policy toteaa:

”ISMS:n tulee sisältää määritellyt soveltamisalan rajat, riskienarviointimenetelmä, mitattavat tavoitteet sekä dokumentoidut hallintakeinot, jotka on perusteltu soveltuvuuslausunnossa (SoA).”

Kohdasta ”Politiikan toteutusvaatimukset”, politiikan lauseke 6.1.2.

Risk Management Policy vahvistaa saman näyttökurinalaisuuden:

”Soveltuvuuslausunnon (SoA) tulee kuvata kaikki riskien käsittelyä koskevat päätökset, ja se tulee päivittää aina, kun hallintakeinojen kattavuutta muutetaan.”

Kohdasta ”Hallinnointivaatimukset”, politiikan lauseke 5.4.

Tietosuojassa REG03:sta tulee PIMS-hallintakeinojen soveltuvuusrekisteri, joka peilaa SoA-kurinalaisuutta. Se ei korvaa ISO/IEC 27001:2022 SoA:ta. Se täydentää sitä lisäämällä GDPR-roolikohtaiset tietosuojapäätökset rekisterinpitäjille, henkilötietojen käsittelijöille, yhteisrekisterinpitäjille ja alikäsittelijöille.

PII Processing Inventory and Lawful Basis Policy tekee tästä yhteydestä nimenomaisen:

”[Molemmat roolit] Tietosuojavastaavan / PIMS-päällikön TULEE yhdistää soveltuvat REG02-käsittelytoimet REG03:n hallintakeinojen soveltuvuustietoihin ennen auditointivalmiuden katselmointia.”

Kohdasta ”Käsittelytoimien luettelon ylläpito”, politiikan lauseke 7.1.5.

Auditoijan tulisi pystyä valitsemaan yksi käsittelytoimi REG02:sta, tunnistamaan GDPR-rooli, jäljittämään soveltuvat hallintakeinot REG03:ssa, katselmoimaan asiaankuuluvat ISO/IEC 27001:2022 -hallintakeinot SoA:ssa ja tarkastamaan todentava aineisto, kuten DPA, oikeusperustetieto, käyttöoikeuskatselmointi, alikäsittelijän hyväksyntä, poikkeamamenettely tai poistoloki.

Roolipohjainen hallintakeinojen soveltuvuusmalli

Nopein tapa tehdä ISO 27701:stä käyttökelpoinen on päättää soveltuvuudesta käsittelytoimikohtaisesti, ei yritystasolla.

SaaS-palveluntarjoajan tulisi välttää toteamusta ”olemme henkilötietojen käsittelijä”. Sen tulisi sanoa: ”asiakkaan tuotantoalustalle lataamien käyttäjätietojen osalta olemme henkilötietojen käsittelijä. Palkanlaskennan osalta olemme rekisterinpitäjä. Tuoteanalytiikan osalta roolimme riippuu siitä, käytetäänkö analytiikkaa vain sopimuspalvelujen tuottamiseen vai omiin riippumattomiin tarkoituksiimme. Asiakasdataa tukevan tikettitoimittajan osalta toimittaja on alikäsittelijä.”

Tämä roolipohjainen näkymä on linjassa GDPR:n osoitusvelvollisuuden kanssa. Rekisterinpitäjien tulee osoittaa periaatteiden noudattaminen, kuten lainmukaisuus, kohtuullisuus, läpinäkyvyys, käyttötarkoitussidonnaisuus, minimointi, täsmällisyys, säilytyksen rajoittaminen, eheys, luottamuksellisuus ja osoitusvelvollisuus. Henkilötietojen käsittelijöiden tulee käsitellä tietoja vain dokumentoitujen ohjeiden perusteella, toteuttaa asianmukainen tietoturva, avustaa rekisterinpitäjiä, hallita alikäsittelijöitä ja tukea palautusta tai poistamista.

Vaarallinen oikotie on olettaa, että jokainen tietosuojan hallintakeino soveltuu kaikkialla. Henkilötietojen käsittelijä ei yleensä määritä oikeusperustetta asiakkaan loppukäyttäjien tiedoille, mutta sen on osoitettava käsittelevänsä tietoja vain asiakkaan ohjeiden mukaisesti. Rekisterinpitäjä ei välttämättä tarvitse asiakkaan alikäsittelijähyväksyntää sisäiseen HR-käsittelyyn, mutta sen tulee tehdä palkanlaskentapalveluntarjoajasta henkilötietojen käsittelijää koskeva huolellisuusarviointi.

Luokittele ennen sopimuksen hyväksyntää tai käsittelyn aloittamista

Yleisin PIMS-valmiuden havainto on myöhäinen rooliluokitus. Sopimus on allekirjoitettu, alusta on tuotannossa, toimittajat on integroitu eikä kukaan ole päättänyt, onko organisaatio rekisterinpitäjä, henkilötietojen käsittelijä, yhteisrekisterinpitäjä vai alikäsittelijä kussakin tietovirrassa.

Viive aiheuttaa ketjussa myöhempiä ongelmia. Käytetään väärää DPA:ta. Alikäsittelijöitä ei ilmoiteta. DPIA:t jäävät tekemättä. Säilytys on epäselvä. Asiakastuki ei tiedä, mitä tietoturvaloukkauksen ilmoitusmääräaikaa sovelletaan. Hankinta käsittelee tietosuojaan vaikuttavaa toimittajaa ”pelkkänä työkaluna”.

Processor, Subprocessor and Third-Party Privacy Management Policy käsittelee ajoitusta suoraan:

”[Molemmat roolit] Tietosuojavastaavan / PIMS-päällikön TULEE luokitella jokainen kolmannen osapuolen tietosuojasuhde rekisterinpitäjäksi, yhteisrekisterinpitäjäksi, henkilötietojen käsittelijäksi, alikäsittelijäksi tai muuksi kolmannen osapuolen suhteeksi REG08:ssa ennen sopimuksen hyväksyntää tai ennen henkilötietojen käsittelyn aloittamista sen mukaan, kumpi tapahtuu ensin.”

Kohdasta ”Suhteen tunnistaminen ja luokittelu”, politiikan lauseke 4.1.3.

REG08:n toimittaja- ja kolmannen osapuolen suhdeluokitus syöttää REG03:a. Jos toimittaja on henkilötietojen käsittelijä, soveltuviin hallintakeinoihin kuuluvat DPA-ehdot, luottamuksellisuus, turvatoimet, auditointioikeudet, rekisteröidyn oikeuksia koskevissa pyynnöissä avustaminen, tietoturvaloukkauksen tuki, palautus tai poistaminen sekä alikäsittelijähallintakeinot. Jos toimittaja on itsenäinen rekisterinpitäjä, painopiste siirtyy oikeusperusteeseen, luovutusten hallinnointiin, siirtoihin, läpinäkyvyyteen ja osoitusvelvollisuuteen.

Pienemmille organisaatioille Third-Party and Supplier Security Policy - SME edellyttää, että tiimit huomioivat:

”Sääntelyaltistus (esim. GDPR:n mukainen henkilötietojen käsittelijän rooli, DORA:n mukaiset finanssialan velvoitteet)”

Kohdasta ”Hallinnointivaatimukset”, politiikan lauseke 5.2.4.

Se asettaa myös selkeän vaatimuksen ennen tietojen jakamista:

”Tietojenkäsittelysopimuksen ehdot tai vastaavat sopimusehdot tulee sopia ennen kuin henkilötietoja tai arkaluonteisia tietoja jaetaan.”

Kohdasta ”Politiikan toteutusvaatimukset”, politiikan lauseke 6.3.2.

Tässä on ero toimittajasopimusten olemassaolon ja auditoitavan tietosuojaroolien hallinnoinnin välillä.

Kartoita hallintakeinot rooliin, riskiin, lakiin ja sopimukseen

Zenith Blueprint, riskienhallintavaihe, vaihe 13: riskien käsittelyn suunnittelu ja soveltuvuuslausunto, selittää soveltuvuuden ydinlogiikan. Hallintakeinot ovat soveltuvia riskien käsittelyä koskevien päätösten, lakisääteisten tai sopimusperusteisten vaatimusten, soveltamisalan merkityksellisyyden ja organisaation toimintaympäristön vuoksi. Poissulut edellyttävät selkeitä perusteluja, ja soveltuvien hallintakeinojen tulisi olla jäljitettävissä riskiin tai vaatimukseen.

Vaiheessa 13 Zenith Blueprint toteaa:

”Varmista yhdenmukaisuus riskirekisterisi kanssa: jokaisen riskienkäsittelysuunnitelmaan kirjaamasi lieventävän hallintakeinon tulisi vastata liite A:n hallintakeinoa, joka on merkitty ’soveltuvaksi’. Vastaavasti, jos hallintakeino on merkitty soveltuvaksi, sen taustalla tulisi olla joko riski tai vaatimus.”

ISO 27701:n osalta sama menetelmä soveltuu tietosuojan hallintakeinoihin. Hallintakeino voi olla soveltuva, koska:

1. GDPR edellyttää sitä organisaation roolin perusteella.
2. Asiakassopimus, DPA tai yhteisrekisterinpitäjien järjestely edellyttää sitä.
3. Tietosuojariskien käsittely edellyttää sitä.
4. Käsittely sisältää erityisiä henkilötietoryhmiä, lasten tietoja, laajamittaista seurantaa, arkaluonteista profilointia tai vaikutuksiltaan merkittäviä henkilötietoja.
5. Toimittaja-, pilvi-, alikäsittelijä- tai rajat ylittävien siirtojen riski tekee hallintakeinosta tarpeellisen.
6. Hallintakeino tukee sertifioinnin soveltamisalaa, auditointivalmiutta tai hyväksyttyjä tietosuojatavoitteita.

Legal and Regulatory Compliance Policy vahvistaa tätä kartoituskurinalaisuutta:

”Kun sääntely koskee useita alueita (esim. GDPR koskee säilytystä, tietoturvaa ja tietosuojaa), tämä tulee kartoittaa selkeästi vaatimustenmukaisuusrekisterissä ja koulutusmateriaaleissa.”

Kohdasta ”Hallinnointivaatimukset”, politiikan lauseke 5.2.2.

Sama Legal and Regulatory Compliance Policy on nimenomainen yrityksen ISMS-integraation osalta:

”Kaikki lakisääteiset ja sääntelyyn perustuvat velvoitteet tulee kartoittaa tietoturvallisuuden hallintajärjestelmän (ISMS) sisällä tiettyihin politiikkoihin, hallintakeinoihin ja omistajiin.”

Kohdasta ”Politiikan toteutusvaatimukset”, politiikan lauseke 6.2.1.

REG03 ei siksi saa koskaan olla irrallinen tietosuojataulukko. Sen tulee yhdistää käsittelytoimet, lakisääteiset velvoitteet, riskien käsittelyt, sopimukset, ISO/IEC 27001:2022 -hallintakeinot ja todentavan aineiston omistajat.

Käytännön esimerkki: SaaS-tuen työnkulku

Tarkastellaan tukityönkulkua Marian SaaS-alustalla. Asiakkaat lähettävät tikettejä, jotka voivat sisältää nimiä, sähköpostiosoitteita, käyttäjätilitunnisteita, kuvakaappauksia ja ajoittain arkaluonteista liiketoimintakontekstia. Tukiagentit käyttävät rajattuja tietueita. Pilvipohjainen tikettipalveluntarjoaja isännöi dataa ja käyttää omia alikäsittelijöitään.

Vaihe 1: Kirjaa toiminta REG02:een

Tietosuojavastaava kirjaa:

• Toiminnon nimi: asiakastuen tikettien käsittely
• Henkilötietoryhmät: käyttäjätunnisteet, yhteystiedot, kuvakaappaukset, käyttäjätilien metatiedot
• Rekisteröidyt: asiakkaiden ylläpitäjät ja loppukäyttäjät
• Tarkoitus: tuki ja palvelun vianmääritys
• Rooli: henkilötietojen käsittelijä asiakkaan toimittamien loppukäyttäjien henkilötietojen osalta, rekisterinpitäjä suorien liiketoimintakontaktien hallinnan osalta, jos tietoja käytetään käyttäjätiliviestintään
• Säilytys: määritetty tuen ja auditoinnin säilytysaika
• Vastaanottajat: sisäinen tukihenkilöstö, tikettitoimittaja, hyväksytyt alikäsittelijät
• Tietoturvaluokitus: luottamuksellinen, henkilötiedot

Data Protection and Privacy Policy - SME tukee tätä perustasoa:

”Tietosuojakoordinaattorin tulee ylläpitää rekisteriä kaikista henkilötietojen käsittelytoimista, mukaan lukien tietoryhmät, tarkoitus, oikeusperuste ja säilytysajat”

Kohdasta ”Hallinnointivaatimukset”, politiikan lauseke 5.2.1.

Vaihe 2: Luokittele toimittaja REG08:ssa

Jos Marian yritys on henkilötietojen käsittelijä asiakasdatan osalta, tikettipalveluntarjoaja on tyypillisesti kyseisen asiakasdatan alikäsittelijä. REG08:ssa tulee kirjata suhteen tyyppi, sopimustilanne, tietoryhmät, tietojen sijainnit, myöhemmän ketjun alikäsittelijät ja varmentamisen todentava aineisto.

Vaihe 3: Kirjaa REG03-soveltuvuus

Yritystason Data Protection and Privacy Policy lisää korkean riskin herätteen:

”Uhkamallinnus ja tietosuojaa koskevat vaikutustenarvioinnit (DPIA) ovat pakollisia korkean riskin käsittelyjärjestelmille.”

Kohdasta ”Politiikan toteutusvaatimukset”, politiikan lauseke 6.3.4.

Data Protection and Privacy Policy - SME sisällyttää suunnitteluodotuksen:

”Sisäänrakennettu ja oletusarvoinen tietosuoja tulee toteuttaa kaikissa uusissa järjestelmissä ja palveluissa”

Kohdasta ”Hallinnointivaatimukset”, politiikan lauseke 5.3.1.

Vaihe 4: Linjaa ISO/IEC 27001:2022 -hallintakeinojen kanssa

Jos tukialusta kuuluu ISMS:n soveltamisalaan, SoA:n tulisi sisältää tukevat ISO/IEC 27002:2022 -hallintakeinot, kuten toimittajasuhteet, toimittajasopimukset, ICT-toimitusketjun hallinta, pääsynhallinta, identiteetinhallinta, tiedonsiirto, pilvipalvelut, poikkeamien hallinta, lokitus ja seuranta, muutoksenhallinta, lakisääteisten vaatimusten noudattaminen ja yksityisyyden suoja.

Zenith Blueprint, riskienhallintavaihe, vaihe 14: riskienkäsittelypolitiikat ja sääntelyn vastaavuusviittaukset, suosittelee GDPR:n, NIS2:n ja DORA:n ristiviittaamista politiikkoihin ja hallintakeinoihin erityisesti henkilötietojen suojan, tietoturvapoikkeamiin reagoinnin, pääsynhallinnan, liiketoiminnan jatkuvuuden ja kolmannen osapuolen ICT-riskin osalta.

Tuloksena on uudelleenkäytettävä todentava aineisto, ei erillisiä taulukoita GDPR:ää, DORA:a, NIS2:ta ja sertifiointia varten.

Mitä Zenith Controls lisää PIMS-soveltuvuuteen

Zenith Controls on Clarysecin eri vaatimustenmukaisuuskehysten välinen opas ISO/IEC 27001:2022- ja ISO/IEC 27002:2022 -hallintakeinojen, auditointimenetelmien ja muiden viitekehysten välisten suhteiden ymmärtämiseen. Se ei ole erillinen hallintakeinojoukko. Tämän aiheen kannalta keskeiset ISO/IEC 27002:2022 -hallintakeinot ovat:

• 5.34 Yksityisyyden suoja ja henkilötietojen suojaus
• 5.19 Tietoturva toimittajasuhteissa
• 5.20 Tietoturvan huomioiminen toimittajasopimuksissa
• 5.21 Tietoturvan hallinta ICT-toimitusketjussa
• 5.22 Toimittajapalvelujen seuranta, katselmointi ja muutoksenhallinta

5.34:n osalta Zenith Controls luokittelee hallintakeinon ennaltaehkäiseväksi, kytkee sen luottamuksellisuuteen, eheyteen ja saatavuuteen, linjaa sen Identify- ja Protect-toimintoihin sekä yhdistää sen tietojen suojaamisen, lakiasioiden ja vaatimustenmukaisuuden kyvykkyyksiin.

Sen GDPR-kartoitus toteaa:

”5.34:n toteutus on suoraa todentavaa aineistoa organisaation kyvystä täyttää GDPR:n osoitusvelvollisuusvaatimukset.”

Lähde: Zenith Controls, yksityisyyden suoja ja henkilötietojen suojaus, GDPR-ristikartoitus.

Lause on merkityksellinen, koska se muuttaa 5.34:n yleisestä tietosuojalausumasta auditointinäytöksi. Sitä tulisi tukea henkilötietojen luetteloilla, luokittelulla, pääsynhallinnalla, maskauksella, suojatulla siirrolla, pilvipalvelujen hallinnoinnilla, DPIA:illa, tietosuojaselosteilla, DSAR-työnkuluilla ja tietoturvaloukkausten käsittelyllä.

Zenith Controls yhdistää yksityisyyden ja henkilötietojen suojan myös asiaan liittyviin standardeihin, kuten ISO/IEC 27018 julkisen pilven henkilötietojen käsittelyä varten, ISO/IEC 29100 tietosuojaperiaatteita varten ja ISO/IEC 29151 henkilötietojen suojauskäytäntöjä varten. Toimittajien tietosuojahallinnointia tukevat ISO/IEC 27036 -standardiperhe toimittajasuhteiden ja ICT-toimitusketjun tietoturvan osalta sekä ISO/IEC 27017 pilviturvallisuuden jaettujen vastuiden osalta.

Toimittaja- ja alikäsittelijänäyttö on kohta, jossa roolit kohtaavat

Rekisterinpitäjän ja henkilötietojen käsittelijän velvoitteet kohtaavat usein toimittajarajapinnassa.

Jos Marian yritys on rekisterinpitäjä, GDPR odottaa sen käyttävän henkilötietojen käsittelijöitä, jotka antavat riittävät takeet. Jos se on henkilötietojen käsittelijä, asiakkaat odottavat sen hallitsevan alikäsittelijöitä, ketjuttavan velvoitteet ja antavan varmentavaa aineistoa. Jos se on alikäsittelijä, se perii velvoitteet ketjun kautta.

Tämä tekee ISO/IEC 27002:2022 -hallintakeinoista 5.19 ja 5.20 keskeisiä ISO 27701 -hallintakeinojen soveltuvuudelle.

5.19:n osalta Zenith Controls korostaa toimittajasuhteiden tietoturvaa hallinnoinnin, ekosysteemin ja suojausalueiden läpi. Se kytkeytyy suoraan 5.20:n toimittajasopimuksiin, 5.21:n ICT-toimitusketjun tietoturvaan, 5.14:n tietojen siirtoon, 5.36:n tietoturvapolitiikkojen, sääntöjen ja standardien noudattamiseen sekä 5.10:n tieto- ja muun siihen liittyvän omaisuuden hyväksyttävään käyttöön.

5.20:n osalta Zenith Controls korostaa sopimuksellista formalisoimista. Toimittajasopimusten tulisi määrittää luottamuksellisuus, tietoturvaloukkauksista ilmoittaminen, auditointioikeudet, alihankkijoiden hyväksyntä, suojattu siirto, tietojen palautus tai tuhoaminen, vaatimustenmukaisuusvelvoitteet ja seuranta.

Zenith Blueprint, Controls in Action -vaihe, vaihe 23: organisatoriset hallintakeinot, antaa käytännön ohjeen alikäsittelijöille:

”Tunnista jokaisen kriittisen toimittajan osalta, käyttävätkö he alihankkijoita (alikäsittelijöitä), joilla voi olla pääsy tietoihisi tai järjestelmiisi. Dokumentoi, miten tietoturvavaatimuksesi ketjutetaan näille osapuolille joko toimittajasi sopimusehtojen tai omien suorien lausekkeidesi kautta.”

Auditoijat eivät pysähdy kysymykseen ”onko teillä DPA?”. He kysyvät, ovatko toimittajat henkilötietojen käsittelijöitä, alikäsittelijöitä, itsenäisiä rekisterinpitäjiä vai yhteisrekisterinpitäjiä, onko alikäsittelijähyväksynnät dokumentoitu, onko velvoitteet ketjutettu, ovatko tietoturvaloukkausten määräajat selkeitä, toteutuuko seuranta ja voidaanko poistosta tai palautuksesta saada todentava aineisto.

Yhdistä vaatimustenmukaisuuskehykset ilman päällekkäisiä hallintakeinojärjestelmiä

ISO 27701 -hallintakeinojen soveltuvuudesta tulee arvokkaampaa, kun se tukee GDPR-, NIS2-, DORA-, NIST CSF 2.0- ja COBIT 2019 -varmennuskeskusteluja samasta näyttöpohjasta.

GDPR ohjaa roolipohjaisia tietosuojavelvoitteita: rekisterinpitäjän osoitusvelvollisuutta, henkilötietojen käsittelijän velvoitteita, oikeusperustetta, rekisteröidyn oikeuksia, turvallisuutta, tietoturvaloukkausten hallinnointia ja sopimuksia.

NIS2 lisää kyberturvallisuuden riskienhallinnan, poikkeamien käsittelyn, liiketoiminnan jatkuvuuden, toimitusketjun tietoturvan, turvallisen kehittämisen, haavoittuvuuksien käsittelyn, pääsynhallinnan, kryptografian, MFA:n ja koulutuksen keskeisille ja tärkeille toimijoille.

DORA soveltuu 17. tammikuuta 2025 alkaen soveltamisalaan kuuluviin finanssialan toimijoihin ja edellyttää ICT-riskien hallintaa, poikkeamien ilmoittamista, häiriönsietokyvyn testausta ja ICT-kolmansien osapuolten riskienhallintaa. Finanssialan toimijoita palvelevilta SaaS- ja ICT-palveluntarjoajilta pyydetään usein tietosuojaa, tietoturvaa, häiriönsietokykyä, auditointioikeuksia ja irtautumista koskeva todentava aineisto yhtenä varmentamispakettina.

NIST CSF 2.0 tarjoaa hallinnointikerroksen GOVERN-toiminnon kautta, mukaan lukien lakisääteiset, sääntelyyn perustuvat, sopimusperusteiset ja tietosuojavelvoitteet, roolit, riskinottohalukkuuden, politiikkavalvonnan ja toimitusketjun hallinnoinnin.

COBIT 2019 lisää hallinnointi- ja johtamiskäytäntöjä. Tietosuojan osalta Zenith Controls kartoittaa 5.34:n COBIT-käytäntöihin DSS06.02, DSS06.08 ja APO13.01. Toimittajien osalta 5.19 ja 5.20 tukevat toimittajariskejä ja toimittajasopimuksia koskevia käytäntöjä.

Strateginen huomio on yksinkertainen. REG03:n tulisi olla enemmän kuin ISO 27701 -artefakti. Sen tulisi olla uudelleenkäytettävä hallintakeinojen soveltuvuuskartta asiakasauditointeihin, sääntelyarviointeihin ja hallitustason varmentamiseen.

Miten auditoijat testaavat ISO 27701 -hallintakeinojen soveltuvuutta

Eri auditoijat aloittavat eri näkökulmista, mutta päätyvät yleensä samaan näyttöketjuun.

ISO-hallintajärjestelmäauditoija aloittaa soveltamisalasta, sidosryhmistä, velvoitteista, riskien arvioinnista, SoA-linjauksesta, sisäisestä auditoinnista, johdon katselmoinnista ja jatkuvasta parantamisesta. Hän testaa, ovatko REG02, REG03 ja ISO/IEC 27001:2022 SoA keskenään yhdenmukaisia.

GDPR-painotteinen auditoija tai tietosuojavastaavan katselmoija testaa roolilogiikkaa. Hän ottaa näytteitä käsittelytoimista ja tarkastaa oikeusperusteen, tietosuojaselosteet, DPA:t, alikäsittelijät, DPIA:t, DSAR-käsittelyn, säilytyksen ja tietoturvaloukkauksia koskevan päätöksenteon.

NIST-suuntautunut arvioija etsii hallinnointituloksia, riskiluokittelua, tietoaineistorekistereitä, pääsynhallintaa, lepotilassa olevien ja siirrettävien tietojen suojaa, seurantaa, tietoturvapoikkeamiin reagointia, toimittajariskejä ja parantamissuunnitelmia.

COBIT 2019- tai ISACA-auditoija tarkastelee hallinnointivastuita, prosessikyvykkyyttä, hallintakeinon suunnittelun toimivuutta ja hallintakeinon toiminnan tehokkuutta. Hän testaa, onko tietosuojan hallintakeinot sisällytetty hankintaan, muutoksenhallintaan, poikkeamien hallintaan ja toimittajaseurantaan.

5.34:n osalta Zenith Controls kuvaa auditoijien katselmoivan tietosuojapolitiikkoja, tietoaineistorekistereitä, DPIA:ita, koulutuslokeja, teknisiä suojatoimia, DSAR-näytteitä, henkilötietopoikkeamia ja sisäänrakennetun tietosuojan todentavaa aineistoa. 5.19:n ja 5.20:n osalta auditoijat pyytävät toimittajaluetteloita, riskiluokituksia, huolellisuusarvioinnin tallenteita, sopimuksia, tietoturvaloukkausehtoja, auditointioikeuksia, alihankkijoiden hyväksyntää, irtautumista koskevaa todentavaa aineistoa ja näyttöä siitä, että toimittajaraportit katselmoidaan.

Ero on ratkaiseva. Auditointivalmius ei ole ”meillä on lauseke”. Auditointivalmius on: ”käytimme lauseketta, seurasimme sitä, katselmoimme todentavan aineiston ja toimimme riskin muuttuessa”.

Yleiset virheet rekisterinpitäjän ja henkilötietojen käsittelijän soveltuvuudessa

Clarysec näkee toistuvasti viisi vältettävissä olevaa puutetta.

Ensinnäkin organisaatiot luokittelevat koko yrityksen yhteen GDPR-rooliin. Tämä ei toimi SaaS-, fintech-, HR-teknologia-, terveysteknologia-, hallinnoitujen palvelujen tai pilvipalveluntarjoajien ympäristöissä, joissa tietovirrat ovat sekoittuneita.

Toiseksi ne käsittelevät ISO 27701 -hallintakeinoja yleisesti soveltuvina ilman rooliperustelua. Tämä luo paisuneita näyttövaatimuksia ja heikkoja poissulkuja.

Kolmanneksi ne sulkevat hallintakeinoja pois dokumentoimatta syytä. ISO/IEC 27001:2022 SoA -logiikassa ja PIMS-soveltuvuuslogiikassa poissulkujen tulee olla tietoisia, perusteltuja ja soveltamisalan, roolin, riskin tai oikeudellisen analyysin tukemia.

Neljänneksi ne unohtavat alikäsittelijät. Henkilötietojen käsittelijän varmentamistarina on yhtä vahva kuin sen myöhempi ketju. Alikäsittelijärekisterit, hyväksyntämekanismit, ketjutettavat lausekkeet ja poistamista koskeva todentava aineisto ovat välttämättömiä.

Viidenneksi ne eivät yhdistä tietosuojan hallintakeinoja tietoturvaoperaatioihin. Sisäänrakennettu tietosuoja ei ole pelkkä DPIA-malli. Sen tulisi vaikuttaa pääsynhallintaan, lokitukseen, turvalliseen kehittämiseen, pilvikonfiguraatioon, toimittajien huolellisuusarviointiin, säilytyksen automatisointiin ja tietoturvapoikkeamiin reagointiin.

Clarysec-valmis tarkistuslista REG03-hallintakeinojen soveltuvuuteen

Käytä tätä tarkistuslistaa ennen ISO 27701 -valmiuskatselmointeja, GDPR-asiakasvarmennusta tai DORA-lähtöisiä toimittaja-arviointeja:

• Luo tai päivitä REG02 jokaiselle henkilötietoja sisältävälle käsittelytoimelle.
• Luokittele PIMS-rooli jokaiselle toimelle ennen käsittelyn aloittamista.
• Luokittele jokainen kolmannen osapuolen suhde REG08:ssa ennen sopimuksen hyväksyntää tai henkilötietojen käsittelyä.
• Tunnista rooliin perustuvat velvoitteet: rekisterinpitäjä, henkilötietojen käsittelijä, yhteisrekisterinpitäjä tai alikäsittelijä.
• Kirjaa soveltuvat PIMS-hallintakeinot REG03:een omistajan, toteutuksen tilan ja todentavan aineiston kanssa.
• Kirjaa poissuljetut hallintakeinot selkeällä perustelulla.
• Yhdistä REG03-päätökset riskeihin, lakisääteisiin velvoitteisiin, sopimuksiin tai soveltamisalan perusteluihin.
• Linjaa REG03 ISO/IEC 27001:2022 SoA:n kanssa silloin, kun tietoturvan hallintakeinot tukevat tietosuojaa.
• Kartoita tietosuojan hallintakeinot ISO/IEC 27002:2022 5.34:ään, kun henkilötietojen suojausta edellytetään.
• Kartoita toimittaja- ja alikäsittelijävaatimukset kohtiin 5.19, 5.20, 5.21 ja 5.22.
• Lisää tarvittaessa vaatimustenmukaisuuskehysten väliset viittaukset GDPR:ään, NIS2:een, DORA:an, NIST CSF 2.0:aan ja COBIT 2019:ään.
• Testaa näyttöketju sisäisen auditoinnin otoksella ennen auditointivalmiuden katselmointia.
• Hanki ylimmän johdon hyväksyntä, kun PIMS:n soveltamisala tai hallintakeinojen soveltuvuus muuttuu.

Privacy Information Management System Policy sulkee tämän hallinnointisilmukan:

”[Molemmat roolit] Ylimmän johdon TULEE hyväksyä muutokset PIMS:n soveltamisalaan ja hallintakeinojen soveltuvuuteen REG01:ssä ja REG03:ssa ennen sertifioinnin soveltamisalan muutosten toimittamista.”

Kohdasta ”PIMS-hallinnointi”, politiikan lauseke 6.1.3.

Tämä on sellaista hallinnointinäyttöä, johon auditoijat luottavat.

Muuta GDPR-roolipäätökset puolustettavaksi todentavaksi aineistoksi

ISO 27701 -hallintakeinojen soveltuvuus on kohta, jossa GDPR-rooliteoria muuttuu operatiiviseksi todellisuudeksi. Rekisterinpitäjä tarvitsee todentavaa aineistoa oikeusperusteesta, läpinäkyvyydestä, säilytyksestä, DPIA:ista, oikeuksien käsittelystä ja henkilötietojen käsittelijöiden valvonnasta. Henkilötietojen käsittelijä tarvitsee todentavaa aineistoa dokumentoiduista ohjeista, luottamuksellisuudesta, tietoturvasta, avustamisesta, alikäsittelijöistä, tietoturvaloukkauksen tuesta ja poistamisesta. Yhteisrekisterinpitäjä tarvitsee läpinäkyvän vastuunjakojärjestelyn. Alikäsittelijä tarvitsee ketjutettavat velvoitteet ja varmentamisen tuen.

Clarysec auttaa organisaatioita rakentamaan tämän näyttökerroksen seuraavien avulla:

• REG02-käsittelytoimien luettelo ja oikeusperusterakenne.
• REG03:n PIMS-hallintakeinojen soveltuvuustiedot.
• REG08:n kolmansien osapuolten tietosuojasuhteiden luokittelu.
• ISO/IEC 27001:2022 SoA -linjaus.
• Politiikkalausekkeet, jotka osoittavat omistajat, ajoituksen ja hyväksyntävaatimukset.
• Vaatimustenmukaisuuskehysten välinen kartoitus Zenith Controlsin kautta.
• Toteutuksen vaiheistus Zenith Blueprintin kautta.

Jos organisaatiosi valmistautuu ISO 27701 PIMS -valmiuteen, GDPR-asiakasvarmennukseen, DORA-toimittajakatselmuksiin tai NIS2:n mukaiseen tietoturvan hallinnointiin, aloita yhdestä korkean riskin käsittelytoimesta. Luokittele rooli. Kartoita soveltuvat hallintakeinot. Linkitä todentava aineisto. Toista, kunnes tietosuojaohjelmasi ei ole vain paperilla vaatimustenmukainen, vaan selitettävissä auditoinnissa.

Lataa Clarysecin PIMS-politiikkapaketti, tutustu Zenith Blueprintiin tai varaa Clarysecin valmiusarviointi, jotta rekisterinpitäjä-, henkilötietojen käsittelijä-, yhteisrekisterinpitäjä- ja alikäsittelijäpäätökset muuttuvat sertifiointivalmiiksi tietosuojan näyttörekisteriksi.