Hvilke risici bør du undersøge hos en softwareleverandør?

Risici, der først viser sig efter underskrift

En demo kører på et rent datasæt: intet mangler, ingen sensor er offline, og ingen bruger har skrevet noget uventet.

Risiciene efter underskrift ligger et andet sted: i hændelser systemet ikke opdager, i hvordan data flyttes ud igen, og i hvad leverandøren gør med persondata.

En analyse af udendørs IoT-overvågning beskriver mekanismen præcist: platformen kan vise grønt, mens problemet vokser på den anden side af muren. Infrastrukturen er designet indefra og ud og stopper reelt ved ydermuren. Den falske tryghed er en risiko i sig selv, ikke et teknisk tilvalg.

Vurderingen bør dække seks områder, som sjældent står på en funktionsliste: omdømme og referencer, persondata og logning, dækning og blinde vinkler, tilgængelighed og fejlhåndtering, integration og interoperabilitet samt hvordan I kommer ud igen.

Skriv svarene ned undervejs. De bliver både beslutningsgrundlag og senere bilag til kontrakten.

Sådan undersøger du risici hos en softwareleverandør

Omdømme, anmeldelser og referencer

Første skridt i at spotte en useriøs softwareleverandør er ifølge en gennemgang af emnet at vurdere omdømmet via anmeldelser, kundeudtalelser og referencer.

Tag omdømmet, før I bruger tid på arkitektur og datamodeller. Dårlige svar her gør de tekniske spørgsmål mindre relevante.

Gør referencerne konkrete i stedet for bekræftende. Bed om navne på kunder, der har opsagt eller skiftet leverandør – ikke kun dem, leverandøren selv fremhæver.

Spørg, hvad der gik i stykker, hvor hurtigt det blev løst, og hvad reaktionstiden var uden for normal arbejdstid. Spørg også, om priser eller vilkår er ændret undervejs, og hvordan det blev håndteret.

Læs anmeldelser på flere uafhængige kilder, og læg mærke til datoen. Gamle roser siger intet om den version, I køber.

Omdømme handler også om, hvem der kan bære et flerårigt forløb. Undersøg ejerforhold, hvor udviklingen foregår, og om nøglepersoner er ansatte eller eksterne konsulenter.

En leverandør, der ikke klart kan svare på, hvem der ejer selskabet og vedligeholder produktet, er svær at holde ansvarlig, når noget skal rettes.

Persondata, logning og informationssikkerhed

Start med at kortlægge, hvilke oplysninger løsningen faktisk indsamler og gemmer – ikke hvilke den har brug for.

Spørg til feltniveau, metadata, IP-adresser og sessionsdata, hændelses- og adgangslogs, opbevaringsperioder, hvor data fysisk ligger, og hvilke medarbejdere hos leverandøren der kan se dem.

Logning kan være nødvendig for drift og sikkerhed, men er også en selvstændig datamængde. En analyse af udendørs IoT peger på GDPR-hensyn ved perimeter-logning.

Bed om leverandørens informationssikkerhedspolitik og politik for behandling af persondata, og læs dem som styringsdokumenter.

Designskolen Kolding offentliggør eksempelvis informationssikkerhedspolitikker, hvor institutionen følger de love og krav, der følger af databeskyttelsesforordningen, også kaldet GDPR.

Spørg, hvornår politikkerne sidst er revideret, hvem der har godkendt dem, og hvordan de omsættes til konkrete kontroller.

Praktiske forhold bør på skrift: databehandleraftale med opdateret underleverandørliste, varsling ved brud og hvem der varsler hvem, procedurer for sletning og tilbagelevering ved ophør samt hvordan adgang styres og logges hos leverandøren selv – herunder udviklernes adgang til produktionsdata.

Afklar også, om jeres data bruges til modeltræning, produktudvikling eller benchmarking. Det er sjældent synligt i en demo, men svært at trække tilbage bagefter.

Vigtige data- og sikkerhedsindikatorer for softwareleverandører

Dækker løsningen virkeligheden – eller kun det, der er let at måle?

Gå ud fra, at det, der ikke overvåges eller registreres, heller ikke opdages.

I bygnings-IoT er mønsteret velbeskrevet: platformene er bygget indefra og ud, kortlægger rum og etager præcist og stopper reelt ved ydermuren.

Klimaskærmen og perimeteren – tag, facade, vinduer, fundamenter, adgangspunkter, teknikskure og udendørs installationer – er netop der, hvor vejr, fugt og adgangshændelser viser sig først. Her er sensordækningen ofte fraværende eller utilstrækkelig.

Tre hændelsestyper forbliver ifølge samme analyse uregistrerede uden dedikeret overvågning udendørs. Vandindtrængning begynder typisk i tagkonstruktionens samlinger eller facadefuger og kan stå på i måneder, inden fugt viser sig indendørs.

Uautoriseret adgang via teknikindgange, nødudgange eller leveringsporte efterlader ikke spor i systemer, der kun overvåger indendørs bevægelse.

Energitab gennem klimaskærmen kan ikke kvantificeres uden temperaturmålinger på begge sider af konstruktionen.

Konsekvenserne er forsikringsskader, der kunne forebygges, driftsafbrydelser uden varsel og energioptimering på ufuldstændige data.

Omsæt det til tre krav til leverandøren. Først: tegn dækningen ind på jeres eget anlæg, punkt for punkt, i stedet for at vise en principskitse. Dernæst: bed om en liste over hændelsestyper, systemet ikke kan registrere. Til sidst: afklar, hvad der sker, når en sensor er offline eller rapporterer urealistiske værdier – hvem opdager det, hvor lang tid tager det, og hvordan ser det ud i grænsefladen.

Forsigtighed ved IoT-overvågning uden ydermursdækning

