Varje ärende som registreras i ett ärendehanteringssystem innehåller personuppgifter. Namn och e-post på den som skickade in ärendet. Anställningsnummer och arbetsstation i handläggarens noteringar. Ibland personnummer, mobilnummer eller uppgifter om hälsa som letar sig in i fritext. GDPR ställer krav på hur dessa uppgifter behandlas – och ansvaret ligger på den organisation som driver systemet, inte på leverantören.
Den här artikeln redogör för de krav som GDPR ställer på ärendehanteringen: rättslig grund, dataminimering, gallringsrutiner, behörighetskontroll och registrerades rättigheter. Säkerhetskraven överlappar delvis med NIS2, som vi går igenom i artikeln om vad NIS2 innebär.
Varför GDPR träffar ärendehanteringen direkt
Artikel 4 i GDPR definierar behandling som varje åtgärd som vidtas med personuppgifter – insamling, lagring, läsning, ändring och radering. En servicedesk som tar emot ärenden via e-post eller webbformulär och lagrar dem i ett system utför per definition personuppgiftsbehandling.
Det gör ärendehanteringssystemet till ett register i GDPR:s mening, och organisationen som driver systemet – den juridiska personen, inte IT-avdelningen – till personuppgiftsansvarig (artikel 24). Ansvaret innefattar:
- Att fastställa och dokumentera rättslig grund för behandlingen
- Att tillämpa dataminimering och lagringsminimering
- Att säkerställa tekniska och organisatoriska skyddsåtgärder
- Att ingå databehandlingsavtal med systemleverantören
- Att kunna tillgodose de registrerades rättigheter
Vilka personuppgifter behandlas i ett ärendesystem
Ärendesystem samlar personuppgifter i flera lager, varav flera är lätta att förbise:
| Kategori | Exempel |
| Kontaktuppgifter | Namn, e-post, telefon, avdelning |
| Teknisk identitet | Användarkonto, IP-adress, datornamn, IMEI |
| Innehåll i fritext | Fritext i beskrivning och kommentarer – kan innehålla personnummer, hälsouppgifter, löneuppgifter |
| Metadata | Tidsstämplar för inläsning, statusändringar, vem som läst ärendet |
| Bifogade filer | Skärmdumpar, loggar, dokument – kan innehålla känsliga uppgifter |
Fritext är den vanligaste källan till oförutsedd behandling av känsliga uppgifter. En användare som anmäler ett lönesystemsproblem inkluderar ofta sin lönespecifikation i bilaga. En sjukvårdsanknuten IT-organisation ser personnummer i felrapporter. Rutiner och systemkonfiguration kan begränsa detta men eliminerar det inte.
Rättslig grund för behandlingen
GDPR artikel 6 kräver att varje behandling vilar på en av sex rättsliga grunder. För ärendehantering i en arbetsgivarkontext är de relevanta grunderna:
| Rättslig grund | Tillämpning i ärendehantering |
| Fullgörande av avtal (art. 6.1b) | Ärenden som rör anställningsförhållandet – IT-support, HR-ärenden |
| Rättslig förpliktelse (art. 6.1c) | Dokumentationskrav i reglerade branscher (vård, offentlig sektor) |
| Berättigat intresse (art. 6.1f) | IT-drift och säkerhetsövervakning – gäller inte känsliga uppgifter |
| Samtycke (art. 6.1a) | Sällan lämplig grund i arbetsgivar- eller leverantörsrelationer |
En vanlig felbedömning är att basera hela ärendehanteringen på samtycke. Samtycke är per definition frivilligt och kan återkallas – det fungerar inte som rättslig grund när ärendehanteringen är en nödvändig del av IT-driften. Berättigat intresse är den vanligaste grunden för intern IT-support, men kräver en intresseavvägning som dokumenteras i behandlingsregistret (artikel 30). Kommuner och myndigheter kan inte stödja sig på berättigat intresse för behandling som sker när de fullgör sina uppgifter (artikel 6.1 andra stycket) – där är grunden normalt allmänt intresse eller myndighetsutövning (artikel 6.1e).
För känsliga personuppgifter (artikel 9) – hälsouppgifter, facklig tillhörighet och liknande – krävs en av de särskilda grunderna i artikel 9.2. IT-avdelningar i vård och offentlig sektor behöver identifiera om ärendeflöden innehåller sådana uppgifter och säkerställa att artikel 9-grunden täcker dem.
Dataminimering – samla inte in mer än vad som behövs
Artikel 5.1c kräver att personuppgifter är adekvata, relevanta och inte för omfattande i förhållande till ändamålet. Tillämpad på ärendehantering innebär det konkret:
- Inlämningsformulär ska bara fråga efter uppgifter som behövs för att handlägga ärendet. Personnummer behövs sällan för ett IT-ärende.
- Fritextfält utan styrning tillåter mer uppgifter att samlas in än vad som behövs. Strukturerade fält med definierade svarsalternativ minskar risken.
- Automatisk eskalering och routning ska inte baseras på känsliga kategorier om det kan undvikas.
- Bilagor bör ha en policy: vilka filtyper accepteras, lagras de permanent eller gallras de efter handläggning?
Gallringsrutiner och bevarandetider
Artikel 5.1e kräver att personuppgifter inte bevaras längre än nödvändigt. För ärendehantering innebär det att organisationen ska ha en dokumenterad policy för bevarandetider per ärendekategori.
| Ärendekategori | Rekommenderad bevarandetid | Kommentar |
| IT-support (intern) | 12–24 månader | Längre om ärendet rör säkerhetsincident |
| HR-ärenden | Enligt arbetsrättslig praxis (vanligen 2 år efter anställning upphör) | Kräver separat rättslig grund |
| Säkerhetsincidenter | Minst 12 månader (NIS2), upp till 5 år om rättslig process inleds | Överlappa med incidentlogg |
| Leverantörsärenden | Avtalets löptid + 3 år | Kopplas till avtalsdokumentation |
| Ärenden med känsliga uppgifter | Kortast möjliga tid, aktiv gallring | Kräver identifiering och märkning i systemet |
Ärendesystemet ska tekniskt stödja automatisk gallring eller anonymisering efter definierad period – inte kräva manuell handläggning per ärende. Manuella gallringsrutiner är i praktiken rutiner som inte utförs.
Behörighetskontroll och spårlogg
Artikel 32 kräver lämpliga tekniska och organisatoriska säkerhetsåtgärder. För ärendehanteringen innebär det minst:
- Rollbaserad åtkomst: Handläggare ser bara de ärenden som tillhör deras kö eller enhet. Ingen generell ’se alla ärenden’-behörighet för supportrollen.
- Behörighet på ärendenivå: Känsliga ärenden (HR, VD-support, säkerhetsincidenter) ska kunna begränsas till enskild handläggarkrets.
- Spårlogg: Varje åtkomst, statusändring och kommentar loggas med tidsstämpel och användaridentitet. Loggen är oföränderlig och tillgänglig för revision.
- Automatisk avprovisionering: Behörighet tas bort automatiskt när en medarbetare slutar – inte via manuell adminbegäran.
Spårloggen fyller en dubbel funktion: den är ett säkerhetsverktyg och ett dokumentationskrav. Vid en personuppgiftsincident eller tillsynsbeslut ska organisationen kunna redovisa vem som haft tillgång till ett ärende och när.
Databehandlingsavtal med systemleverantören
Artikel 28 kräver att personuppgiftsansvarig ingår ett skriftligt databehandlingsavtal (DPA) med varje personuppgiftsbiträde – inklusive leverantören av ärendehanteringssystemet. DPA:t ska reglera:
- Ändamålet och instruktionerna för behandlingen
- Tekniska och organisatoriska säkerhetsåtgärder
- Eventuell anlitning av underbiträden
- Rutiner för hantering av den registrerades rättigheter
- Rutiner vid personuppgiftsincident – biträdet underrättar den personuppgiftsansvarige utan onödigt dröjsmål, så att anmälan till IMY kan göras inom 72 timmar (artikel 33)
- Geografisk placering av datalagring och tredjelandsöverföringar
Datalagring utanför EU/EES kräver ett av GDPR:s överföringsverktyg (artikel 46): standardavtalsklausuler (SCCs), bindande företagsbestämmelser eller adekvansbeslutet för det aktuella landet. Det räcker inte att leverantören lovar GDPR-compliance – DPA:t ska specificera lagringsland och rättslig mekanism för eventuell överföring.
De registrerades rättigheter i ett ärendeflöde
GDPR kapitel III ger registrerade en rad rättigheter. Ärendehanteringssystemet berörs av flera:
| Rättighet | Innebär i ärendekontext | Tekniskt krav |
| Rätt till tillgång (art. 15) | Anmälare kan begära ut alla uppgifter om sig i systemet | Sökning och export per person |
| Rätt till rättelse (art. 16) | Felaktiga uppgifter ska kunna korrigeras | Redigeringsfunktion utan att revisionsloggen raderas |
| Rätt till radering (art. 17) | Ärenden ska kunna raderas om rättslig grund upphör | Radering per ärende, inklusive bilagor och metadata |
| Rätt till begränsning (art. 18) | Behandlingen kan begränsas medan tvist pågår | Frysning av ärende utan radering |
| Rätt till dataportabilitet (art. 20) | Gäller vid samtycke eller avtal – sällan tillämplig i IT-support | Export i strukturerat format |
Den praktiska utmaningen är att rätten till radering (artikel 17) kolliderar med skyldigheten att bevara spårlogg för säkerhetsincidenter och med arbetsrättsliga bevarandekrav. Organisationen behöver en definierad process: vad raderas, vad anonymiseras och vad bevaras av rättslig förpliktelse?
Hur Nilex stödjer GDPR-efterlevnad
Nilex är ett ärendehanteringssystem med konfigurerbara arbetsflöden och inbyggda kontroller för tillgångsstyrning och spårbarhet:
- Behörighetsstyrning – säkerhetsnivåer anpassas per användare, och vilka tjänster och ärendetyper som visas styrs av användarens behörighet eller avdelning
- Spårbar e-signering – dokument och beslut signeras direkt i Nilex, med spårbarhet genom hela signeringsprocessen
- Arkivering av stängda ärenden – stängda ärenden flyttas automatiskt från den aktiva databasen till ett separat arkiv, så att det dagliga arbetsflödet bara rymmer pågående ärenden
- Datalagring i Sverige – Nilex molntjänst driftas hos partnern Diflex i Ängelholm. Data lämnar inte Sverige och inga tredjelandsöverföringar sker. Driftpartnern är certifierad enligt ISO 27001 och ISO 9001
- Konfigurerbara ärendeformulär – formulär anpassas per avdelning i gränssnittet utan kodning, så att bara de uppgifter som behövs för handläggningen efterfrågas
- Katalogintegration – färdiga kopplingar mot Active Directory, Microsoft Entra ID och ADFS
Nilex ersätter inte organisationens behandlingsregister eller integritetsanalys (DPIA) – det är verksamhetens ansvar att dokumentera behandlingsändamål och rättslig grund. Systemet ger de tekniska förutsättningarna för GDPR-efterlevnad; policy och process är organisationens ansvar.
Läs mer om vad ett modernt ärendehanteringssystem ska klara tekniskt och funktionellt på nilex.se.
Kontakta Nilex
Har ni frågor om hur Nilex konfigureras för att uppfylla er organisations GDPR-krav – kontakta oss för en teknisk genomgång.
