Yhteisrekisterinpitäjien hallinnointi: GDPR Article 26 -auditointiopas

Puhelu tuli tiistaiaamuna. CareConnectin tietoturvajohtajalle, nopeasti kasvavan MedTech SaaS -palveluntarjoajan vastuuhenkilölle, se oli hetki, jolloin tilanne muuttui olennaisesti.

Langan toisessa päässä oli MetroHealthin, yhtiön tärkeimmän sairaalakumppanin, vaatimustenmukaisuuspäällikkö. Heidän yhdessä hallinnoitua etäseuranta-alustaansa käyttävä potilas oli tehnyt rekisteröidyn tarkastuspyynnön kuukautta aiemmin. Kumpikaan organisaatio ei ollut vastannut siihen kokonaisuudessaan. Molemmat olettivat toisen olevan vastuussa.

Sitten lakiasiat välitti toisen viestin. CareConnectin juniorikehittäjä oli vahingossa paljastanut ei-kriittisen API-päätepisteen, joka sisälsi rajallisia potilastunnisteita. Tapaus näytti rajattavissa olevalta, eikä GDPR:n 72 tunnin ilmoitusikkuna ollut vielä sulkeutunut. Sama kysymys pysäytti kuitenkin molemmat tiimit.

Kuka ilmoittaa valvontaviranomaiselle? Kuka viestii potilaille? Kuka omistaa tietosuojaselosteen? Kuka validoi rekisteröidyn pyynnön? Kuka dokumentoi päätöksen?

Kaupallinen sopimus oli yksityiskohtainen palveluhyvitysten, laskutuksen, vastuunrajoitusten ja tuotteen tiekartan virstanpylväiden osalta. Se oli lähes vaiti GDPR Article 26:n mukaisen yhteisrekisterinpitäjien hallinnoinnin operatiivisesta todellisuudesta.

Tässä moni kumppanuus epäonnistuu. Ongelma ei ole se, etteivät tietosuoja-, lakiasia-, tietoturva- ja hankintatiimit olisi koskaan kuulleet ilmaisua ”yhteisrekisterinpitäjäjärjestely”. Ongelma on se, ettei kukaan pysty ennen käsittelyn aloittamista osoittamaan, kuka vastaa läpinäkyvyydestä, oikeusperusteesta, rekisteröidyn oikeuksista, tietoturvaloukkausten eskaloinnista, toimittajille ketjutettavista velvoitteista, siirroista, säilytyksestä, näytöstä ja viranomaisviestinnästä.

GDPR määrittää velvoitteen. ISO/IEC 27701:2025 antaa tietosuojatiimeille hallintajärjestelmärakenteen. Clarysecin PIMS-politiikat, Zenith Blueprint: auditoijan 30 vaiheen tiekartta ja Zenith Controls: poikkivaatimustenmukaisuuden opas muuttavat Article 26:n auditointivalmiiksi operatiiviseksi näytöksi.

Miksi yhteisrekisterinpitäjien hallinnointi epäonnistuu ennen kuin kukaan huomaa

Yhteisrekisterinpitäjäsuhde syntyy, kun kaksi tai useampi osapuoli määrittää yhdessä henkilötietojen käsittelyn tarkoitukset ja keinot. Laukaisija ei ole sopimuksen sanamuoto. Ratkaisevaa on päätösvalta.

CareConnectin ja MetroHealthin esimerkissä CareConnect tarjoaa alustan, analytiikan, teknisen arkkitehtuurin, käyttöliittymän ja tietovirrat. MetroHealth tarjoaa potilassuhteen, kliinisen kontekstin, palvelumallin ja potilastiedot. Molemmat vaikuttavat siihen, miksi henkilötietoja käsitellään ja miten käsittely toimii. Tämä eroaa olennaisesti tilanteesta, jossa toimittaja vain isännöi tietokantaa tai lähettää viestejä dokumentoitujen ohjeiden perusteella.

Sama malli näkyy taloudellisen hyvinvoinnin kampanjoissa, sulautetuissa vakuutuskumppanuuksissa, verkkomarkkinapaikoissa, petostentorjunnan konsortioissa, yhdistetyissä terveysalustoissa, kanta-asiakasohjelmissa, identiteetin varmentamisen ekosysteemeissä ja analytiikkayhteistöissä. Pankki, vakuutusyhtiö ja SaaS-alusta voivat yhdessä päättää kohdesegmenteistä, profilointisäännöistä, konversiomittareista ja markkinointikanavista. Henkilötietojen käsittelijän tietojenkäsittelysopimus ei ratkaise ongelmaa, jos osapuolet ovat tosiasiallisesti yhteisrekisterinpitäjiä.

Käytännön epäonnistumiset ovat ennakoitavia:

1. Tietosuojaseloste sanoo vain hieman enemmän kuin ”voimme jakaa tietoja kumppaneiden kanssa”.
2. Käsittelytoimien luettelo tunnistaa osapuolet mutta ei velvoitteiden jakautumista.
3. Rekisteröidyn oikeuksia koskevassa työnkulussa ei ole reittiä pyyntöjen välittämiselle, validoinnille tai niihin vastaamiselle.
4. Poikkeamasuunnitelmassa todetaan ”ilmoita lakiasioille”, mutta ei määritetä, mikä yhteisrekisterinpitäjä johtaa ulkoista viestintää.
5. Sopimusta käsitellään kaupallisena asiakirjana, ei osoitusvelvollisuuden näyttönä.
6. Päättämisehdot eivät kata tietojen palauttamista, poistamista, anonymisointia, käyttöoikeuksien poistamista tai näytön säilyttämistä.

GDPR Article 5 tekee näistä epäonnistumisista auditoinnin kannalta herkkiä, koska rekisterinpitäjien ei ainoastaan tule noudattaa lainmukaisuuden, kohtuullisuuden, läpinäkyvyyden, käyttötarkoitussidonnaisuuden, minimoinnin, täsmällisyyden, säilytyksen rajoittamisen, eheyden, luottamuksellisuuden ja osoitusvelvollisuuden kaltaisia periaatteita. Niiden on myös pystyttävä osoittamaan vaatimustenmukaisuus. Article 6 lisää oikeusperustetta koskevan vaatimuksen. Article 3 voi tuoda EU:n ulkopuoliset SaaS-, fintech-, health-tech- ja analytiikkapalveluntarjoajat soveltamisalaan, kun ne tarjoavat palveluja EU:ssa oleville henkilöille tai seuraavat heidän käyttäytymistään.

Tietoturvajohtajille ja vaatimustenmukaisuuspäälliköille opetus on suora: yhteisrekisterinpitäjien hallinnointi ei ole ”vain lakiasia”. Se on poikkitoiminnallinen kontrollijärjestelmä, johon kuuluvat tietosuoja, tietoturva, hankinta, tuote, ohjelmistokehitys, tuki, tietoturvapoikkeamiin reagointi, markkinointi ja johdon valvonta.

ISO/IEC 27701:2025 PIMS -periaate: päätä ennen käsittelyn aloittamista

ISO/IEC 27701:2025 -standardin mukainen henkilötietojen hallintajärjestelmä toimii vain, jos tietosuojaroolit määritetään ennen käsittelyn aloittamista. Tämä operatiivinen kurinalaisuus estää Article 26:ta muuttumasta poikkeaman jälkeiseksi jälleenrakennusharjoitukseksi.

Clarysecin Henkilötietojen hallintajärjestelmän politiikan kohdassa 4.2.2 todetaan:

[Yhteisrekisterinpitäjä] Toimittaja-/hankintaomistajan TULEE dokumentoida yhteisrekisterinpitäjien vastuunjako REG08:ssa ennen yhteisen käsittelyn aloittamista.

Ilmaus ”ennen yhteisen käsittelyn aloittamista” on kontrollipiste. Se tarkoittaa ennen kuin alustaintegraatio viedään tuotantoon, ennen kuin jaettu hallintanäkymä otetaan käyttöön, ennen kuin CRM-synkronointi alkaa, ennen kuin kampanjayleisöt aktivoidaan ja ennen kuin rekisteröityjen pyynnöt alkavat saapua.

Tukeva inventaariovelvoite on Henkilötietojen käsittelytoimien luetteloa ja oikeusperustetta koskevan politiikan kohdassa 4.3.5:

[Yhteisrekisterinpitäjä] Toimittaja-/hankintaomistajan TULEE kirjata yhteisrekisterinpitäjien käsittelyn tarkoitus ja vastuunjaon viite REG02:een ja REG08:aan ennen yhteisrekisterinpitäjien käsittelyn aloittamista.

Yhdessä nämä kohdat luovat auditoijien odottaman näyttöketjun:

• REG02 dokumentoi käsittelytoimen, tarkoituksen, tietoluokat, oikeusperusteen, säilytyksen, järjestelmät, vastaanottajat, siirrot ja yhteisrekisterinpitäjäviitteen.
• REG08 dokumentoi yhteisrekisterinpitäjäjärjestelyn ja vastuunjaon.
• REG07 dokumentoi julkisen läpinäkyvyysyhteenvedon.
• REG06 voi dokumentoida oikeuksia koskevan pyynnön vastaanoton, reitityksen, validoinnin, määräajat ja vastausnäytön.
• REG10 dokumentoi poikkeamia ja tietoturvaloukkausten arviointia koskevat päätökset.

Tämä ketju muuttaa Article 26:n oikeudellisesta lausumasta hallintajärjestelmäprosessiksi.

Aloita soveltamisalasta, sidosryhmistä ja RACI-mallista

Zenith Blueprint alkaa soveltamisalasta ja sidosryhmistä, koska yhteisrekisterinpitäjien hallinnointi epäonnistuu, kun asianomaiset osapuolet ja vaatimukset tunnistetaan liian myöhään.