Tilgængelighed, sprog og fejlhåndtering

Tilgængelighed er en effektiv prøve på håndværket, fordi den kan måles.

Formize.ai's gennemgang af tilgængelige formularer fremhæver WCAG 2.2 som rettesnor og peger på, at mange jurisdiktioner håndhæver WCAG-overholdelse for offentligt tilgængeligt digitalt indhold. Manglende overensstemmelse kan føre til bøder og retssager.

Samme gennemgang nævner, at personer med handicap udgør 15 % af verdens befolkning. Udelukkelse af brugere indfører bias; inkluderende formularer giver mere repræsentative indsigter.

Konkrete ting at efterprøve i brugerfladen: felter har sigende ARIA-egenskaber som aria-label og aria-describedby, så skærmlæsere giver klar kontekst.

Der bruges semantisk HTML5 med fieldset, legend og label, hvilket forbedrer navigationen for hjælpemidler og forenkler tastaturinteraktion.

Farvekontraster vurderes mod WCAG AA/AAA-tærskler. Fejl beskrives inline, knyttes til det pågældende felt via aria-live="assertive" og formuleres i letforståelige beskeder.

Har formularen stem-input, bør speech-attributten være sat på de relevante felter.

Sprog og fejlhåndtering er datakvalitet. Kan brugerfladen ikke betjenes med tastatur alene, eller bliver fejl ikke annonceret for en skærmlæser, ved brugeren ikke, hvad der skal rettes. Resultatet er manglende eller forkerte svar, og beslutningsgrundlaget bliver skævt.

Bed om en dansk sprogversion. Spørg, om tilgængelighedsmetadata bevares på tværs af sprogversioner, så etiketter og fejlbeskeder ikke falder tilbage til engelsk eller forsvinder, når der skiftes sprog.

Integration, interoperabilitet og vejen ud igen

Bed om dataudvekslingens anatomi: hvilke identifikatorer bruges, er de stabile over tid, og udveksles data i aftalte formater eller i leverandørens eget?

Et konkret forbillede findes i de europæiske DPP-standarder.

Den 15. juli 2026 offentliggjorde EU henvisninger til seks harmoniserede standarder for digitalt produktpas i Den Europæiske Unions Tidende, Beslutning (EU) 2026/1736.

EN 18219:2026 handler om, hvordan produkter, økonomiske aktører og faciliteter identificeres konsekvent – med produktidentitet, der kan tildeles på model-, batch- eller enkeltvareniveau.

To råd fra DPPora's gennemgang kan overføres direkte til leverandørvalg: hold identifikatoren adskilt fra webadressen, der viser oplysningerne, og beslut eksplicit, om to produkter kan dele identitet eller kræver separate optegnelser.

Samme gennemgang opdeler livscyklussen i fire trin – identificér, forbind, vedligehold, udveksl – og understreger, at forordninger fastsætter forpligtelser, mens standarder understøtter implementeringen.

Bemærk også forbeholdet: overensstemmelse med harmoniserede standarder kan give en formodning om overensstemmelse med de ESPR-krav, de dækker, men er ikke en generel certificering af et produkt eller en platform.

Integration mellem applikationer og ERP giver sikkerhed og synlighed, men beskrives af SAP som en udfordring for moderne virksomheder.

Spørg derfor, hvem der har ejerskab til data i grænsefladen, hvordan rettigheder og adgangsstyring håndteres på tværs af systemer, og hvordan I verificerer, at oplysningerne er opdaterede.

Et integrationspunkt, der kun synkroniserer én gang i døgnet, kan se korrekt ud og alligevel være forkert.

Til exit: få skriftligt, i hvilke formater hele jeres historik kan eksporteres, om logfiler og metadata følger med, hvad eksporten koster, og hvad der sker med data ved ophør – herunder frister for sletning.

Afklar også, om identifikatorer og webadresser er bundet til leverandørens domæne. Hvis ja, er en flytning ikke kun et teknisk projekt, men en oprydning i alle jeres egne referencer.

Forhold mellem EU DPP-standarder og danske krav til dataidentitet

Fra tjekliste til konkrete spørgsmål

Risikoområderne bliver først nyttige, når de står som spørgsmål, I kan stille og skrive svarene ned på. Notér dato, hvem der svarede, og om svaret var mundtligt eller skriftligt.

Referencer: Kan vi tale med to kunder, der har opsagt jer eller skiftet leverandør? Hvad gik i stykker, hvor lang tid tog det at rette, og hvad var reaktionstiden uden for normal arbejdstid?

Data og logning: Hvilke felter og logtyper gemmer I, hvor længe, og hvor? Hvem hos jer kan se dem? Kan vi få jeres informationssikkerhedspolitik og jeres politik for behandling af persondata, og er der en databehandleraftale med en opdateret underleverandørliste?

Dækning: Kan I tegne jeres dækning ind på vores anlæg og liste de hændelsestyper, I ikke kan registrere? Hvad sker der, når en sensor er offline i en uge?

Tilgængelighed: Kan hele brugerfladen betjenes med tastatur alene? Hvilke WCAG 2.2-niveauer tester I efter, kan vi se resultatet, hvordan formidles fejl til skærmlæsere, og findes der en dansk sprogversion, hvor etiketter og metadata bevares?

Integration og exit: Hvilke identifikatorer bruger I, er de stabile og adskilt fra webadresser, i hvilke formater kan hele vores historik eksporteres, hvad koster det, og hvad sker der med data ved ophør?

Læg svarene i et bilag, der dateres og følger kontrakten, og gennemgå dem igen ved fornyelse. Ændrer leverandøren arkitektur, ejerforhold eller underleverandører undervejs, er det de samme spørgsmål, der skal stilles forfra.