Slik velger du et GDPR-trygt CRM-system

Personvern handler om hva dere faktisk gjør med opplysningene, ikke om hvilken programvare dere har kjøpt. Start med en enkel oversikt over behandlingen: hvilke personopplysninger som samles inn, hvor de kommer fra, hvor lenge de skal lagres, og hvem i bedriften som trenger dem for å gjøre jobben. Den oversikten blir kravspesifikasjonen dere bruker når dere senere sammenligner leverandører.

Ta listen sammen med den som faktisk følger opp kunder, ikke bare med den som skal betale for systemet. Dette bør dere få med:

• Hvilke kategorier opplysninger dere lagrer, for eksempel navn, kontaktinfo, adresse, bilder fra befaring og egne notater
• Hvor opplysningene kommer fra: skjema på nettsiden, telefon, e-post eller innkjøpte lister
• Hvor lenge hver kategori skal lagres, og hva som skal skje når lagringstiden er over
• Hvem som skal ha tilgang, og hvem som ikke skal ha det

Fallgruven er å begynne med funksjonslister og selgerdemoer. Da ender mange med et system som har mange felt og mange moduler, men ingen svar på hvor dataene ligger eller hvordan en slettforespørsel håndteres i praksis. Behovsavklaringen bør være ferdig før første leverandørmøte.

Når CRM-et ligger i skyen, er leverandøren databehandler og dere er behandlingsansvarlig. Da trenger dere en databehandleravtale (DPA) som beskriver hva leverandøren kan gjøre med opplysningene, hvilke underleverandører som brukes, hvordan sikkerheten er organisert, og hva som skjer med dataene ved avsluttet avtale.

Spør om lagringssted, ikke bare om leverandøren er norsk. Det som betyr noe er hvor dataene fysisk lagres, hvilke underleverandører som er involvert i drift og support, og om opplysninger overføres ut av EØS. Overføring ut av EØS krever et gyldig overføringsgrunnlag, og leverandøren skal kunne redegjøre for det uten å vise til en generell markedsføringsside.

En lokal løsning på egne servere fjerner ikke ansvaret. Da har dere fortsatt ansvar for sikkerhetskopi, oppdateringer, tilgangsstyring og logging, og dere må kunne dokumentere at det blir gjort. For de fleste små bedrifter er det enklere å kreve at leverandøren dokumenterer dette, enn å bygge det selv.

Still de samme spørsmålene til alle dere vurderer, og be om svarene skriftlig. Da blir sammenligningen reell, og dere har dokumentasjonen liggende når noen spør hvordan dere har vurdert leverandøren:

• Kan dere sende databehandleravtalen før vi bestiller noe?
• Hvor lagres dataene, og hvilke underleverandører er involvert i drift og support?
• Hvordan styres tilganger, og kan vi selv opprette og fjerne brukere?
• Hva logges, hvor lenge, og kan vi lese loggen selv?
• Hvordan lager vi en innsynsrapport for én kunde, og hvordan sletter vi vedkommende?
• Hva skjer med dataene våre hvis vi sier opp avtalen?

Svarene bør komme som dokumenter, ikke som muntlige lovnader i et møte. Be om å få dem tilsendt, slik at de kan legges ved deres egen oversikt over behandlingsaktiviteter.

En vanlig feil er å godta et svar som «systemet er GDPR-godkjent» uten å spørre hva det betyr i praksis. Det finnes ingen merkeordning som gjør jobben for dere. Det er funksjonene, avtalene og rutinene som teller, og de skal kunne vises konkret.

Tilgangsstyring er der personvern feiler oftest i små bedrifter. Sjekk at systemet har roller som gjør at en håndverker i felt ser sine egne jobber, mens regnskap og ledelse ser det de trenger. Alle skal ikke ha tilgang til alt bare fordi det er enkelt å sette opp slik.

Logging er det som gjør at dere kan svare på hva som har skjedd. Dere bør kunne se hvem som har åpnet en kundepost, endret den, eksportert den eller slettet den. Spør også om hvor lenge loggen oppbevares, og om den kan eksporteres hvis dere bytter system.

