ERP Databeskyttelse: SAP Business One Guide

Et ERP samler præcis de data, der er særligt følsomme ved en databeskyttelsesrevision: kundeadresser, kontaktpersoner, lønoplysninger, bankforbindelser, ordrer, reklamationer og brugerlogfiler. En ERP-databeskyttelsesvejledning skal derfor kunne mere end blot at henvise til GDPR. Den skal vise, hvem der ser hvilke data i hverdagen, hvorfor det er nødvendigt, og hvordan du styrer det pålideligt - uden at blokere dine processer med bureaukrati.

I SAP Business One er dette godt løst, hvis databeskyttelse ikke først lander på en lang opgaveliste efter go-live. Rettigheder, opbevaringsfrister, grænseflader og brug af AI bør fra starten indgå i systemarkitekturen. Det sparer dig for senere ombygninger, diskussioner med revisorer og frem for alt unødvendige risici.

ERP Databeskyttelsesvejledning: Hvad der skal beskyttes i systemet

Databeskyttelse i ERP vedrører ikke kun åbenlyse personaledata. Allerede en kundedatabase med navn, forretnings-e-mailadresse og lokalnummer indeholder personoplysninger. Det samme gælder leverandørkontakter, kontaktpersoner i tilbud, data fra enkeltmandsvirksomheder, rejseudgiftsbilag eller tildeling af en sag til en medarbejder.

Det afgørende er formålet. Dit salgsteam har brug for kontaktdata for at følge op på tilbud. Regnskabsafdelingen har brug for bankdata for at betale regninger. Lageret har som regel ikke brug for lønoplysninger eller åbne personaleforhold. Databeskyttelse betyder her ikke at gøre data ubrugelige. Det betyder at begrænse deres anvendelse forståeligt til den respektive forretningsproces.

I SAP Business One tilføjes yderligere dataniveauer: dokumenter og vedhæftninger, brugerkonti, ændringslogfiler, individuelle felter, rapporter samt data fra add-ons og tilsluttede systemer. Især selvoprettede felter overses ofte. Hvis der står private telefonnumre, fødselsdata eller noter om kreditværdighed, gælder de samme regler som for stamdata i standarden.

Ikke alle oplysninger kræver samme beskyttelsesniveau

En leveringsadresse for en virksomhed skal vurderes anderledes end en sygemelding eller en naturlig persons bankforbindelse. Alligevel bør dit team ikke skulle foretage juridiske individuelle vurderinger for hver datasæt. Praktisk er en klar opdeling: generelle forretnings- og kontaktdata, finansielle data, personaledata og særligt beskyttelsesværdige data.

Fra denne opdeling følger passende beskyttelsesforanstaltninger. For fortrolige personaledata har du brug for betydeligt strammere tilladelser end for en forretningskundes adresseoplysninger. Hvis der behandles særlige kategorier af personoplysninger, såsom sundhedsdata, er en særlig omhyggelig vurdering nødvendig. I tvivlstilfælde hører disse oplysninger ikke hjemme i et frit tilgængeligt ERP-felt.

Klare ansvarsområder inden projektet

For din behandling i ERP er du som virksomhed som regel ansvarlig. Din SAP-partner, hostingudbyder eller operatør af en tilsluttet AI behandler derimod ofte data på dine vegne. Disse roller skal være klart dokumenteret, før produktive data flyder.

Dette inkluderer en databehandlingsaftale, hvis en tjenesteudbyder behandler personoplysninger for dig. Aftalen alene løser dog ikke et databeskyttelsesproblem. Du bør også vide, hvor data behandles, hvilke underleverandører der er involveret, hvordan adgange sikres, og hvordan en sikkerhedshændelse rapporteres.

Grænseflader kræver særlig opmærksomhed. Et ERP er sjældent alene: butik, forsendelsestjenester, dokumenthåndtering, finansbogføring, tidsregistrering eller CRM udveksler data. Hver grænseflade udvider angrebsfladen og skaber et yderligere sted, hvor ansvarsområder, datamængde og sletningskoncept skal afklares. Den bedste tilladelse i ERP hjælper lidt, hvis en eksport ukontrolleret lander i en fælles mappe.

Hvis data behandles uden for Det Europæiske Økonomiske Samarbejdsområde, skal du yderligere kontrollere det juridiske grundlag for tredjelandsoverførslen. Det er ikke et spørgsmål om virksomhedens størrelse. Selv en start-up med tre brugere skal vide, hvor deres kundedata og dokumenter teknisk set ender.

Tilladelser: Mindre adgang, mindre risiko

Den hyppigste fejl er bekvem, men dyr: Alle får omfattende rettigheder, så ingen skal vente på godkendelser. Derved ser medarbejdere data, som de ikke har brug for i deres arbejde, og fejl kan senere næppe spores.

Opret roller efter opgaver, ikke efter personer. En medarbejder i salg har brug for andre funktioner end en person i regnskab eller på lageret. Særligt kritiske er rettigheder til at ændre bankforbindelser, til at bogføre og annullere, til at eksportere store datamængder samt til brugerstyring.

En fornuftig rettighedskontrol besvarer fire spørgsmål: Hvem må læse data? Hvem må ændre dem? Hvem må eksportere dem? Hvem må tildele rettigheder? Denne kontrol bør ikke kun finde sted ved go-live. Roller ændrer sig, medarbejdere skifter afdelinger eller forlader virksomheden. En deaktiveret brugerkonto på den sidste arbejdsdag er ikke en detalje, men en grundkontrol.

