GDPR + ITIL = Sant

För många känns kanske GDPR som ett högt berg man måste ta sig över. Men för er som jobbat med ITIL, information technology infrastructure library, känns nog GDPR mer som en kulle ni redan promenerat över flera gånger tidigare.

GDPR + ITIL = Sant! Hur menar jag nu?

När allt kommer omkring så handlar GDPR om att ta fram processer och sedan följa dem. Precis på samma sätt som när man t.ex. definierar hur man sätter upp en arbetsplats åt en nyanställd. Personen ska ha en stol och ett skrivbord, en dator som passar arbetsuppgifterna, konton för att kunna logga in osv. Har man tydliga och detaljerade rutiner för detta så kan vem som helst leverera en arbetsplats åt en ny kollega. Man vet vart man beställer möbler från, vilken datorutrustning personen behöver och vilka system denne behöver komma åt. På samma sätt kan man applicera detta så att vem som helst kan hantera en begäran om att en person vill få sina personliga uppgifter utlämnade eller raderade. Förutsatt att man har tillräckligt bra processer för det såklart.

Så var börjar man om man ska bestiga ett berg?

Jo, helt enkelt genom att bryta ner kraven steg för steg. Precis som när du skapar en process i ITIL, tills du kommit tillräckligt långt ner för att kunna skriva ett par någorlunda korta men detaljerade rutiner. Jag tänkte illustrera likheterna genom att bryta ner ett krav från GDPR och en vanlig IT-tjänst parallellt.

De två förutsättningarna är följande

GDPR säger att vi behöver kunna radera all personlig information om en person på begäran. Detta ska kunna utföras inom en viss tidsram och med tillräckligt hög precision för vi ska vara i stort sett hundra procent säkra på att informationen eliminerats.
IT-avdelningen behöver tillhandahålla en tjänst så att en anställd kan skicka och ta emot e-post. En beställning av denna tjänst ska kunna levereras snabbt, kostnadseffektivt och konsekvent. Tjänsten som sådan ska vara lättförståelig, tillförlitlig och uppfylla användarens behov.

Vi börjar med några grova skattningar

För att kunna radera information måste vi veta vilken typ av information vi ska radera och var den finns. Först måste vi definiera typen av information som berörs, i detta fall allt som kan identifiera en person eller som tillsammans med annan information kan identifiera en person. Sedan måste vi veta var informationen finns.
Här behöver vi definiera när samt från var e-posten skall vara tillgänglig. Att den är tillgänglig mer eller mindre dygnet runt låter rimligt och även att man kan komma åt den varifrån som helst där internet finns.

Vi är redan en bit på väg men nu bryter vi ner det ett steg till

Vilken personlig information företag hanterar är väldigt olika. I det här exemplet säger vi att det är följande: personnummer, namn och alla sorters adresser. Dessa förekommer i företagets CRM-system, både i de avsedda fälten men också som fritext. De kan även finnas i e-post hos olika användare, i företagets dokumentsystem, på personliga datorer och i chatloggar.
Det kommer behöva utföras visst underhåll av epostsystemet. En timme per vecka är det i exemplet ok att det ej är tillgängligt, förutsatt att det är utanför kontorstid och att användarna meddelas i förväg. För att komma åt e-posten behöver användarna en e-postklient, både på datorn och i mobiltelefonen samt i nödfall tillgång till en webbaserad klient.

Nu börjar vi närma oss, vi tar ett steg till och ser var vi hamnar

Att spara information på många ställen är ganska opraktiskt när vi behöver leta rätt på den. Det bästa vore helt klart att begränsa antalet ställen samt endast lagra information där det är lätt att hitta den. Vi inför en policy som talar om att den anställda inte får lagra personlig information på sina privata datorer, inte använda fritextfält i CRM-systemet samt inte skriva personlig information i chatten. I CRM-systemet vet vi nu vilka fält vi behöver kunna radera eller anonymisera så det kan enkelt göras manuellt. För övrig information behöver vi ett sökverktyg.
Att använda Office 365 minimerar tiden för underhåll samtidigt som användarna får tillgång till sin e-post var som helst både i Outlook och via ett webbaserat gränssnitt. Det vi behöver göra för att tillhandahålla e-posttjänsten till användarna är helt enkelt att skapa ett konto i Office 365 och tilldela en licens för e-post. För att allt ska funka smidigt bör vi ta fram en standard för användarnamn, e-postadress, vilka säkerhetsregler som ska gälla och policys/regler för användandet.

Nästan i mål, då är det dags att titta på lite detaljer

Vi ska nu börja utforma processerna, identifiera vilken funktion som ska utföra dem och se till att funktionen både har rättigheter, kunskap och verktyg för att utföra arbetet.

Genom att använda tjänsten eDiscovery i Office 365 så kan vi leta igenom all e-post och alla dokument i SharePoint för att se var informationen lagras. IT-avdelningens servicedesk/support känns som en ganska naturlig mottagare av förfrågningarna, men de kanske inte utför själva arbetet då det kräver tillgång till stora mängder av känslig information. Vi bestämmer därför att de ska eskalera ärendet till avdelningen som jobbar med IT-säkerhet. Här tar de mer detaljerade instruktionerna vid som förklarar var i CRM man ska leta efter informationen, hur man gör sökningar med hjälp av eDiscovery, om informationen skall raderas eller anonymiseras och hur man rapporterar tillbaka till personen som vill ta del av uppgifterna.
I ITIL så använder man sig av en metod som kallas RACI. Det står för: Responsible (vem som utför uppgiften), Accountable (vem som ansvarar för att uppgiften blir utförd), Consulted (en person som kan ha viktig information gällande ärendet), Informed (någon som behöver informeras om att uppgiften blivit utförd). Genom att tydligt dela upp vem som ska göra vad så minimeras risken att saker faller mellan stolarna eller att oklarhet uppstår om vem som ska göra vad. I detta exempel så kan IT-avdelningens servicedesk ansvara för att skapa kontot enligt fastslagna regler. Supportchefen kontrollerar att allt satts upp korrekt, att processdokumentationen hålls uppdaterad samt att mätvärden rörande effektivitet loggas. Den nyanställdes chef ska konsulteras för att säkerställa att personen faktiskt ska ha ett e-postkonto (om densamma inte beställt kontot). Slutligen ska också Ekonomiavdelningen informeras då de ska betala licensen för användaren.

Summering av exemplet

Som ni kan se är likheterna mellan hur man tacklar GDPR och uppförandet av en ny IT-tjänst ganska likartade och jag ser stora fördelar med att samtidigt som ett företag förbereder sig för GDPR även börja se över sina övriga processer. Och har man väl tagit till sig tänket som ITIL medför sitter det dessutom i ryggmärgen att använda sig av en stödprocess som kallas Deming Cycle. Den innebär att man kontinuerligt utvärderar alla processer för att se om man kan göra dem effektivare. Då slipper man bestiga berg gång på gång och kan lättare ta sig över de små kullarna!

Till sist

Även om GDPR kanske inte är något som direkt ligger under IT-avdelningen så kan ITIL appliceras på det då likheterna med en IT-tjänst är så pass stora. Och eftersom jag arbetar med Dynamics 365 så tänkte jag avsluta med något som många säljare nog känner igen: ett enkelt processflöde för att ta sig från start till mål. Dock är detta inte en säljprocess, utan en GDPR-process.