ISMS Foundation & Leadership -vaiheen vaiheessa 2, Sidosryhmien tarpeet ja ISMS:n soveltamisala, Zenith Blueprint suosittelee sidosryhmäanalyysiä, joka kattaa nimenomaiset ja oletetut vaatimukset:

Näin tunnistat tarpeet ja odotukset: Laadi kullekin tunnistetulle sidosryhmälle luettelo siitä, mitä ne
edellyttävät tietoturvallisuuden osalta. Osa vaatimuksista on nimenomaisia (lait, sopimukset,
palvelutasosopimukset), kun taas osa on oletettuja (odotukset tai yleiset hyvät käytännöt). Tämä auttaa:

✓ Tarkista toimintaympäristöösi sovellettavat lakisääteiset ja sääntelyvaatimukset (vaiheen 1
toimintaympäristöanalyysistä). Laadi luettelo tietoturvallisuuteen tai tietosuojaan liittyvistä
erityisistä kohdista tai velvoitteista.
✓ Tarkista sopimukset ja järjestelyt: monissa liiketoimintasopimuksissa on luottamuksellisuus- tai
tietoturvaliitteitä. Poimi niistä vaatimukset.
✓ Toteuta sidosryhmähaastatteluja tai työpajoja: osallista kunkin ryhmän edustajia
(esim. HR-päällikkö työntekijänäkökulmaa varten, myyntipäällikkö asiakasodotuksia varten),
jotta ymmärrät heidän huolensa tai tarpeensa.
✓ Huomioi toimialan standardit tai käytännesäännöt, joiden noudattamista sidosryhmät odottavat.

Auditoitavaa GDPR Article 26 -yhteisrekisterinpitäjäjärjestelyä varten asianomaisia osapuolia koskevan analyysin tulee sisältää asiakkaat, potilaat, käyttäjät, valvontaviranomaiset, muut rekisterinpitäjäosapuolet, henkilötietojen käsittelijät, alikäsittelijät, vakuuttajat, pilvipalveluntarjoajat, sisäiset osastot, viranomaiset ja hallintoelimet.

Vaihe 4, Roolit ja vastuut ISMS:ssä, muuttaa tämän analyysin omistajuudeksi. Zenith Blueprint korostaa RACI-mallin arvoa:

✓ Osoitusvelvollisuus vs. vastuu: hyödyllinen työkalu on RACI-matriisi (Responsible,
Accountable, Consulted, Informed). Tunnista kunkin merkittävän ISMS-prosessin tai kontrollin osalta,
kuka on Responsible (tekee työn), kuka on Accountable (viime kädessä vastuussa, usein
esihenkilö), kuka on Consulted (antaa syötteitä) ja kuka on Informed (pidetään ajan tasalla).

Yhteisrekisterinpitäjille RACI ei käytännössä ole vapaaehtoinen. Ilman sitä lakiasiat olettaa tietosuojan vastaavan pyyntöön, tietosuoja olettaa tuella olevan vastaanottojono, tuki olettaa kumppanin vastaavan, ja lakisääteinen määräaika jatkaa kulumistaan.

Clarysecin yhteisrekisterinpitäjien näyttömalli

Kypsän yhteisrekisterinpitäjäjärjestelyn tulee olla ymmärrettävissä yhdellä sivulla ja todennettavissa kymmenessä minuutissa. Tavoite ei ole haudata tiimejä oikeudelliseen paperityöhön. Tavoite on tehdä vastuut näkyviksi, hyväksytyiksi ja testattaviksi.

Clarysecin tietosuojapolitiikat vahvistavat jokaisen kerroksen.

Tietosuojaseloste- ja läpinäkyvyyspolitiikan kohdassa 4.1.5 todetaan:

[Yhteisrekisterinpitäjä] Tietosuojavastaavan / PIMS-päällikön TULEE kirjata julkinen yhteisrekisterinpitäjien vastuuyhteenveto ja yhteyspiste REG07:ään ennen yhteisrekisterinpitäjien käsittelyn käynnistämistä tai olennaista muuttamista.

Rekisteröidyn oikeuksien hallintapolitiikan kohdassa 6.1.5 todetaan:

[Yhteisrekisterinpitäjä] Tietosuojavastaavan / PIMS-päällikön TULEE dokumentoida oikeuksien käsittelyä koskevat vastuut ja yhteydenottoreitit REG02:een, REG06:een tai REG08:aan ennen yhteisrekisterinpitäjien käsittelyn aloittamista.

Henkilötietopoikkeamien ja tietoturvaloukkausten hallintapolitiikan kohta 4.2.5 lisää:

[Yhteisrekisterinpitäjä] Tietosuojavastaavan / PIMS-päällikön TULEE varmistaa sovittu tietoturvaloukkausvastuu, johtava viestintävastuu ja koordinointijärjestely ennen yhteisrekisterinpitäjän tekemää ulkoista ilmoitusta tai viestintää, ja päätös TULEE kirjata REG08:aan ja REG10:een.

Tässä kohdassa ISO/IEC 27701:2025 ja GDPR muuttuvat operatiivisiksi. Organisaatio ei ainoastaan sano, että vastuut on jaettu. Se osoittaa, missä ne on kirjattu, kuka ne hyväksyi, milloin ne testattiin ja miten niitä käytetään.

Käytännön esimerkki: REG08 etäseuranta-alustalle

Oletetaan, että CareConnect ja MetroHealth käyttävät yhdessä etäseuranta-alustaa. Molemmat päättävät, miksi potilastietoja käsitellään, mitä tietoja kerätään, miten seurannan hälytykset konfiguroidaan, miten analytiikkaa käytetään ja miten potilaat käyttävät palvelua.

Ensiksi REG02:n tulee dokumentoida käsittelytoimi:

• Käsittelyn nimi: Potilaan etäseurantapalvelu
• Rekisterinpitäjärooli: Yhteisrekisterinpitäjä
• Osapuolet: CareConnect ja MetroHealth
• Tarkoitus: potilasseuranta, hoidon koordinointi, palvelun parantaminen, alustan analytiikka
• Henkilötietoluokat: yhteystiedot, käyttäjätilitunnisteet, kliiniset havainnot, laitetapahtumat, tukivuorovaikutukset
• Erityisten henkilötietoryhmien tarkistus: terveystietoja käsitellään ja ne edellyttävät vahvistettuja suojatoimia
• Oikeusperuste: dokumentoitu osapuoli- ja tarkoituskohtaisesti
• Säilytys: määritetty kliinisten, alusta-, oikeudellisten ja operatiivisten vaatimusten perusteella
• Järjestelmät: mobiilisovellus, seuranta-alusta, tukityökalu, analytiikkatietovarasto, identiteetin tarjoaja
• Vastaanottajat: yhteisrekisterinpitäjäosapuolet, hosting-palveluntarjoaja, tukitoimittajat, ilmoituspalveluntarjoajat
• Siirrot: etäkäyttö ja ETA-alueen ulkopuolinen käsittely arvioitu
• REG08-viite: JC-2026-004

Toiseksi REG08:n tulee jakaa vastuut tavalla, jota operatiiviset toimijat voivat noudattaa.

Kolmanneksi REG07:n tulee dokumentoida julkinen yhteenveto. Selosteen tulee selittää yhteisjärjestelyn olennainen sisältö selkeällä kielellä, tunnistaa yhteisrekisterinpitäjät, kuvata kunkin vastuut ja tarjota käyttökelpoinen yhteyspiste. Sen ei tule pakottaa potilaita tai käyttäjiä purkamaan sisäistä operatiivista monimutkaisuutta.

Neljänneksi työnkulku tulee testata ennen käyttöönottoa. Lähetä simuloitu tarkastuspyyntö julkaistuun yhteyspisteeseen. Varmista, että tuki tunnistaa sen rekisteröidyn oikeuksia koskevaksi pyynnöksi, reitittää sen tietosuojalle, tarkistaa REG08:n, pyytää kumppanin syötteen, kirjaa toimet REG06:een ja tuottaa vastauspaketin. Toteuta sen jälkeen tietoturvaloukkausta koskeva pöytäharjoitus skenaariolla, kuten ”API-päätepiste paljastaa potilastunnisteita luvattomille käyttäjille” tai ”poistamista varten estolistalla olevat käyttäjät sisällytetään vahingossa sitouttamiskampanjaan”.

Nämä testit paljastavat todelliset puutteet: omistamattomat postilaatikot, epäselvät kumppanien palvelutasosopimukset, hyväksymätön selosteteksti, puutteelliset oikeusperustetallenteet, puuttuvat erityisten henkilötietoryhmien tarkistukset ja poikkeamien toimintamallit, joissa ulkoisen viestinnän vastuuhenkilöä ei nimetä.

Kartoita Article 26 ISO/IEC 27002:2022 -kontrolleihin Zenith Controlsin avulla

Yhteisrekisterinpitäjäjärjestely ei ole pelkkä oikeudellinen artefakti. Sitä on tuettava teknisillä ja organisatorisilla kontrolleilla. Zenith Controls auttaa tiimejä kartoittamaan ISO/IEC 27001:2022- ja ISO/IEC 27002:2022 -kontrolliodotukset tietosuoja-, toimittaja-, poikkeama-, pilvi- ja hallinnointinäyttöön.

Kolme ISO/IEC 27002:2022 -kontrollia on erityisen merkityksellisiä.

