Be de flesta företag om deras register över behandlingar och du får ett av två svar. Antingen en tom blick, eller ett kalkylark som någon byggde för två år sedan och inte rört sedan dess. Båda svaren faller i en granskning, och båda lämnar dig oförmögen att förklara vad du faktiskt gör med personuppgifter.

Registret över behandlingar är det första dokument en tillsynsmyndighet ber att få se. Det är också det som blir inaktuellt snabbast, eftersom din behandling ändras varje gång du lägger till ett verktyg, lanserar en funktion eller tecknar avtal med en ny leverantör. Den här guiden går på djupet med vad registret är, exakt vad som hör hemma i det och hur du håller det aktuellt i stället för att bygga om det i panik.

Vad ett register över behandlingar faktiskt är

Artikel 30 i GDPR kräver att de flesta organisationer för ett skriftligt register över den behandling av personuppgifter de utför. Det är inte en integritetspolicy, som är ett offentligt löfte. Det är inte ett personuppgiftsbiträdesavtal, som är ett kontrakt med en leverantör. Registret är din interna inventering: en strukturerad redogörelse för varje behandling som rör personuppgifter, varför du gör den och hur.

Se det som kartan över ditt datalandskap. En integritetspolicy berättar för omvärlden vad du gör i allmänna ordalag. Registret berättar för dig, exakt, vilka system som håller vilka uppgifter, för vilket ändamål, på vilken laglig grund och vem mer som ser dem. Utan den kartan blir varje annan del av ditt GDPR-program gissningar.

Mindre organisationer antar ibland att registret inte gäller dem. Undantaget för företag med färre än 250 anställda är snävt, och det försvinner i samma stund som din behandling är regelbunden, omfattar särskilda kategorier av personuppgifter eller kan innebära en risk för människors rättigheter. För nästan alla företag som hanterar kund- eller personaldata i någon omfattning är registret obligatoriskt.

Varför registret är grunden för ansvarsskyldigheten

GDPR:s princip om ansvarsskyldighet säger att du måste kunna visa att du följer reglerna, inte bara påstå det. Registret är hur du visar det. Varje efterföljande skyldighet vilar på att du först känner till din egen behandling.

Du kan inte svara på en begäran om åtkomst om du inte vet var en persons uppgifter finns. Du kan inte tillmötesgå en begäran om radering om du inte kan lista varje system som håller den posten. Du kan inte bedöma risken vid en incident inom 72-timmarsfristen om du inte redan vet vilka uppgifter ett drabbat system höll. Du kan inte göra en konsekvensbedömning av en högriskbehandling du aldrig dokumenterat. Registret är källan som matar allt detta.

Därför börjar både revisorer och företagsköpare här. Ett aktuellt och detaljerat register signalerar ett program som har kontroll. Ett saknat eller inaktuellt register signalerar motsatsen, och det förvandlar en rutinmässig säkerhetsgranskning till en djup och skeptisk grävning.

Vad som hör hemma i registret

Artikel 30 anger ett minimum, men ett register som bara når minimum klarar sällan en verklig granskning. Det här bör varje behandling fånga.

Ändamål och laglig grund

Varje behandling behöver ett tydligt ändamål i klarspråk: "hantera kundsupportärenden", inte "drift". Vaga ändamål döljer att omfånget växer. Vid sidan av ändamålet noterar du den lagliga grund du stödjer dig på, oavsett om det är samtycke, avtal, rättslig förpliktelse eller berättigat intresse. Om du åberopar berättigat intresse noterar du den intresseavvägning som motiverar det. Ändamål och laglig grund hör ihop, och ett ändamål utan grund är en lucka en revisor hittar.

Kategorier av registrerade och personuppgifter

Ange vems uppgifter du behandlar, till exempel kunder, anställda, potentiella kunder och webbplatsbesökare, och vilka kategorier av uppgifter varje behandling omfattar, som kontaktuppgifter, betaluppgifter eller användningsloggar. Flagga alla särskilda kategorier, som hälsouppgifter eller biometriska uppgifter, eftersom de bär strängare regler och ofta utlöser en konsekvensbedömning. Att vara specifik här är vad som låter dig besvara en begäran om åtkomst ärligt senare.

Mottagare och tredjelandsöverföringar

Notera vem som tar emot uppgifterna. Det inkluderar interna team, men de som betyder mest är externa: dina biträden, deras underbiträden och eventuella myndigheter. För varje mottagare utanför EU anger du destinationsland och den skyddsåtgärd du förlitar dig på, oavsett om det är ett beslut om adekvat skyddsnivå, standardavtalsklausuler eller bindande företagsbestämmelser. En tredjelandsöverföring utan en namngiven skyddsåtgärd är en anmärkning som väntar på att inträffa.