Mange lekkasjer skjer utenfor CRM-et: noen eksporterer kundelisten til et regneark, deler en brukerkonto mellom flere ansatte, eller glemmer å fjerne tilgang når noen slutter. Systemet kan støtte gode rutiner, men det kan ikke erstatte dem. Lag derfor en kort intern regel for hvem som får tilgang, hvem som godkjenner det, og hva som skjer ved ansettelse og avslutning.

Et system som gjør personvernarbeidet tungt, blir sjelden brukt riktig. Test derfor hvordan rettighetene løses i praksis: kan dere hente ut alt dere har om én person i én oversikt, kan dere rette feil, kan dere slette, og kan dere begrense behandlingen midlertidig? Hvis svaret krever utviklerhjelp eller manuell leting i flere systemer, er det et faresignal.

Samtykke og markedsføring må henge sammen med oppfølgingen. Registrer hvor kontakten kom fra, hva personen samtykket til, og når. Da slipper dere å gjette når noen klager. Dette grenser til det dere gjør på nettsiden, og vi har skrevet mer om GDPR og CRM: slik behandler du kundedata trygt og om regler for nettsider og netthandel: personvern, samtykke og angrerett.

Sletting er sjelden bare sletting. Noen opplysninger må beholdes av regnskapshensyn, og sikkerhetskopier kan ligge et stykke bakover i tid. Spør leverandøren hvordan sletting håndteres i selve systemet, i sikkerhetskopier og hos underleverandører, og skriv ned svaret. Da har dere en forklaring som holder hvis en kunde spør.

Kravene til sikkerhet er skrevet som et krav om egnede tiltak, ikke som en sjekkliste dere kan krysse av. Det betyr at dere må vurdere risikoen ved nettopp deres data. Vi har samlet mer om temaet i GDPR artikkel 32: sikkerhet og kryptering av e-post.

Dette bør dere kreve av leverandøren:

• Sikker innlogging, og støtte for to-trinns pålogging
• Kryptering av data både når de sendes og når de ligger lagret
• Rolletilgang og logging som dere kan lese selv
• Sikkerhetskopi med en rutine for gjenoppretting, ikke bare en påstand om at det tas backup
• En beskrevet rutine for hva som skjer ved sikkerhetsbrudd, og hvem som varsler hvem

Leverandøren dekker bare halve bildet. Resten er deres egne vaner: ingen delte brukerkontoer, ingen kundelister på private telefoner, og en fast rutine for å fjerne tilganger. Et årshjul gjør dette håndterbart, og vi har laget et opplegg i GDPR i drift: årshjul for etterlevelse.

Be om en demo der dere styrer scenarioene. Velg ut noen oppgaver på forhånd: hent opp en kundepost og vis hva som er lagret, lag en innsynsrapport, slett en tenkt kunde, vis loggen for de siste endringene, og vis hvordan en ny ansatt får begrenset tilgang. Da ser dere systemet slik dere skal bruke det, ikke slik det presenteres.

Migrering er en egen risiko. Rens dataene før dere flytter dem, avtal hvilke felt som skal mappes, gjør en testmigrering og verifiser med stikkprøver. Ha en plan for hvordan dere kommer tilbake til utgangspunktet hvis noe går galt. Erfaringen fra mange innføringer er at dårlig datakvalitet og svak bruk blir dyrere enn selve lisensen.

En enkel beslutningsregel kan se slik ut:

• Velg en skybasert løsning hvis dere ikke har egen IT-drift og vil at leverandøren skal dokumentere sikkerhet, backup og tilgangsstyring
• Velg en lokal løsning hvis dere har kompetanse og interne krav til lagring, og kan ta ansvaret selv
• Velg bort leverandøren hvis dere ikke får databehandleravtale, lagringssted eller slettefunksjon skriftlig

Vil dere koble nettside, skjemaer og et kundesystem for oppfølging av henvendelser, kan Nettsaga være et naturlig neste steg. Vi har 4,6 av 5 stjerner på Google fra 35 omtaler, over 1 200 bedrifter har valgt oss, og kundene våre fikk 119 000 kundehenvendelser de siste 12 månedene. Alt samles på ett sted: nettside, Google Bedriftsprofil, oppføringer, omtaler, annonser og kundesystem, med et norsk team i Oslo som jobber med bedrifter i hele landet. Første steg er å booke en demo.