Control 5.2, Information Security Roles and Responsibilities, tukee toimintamallia. Se liittyy ISO/IEC 27001:2022:n kohtaan 5.3, Organizational roles, responsibilities and authorities. Se tukee myös valmiutta poikkeamatilanteisiin, koska epäselvät roolit heikentävät ISO/IEC 27002:2022 Control 5.24, Information Security Incident Management Planning and Preparation -kontrollia. Yhteisrekisterinpitäjien hallinnoinnissa Control 5.2 on kohta, jossa RACI, REG08-omistajat, DSR-käsittelijät, tietoturvaloukkausten vastuuhenkilöt ja eskalointiyhteyshenkilöt muuttuvat auditointinäytöksi.

Control 5.31, Legal, Statutory, Regulatory and Contractual Requirements, on kohta, jossa GDPR Article 26:sta tulee osa ISMS:ää eikä vain lakiasioiden asia. Se tukee GDPR Article 5:n osoitusvelvollisuuden, Article 6:n oikeusperusteen, Article 26:n vastuunjaon, Article 32:n turvallisuuden, Article 33:n valvontaviranomaiselle ilmoittamisen ja Article 34:n rekisteröidyille viestimisen tunnistamista ja hallintaa. Se liittyy myös ISO/IEC 27001:2022:n kohtaan 4.2, asianomaisten osapuolten tarpeiden ja odotusten ymmärtäminen, sekä kohtaan 6.1.3, tietoturvariskien käsittely.

Control 5.34, Privacy and Protection of PII, tuo henkilötietojen suojauksen osaksi tietoturvan toimintamallia. Se on erityisen tärkeä, kun järjestelyssä käytetään pilvianalytiikkaa, jaettuja hallintanäkymiä, data clean room -ympäristöjä, seuranta-alustoja, markkinoinnin automaatiota tai tukityökaluja. Liittyviä suojatoimia voivat olla ISO/IEC 27002:2022 Control 5.23, Information Security for Use of Cloud Services, ja Control 8.11, Data Masking.

Myös tukeva ISO-ekosysteemi on tärkeä. ISO/IEC 27018 auttaa, kun julkiset pilvipalvelut käsittelevät henkilötietoja. ISO/IEC 29100 tarjoaa tietosuojaperiaatteita, kuten läpinäkyvyys, suostumus, oikeutettu tarkoitus, keruun rajoittaminen, tietojen minimointi, käytön rajoittaminen, täsmällisyys, tietoturvasuojatoimet ja osoitusvelvollisuus. ISO/IEC 27001:2022 tarjoaa hallintajärjestelmän rungon toimintaympäristön, asianomaisten osapuolten, soveltamisalan, johtajuuden, riskien arvioinnin, riskien käsittelyn, soveltuvuuslausunnon, sisäisen tarkastuksen, johdon katselmoinnin ja jatkuvan parantamisen kautta.

Sopimusten on vastattava toimintamallia

Yhteisrekisterinpitäjäjärjestely ei voi elää vain tietosuojaselosteessa. Sen on näyttävä sopimuksissa, liitteissä, operatiivisissa menettelyissä, poikkeamien toimintamalleissa, eskalointireiteissä ja päättämisehdoissa.

Clarysecin Laki- ja sääntelyvaatimusten noudattamisen politiikan kohta 5.3.1.2 tuo sopimustyypit nimenomaisesti osaksi hallinnointia, mukaan lukien:

Sopimukset, joihin sisältyy tietojen jakamista, immateriaalioikeuksia, vastuunrajoituksia tai auditointilausekkeita

Tietosuoja- ja yksityisyydensuojapolitiikan kohta 5.1 määrittää yritystason perustan:

Organisaation tulee ylläpitää muodollista tietosuojan hallinnointikehystä, joka on integroitu tietoturvallisuuden hallintajärjestelmään (ISMS) tämän politiikan soveltamiseksi.

Pk-yrityksissä sama periaate skaalataan operatiiviseen todellisuuteen. Tietosuoja- ja yksityisyydensuojapolitiikka-sme - SME, kohta 5.2.1, toteaa:

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

Kohta 5.2.2 lisää:

Henkilötietoja käsittelevien kolmansien osapuolten kanssa tehtyihin sopimuksiin tulee sisällyttää tietosuojalausekkeet, ja toimitusjohtajan tai oikeudellisen neuvonantajan tulee katselmoida ne

Tämä on suhteutettua hallinnointia. Monikansallisella organisaatiolla voi olla erilliset lakiasia-, tietosuoja-, hankinta-, tietoturva-, riski- ja vaatimustenmukaisuustiimit. Pk-yritys voi nojata tietosuojakoordinaattoriin, toimitusjohtajaan ja ulkoiseen oikeudelliseen neuvonantajaan. Näyttöodotus pysyy samana: käsittelytoimet, vastuut, oikeusperuste, selosteet, oikeuksien käsittely, poikkeamien eskalointi ja päättämisvelvoitteet tulee dokumentoida ja niiden tulee olla katselmoitavissa.