Også administratoradgange fortjener faste regler. De er nødvendige for drift, support og fejlanalyse, men bør begrænses til få personer, være sporbare og tidsmæssigt så snævre som muligt. Ved ekstern support er en reguleret fjernadgang bedre end permanent åbne konti. Så forbliver hjælp hurtigt tilgængelig, uden at du mister kontrollen.

Opbevaring, sletning og sikring - uden modstrid

Mange virksomheder hører kun ved sletningsforpligtelser: Data skal væk. I ERP er det mere kompliceret. Handels- og skatteretlige krav kræver, at fakturaer, bogføringer og visse forretningsdokumenter forbliver sporbare i årevis. At slette en kundekonto, selvom der stadig findes opbevaringspligtige dokumenter, ville være den forkerte vej.

Den praktiske løsning er et sletnings- og opbevaringskoncept. Det fastlægger, hvilken datakategori der opfylder hvilket formål, hvor længe informationen er nødvendig, og hvad der derefter sker. Ofte betyder det ikke straks sletning, men først at spærre eller anonymisere. En tidligere kontaktperson må for eksempel ikke længere bruges til markedsføringsformål, mens hans data fortsat teknisk set kan være til stede i et opbevaringspligtigt fakturadokument.

Backups er en anden særtilfælde. De beskytter dig mod nedbrud, ransomware og forkerte ændringer, men indeholder ofte historiske personoplysninger. Definer derfor opbevaringstider, krypter sikkerhedskopier og begræns adgangen. En gendannelse må ikke føre til, at længe fjernede brugerkonti eller udløbne tilladelser ubemærket bliver aktive igen.

Databeskyttelse ved dokumenter, bilag og mobiladgang

Indgående fakturaer, følgesedler og kontrakter indeholder regelmæssigt navne, kontooplysninger og kontaktoplysninger. Når PDF’er vedhæftes til SAP Business One eller behandles gennem automatisk dokumentgenkendelse, kontrollerer du ikke kun ERP-serveren. Relevante er også e-mail-indbakker, midlertidige lagre, scannere, godkendelsesprocesser og behandlingen af den respektive tjeneste.

Mobiladgang og arbejde hjemmefra er ikke en udelukkelsesgrund. De kræver kun klare tekniske regler: multifaktor-login, sikrede enheder, opdaterede systemer og ingen ukontrolleret download af fortrolige lister til private enheder. Om en forskrift skal være streng eller moderat afhænger af datatypen, risikoen og arbejdsmetoden. For regnskabsafdelingen gælder forståeligt højere krav end for en generel produktkatalog.

AI i ERP: Databeskyttelse afgøres ved arkitekturen

AI kan konkret spare tid i ERP: indfange dokumenter fra PDF’er, forespørge informationer via chat eller forberede tilbagevendende trin. Men netop her opstår de spørgsmål, der med rette bremser mange virksomheder: Hvilken model behandler forespørgslen? Gemmes indtastninger eller bruges til træning? Forlader indholdet dit netværk? Hvilke data må en AI-agent overhovedet læse eller ændre?

Der er ikke et generelt svar. Hvis medarbejdere kun forespørger anonymiserede nøgletal, er risikoen anderledes end med en AI, der evaluerer kundejournaler, åbne fordringer eller personaledata. Det afgørende er, at du vurderer dataflowet pr. anvendelsestilfælde og ikke kun overfladen af løsningen.

For følsomme ERP-data bør arkitekturen tilbyde valgmuligheder: en model hostet i Tyskland, brugen af en egen API-nøgle eller en fuldstændig lokal model i dit eget netværk. RConsult implementerer denne tilgang i AI-løsninger til SAP Business One praktisk. Så kan du bruge AI produktivt uden blindt at give løn-, finans- eller kundedata til en ekstern tjeneste.

Derudover har en AI-agent brug for de samme grænser som en medarbejder. Han må kun få adgang til de data, der er nødvendige for hans opgave. Skrivehandlinger - såsom oprettelse af et dokument eller ændring af stamdata - bør være sporbare, godkendte og klart adskilt fra rene forespørgsler. Hastighed er værdifuld, ukontrolleret automatisering er det ikke.

Den kontrollerbare standard i stedet for databeskyttelse på anmodning

En god databeskyttelsesproces skal fungere i hverdagen, selv når databeskyttelsesrådgiveren ikke står ved siden af. Dokumenter derfor dataflows, roller, anvendte tjenesteudbydere, sletningsfrister og tekniske foranstaltninger, så dit team kan arbejde med det. En fortegnelse over behandlingsaktiviteter er ikke en arkiveringspligt, men et kort over din databehandling.

Planlæg også faste kontroller: ved nye add-ons, nye grænseflader, en HANA-migration, et partnerbytte eller starten på en AI-anvendelsestilfælde. Især efter migrationer er det værd at se på overtagne brugere, gamle tilladelser og ikke længere nødvendige datafelter. Voksende systemer bringer ofte med sig gamle byrder, som ingen med vilje har skabt.

Databeskyttelse i ERP bliver håndterbar, når du behandler den som en forretningsproces: med klare ansvarlige, faste regler og en teknologi, der virkelig håndhæver dine krav. Så forbliver SAP Business One et værktøj til hurtigere afslutninger og bedre beslutninger - ikke den næste kilde til Excel-lister, særfremskrivelser og ubehagelige overraskelser.