Tutustu raportointitoimintoihin ennen kuin valitset säätimiä
GDPR -analyysi koskee käsittelytoimintaa, ei pelkästään a DMARC -tietue. Selvitetään, kuuluvatko asianomainen rekisterinpitäjä tai käsittelijä ja toiminta asetuksen aineelliseen ja alueelliseen soveltamisalaan. EU:n sijoittautuminen ja tietyt unionissa oleville ihmisille suunnatut toimet ovat 2 ja 3 artiklan mukaisia eri sovellettavuuspolkuja. Sen enempää eurooppalainen vastaanottajan osoite kuin ulkomainen isäntäpaikkakaan eivät ratkaise kysymystä yksinään. GDPR on ollut voimassa 25. toukokuuta 2018 alkaen; EUR-Lex-merkintä ja siihen linkitetty konsolidoitu teksti tarkistettiin 8.11.2026. GDPR n ensisijainen teksti.
Kuvaile, miksi organisaatio haluaa raportteja, kuka ne vastaanottaa, mitä päätöksiä ne tukevat ja tarvitaanko viestitason näyttöä. Erillinen verkkotunnuksen tietoturvatutkimus työntekijöiden valvonnasta, asiakasprofiloinnista tai asiaankuulumattomasta analytiikasta. Raportointiominaisuuden saatavuus ei oikeuta kaikkia mahdollisia tulostensa käyttöä. Yksityisyyden omistajan tulee hyväksyä tarkoitus ja sovellettava oikeusperusta ennen uuden käsittelyjärjestelyn alkamista.
Erota koostetut kentät viestin sisällöstä
RFC 9990 määrittää koosteraportoinnin verkkotunnustason todennustietojen avulla. Sen skeema sisältää yhdistävän sähköpostipalvelimen IP-osoitteen, viestimäärät, käytännön arvioinnin ja tekijä-verkkotunnuksen tunnisteet; jotkin kirjekuorialueen kentät ovat valinnaisia. Tietosuojaosio kuvaa tätä raportointimallia siten, että se ei sisällä yksittäisiä käyttäjäosoitteita, yksittäisiä IP-osoitteita ja viestien sisältöä. Älä kerro lukijoille, että se on mukautettu kokonaisraportti sisältää välttämättä vastaanottajan täyden postilaatikon tai alkuperäisen viestin. Aggregaattiraportoinnin määritys.
Toimintakatselmuksessa on kuitenkin tarkastettava varsinainen syöttö ja käsittely. Myyjä voi rikastaa ennätys, lisätä tilitietoja, säilyttää ladattuja viestinäytteitä tai yhdistää raportteja muihin lokeihin. Tietosuojakysymys koskee sitten sitä todellista tietojoukkoa ja sen tunnistettavuutta, ei vain standardin tarkoitettua skeemaa. Dokumentoi väärin muotoillut tai odottamattomat kentät sen sijaan, että käsittelet niitä hiljaa valtuutettuna kokoelmana. Kenttä, jonka nimi on source_ip, tulee tulkita sen raportointikontekstissa, ei automaattisesti yksittäisen loppukäyttäjän osoitteeksi.
Vikailmoitukset vaativat erilaisen arvioinnin. RFC 9991 sallii yksityiskohtaiset tiedot epäonnistuneista viesteistä ja selittää, että raportit voivat paljastaa otsikot, osoitteet, sisällön ja aiemmin piilotetut edelleenlähetyskohteet. Sen yksityisyysosio kehottaa kontrolloituja kohteita, minimointia ja rajoitettua diagnostiikkaa. Muokkaus voi vähentää altistumista poistamatta kaikkia tunnistetietoja. Vastaanottajat voivat rajoittaa tai hylätä tämän raportoinnin; pyynnön julkaiseminen ei takaa vastaanottamista. Virheilmoitusten määrittely.
Määritä laillinen tarkoitus ja käsittelysuhde
Kun henkilötietoja käsitellään, kirjaa valitut 6 artiklan perusteet ja sitä tukevat perustelut. Turvallisuustarkoitukset eivät automaattisesti luo suostumusta tai oikeutettuja etuja. EDPB:n ohjeissa kuvataan todellisen, laillisen edun tarvetta, tarpeellisuutta ja tasapainoa yksilöiden oikeuksiin silloin, kun oikeutettuihin etuihin vedotaan. Viranomaiset eivät voi käyttää 6 artiklan 1 kohdan f alakohtaa käsittelyyn tehtäviään suorittaessaan. Hanki asianmukainen oikeudellinen arviointi sen sijaan, että valitset perusteen ohjelmistovalikosta. EDPB:n laillisen käsittelyn ohjeet ja GDPR artikla 6.
Kartoita kunkin osapuolen todellinen rooli: vastaanottava sähköpostipalvelu, verkkotunnuksen omistaja, raportoinnin prosessori, tuen tarjoaja ja kaikki myöhemmät vastaanottajat. Rekisterinpitäjän ja käsittelijän merkinnät riippuvat siitä, kuka määrittää tarkoitukset ja keinot ja kuka toimii kenen ohjeiden mukaan. Jos sovelletaan artiklaa 28, käsittelysopimuksessa on mainittava vaaditut ohjeet ja takeet. Raportoivan postilaatikon DNS valtuutus ei ole tietojenkäsittelysopimus tai hyväksyntä asiaan liittymättömään jatkokäyttöön.
Suunnittele pääsy ja säilyttäminen tarpeen mukaan
Artikla 5 edellyttää minimointia ja varastoinnin rajoittamista, kun taas 25 ja 32 artikla koskevat suojaavaa suunnittelua ja riskinmukaista turvallisuutta. Käytä näitä varsinaiseen raporttiputkeen: vastaanottopostilaatikko, jäsentäjä, kojelauta, vienti, tukiliput ja varmuuskopiot. Anna kullekin valtuutetulle roolille vähiten sen tehtävän tarvitsemaa tietoa. Yhdistelmätuonnin vianmääritystä tekevä tukiinsinööri ei tarvitse automaattisesti muokkaamatonta epäonnistuneen viestin liitettä. GDPR konsolidoitu teksti.
Ei ole olemassa universaalia DMARC tämän artikkelin ilmoittama säilytysaika. Aseta jokaiselle tietojoukolle ja tarkoitukselle perusteltu ajanjakso, ja kaikki lain edellyttämät säilytystoimenpiteet harkitaan erikseen. Määritä, milloin poisto tapahtuu, kuinka vienti ja kopiot katetaan ja kuka vahvistaa prosessin. Testaa hyväksytty käyttäytyminen turvallisilla kalusteilla ennen kuin luotat siihen. Käyttöliittymässä näkyvä säilytysarvo ei ole todiste siitä, että jokainen varmuuskopio tai tukiliite noudattaa tätä arvoa.
Tutki siirrot ja riskinotto
Tallenna säilytys- ja käyttöpaikat, alihankkijat ja edelleen tiedot. Jos siirtoon sovelletaan lukua V, vastuullisen tarkastajan on määritettävä asianmukainen siirtoreitti ja suojatoimet. Salaus on suoja, ei automaattinen korvaaminen siirron arvioinnille. EU-aluetunnus ei kuvaa kaikkea etäkäyttöä tai tukikäsittelyä ilman lisätodisteita. GDPR -siirtosäännökset.
Harkitse, aiheuttaako ehdotettu toimenpide todennäköisesti suuren riskin, mikä edellyttää 35 artiklan mukaista tietosuojavaikutusten arviointia. Epäonnistuneen ilmoituksen sisältö, laajuus, arkaluontoiset tiedot ja yhdistelmä käyttäytymistä koskevien tietokokonaisuuksien kanssa voivat vaikuttaa arviointiin. Älä määritä jokaista koontiraporttien käyttöönottoa DPIA:n alaisiksi tai vapauta jokaista suojaustyökalua. Avoimuus, yksilöiden oikeudet ja tapausten käsittely vaativat myös yksityisyyden omistajan huomion varsinaisessa palvelusuunnittelussa.
Valmista kuvitteellinen kenttäkartta keksimättä hyväksyntää
Kuvitteellisessa organisaatiossa rutiininomaiset aggregaattiraportit menevät tietoturvan kojelautaan, kun taas satunnaiset diagnostiset näytteet joutuisivat tukijonoon. Ehdotettu kartta tallentaa vakiokokoiset kentät erillään mahdollisesta koko viestin sisällöstä, nimeää aiotut vastaanottajat ja jättää laillisen perusteen hyväksynnän, käsittelijän ehdot, siirron arvioinnin ja säilytyksen hyväksymisen täyttämättä. Tätä esimerkkiä varten ei kerätty raporttia tai tarkastettu asiakastietoja.
Tarkka käyttöönottovaatimus on: Kartoita todelliset raporttikentät ja käsittelysuhteet tietosuojatarkistusta varten. Tämä paketti tarjoaa ehdotetun kenttä- ja suhdekartan, ei varsinaista käyttöönottotodistetta. Ennen käyttöönotto- tai vaatimustenmukaisuusvaatimusten esittämistä omistajan on toimitettava valtuutetut näytteet tai kaaviot, vahvistetut vastaanottajat ja sopimussuhteet, käyttö- ja poistotodisteet sekä tietosuoja-asiantuntijan arvio. Myös tekniset pk-yritykset, tuotantoreitti, visuaaliset ja julkaisuportit ovat auki. Mitään raportteja ei ole otettu käyttöön, ladattu, siirretty tai poistettu, eikä EmailAuth tietosuojaominaisuuksia ole vahvistettu.