Zenith Blueprint, vaihe 23, Organisatoriset kontrollit, tukee toimittajasopimusten kurinalaisuutta luottamuksellisuuden, pääsynhallintavastuiden, teknisten ja organisatoristen toimenpiteiden, poikkeamien ilmoitusmääräaikojen, auditointioikeuksien, alihankkijakontrollien ja sopimuksen päättymistä koskevien ehtojen kautta. Yhteisrekisterinpitäjäsuhteissa nämä lausekkeet tulee mukauttaa tietojen jakamiseen ja vastuunjakoon sen sijaan, että ne kopioidaan henkilötietojen käsittelijän mallipohjasta.

Poikkeamien ja tietoturvaloukkausten hallinnointi: päätä vastuullinen taho ennen loukkausta

Yhteisrekisterinpitäjien tietoturvaloukkaukset muuttuvat kaoottisiksi, jos tiimit odottavat poikkeamaan asti päättääkseen, kuka viestii ulkoisesti.

GDPR määrittää henkilötietojen tietoturvaloukkauksen turvallisuuden loukkaukseksi, joka johtaa henkilötietojen vahingossa tapahtuvaan tai lainvastaiseen tuhoamiseen, häviämiseen, muuttamiseen, luvattomaan luovuttamiseen tai henkilötietoihin pääsyyn. Tarvittaessa valvontaviranomaiselle on ilmoitettava ilman aiheetonta viivytystä ja mahdollisuuksien mukaan 72 tunnin kuluessa siitä, kun loukkaus on tullut tietoon. NIS2 ja DORA voivat lisätä muita kyberpoikkeamien raportointia ja asiakasviestintää koskevia odotuksia.

Clarysecin Tietoturvapoikkeamiin reagoinnin politiikka-sme - SME, kohta 5.3.2, tiivistää aikataulukurin:

Reagointiaikataulut, mukaan lukien tietojen palauttaminen ja ilmoitusvelvoitteet, tulee dokumentoida ja yhdenmukaistaa lakisääteisten vaatimusten kanssa, kuten GDPR:n 72 tunnin henkilötietojen tietoturvaloukkausta koskevan ilmoitusvaatimuksen kanssa.

Zenith Blueprint, vaihe 5, Viestintä, tietoisuus ja pätevyys, korostaa ulkoisen viestinnän suunnittelua, mukaan lukien asiakkaat, viranomaiset, kumppanit ja yleisö. Yhteisrekisterinpitäjien osalta poikkeamamatriisin tulee tunnistaa, kuka tekee alustavan tietoturvaloukkauksen luokittelun, kuka ottaa yhteyttä toiseen rekisterinpitäjään, kuka määrittää, koskeeko asia henkilötietoja, kuka arvioi ilmoituskynnykset, kuka laatii viranomaisilmoitukset, kuka viestii rekisteröidyille, kuka koordinoi NIS2- tai DORA-raportointia, kuka hyväksyy julkiset kannanotot ja kuka kirjaa näytön REG10:een.

Jos järjestely koskee DORA-asetuksen soveltamisalaan kuuluvaa finanssiyhteisöä, poikkeamaprosessin tulee tukea myös merkittävän TVT-poikkeaman luokittelua, eskalointia ylimmälle johdolle, välipäivityksiä, loppuraportointia ja asiakasviestintää silloin, kun asiakkaiden taloudelliset edut vaikuttuvat. Jos organisaatio kuuluu NIS2:n soveltamisalaan, merkittävien poikkeamien raportointi voi edellyttää vaiheittaista ilmoittamista ja viestintää palvelun vastaanottajille.

Turvallisin käytäntö on yhteinen pöytäharjoitus ennen käyttöönottoa. Hyvä skenaario pakottaa tiimit käyttämään REG08:aa, REG10:tä, poikkeaman toimintamallia, kumppaniyhteystietoja, ilmoituspohjia, eskalointipuita ja näyttölokeja aikapaineessa.

Poikkivaatimustenmukaisuus: Article 26 ei yleensä elä yksin

Yhteisrekisterinpitäjäjärjestelyt sijaitsevat usein laajemmissa säännellyissä ekosysteemeissä. Fintech-kampanja, yhdistetty terveysalusta, hallinnoitu palvelusuhde, pilvimarkkinapaikan integraatio tai digitaalisen infrastruktuurin kumppanuus voi laukaista velvoitteita GDPR:n lisäksi.

NIS2 voi soveltua keskisuuriin ja suuriin keskeisiin tai tärkeisiin toimijoihin aloilla, kuten digitaalinen infrastruktuuri, pilvipalvelut, datakeskukset, hallinnoidut palveluntarjoajat, hallinnoidut tietoturvapalveluntarjoajat, verkkomarkkinapaikat, hakukoneet ja sosiaalisen verkostoitumisen alustat. NIS2 Article 20 asettaa kyberturvallisuuden riskienhallinnan valvonnan hallintoelimille. Article 21 edellyttää teknisiä, operatiivisia ja organisatorisia toimenpiteitä, mukaan lukien riskianalyysi, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun tietoturva, turvallinen kehittäminen, haavoittuvuuksien käsittely, koulutus, salaus, henkilöstöturvallisuus, pääsynhallinta, omaisuudenhallinta ja todennus. Article 23 ottaa käyttöön merkittäviä poikkeamia koskevan vaiheittaisen raportoinnin.

