GDPR:n 72 tunnin henkilötietojen tietoturvaloukkauksen pelikirja tietoturvajohtajille
Hälytys laukeaa tiistaina klo 2.13 aamuyöllä.
Maria, nopeasti kasvavan fintech-SaaS-alustan tietoturvajohtaja, herää tietoturvavalvomon eskalointiin: kehittäjätililtä tehdään poikkeavia tietokantakyselyjä. Tili on käsitellyt tauluja, jotka sisältävät asiakkaiden nimiä, sähköpostiosoitteita, tapahtumahistorioita ja kansallisia henkilötunnuksia. Muutamassa minuutissa tiimi vahvistaa, että kehittäjän tunnistetiedot on varastettu tietojenkalasteluhyökkäyksessä. Altistumisikkuna on epäselvä. Hyökkääjän tarkoitus on tuntematon. Vaikutusaluetta selvitetään edelleen.
Määräaika alkaa nyt.
GDPR:n osalta Marialla voi olla 72 tuntia aikaa ilmoittaa valvontaviranomaiselle, jos poikkeama todennäköisesti aiheuttaa riskin henkilöille. NIS2:n osalta, jos yritys on keskeinen tai tärkeä toimija ja poikkeama on merkittävä, varhaisvaroitus voi olla annettava 24 tunnin kuluessa ja varsinainen ilmoitus 72 tunnin kuluessa. DORA-asetuksen osalta myös finanssialan TVT-poikkeamien raportointi ja operatiivista häiriönsietokykyä koskevat velvoitteet voivat tulla sovellettaviksi. Asiakkaat, vakuutusyhtiöt, oikeudelliset neuvonantajat, ylin johto ja auditoijat odottavat kaikki vastauksia.
Tämä on hetki, jossa yleinen tietoturvapoikkeamiin reagointisuunnitelma usein pettää. Haittaohjelmien palautusohje voi kuvata päätelaitteen eristämisen. SOC-menettely voi kuvata lokien säilyttämisen. ISO/IEC 27701:2025 -standardin mukaisen henkilötietojen tietoturvaloukkausten hallintaprosessin on kuitenkin vastattava paineen alla vaikeampiin kysymyksiin:
- Ovatko henkilötiedot altistuneet, muuttuneet, kadonneet, tuhoutuneet tai joutuneet luvattoman käytön kohteeksi?
- Toimiiko organisaatio rekisterinpitäjänä, henkilötietojen käsittelijänä, yhteisrekisterinpitäjänä vai alikäsittelijänä?
- Milloin organisaatio tuli asiasta tietoiseksi, ja mikä todentava aineisto osoittaa sen?
- Edellyttääkö GDPR Article 33 viranomaisilmoitusta?
- Kohdistuuko vaikutuksen kohteena oleviin henkilöihin korkea riski GDPR Article 34:n mukaisesti?
- Jos organisaatio toimii henkilötietojen käsittelijänä, kuinka nopeasti rekisterinpitäjälle on ilmoitettava?
- Mikä todentava aineisto osoittaa päätöksen oikeellisuuden kuuden kuukauden kuluttua auditoinnissa?
Ero kaaoksen ja hallinnan välillä ei ole tietoturvatyökalujen määrä. Ratkaisevaa on, onko organisaatio rakentanut kurinalaisen henkilötietojen hallintajärjestelmän eli PIMS:n, joka yhdistää tietoturvapoikkeamiin reagoinnin, tietosuojan hallinnan, todentavan aineiston käsittelyn, toimittajaeskaloinnin ja sääntelyraportoinnin yhdeksi puolustettavaksi elinkaareksi.
Tietoturvaloukkausten hallinta alkaa ennen kuin kukaan käyttää sanaa “tietoturvaloukkaus”
Ensimmäinen operatiivinen virhe on olettaa, että henkilötietojen tietoturvaloukkausten hallinta alkaa vasta, kun lakitiimi vahvistaa henkilötietojen tietoturvaloukkauksen. Todellisuudessa prosessi alkaa, kun henkilö, järjestelmä, toimittaja tai asiakas havaitsee jotain, joka saattaa koskea henkilötietoja.
Clarysecin Zenith Blueprint: auditoijan 30 vaiheen tiekartta Zenith Blueprint sijoittaa tämän ihmisen käynnistämän herätteen Kontrollit käytännössä -vaiheeseen, vaiheeseen 16: Henkilöstökontrollit II. Oppaassa todetaan:
“Tehokas tietoturvapoikkeamiin reagointijärjestelmä ei ala työkaluista vaan ihmisistä. Hallintakeino 6.8 korostaa sen merkitystä, että jokainen työntekijä, sopimuskumppani tai sidosryhmän edustaja tietää, miten mahdollinen tietoturvapoikkeama tunnistetaan ja ilmoitetaan, ja kokee voivansa tehdä sen turvallisesti ja valtuutetusti.”
Tällä on merkitystä, koska monet tietosuojapoikkeamat eivät näy ensin SIEM-järjestelmässä. Ne alkavat siitä, että tukihenkilö näkee toisen asiakkaan liitteen, palkanlaskennan työntekijä huomaa väärään osoitteeseen lähetetyn laskentataulukon, asiakas ilmoittaa toisen käyttäjän laskusta tai toimittaja ilmoittaa kadonneesta kannettavasta tietokoneesta.
Tietosuoja- ja yksityisyydensuojapolitiikka pk-yrityksille Tietosuoja- ja yksityisyydensuojapolitiikka pk-yrityksille, kohta Soveltaminen ja vaatimustenmukaisuus, lauseke 8.3.1, muuttaa tämän välittömäksi velvoitteeksi:
“Kaikki henkilötietojen tietoturvaloukkaukset tai epäillyt poikkeamat on ilmoitettava viipymättä tietosuojakoordinaattorille.”
Yritystason ohjelmissa Tietosuoja- ja yksityisyydensuojapolitiikka Tietosuoja- ja yksityisyydensuojapolitiikka, kohta Soveltaminen ja vaatimustenmukaisuus, lauseke 8.3.2, osoittaa johtovastuun:
“Tietosuojavastaavan (DPO) tulee johtaa tietoturvaloukkauksen rajaamista, analysointia ja eskalointia ISO/IEC 27035 -standardin sekä GDPR Article 33:n ja Article 34:n mukaisesti.”
Tämä on siirtymä tilanteesta “IT selvittää asiaa” tilanteeseen “PIMS:n tietoturvaloukkauksen elinkaari on aktivoitu”.
Ensimmäinen painepiste: tapahtuma, tietoturvapoikkeama, tietosuojapoikkeama vai henkilötietojen tietoturvaloukkaus
Klo 2.13 Marian tiimillä on hälytys. Sillä ei vielä ole vahvistettua ilmoitusvelvollisuuden piiriin kuuluvaa tietoturvaloukkausta. Ensimmäinen kriittinen päätös on luokittelu.
Zenith Blueprint, Kontrollit käytännössä -vaihe, vaihe 23: Organisatoriset kontrollit, selittää ISO/IEC 27002:2022 -standardin hallintakeinon 5.25, tietoturvatapahtumien arviointi ja päätöksenteko:
“Kaikki poikkeamat eivät ole katastrofeja. Jokainen hälytys ei merkitse vaarantumista. Käytännössä tietoturvatiimit ja liiketoimintayksiköt hukkuvat hälyyn: kirjautumisyrityksiin, lokipoikkeamiin, vähäisiin politiikkarikkomuksiin ja varjo-IT-toimintaan. Todellinen haaste ei ole pelkkä havaitseminen vaan harmittoman erottaminen haitallisesta ja sen ymmärtäminen, mikä edellyttää eskalointia.”
Tietoturvaloukkauksen elinkaaren on tehtävä tämä erottelu toistettavasti. Sen ei tule riippua siitä, kuka sattuu olemaan päivystämässä, mikä juristi osallistuu ensin tai kuinka mukavaksi tietoturvajohtaja kokee epävarmuuden.
Käytännöllinen Clarysec-luokittelumalli erottaa neljä vaihetta:
| Luokitteluvaihe | Kysymys | Tyypillinen omistaja | Vaadittava todentava aineisto |
|---|---|---|---|
| Tapahtuma | Tapahtuiko jotain poikkeavaa? | Helpdesk, SOC, liiketoimintavastaava | Tiketti, raportti, hälytys, sähköposti, lokiote |
| Tietoturvapoikkeama | Uhkasiko tai vaaransiko tapahtuma tietoturvallisuuden? | Tietoturvapoikkeamiin reagoinnin koordinaattori | Poikkeamatiketti, triage-muistiinpanot, vaikutuksen kohteena olevat järjestelmät |
| Tietosuojapoikkeama | Voiko tapahtuma koskea henkilötietoja tai tietosuojavelvoitteita? | Tietosuojavastaava tai DPO | Henkilötietoryhmät, rekisteröidyt, käsittelyrooli |
| Vahvistettu tai epäilty henkilötietojen tietoturvaloukkaus | Ovatko henkilötiedot altistuneet, kadonneet, muuttuneet, tuhoutuneet tai tulleet lainvastaisesti tai vahingossa käsitellyiksi? | DPO, tietosuojavastaava, lakiasiat, liiketoimintavastaava | Riskinarviointi, ilmoituspäätös, todentavan aineiston rekisteri |
Sana “epäilty” on olennainen. Clarysec ei suosittele odottamaan täydellistä varmuutta ennen tietoturvaloukkaustyönkulun avaamista. Tietoturvaloukkausrekisteri tulee avata, kun henkilötietojen tietoturvaloukkausta voidaan perustellusti epäillä, ja sitä tulee päivittää tosiseikkojen tarkentuessa.
Henkilötietopoikkeamien ja tietoturvaloukkausten hallintapolitiikka Henkilötietopoikkeamien ja tietoturvaloukkausten hallintapolitiikka, kohta Luokittelu ja tietoturvaloukkauksen arviointi, lauseke 4.2.3, edellyttää, että rekisterinpitäjät dokumentoivat päätöksen ennen ulkoisia toimia:
“[Rekisterinpitäjä] Tietosuojavastaavan / tietosuojaneuvonantajan TULEE arvioida vaikutuksen kohteena oleviin rekisteröityihin kohdistuva riski jokaisen vahvistetun tai perustellusti epäillyn henkilötietojen tietoturvaloukkauksen osalta ja kirjata ilmoitussuositus, riskiperustelu ja neuvonta REG10:een ennen ulkoisen ilmoituspäätöksen tekemistä.”
Tämä lauseke on auditointivalmiin GDPR-tietoturvaloukkausprosessin operatiivinen ydin: arvioi riski, kirjaa perustelu, tallenna neuvonta, tee päätös ja säilytä todentava aineisto REG10:ssä.
72 tunnin määräaika on todentavan aineiston ongelma, ei kalenterimuistutus
Monet tiimit käsittelevät GDPR:n 72 tunnin ilmoitusvaatimusta projektisuunnitelman määräpäivänä. Todellisessa poikkeamassa vaikeinta on osoittaa, milloin organisaatio tuli asiasta tietoiseksi, mitä tuolloin tiedettiin, kuinka nopeasti organisaatio toimi ja miksi ilmoituspäätös oli perusteltu.
Tietoturvapoikkeamien hallintapolitiikka pk-yrityksille Tietoturvapoikkeamien hallintapolitiikka pk-yrityksille, kohta Tarkoitus, lauseke 1.2, määrittää tavoitteen:
“Tämän politiikan avulla organisaatio voi vähentää vahinkoja, suojata asiakastietoja ja täyttää sääntelyvelvoitteet, kuten GDPR:n 72 tunnin henkilötietojen tietoturvaloukkausta koskevan ilmoitusvaatimuksen.”
Tietosuoja- ja yksityisyydensuojapolitiikka pk-yrityksille, kohta Soveltaminen ja vaatimustenmukaisuus, lauseke 8.3.3, toteaa:
“Tarvittaessa viranomaisille ja vaikutuksen kohteena oleville henkilöille on ilmoitettava 72 tunnin kuluessa.”
Yritystason ohjelmissa Tietosuoja- ja yksityisyydensuojapolitiikka, kohta Soveltaminen ja vaatimustenmukaisuus, lauseke 8.3.3, toteaa:
“Tietoturvaloukkaukset, jotka täyttävät lakisääteisen ilmoituskynnyksen, on ilmoitettava valvontaviranomaisille 72 tunnin kuluessa.”
Tarkoitus ei ole ilmoittaa jokaista poikkeamaa. Tarkoitus on tehdä puolustettava päätös riittävän nopeasti, jotta vaadittu ilmoitus voidaan tehdä määräajassa. Kypsä PIMS käyttää siksi sisäisiä määräaikoja, jotka ovat ulkoisia lakisääteisiä määräaikoja lyhyempiä.
| Aika tietoon tulemisesta | PIMS-toimi | REG10:een tallennettava todentava aineisto |
|---|---|---|
| 0–4 tuntia | Avaa henkilötietopoikkeaman tietue, nimeä omistaja, säilytä alkuperäinen todentava aineisto, tunnista käsittelyrooli | Vastaanottoraportti, tietoon tulemisen ajankohta, nimetyt roolit, alkuvaiheen tiedot järjestelmistä ja tiedoista |
| 4–12 tuntia | Rajaa altistuminen, tunnista henkilötietoryhmät, määritä rekisterinpitäjän tai henkilötietojen käsittelijän velvoitteet | Rajaamistoimet, vaikutuksen kohteena olevat tietotyypit, rooliarviointi, toimittaja- tai asiakasriippuvuudet |
| 12–24 tuntia | Tee alustava riskinarviointi ja päätä, onko valvontaviranomaiselle ilmoittaminen todennäköistä | Riskiperustelu, todennäköinen vaikutus, epävarmuustekijät, DPO:n neuvonta, oikeudellinen arvio |
| 24–48 tuntia | Valmistele ilmoitus tai ilmoittamatta jättämisen perustelu, koordinoi asiakas- tai rekisterinpitäjäviestintä | Ilmoitusluonnos, päätösloki, hyväksynnät, asiakasilmoitukset, viittaukset todentavaan aineistoon |
| 48–72 tuntia | Tee vaadittu ilmoitus, dokumentoi tarvittaessa viivästyksen perustelu, valmistele henkilöille annettava viestintä, jos riski on korkea | Lähetyskohtainen todentava aineisto, viranomaisviite, lopullinen päätös, viestintäsuunnitelma |
| 72 tunnin jälkeen | Jatka tutkintaa, päivitä viranomaista tarvittaessa, ilmoita henkilöille vaadittaessa, toteuta opit | Jatkoraportit, korjaavat toimenpiteet, sulkemishyväksyntä, parannusten työjono |
Henkilötietopoikkeamien ja tietoturvaloukkausten hallintapolitiikka, kohta Ilmoitukset ja viestintä, lauseke 4.4.1, tekee dokumentointivaatimuksesta yksiselitteisen:
“[Rekisterinpitäjä] Tietosuojavastaavan / PIMS-päällikön TULEE laatia dokumentoitu viranomaisilmoitusta koskeva päätös jokaisesta vahvistetusta henkilötietojen tietoturvaloukkauksesta ilman aiheetonta viivytystä ja sellaisessa sisäisessä määräajassa, joka tukee sovellettavia ulkoisia ilmoitusmääräaikoja, ja TULEE säilyttää ilmoitus, ilmoittamatta jättämisen perustelu tai viivästyksen perustelu REG10:ssä.”
Viranomainen voi kyseenalaistaa päätöksen. Auditoija voi testata, noudatettiinko prosessia. Jos organisaatio kuitenkin pystyy osoittamaan ajantasaisen todentavan aineiston, jäsennellyt kriteerit, DPO:n neuvonnan ja dokumentoidun perustelun, sen asema on huomattavasti vahvempi kuin tiimillä, joka toteaa: “Keskustelimme tästä puhelussa.”
Rekisterinpitäjät ja henkilötietojen käsittelijät tarvitsevat eri tietoturvaloukkauspolut
Nykyaikaiset SaaS-yhtiöt toimivat usein useammassa kuin yhdessä tietosuojaroolissa. Marian fintech-alusta voi olla rekisterinpitäjä suorille tilaajilleen ja henkilötietojen käsittelijä yritysasiakkailleen. Toisessa tilanteessa B2B-tukiporras voi olla henkilötietojen käsittelijä asiakkaiden tukipyyntöliitteiden osalta mutta rekisterinpitäjä omien sisäisten tukipalvelun metatietojensa osalta.
Tämä ero muuttaa ilmoituspolun.
| Velvoite | Henkilötietojen rekisterinpitäjän rooli | Henkilötietojen käsittelijän rooli |
|---|---|---|
| Ensisijainen velvollisuus | Ilmoittaminen valvontaviranomaiselle ja vaikutuksen kohteena oleville henkilöille, kun kynnysarvot täyttyvät | Ilmoittaminen vaikutuksen kohteena olevalle rekisterinpitäjälle tai asiakkaalle |
| Ilmoituksen kohde | Asianomainen valvontaviranomainen ja, jos riski on korkea, vaikutuksen kohteena olevat henkilöt | Sopimuksessa nimetty asiakas tai rekisterinpitäjä |
| Ilmoituksen laukaiseva tekijä | Riski luonnollisten henkilöiden oikeuksille ja vapauksille | Tietoisuus asiakkaan henkilötietoihin vaikuttavasta tietoturvaloukkauksesta |
| Aikataulu | Ilman aiheetonta viivytystä ja mahdollisuuksien mukaan 72 tunnin kuluessa tietoon tulemisesta | Ilman aiheetonta viivytystä ja sopimusmääräajoissa, usein 24 tai 48 tunnin kuluessa |
| Riskinarviointi | On arvioitava henkilöihin kohdistuva riski ja päätettävä Article 33 ja 34 -ilmoituksista | Toimittaa tosiseikat, joiden perusteella rekisterinpitäjä voi arvioida riskin |
Henkilötietojen käsittelijöiden osalta Henkilötietopoikkeamien ja tietoturvaloukkausten hallintapolitiikka, kohta Ilmoitukset ja viestintä, lauseke 4.4.4, toteaa:
“[Henkilötietojen käsittelijä] Tietosuojavastaavan / PIMS-päällikön TULEE ilmoittaa vaikutuksen kohteena olevalle rekisterinpitäjälle tai asiakkaalle ilman aiheetonta viivytystä ja sovellettavan sopimusmääräajan kuluessa sen jälkeen, kun se on tullut tietoiseksi asiakkaan henkilötietoihin vaikuttavasta henkilötietojen tietoturvaloukkauksesta, ja TULEE kirjata alkuperäiset ja jatkoilmoitukset REG08:aan ja REG10:een.”
Henkilötietojen käsittelijän ei tule odottaa, että rekisterinpitäjän GDPR-riskianalyysi valmistuu. Sen on ilmoitettava rekisterinpitäjälle käytettävissä olevat tosiseikat ja toimitettava päivityksiä tutkinnan edetessä. Tämän jälkeen rekisterinpitäjä päättää valvontaviranomaiselle tehtävästä ilmoituksesta ja vaikutuksen kohteena oleville henkilöille annettavasta viestinnästä oman käsittelynsä osalta.
Jos henkilöihin kohdistuvat vaikutukset ovat korkean riskin tasolla, rekisterinpitäjän on arvioitava myös suora viestintä. Henkilötietopoikkeamien ja tietoturvaloukkausten hallintapolitiikka, lauseke 4.4.3, toteaa:
“[Rekisterinpitäjä] Tietosuojavastaavan / PIMS-päällikön TULEE koordinoida viestintä vaikutuksen kohteena oleville rekisteröidyille, kun tietoturvaloukkauksen arviointi tunnistaa korkean riskin tai vastaavan viestintälaukaisijan, ja TULEE kirjata viestinnän sisältö, kohderyhmä, ajoitus, toimitustapa ja hyväksyntää koskeva todentava aineisto REG10:een.”
Yritystason Tietosuoja- ja yksityisyydensuojapolitiikka, kohta Soveltaminen ja vaatimustenmukaisuus, lauseke 8.3.4, vahvistaa tämän:
“Jos henkilöihin kohdistuva korkea riski tunnistetaan, vaikutuksen kohteena oleville rekisteröidyille on ilmoitettava ilman aiheetonta viivytystä, ellei poikkeusta sovelleta (esim. käytössä on vahva salaus).”
Poikkeuksen on perustuttava todentavaan aineistoon. Ei riitä sanoa, että “tiedot olivat salattuja”. Organisaation on pystyttävä osoittamaan, että altistuneet tiedot eivät olleet luvattomien osapuolten luettavissa ja että asiaankuuluvat avaimet eivät vaarantuneet.
Toimittajat voivat ratkaista ensimmäiset 24 tuntia
Kolmansilla osapuolilla on usein luokitteluun ja ilmoittamiseen tarvittavat tosiseikat. Pilvipalveluntarjoajalla voi olla käyttölokit. Palkanlaskennan henkilötietojen käsittelijä voi tietää, mihin työntekijöihin vaikutus kohdistui. Hallinnoitu palveluntarjoaja on voinut tehdä konfiguraatiomuutoksen. Alikäsittelijällä voi olla forensista telemetriatietoa.
Toimittajien tietoturvaloukkauslausekkeet on siksi suunniteltava ennen poikkeamaa.
Kolmansien osapuolten ja toimittajien tietoturvapolitiikka Kolmansien osapuolten ja toimittajien tietoturvapolitiikka, kohta Hallinnointivaatimukset, lauseke 5.3.3, sisältää sopimuksiin perustuvan hallinnoinnin seuraavasta:
“Tietoturvaloukkauksista ilmoittamisen määräajat (esim. 24 tai 72 tunnin kuluessa kriittisyydestä ja sääntelyvaatimuksista riippuen).”
Pienemmille organisaatioille Kolmansien osapuolten ja toimittajien tietoturvapolitiikka pk-yrityksille Kolmansien osapuolten ja toimittajien tietoturvapolitiikka pk-yrityksille tukee vastaavasti tietoturvaloukkausten ilmoitusmääräaikoja toimittajahallinnassa.
Clarysec suosittelee, että toimittajasopimukset ja tietojenkäsittelysopimukset määrittävät seuraavat asiat:
- Mikä muodostaa epäillyn henkilötietojen tietoturvaloukkauksen
- Kenelle on ilmoitettava ja mitä kanavaa käyttäen
- Ensimmäisen ilmoituksen määräaika, usein rekisterinpitäjän viranomaismääräaikaa lyhyempi
- Ensimmäisessä ilmoituksessa vaadittavat vähimmäistiedot
- Päivitystiheys tutkinnan aikana
- Todentavan aineiston säilyttämisvelvollisuudet
- Alikäsittelijöille ketjutettavat ilmoitusvelvoitteet
- Tuki viranomais- ja rekisteröityviestintään
- Poikkeaman jälkeiset korjaavia toimenpiteitä koskevat velvoitteet
Jos toimittajasopimuksissa käytetään epämääräisiä ilmaisuja, kuten “niin pian kuin käytännössä mahdollista”, rekisterinpitäjän GDPR-määräaika voi riippua toisen organisaation sisäisestä pohdinnasta. Se ei ole puolustettava toimintamalli.
Todentava aineisto tekee reagoinnista puolustettavaa vaatimustenmukaisuutta
Marian poikkeamassa tiimi tarvitsee todennuslokit, tietokantakyselyjen tallenteet, tietojenkalasteluun liittyvän todentavan aineiston, pääsynhallinnan muutokset, vaikutuksen kohteena olevien asiakkaiden luettelot, rajaamistoimet, DPO:n neuvonnan ja viestintäluonnokset. B2B SaaS -portaalin tilanteessa tiimi voi tarvita kuvakaappauksia, objektitallennuksen käyttöoikeuksia, tukipyyntöjen tunnisteita, IAM-muutoksia ja asiakasympäristöjen välisiä käyttölokeja.
Todentava aineisto on säilytettävä asianmukaisesti. Irralliset kuvakaappaukset, chat-viennit ja henkilökohtaiset kansiot eivät riitä.
Zenith Blueprint, Kontrollit käytännössä -vaihe, vaihe 23, käsittelee ISO/IEC 27002:2022 -standardin hallintakeinoa 5.28, todentavan aineiston kerääminen:
“Kun tietoturvapoikkeama tapahtuu, yksi reagoinnin kriittisimmistä mutta usein sivuutetuista osatekijöistä on todentava aineisto. Ei pelkkiä lokeja, kuvakaappauksia tai irrallisia kertomuksia, vaan asianmukaisesti säilytettyä, hallussapitoketjua kunnioittavaa ja peukaloinnin kestävää todentavaa aineistoa.”
Todentavan aineiston keräämisen ja digitaalisen forensiikan politiikka Todentavan aineiston keräämisen ja digitaalisen forensiikan politiikka, kohta Hallinnointivaatimukset, lauseke 5.5, toteaa:
“Kaikki kerätty todentava aineisto on yksilöitävä, merkittävä ja säilytettävä suojatussa tietovarastossa, jossa on:”
Henkilötietopoikkeamien ja tietoturvaloukkausten hallintapolitiikka, kohta Todentava aineisto, kirjanpito ja luottamuksellisuus, lauseke 4.5.1, yhdistää tämän todentavan aineiston PIMS-tietueeseen:
“[Molemmat] Tietoturvapoikkeamiin reagoinnin koordinaattorin TULEE ylläpitää täydellistä REG10-tietuetta jokaisesta epäillystä tai vahvistetusta henkilötietopoikkeamasta vastaanotosta sulkemiseen asti, mukaan lukien tosiseikat, ajoitus, luokittelu, arviointi, toimet, päätökset, ilmoitukset, viittaukset todentavaan aineistoon ja sulkemisen tila.”
REG10:stä tulee poikkeaman yksi totuuden lähde. REG08 tallentaa tarvittaessa asiakas- tai rekisterinpitäjäilmoitukset. Yhdessä ne mahdollistavat sen, että tietoturva-, tietosuoja-, lakiasia- ja auditointitiimit työskentelevät yhden näyttöketjun pohjalta.
| REG10-kenttä | Esimerkkimerkintä |
|---|---|
| Poikkeaman tunniste | PII-2026-034 |
| Tietoon tulemisen ajankohta | 2026-06-23 02:13 UTC, SOC-hälytys vahvistettu |
| Käsittelyrooli | Rekisterinpitäjä suorille tilaajille, henkilötietojen käsittelijä yritysasiakkaiden tietoaineistoille |
| Kyseiset henkilötiedot | Nimet, työsähköpostiosoitteet, tapahtumahistoriat, kansalliset henkilötunnukset |
| Alustava luokittelu | Vahvistettu tietoturvapoikkeama, johon liittyy epäilty henkilötietojen tietoturvaloukkaus |
| Rajaaminen | Kehittäjän tunnistetiedot peruttu, istunnot päätetty, vaikutuksen kohteena olevan tietokannan käyttöä rajoitettu |
| Riskinarviointi | Ei-julkisia tunnisteita käytetty; identiteettipetoksen riskiä ei voida sulkea pois |
| Ilmoituspäätös | Valvontaviranomaiselle tehtävä ilmoitus hyväksytty rekisterinpitäjän tietojen osalta; yritysasiakkaille ilmoitettu rekisterinpitäjinä |
| Viittaukset todentavaan aineistoon | Todennusloki E-034-01, kyselyvienti E-034-02, tietojenkalasteluartefakti E-034-03 |
| Sulkeminen | Juurisyy korjattu, MFA-kontrolleja vahvistettu, tietojenkalastelukoulutus päivitetty, asiakasseuranta toteutettu |
Tarkoitus ei ole byrokratia. Tarkoitus on estää organisaatiota rekonstruoimasta muistia hajanaisista Slack-viesteistä sen jälkeen, kun viranomainen ottaa yhteyttä.
ISO 27701 -standardin mukaisen PIMS-reagoinnin yhdistäminen ISO 27001- ja ISO 27002 -standardeihin
Kypsä henkilötietojen tietoturvaloukkausprosessi sijaitsee tietosuojan hallinnan ja tietoturvallisuuden hallintajärjestelmän leikkauspisteessä.
ISO/IEC 27001:2022 -standardin lausekkeet 4.1–4.4 edellyttävät, että organisaatiot ymmärtävät toimintaympäristön, sidosryhmät, ISMS:n soveltamisalan ja hallintajärjestelmän prosessit. Henkilötietojen tietoturvaloukkausten hallinnassa tämä tarkoittaa, että prosessin on kuvastettava sääntelyvelvoitteita, asiakassopimuksia, käsittelyrooleja, toimittajariippuvuuksia ja alakohtaisia velvoitteita jo ennen poikkeamaa.
Zenith Controls: vaatimustenmukaisuuden viitekehysten välinen opas Zenith Controls auttaa kartoittamaan poikkeamakontrollit laajempaan varmentamismalliin. Keskeisimmät ISO/IEC 27002:2022 -hallintakeinot ovat:
| ISO/IEC 27002:2022 -hallintakeino | Käsittely Zenith Controls -oppaassa | Miksi sillä on merkitystä henkilötietojen tietoturvaloukkausten hallinnassa |
|---|---|---|
| 5.24 Tietoturvapoikkeamien hallinnan suunnittelu ja valmistelu | Korjaava kontrolli, reagointi ja palautuminen, hallinnointi ja tietoturvatapahtumien hallinta | Määrittää suunnitelmat, roolit, eskalointipolut, viestintämallit ja valmiuden henkilötietojen tietoturvaloukkauksiin |
| 5.25 Tietoturvatapahtumien arviointi ja päätöksenteko | Havaitseva kontrolli, havaitseminen ja reagointi, tietoturvatapahtumien hallinta | Luo jäsennellyn päätöspisteen tietosuojapoikkeamien ja epäiltyjen henkilötietojen tietoturvaloukkausten luokitteluun |
| 5.26 Tietoturvapoikkeamiin reagointi | Korjaava kontrolli, reagointi ja palautuminen, tietoturvatapahtumien hallinta | Aktivoi rajaamisen, koordinoinnin, ilmoitustuen, palautumisen ja sidosryhmäviestinnän |
| 5.28 Todentavan aineiston kerääminen | Todentavan aineiston säilyttäminen ja tutkinnan luotettavuus poikkeaman elinkaaren aikana | Tukee GDPR:n osoitusvelvollisuutta, forensista laatua, viranomaiskysymyksiä ja auditoinnissa puolustettavuutta |
| 6.8 Tietoturvatapahtumien ilmoittaminen | Ihmislähtöinen ilmoituskanava ja tietoturvatietoisuuskoulutus | Varmistaa, että työntekijät, sopimuskumppanit ja sidosryhmät ilmoittavat epäillyistä henkilötietopoikkeamista nopeasti |
ISO/IEC 27035 tukee jäsenneltyä poikkeamien hallintaa. ISO/IEC 27037 tukee digitaalisen todistusaineiston käsittelyä. ISO/IEC 29134 voi tukea tietosuojavaikutusten arvioinnin logiikkaa, kun tietoturvaloukkauksen korjaaminen osoittaa tarpeen syvemmälle DPIA-katselmoinnille. ISO/IEC 27701:2025 tuo tämän jälkeen tietosuojaroolien kontekstin, rekisteröityihin kohdistuvan vaikutuksen, rekisterinpitäjän ja henkilötietojen käsittelijän velvoitteet sekä PIMS:n todentavaa aineistoa koskevat vaatimukset osaksi hallintajärjestelmää.
Yksi poikkeama, monta sääntelyn näkökulmaa
Marian poikkeama ei ole vain GDPR-kysymys. Koska yritys tarjoaa pilvipalveluja finanssialan asiakkaille, myös NIS2 ja DORA voivat soveltua. Asiakassopimukset voivat edellyttää ilmoitusta 24 tunnin kuluessa. Kybervakuutus voi edellyttää nopeaa ilmoitusta. Sisäinen hallinnointi voi edellyttää raportointia hallitukselle.
Erillisten kertomusten laatiminen jokaista viitekehystä varten luo ristiriitariskin. Clarysecin menetelmä on ylläpitää yhtä näyttöketjua ja muodostaa siitä viitekehyskohtaiset tuotokset.
| Viitekehys tai säädös | Poikkeaman näkökulma | Clarysecin näyttöketjun tuotos |
|---|---|---|
| GDPR | Henkilötietojen tietoturvaloukkaus, henkilöihin kohdistuva riski, valvontaviranomaiselle ilmoittaminen, vaikutuksen kohteena oleville henkilöille viestiminen | REG10-päätöstietue, DPO:n neuvonta, Article 33 ja 34 -perustelu, viestintään liittyvä todentava aineisto |
| ISO/IEC 27701:2025 | PIMS-hallinnointi, rekisterinpitäjän ja henkilötietojen käsittelijän velvollisuudet, rekisteröityyn kohdistuva riski, tietosuojan todentava aineisto | Henkilötietopoikkeaman luokittelu, rooliarviointi, REG08 ja REG10, korjaavat toimenpiteet |
| ISO/IEC 27001:2022 | ISMS:n toimintaympäristö, sidosryhmät, tietoturvapoikkeamiin reagointiprosessi, jatkuva parantaminen | Poikkeamatietue, riskien käsittelyn päivitykset, johdon katselmoinnin syöte, kontrollin toimivuuden todentava aineisto |
| NIS2 | Merkittävän poikkeaman käsittely, vaiheittainen raportointi, kaikki vaarat huomioon ottavat turvatoimet | 24 tunnin varhaisvaroituksen todentava aineisto, 72 tunnin poikkeamailmoituspaketti, kuukauden loppuraportin tuki |
| DORA | Finanssitoimijoiden TVT-poikkeamien hallinta ja digitaalinen operatiivinen häiriönsietokyky | TVT-vaikutusten tosiseikat, kolmannen osapuolen riippuvuudet, häiriönsietokyvyn testauksen palaute, poikkeamaraportoinnin tuki |
| NIST CSF 2.0 | Nykyprofiili ja tavoiteprofiili, priorisoitu toimintasuunnitelma, riskiviestintä | Puutepäivitykset, tavoiteparannukset, hallitustasoinen riskikertomus |
| COBIT 2019 | Hallinnointi, johtamisen tavoitteet, osoitusvelvollisuus, kontrollien suorituskyky | RACI, päätöslokit, prosessimittarit, korjaavien toimenpiteiden seuranta |
NIS2 Article 21 määrittää kyberturvallisuuden riskienhallintatoimenpiteet, mukaan lukien poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun turvallisuus, vaikuttavuuden arviointi, kyberhygienia, kryptografia, pääsynhallinta, omaisuudenhallinta, MFA ja turvallinen viestintä. NIS2 Article 23 luo merkittäviä poikkeamia koskevan vaiheittaisen raportoinnin, johon kuuluvat varhaisvaroitus 24 tunnin kuluessa, poikkeamailmoitus 72 tunnin kuluessa, pyydettäessä annettavat päivitykset sekä loppuraportti viimeistään yhden kuukauden kuluttua poikkeamailmoituksesta.
DORA:aa sovelletaan 17.1.2025 alkaen, ja se määrittää yhdenmukaiset vaatimukset TVT-riskien hallinnalle, TVT-poikkeamien raportoinnille, digitaalisen operatiivisen häiriönsietokyvyn testaukselle, tietojen jakamiselle ja finanssitoimijoiden TVT-kolmansien osapuolten riskienhallinnalle. Fintech-toimittajan yksittäinen poikkeama voi siten olla GDPR:n mukainen tietoturvaloukkaus, NIS2:n mukainen merkittävä poikkeama, asiakkaiden kannalta DORA-relevantti TVT-tapahtuma ja sopimukseen perustuva ilmoitustapahtuma.
Miten auditoijat testaavat elinkaaren
Auditoijat eivät yleensä pysähdy kysymykseen “näytä tietoturvapoikkeamiin reagointipolitiikkanne”. He testaavat, toimiiko elinkaari näyttöpaineen alla.
ISO/IEC 27701:2025- tai ISO/IEC 27001:2022 -auditoija kysyy, miten tietosuojapoikkeamat tulevat ISMS:n ja PIMS:n piiriin, kuka luokittelee tapahtumat, miten rekisterinpitäjän ja henkilötietojen käsittelijän velvollisuudet eroavat toisistaan ja miten poikkeamat johtavat korjaaviin toimenpiteisiin.
GDPR-auditoija tai valvontaviranomainen keskittyy tietoon tulemisen ajankohtaan, henkilöihin kohdistuvaan riskiin, DPO:n osallistumiseen, ilmoitusperusteluun, vaikutuksen kohteena oleville henkilöille annettavaan viestintään ja osoitusvelvollisuuteen. He voivat poimia otokseen poikkeamia, joista ei ole ilmoitettu, ja testata, onko ilmoittamatta jättämisen perustelu dokumentoitu.
NIS2- tai DORA-katselmointi tarkastelee merkittävän poikkeaman kynnysarvoja, vaiheittaista raportointia, TVT-vaikutusta, kolmansien osapuolten riippuvuuksia, häiriönsietokykyvaikutuksia ja sitä, vastasiko raportointi toimivaltaisen viranomaisen tai asiakkaan vaatimuksia.
NIST CSF 2.0 -arvioija kysyy, muuttiko poikkeama organisaation nykyprofiilia ja tavoiteprofiilia. COBIT 2019 -katselmoija keskittyy hallinnointiin, osoitusvelvollisuuteen, prosessiomistajuuteen, mittareihin ja korjaavien toimenpiteiden seurantaan.
Vahvan auditointipaketin tulisi sisältää:
| Todentavan aineiston kohde | Miksi auditoijat pyytävät sitä |
|---|---|
| REG10-poikkeamatietue | Osoittaa vastaanoton, ajoituksen, luokittelun, arvioinnin, päätökset, ilmoitukset ja sulkemisen |
| REG08-asiakas- tai rekisterinpitäjäilmoituksen tietue | Osoittaa henkilötietojen käsittelijän viestinnän ja asiakaspäivitysten historian |
| Alkuperäinen raportti tai hälytys | Määrittää, miten poikkeama havaittiin ja milloin organisaatio tuli siitä tietoiseksi |
| Keskeisten toimien aikajana | Osoittaa rajaamisen, arvioinnin, hyväksynnät ja ilmoituspäätökset |
| Käsittelyroolin arviointi | Osoittaa rekisterinpitäjän ja henkilötietojen käsittelijän velvoitteiden erottamisen |
| Henkilötietoryhmät ja vaikutuksen kohteena olevat rekisteröidyt | Tukee riskinarviointia ja ilmoituksen soveltamisalaa |
| DPO:n tai tietosuojaneuvonantajan suositus | Osoittaa vastuullisen tietosuojaneuvonnan ennen ulkoista päätöstä |
| Ilmoitus tai ilmoittamatta jättämisen perustelu | Tukee GDPR Article 33 ja 34 -osoitusvelvollisuutta |
| Todentavan aineiston tietovaraston hakemisto | Osoittaa todentavan aineiston eheyden ja hallussapitoketjun kurinalaisuuden |
| Juurisyy ja korjaavien toimenpiteiden suunnitelma | Osoittaa jatkuvan parantamisen ja kontrollin tehokkuuden arvioinnin |
Tässä Zenith Controls on kaupallisesti ja operatiivisesti arvokas. Se auttaa kartoittamaan saman todentavan aineiston ISO/IEC 27002:2022 -standardin poikkeamakontrolleihin, GDPR:n osoitusvelvollisuuteen, NIS2:n poikkeamien käsittelyyn, DORA:n häiriönsietokykyodotuksiin, NIST CSF -viestintään ja COBIT-hallinnointiin ilman, että auditointikertomusta rakennetaan joka kerta uudelleen.
Ensimmäisen 24 tunnin toimintarytmi
Realistisen henkilötietojen tietoturvaloukkauksen pelikirjan tulee tuntua käytännölliseltä, ei teoreettiselta. Tarkastellaan asiakkaan klo 08.12 ilmoittamaa asiakasympäristöjen välistä SaaS-altistumista.
Klo 08.12 asiakkuustiimi vastaanottaa ilmoituksen ja noudattaa Zenith Blueprint -oppaan vaiheen 16 mukaista ilmoituskäyttäytymistä. Tiketti merkitään epäillyksi henkilötietopoikkeamaksi.
Klo 08.25 tietoturvapoikkeamiin reagoinnin koordinaattori avaa REG10:n. Tietue sisältää tietoon tulemisen ajankohdan, ilmoittajan, järjestelmän, epäillyt tietotyypit ja omistajan.
Klo 09.02 tekninen tiimi peruuttaa käyttöoikeusmuutoksen. Lokit viedään ennen niiden kiertoa. Todentavan aineiston vastuuhenkilö merkitsee asiakkaan ilmoituksen, IAM-muutoksen, käyttölokin viennin ja rajaamisen vahvistuksen suojattuun tietovarastoon.
Klo 10.30 tietosuojavastaava toteaa, että organisaatio toimii asiakkaan tukiliitteiden henkilötietojen käsittelijänä. Henkilötietopoikkeamien ja tietoturvaloukkausten hallintapolitiikan lausekkeen 4.4.4 mukaisesti vaikutuksen kohteena oleville rekisterinpitäjäasiakkaille on ilmoitettava ilman aiheetonta viivytystä ja sopimusmääräaikojen kuluessa. REG08 avataan.
Klo 12.00 DPO arvioi rekisteröityihin kohdistuvan riskin. Tiedot vaikuttavat rajallisilta, mutta osa liitteistä voi sisältää työntekijöiden nimiä ja sisäisiä tunnisteita. DPO kirjaa riskiperustelun ja suosituksen REG10:een.
Klo 15.00 vaikutuksen kohteena olevat rekisterinpitäjäasiakkaat saavat ensimmäisen ilmoituksen: mitä tapahtui, milloin se havaittiin, mitä rajattiin, mitä henkilötietoja voi olla mukana, mitä edelleen analysoidaan ja milloin seuraava päivitys toimitetaan.
Klo 18.00 johto saa lyhyen tilannekatsauksen: asiakasilmoitukset on lähetetty, asiakkaiden henkilötietojen osalta viranomaisilmoituspäätökset kuuluvat rekisterinpitäjille, sisäistä rekisterinpitäjänä tehtävää käsittelyä arvioidaan edelleen, todentava aineisto on säilytetty ja juurisyyanalyysi on käynnissä.
Tällainen rytmi estää yleisimmät tietoturvaloukkausten epäonnistumiset: määräaikojen ohittamisen, roolien sekoittumisen, dokumentoimattoman neuvonnan ja hallitsemattoman viestinnän.
Yleiset epäonnistumismallit, jotka tulee poistaa ennen seuraavaa hälytystä
Vahingollisimmat tietosuojapoikkeamien epäonnistumiset johtuvat harvoin yhdestä puuttuvasta asiakirjasta. Ne johtuvat katkoksista tietoturvan, tietosuojan, lakiasioiden, toimittajien ja liiketoimintavastaavien välillä.
Clarysec näkee usein seuraavia malleja:
- Tietoturvapoikkeamiin reagointisuunnitelmat ovat olemassa, mutta henkilötietojen tietoturvaloukkauksen luokittelu puuttuu.
- GDPR:n 72 tunnin ilmoitus mainitaan, mutta sisäiset määräajat eivät ole lakisääteistä määräaikaa lyhyempiä.
- Henkilötietojen käsittelijän eskalointi viivästyy, koska tiimit odottavat täydellistä juurisyyanalyysiä.
- Toimittajasopimukset eivät edellytä nopeaa tietoturvaloukkausilmoitusta tai tukea todentavan aineiston toimittamiseen.
- DPO:n neuvonta annetaan suullisesti eikä sitä koskaan kirjata tietoturvaloukkausrekisteriin.
- Korkean riskin henkilöviestintää harkitaan liian myöhään.
- Todentava aineisto tallennetaan henkilökohtaisiin kansioihin, chat-ketjuihin tai tikettikommentteihin.
- Ilmoittamatta jättämistä koskevia päätöksiä ei dokumentoida.
- Opit eivät päivitä kontrolleja, koulutusta, toimittajalausekkeita tai riskienkäsittelysuunnitelmia.
Zenith Blueprint, vaihe 23, kiteyttää, miksi rakenteella on merkitystä:
“Ilman rakennetta tietoturvapoikkeamiin reagointi muuttuu sekavaksi ryntäilyksi. Sähköposteja lähetetään, kokouksia kutsutaan koolle ja päätöksiä tehdään tunnepohjaisesti tai epäjohdonmukaisesti. Kypsä ISMS muuttaa reagoinnin kuitenkin kurinalaiseksi toiminnaksi.”
Tämä kurinalaisuus on ISO/IEC 27701:2025 -standardin mukaisen henkilötietojen tietoturvaloukkausten hallinnan tarkoitus.
Rakenna Clarysecin henkilötietojen tietoturvaloukkauksen elinkaari
Clarysecin lähestymistapa yhdistää kolme kerrosta.
Ensinnäkin Zenith Blueprint tarjoaa toteutuksen tiekartan. Vaihe 16 varmistaa, että ihmiset tunnistavat ja ilmoittavat epäillyt poikkeamat. Vaihe 23 operationalisoi arvioinnin, päätöksenteon, reagoinnin ja todentavan aineiston keräämisen ISO/IEC 27002:2022 -standardin hallintakeinojen 5.25, 5.26 ja 5.28 avulla.
Toiseksi politiikkakokonaisuus määrittää toimivallan ja velvoitteet. Pk-yrityksille tarkoitetut politiikat tekevät ilmoittamisesta, 72 tunnin määräajasta ja poikkeamarekistereistä käytännöllisiä pienemmille organisaatioille. Yritystason politiikat osoittavat DPO:n johtovastuun, tietoturvaloukkauskynnykset, vaikutuksen kohteena oleville henkilöille annettavan viestinnän, toimittajien ilmoitusehdot, todentavan aineiston käsittelyn ja forensisen hallinnoinnin. PIMS-kohtainen Henkilötietopoikkeamien ja tietoturvaloukkausten hallintapolitiikka lisää roolipohjaiset rekisterinpitäjän ja henkilötietojen käsittelijän velvollisuudet, REG08:n, REG10:n, ilmoitusperustelun ja sulkemisen todentavan aineiston.
Kolmanneksi Zenith Controls toimii vaatimustenmukaisuuden viitekehysten välisenä kompassina. Se kartoittaa poikkeamasuunnittelun, arvioinnin, reagoinnin ja todentavan aineiston integroituun näkymään ISO/IEC 27002:2022-, GDPR-, NIS2-, DORA-, NIST CSF 2.0- ja COBIT-tyylisten varmentamisodotusten välillä.
Tietoturvajohtajille tämä vähentää operatiivista epäselvyyttä. Tietosuojavastaaville se luo puolustettavan tietosuojapäätösten jäljen. Vaatimustenmukaisuuspäälliköille se yhdistää yhden poikkeamatietueen useisiin sääntelytuotoksiin. Auditoijille se luo jäljitettävän todentavan aineiston. Johdolle se vähentää riskiä, että hallittavissa oleva tietosuojapoikkeama muuttuu sääntely- ja mainekriisiksi.
Seuraava askeleesi
Älä odota klo 2:n hälytystä saadaksesi selville, toimiiko henkilötietojen tietoturvaloukkausprosessisi.
Aloita tällä viikolla kolmella toimella:
- Katselmoi, kerääkö poikkeamien vastaanotto nimenomaisesti epäillyt henkilötietopoikkeamat.
- Varmista, että rekisterinpitäjän ja henkilötietojen käsittelijän tietoturvaloukkausvelvoitteet on erotettu politiikoissa, sopimuksissa ja todentavan aineiston rekistereissä.
- Toteuta pöytäharjoitus realistisella skenaariolla, kuten vaarantuneilla tunnistetiedoilla, asiakasympäristöjen välisellä altistumisella, väärään osoitteeseen lähetetyllä palkanlaskentatiedostolla, kadonneella salatulla kannettavalla tietokoneella tai toimittajan vaarantumisella.
Clarysec voi auttaa operationalisoimaan tämän Zenith Blueprint: auditoijan 30 vaiheen tiekartan Zenith Blueprint, Zenith Controls: vaatimustenmukaisuuden viitekehysten välisen oppaan Zenith Controls ja ISO/IEC 27701:2025 -standardin mukaisen PIMS-politiikkakokonaisuuden avulla. Kokonaisuuteen kuuluvat muun muassa Henkilötietopoikkeamien ja tietoturvaloukkausten hallintapolitiikka Henkilötietopoikkeamien ja tietoturvaloukkausten hallintapolitiikka, Tietosuoja- ja yksityisyydensuojapolitiikka Tietosuoja- ja yksityisyydensuojapolitiikka, Tietoturvapoikkeamien hallintapolitiikka pk-yrityksille Tietoturvapoikkeamien hallintapolitiikka pk-yrityksille, Kolmansien osapuolten ja toimittajien tietoturvapolitiikka Kolmansien osapuolten ja toimittajien tietoturvapolitiikka ja Todentavan aineiston keräämisen ja digitaalisen forensiikan politiikka Todentavan aineiston keräämisen ja digitaalisen forensiikan politiikka.
Lataa Clarysecin PIMS-työkalupaketti, varaa tietoturvaloukkausvalmiuden arviointi tai sovi demo, jotta GDPR:n 72 tunnin reagointisi muuttuu sekavasta ryntäilystä kurinalaiseksi, auditointivalmiiksi prosessiksi.
Hanki PECB ISO/IEC 27701 -sertifikaatti ja ota PIMS käyttöön
- ✓ Viralliset PECB-kurssimateriaalit ja kaksi koeyritystä
- ✓ Sertifiointimaksu ja ensimmäisen vuoden AMF sisältyvät, kun sovellettavissa
- ✓ Itseopiskelu tai live-verkkokoulutus · kurssi osoitetaan 1 arkipäivässä
Tietoa kirjoittajasta
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council