Lagringstider och säkerhetsåtgärder

För varje behandling anger du hur länge du behåller uppgifterna och vad som utlöser radering. "Så länge det behövs" är ingen lagringstid. Sedan beskriver du de tekniska och organisatoriska säkerhetsåtgärder som skyddar uppgifterna, som behörighetsstyrning, kryptering och pseudonymisering. Det är här registret kopplas till dina faktiska kontroller, och där en revisor kontrollerar om dina papperslöften stämmer med din verkliga praktik.

Register för ansvariga och register för biträden

Artikel 30 definierar två register, och de flesta företag behöver båda.

Som personuppgiftsansvarig bestämmer du varför och hur personuppgifter behandlas, och ditt register täcker ändamålen och de lagliga grunderna ovan. Som personuppgiftsbiträde hanterar du uppgifter på en ansvarigs instruktion, och ditt register är smalare: kategorierna av behandling du utför för varje kund, överföringarna som ingår och dina säkerhetsåtgärder. Du för inte in den ansvariges ändamål, eftersom det inte är ditt att definiera.

De flesta SaaS-bolag bär båda hattarna. Du är ansvarig för dina egna anställda och marknadskontakter, och biträde för kunddatan du lagrar åt dem. Att hålla de två registren åtskilda spelar roll, eftersom en kund som frågar om dina biträdesskyldigheter inte ska få svar som är hopblandade med din interna personalhantering.

Varför kalkylark blir inaktuella och faller i granskningar

Kalkylarksregistret är standardvalet, och det faller av förutsägbara skäl.

Det har ingen ägare, så ingen uppdaterar det när behandlingen ändras. Det lever frikopplat från dina faktiska biträden och bevis, så lagringstiden i cell D14 har ingen länk till leverantören som upprätthåller den. Det fångar ett ögonblick, inte ett levande tillstånd, så när en revisor väl öppnar det beskriver flikarna system du avvecklat och missar de tre verktyg du införde förra kvartalet. Och det kan inte bevisa sig självt: ett kalkylark påstår att du har en skyddsåtgärd för överföring, men det kan inte visa de signerade klausulerna bakom påståendet.

När registret glider ifrån verkligheten glider varje svar som byggts på det med. Så hamnar ett företag i att med självförtroende berätta något för en revisor som slutade vara sant för månader sedan.

Så håller OptiTech registret levande

I OptiTech Console är registret över behandlingar ett strukturerat och sammankopplat register snarare än en statisk fil. Varje behandling är ett objekt kopplat till det som definierar den: ändamålet, den lagliga grunden, kategorierna av uppgifter och registrerade, lagringstiden och säkerhetsåtgärderna.

Kopplingarna är vad som håller det levande. Varje behandling länkar till de biträden den vilar på, och varje biträde bär sitt eget avtal och sin överföringsmekanism. Så när du lägger till en leverantör eller byter ett underbiträde uppdateras de berörda behandlingarna i stället för att tyst glida isär. Lagringstider och säkerhetsåtgärder länkar till de kontroller och bevis som upprätthåller dem, så att registret inte bara påstår en skyddsåtgärd utan pekar på beviset.

Eftersom registret är sammankopplat matar det resten av ditt program automatiskt. En begäran om åtkomst utgår från behandlingarna som håller personens uppgifter. En incidentbedömning utgår från systemen och kategorierna registret redan listar. Och ditt trust center kan lyfta fram de delar köpare bryr sig om, så att en säkerhetsgranskning bygger på samma levande register som din revisor ser.

Kom igång

Du behöver inte dokumentera allt på en gång. En realistisk första omgång ser ut så här:

1. Inventera din mest omfattande behandling först. Börja med systemen som håller flest personuppgifter, som ditt CRM, supportverktyg och personalsystem.
2. Fånga ändamål och laglig grund för varje. Var specifik. Ett tydligt ändamål per behandling slår en vag samlingspost.
3. Kartlägg biträden och överföringar. Koppla varje behandling till sina biträden, och namnge en skyddsåtgärd för varje överföring utanför EU.
4. Länka lagring och säkerhet till verkliga kontroller. Koppla varje behandling till beviset som styrker skyddsåtgärden, inte bara en beskrivning av den.

Bygg registret en gång, håll det sammankopplat, så slutar det vara artefakten du bävar för och blir den du sträcker dig efter. För mer om att driva GDPR som ett levande program, se resten av vår blogg.

Redo att byta ut det inaktuella kalkylarket mot ett levande register? Boka en demo och se hur OptiTech kopplar dina behandlingar till ändamål, biträden och bevis.