DORA soveltuu moniin finanssiyhteisöihin 17. tammikuuta 2025 alkaen. Se kattaa TVT-riskien hallinnan, merkittävien TVT-poikkeamien raportoinnin, digitaalisen toiminnallisen häiriönsietokyvyn testauksen, TVT:n kolmannen osapuolen riskin, sopimusjärjestelyt TVT-palveluntarjoajien kanssa ja kriittisten TVT-palveluntarjoajien valvonnan. DORA Article 5 asettaa TVT-riskien hallinnoinnin hallintoelimen tasolle. Articles 8 to 14 kattavat omaisuuden tunnistamisen, suojauksen, havaitsemisen, jatkuvuuden, varmuuskopioinnin, toipumisen, opit, koulutuksen ja kriisiviestinnän. Articles 17 to 20 määrittävät poikkeaman elinkaaren ja raportoinnin. Articles 28 to 30 tekevät kolmannen osapuolen TVT-riskistä, sopimusehdoista, rekistereistä, keskittymäriskistä, auditointioikeuksista ja irtautumissuunnittelusta keskeisiä velvoitteita.

NIST CSF 2.0 tarjoaa käytännöllisen integraatiokerroksen. Sen GOVERN Function sisältää lakisääteiset, sääntelyyn perustuvat, sopimusperusteiset, tietosuojaan ja kansalaisvapauksiin liittyvät velvoitteet, johdon vastuun, riskinottohalukkuuden, politiikan, valvonnan ja toimittajariskin. Tulokset, kuten GV.OC-03 ja GV.SC-02, kohdistuvat luontevasti Article 26 -näyttöön, koska ne edellyttävät oikeudellisten velvoitteiden ja kumppaniroolien ymmärtämistä, hallintaa, viestimistä ja koordinointia.

Clarysecin mallin etu on näytön uudelleenkäyttö. REG08 ei ole vain GDPR-tallenne. Se tukee ISO/IEC 27701:2025:n osoitusvelvollisuutta, ISO/IEC 27001:2022:n hallinnointia, NIST CSF 2.0:n toimittajaroolien selkeyttä, DORA-asetuksen kolmansien osapuolten hallinnointia finanssipalveluissa sekä NIS2:n johdon valvontaa silloin, kun toimija kuuluu soveltamisalaan.

Mitä auditoijat ja valvojat testaavat

Eri arvioijat lähestyvät yhteisrekisterinpitäjien hallinnointia eri näkökulmista, mutta he päätyvät samaan ydinkysymykseen: pystyykö organisaatio osoittamaan, että osoitusvelvollisuus toimii?

Vahvin auditointiasema on jäljitettävyys. Aloita oikeudellisesta vaatimuksesta, yhdistä se PIMS-politiikkaan, osoita rekisterimerkintä, näytä työnkulku ja esitä sen jälkeen testinäyttö tai todellinen tapaustallenne.

Esimerkiksi GDPR Article 26 edellyttää yhteisrekisterinpitäjien vastuiden jakamista. Henkilötietojen hallintajärjestelmän politiikka edellyttää REG08:aa ennen käsittelyn aloittamista. REG08 näyttää vastuunjaon tietosuojaselosteiden, oikeuksien, tietoturvaloukkausten, säilytyksen, toimittajahallinnan ja yhteyshenkilöiden osalta. REG07 näyttää julkisen yhteenvedon. DSR-simulaatio osoittaa työnkulun toimivuuden. Johdon katselmuksen pöytäkirjat osoittavat poikkeukset, päätökset ja parannukset.

Tämä on auditoitavaa hallinnointia.

Johdon katselmointi muuttaa tietosuojariskin ylimmän johdon vastuuksi

Yhteisrekisterinpitäjien hallinnointia ei tule piilottaa tietosuojakansioon. Se kuuluu johdon katselmointiin, koska se vaikuttaa sääntelyaltistukseen, asiakkaiden luottamukseen, potilaiden luottamukseen, valmiuteen poikkeamatilanteisiin, toimittajariskiin, sopimusvastuuseen ja toiminnan häiriönsietokykyyn.

ISO/IEC 27001:2022 edellyttää johdon sitoutumista, rooleja, resursseja, politiikan yhdenmukaisuutta, riskiperusteista suunnittelua, suorituskyvyn arviointia ja jatkuvaa parantamista. NIS2 asettaa kyberturvallisuuden valvontavelvoitteita hallintoelimille. DORA asettaa finanssiyhteisöissä lopullisen TVT-riskivastuun hallintoelimelle.

Clarysecin Hallinnointirooleja ja vastuita koskeva politiikka-sme - SME, kohta 5.5, toteaa:

Kaikki merkittävät tietoturvapäätökset, poikkeukset ja eskaloinnit tulee kirjata, ja niiden tulee olla jäljitettävissä.

Yritysorganisaatioille Hallinnointirooleja ja vastuita koskevan politiikan kohta 5.2 edellyttää:

Rooli- ja vastuurekisteriä tulee ylläpitää, ja sen tulee sisältää:

Tämän rekisterin tulee sisältää tietosuojan hallinnointiroolit silloin, kun ne vaikuttavat tietoturvaan, tietoturvapoikkeamiin reagointiin, toimittajavarmennukseen, toiminnan häiriönsietokykyyn ja johdon raportointiin. Yhteisrekisterinpitäjäpoikkeukset tulee eskaloida ennen käyttöönottoa, ei vasta valituksen jälkeen.

Käytännöllisen johdon katselmointipaketin tulee sisältää:

• Uudet ja muuttuneet yhteisrekisterinpitäjäjärjestelyt
• REG08:n valmistumistila
• Korkean riskin käsittelytoimet ja DPIA-tila soveltuvin osin
• Avoimet oikeusperuste- tai läpinäkyvyysasiat
• DSR-suorituskyky ja kumppanien myöhässä olevat toimet
• Tietoturvaloukkausten pöytäharjoitusten tulokset ja ratkaisemattomat puutteet
• Toimittaja-, alikäsittelijä-, pilvi- ja siirtoriippuvuudet
• Säilytys- ja päättämispoikkeukset
• Auditointihavainnot ja korjausten tila
• GDPR-, NIS2-, DORA-, NIST CSF 2.0- ja COBIT 2019 -raportointivaikutus

Clarysecin viiden vaiheen malli Article 26:n tekemiseksi auditoitavaksi

Jos organisaatiosi jakaa päätöksentekoa henkilötietojen käsittelystä toisen osapuolen kanssa, älä odota valitusta, auditointia, tietoturvaloukkausta tai kumppaniriitaa vastuiden selkeyttämiseksi.

Käytä tätä viiden vaiheen mallia:

1. Käytä Zenith Blueprint -vaihetta 2 sidosryhmien, lakisääteisten vaatimusten, kumppanien odotusten, tietosuojavelvoitteiden ja sääntelyyn perustuvan soveltamisalan tunnistamiseen.
2. Käytä Zenith Blueprint -vaihetta 4 RACI-mallin rakentamiseen tietosuojaselosteille, oikeusperusteelle, oikeuksille, tietoturvaloukkausviestinnälle, säilytykselle, siirroille, toimittajille, auditointinäytölle ja päättämiselle.
3. Kirjaa käsittelytoimi REG02:een ja yhteisrekisterinpitäjien vastuunjako REG08:aan Clarysecin PIMS-politiikkakokonaisuuden avulla.
4. Kartoita järjestely Zenith Controls -oppaan avulla, erityisesti ISO/IEC 27002:2022 Control 5.2:n, Control 5.31:n ja Control 5.34:n osalta.
5. Testaa järjestely DSR-simulaatiolla ja tietoturvaloukkauksen pöytäharjoituksella ennen käsittelyn aloittamista.

CareConnect ja MetroHealth eivät tarvinneet lisää epämuodollista yhteensovittamista. Ne tarvitsivat dokumentoidun vastuunjaon, julkisen yhteenvedon, oikeuksia koskevan työnkulun, tietoturvaloukkausten koordinointitallenteen, sopimuslausekkeet ja johdon katselmoinnin näytön.

Siinä on ero väitteiden ”luulimme kumppanin hoitavan sen” ja ”tässä on hyväksytty järjestely, seloste, työnkulku, testinäyttö ja tietoturvaloukkauksen päätöstallenne” välillä.

Clarysec voi auttaa toteuttamaan ISO/IEC 27701:2025 PIMS -hallinnoinnin, yhdenmukaistamaan sen GDPR Article 26:n kanssa, integroimaan sen ISO/IEC 27001:2022 ISMS:ään ja tuottamaan auditointivalmista näyttöä GDPR-, NIS2-, DORA-, NIST CSF 2.0- ja COBIT 2019 -odotusten mukaisesti.

Haluatko korvata yhteisrekisterinpitäjien epäselvyyden auditointivalmiilla näytöllä? Tutustu Zenith Blueprint: auditoijan 30 vaiheen tiekarttaan, käytä Zenith Controls: poikkivaatimustenmukaisuuden opasta tai ota yhteyttä Claryseciin PIMS- ja ISMS-arviointia varten, joka muuttaa Article 26:n toimivaksi kontrollijärjestelmäksi ennen seuraavan kumppanuutesi tuotantokäyttöönottoa.