Hvis du har prøvet at stå med en leverandør, der lover “alt i én platform”, men ikke kan svare klart på logning, eksport eller offline-mode, så ved du, hvor dyrt uklare krav kan blive.
Denne artikel er en praktisk kravspec-guide til digitale løsninger, hvor data, drift og adgangskontrol er afgørende. Du får konkrete kravformuleringer, typiske faldgruber og en tjekliste til dialogen med leverandører—med fokus på dataminimering, logning, eksport, offline-mode, rollebaseret adgang, white-label, support og failover-plan.
Tidligt en definition: En kravspec (kravspecifikation) er en beskrivelse af, hvad systemet skal kunne, under hvilke betingelser, og hvordan det dokumenteres og testes. Den betyder noget, fordi den reducerer misforståelser, gør tilbud sammenlignelige og giver dig noget at holde leverandøren op på ved go-live og incident-håndtering.
1) Overblik: kravspec, der kan testes og forhandles
De bedste kravspec’er kan testes. I praksis betyder det, at du skriver krav som “systemet skal” + målbar betingelse + bevis. Eksempel: “Systemet skal kunne eksportere deltagerdata i CSV inkl. felter X, Y, Z inden for 60 sekunder for op til 50.000 rækker.” Så er det ikke en holdning—det er en test.
Et nyttigt greb er at skelne mellem funktionelle krav (hvad brugeren kan) og ikke-funktionelle krav (drift, sikkerhed, performance, compliance). De otte emner i denne artikel ligger typisk i krydsfeltet: de er “funktioner”, men de afgør også compliance og drift.
Mini-konklusion: Hvis du kan teste kravet på en demo eller i en accepttest, kan du også håndhæve det i kontrakten.
2) Dataminimering: mindre data, mindre risiko, bedre compliance
Dataminimering handler om at indsamle og opbevare så få persondata som nødvendigt for formålet. I praksis er det en af de mest effektive måder at reducere GDPR-risiko, angrebsflade og oprydningsarbejde på. Jeg har set projekter, hvor man “for en sikkerheds skyld” indsamlede fødselsdato, adresse og jobtitel—og senere brugte ingen af felterne. De blev til ren risiko.
Hvad skal du kræve?
- Formålsbinding pr. datafelt: For hvert felt angives formål og hjemmel (samtykke, kontrakt, legitim interesse osv.).
- Konfigurerbare felter: Admin kan slå felter til/fra (fx telefonnummer) uden udvikling.
- Standard = minimum: Standardformularer må ikke være “maximalistiske”.
- Opbevaringspolitik: Automatisk sletning/anonymisering efter fx 30/90/365 dage (afhænger af use case).
- Dataseparation: Skel mellem “check-in data” og marketingdata, så du ikke blander formål.
Typiske fejl og hvordan du undgår dem
Faldgrube 1: Man kopierer felter fra et gammelt Excel-ark. Løsning: Lav en “feltliste” med nødvendighed (skal/kan/skal ikke) og formål. Faldgrube 2: Man gemmer fritekst-noter (som ofte ender med følsomme oplysninger). Løsning: Begræns fritekst, eller gør den til strukturerede valg.
Mini-konklusion: Dataminimering er ikke kun jura—det er produktdesign og risikostyring, der kan spare dig for både incidents og oprydningsomkostninger.
3) Logning og audit trail: hvem gjorde hvad, hvornår og hvorfor
Logning er din “sort boks”. Den afgør, om du kan forklare en hændelse, dokumentere compliance og finde root cause. Mange løsninger siger “vi logger”, men uden detaljegrad, retention og adgangskontrol er det værdiløst.
Minimumskrav til logning
- Audit events: loginforsøg, ændring af roller, eksport, sletning, ændring af felter, ændring af integrationer.
- Event-detaljer: tidsstempel (UTC), bruger-id, rolle, IP-adresse eller device-id, objekt-id (fx deltager-id), før/efter-værdi hvor relevant.
- Retention: fx 180 dage som minimum, eller efter compliance-krav; mulighed for længere retention.
- Adgang: kun admins med særskilt rettighed; logs må ikke kunne redigeres.
- Eksport: logs kan udtrækkes til CSV/JSON for revision.
Hvad koster “ordentlig logning” typisk?
Det afhænger af volumen og retention. Som tommelfingerregel kan logning koste “mindre end du tror” i udvikling, men mere i drift, fordi storage og søgning i logs koster. Har du fx 50.000 check-ins og 10 log-events pr. check-in, bliver det 500.000 events. Løsningen er ikke at droppe logs—men at definere, hvad der er audit-kritisk, og hvad der er debug.
Mini-konklusion: Audit trail er ikke en nice-to-have. Det er din evne til at bevise, at systemet blev brugt korrekt—og til at opdage, når det ikke blev.
4) Eksport og data-portabilitet: undgå at blive låst fast
Eksport lyder simpelt, men er ofte stedet, hvor leverandør-lock-in gemmer sig. “Du kan eksportere” kan betyde en PDF uden rådata, en CSV uden nøgler, eller en export der kræver supportbillet og 14 dage.
Hvis du arbejder med tilmeldinger, check-in eller adgangskontrol, bør du kræve eksport, der understøtter både drift og revision. Det gælder især, hvis du skifter leverandør, eller hvis økonomi/ledelse kræver dokumentation.
Midt i mange setup’s er der brug for en stabil check-in løsning; her ser jeg ofte, at teams sammenligner platforme og inkluderer en event check-in app i deres shortliste, men glemmer at teste eksport af data og logs i praksis.
Krav, der gør eksport brugbar
- Formater: CSV og JSON som minimum; evt. Excel (XLSX) som convenience.
- Komplethed: alle felter, inkl. custom fields, statusfelter, timestamps, og interne nøgler.
- Filtrering: eksport pr. event, dato, status (checked-in/not), og segmenter.
- Hastighed: SLA for eksport, fx “under 2 min for 100.000 rækker”.
- API: mulighed for automatiseret eksport via API eller webhook.
- Versionshistorik: hvis data ændres, skal der være en måde at se historik eller ændringslog.
Faldgrube: Eksport uden unikke id’er. Så kan du ikke sammenholde data på tværs af systemer. Kræv altid stabile nøgler (deltager-id, order-id, ticket-id).
Mini-konklusion: Eksport er din forsikring mod lock-in—og din bedste ven, når nogen spørger “kan vi dokumentere det?”.
5) Offline-mode: når nettet forsvinder i praksis
Offline-mode er ofte afgørende ved events, lager, byggepladser eller mobile teams. Og det er et område, hvor leverandørers definitioner varierer: Nogle mener “appen åbner”, andre mener fuld check-in, kvittering og synk.
Hvad skal offline-mode kunne?
- Lokalt cachede data: nødvendige lister og nøgler ligger på enheden før offline.
- Konflikthåndtering: hvad sker der, hvis to enheder checker samme ticket ind offline?
- Synk-strategi: automatisk synk ved netforbindelse, med synk-status og fejlvisning.
- Offline-sikkerhed: data krypteret på enheden; mulighed for remote wipe ved tab.
- Begrænsning: definer max. datasæt (fx 20.000 deltagere pr. device) og performance.
Sådan tester du offline realistisk
Bed om en accepttest, hvor I: 1) downloader data, 2) slår flytilstand til, 3) gennemfører 200 check-ins på 2 enheder, 4) skaber en konflikt med samme ticket, 5) går online og verificerer, at systemet ender i korrekt end-state. Det tager under en time og afslører 80% af “offline”-sandheden.
Mini-konklusion: Offline-mode er ikke et kryds i et feature-skema—det er et helt flow, som skal specificeres, testes og sikres.
6) Rollebaseret adgang (RBAC): mindst mulige rettigheder i praksis
Rolle-adgang er et område, hvor “admin” ofte bliver en skraldespand. I en moden løsning skal du kunne give præcis adgang til præcise handlinger—og kunne dokumentere det. RBAC er også en af de letteste måder at forebygge interne fejl, fx at en frivillig eksporterer deltagerlisten ved et uheld.
Krav til roller og rettigheder
Start med at beskrive 4–6 standardroller og deres handlinger. Eksempel:
- Superadmin: alt inkl. sletning, rolleændringer, integrationer.
- Event-admin: konfigurere event, men ikke se andre events.
- Check-in staff: kan kun søge og checke ind; kan ikke eksportere.
- Support/Read-only: kan se status og logs, men ikke ændre.
- Finance: kan se ordre-/betalingsdata, men ikke personfelter der ikke er nødvendige.
Best practice: kombiner RBAC med “scope”
En rolle uden scope er farlig. Scope betyder, at adgang begrænses til et event, en lokation eller en kunde. Kræv fx: “Rolle X kan kun tilgå data for event-id Y og lokation Z”. Det er især vigtigt i multi-event- eller multi-kunde-setup.
Mini-konklusion: God rolle-adgang er både sikkerhed og effektiv drift—fordi folk kun ser det, de skal bruge.
7) White-label: hvad betyder det egentlig, og hvor går grænsen?
White-label kan være alt fra “indsæt logo” til fuld brandet oplevelse med eget domæne, farver, e-mails og app-ikon. Uden afklaring ender man tit med at love for meget internt og levere for lidt eksternt.
Overvej at dele krav i tre niveauer: basis (logo/farver), udvidet (domæne, e-mailskabeloner), og avanceret (app-branding, flere brand-profiler, per-event temaer). Det gør pris og scope tydeligt.
- Domæne og SSL: eget subdomæne (fx checkin.ditbrand.dk) med korrekt certifikat.
- E-mail: afsenderdomæne, DKIM/SPF, skabeloner, og log over udsendelser.
- UI-tema: farver, typografi, knapper, og evt. dark mode.
- Flere brands: hvis I har flere afdelinger/kunder, skal I kunne styre brand pr. event.
Faldgrube: White-label uden governance. Hvis 10 events selv kan ændre skabeloner, ender du med brand-kaos. Kræv versionsstyring eller godkendelsesflow for skabeloner.
Mini-konklusion: White-label er en kombination af teknik (domæne, e-mail) og designprocesser (styring). Specificér niveau, ansvar og godkendelse.
8) Support og failover-plan: det du først savner, når det brænder på
Support og failover er ofte underprioriteret, indtil første gang der er kø ved indgangen, eller et system bliver langsomt 10 minutter før åbning. Kravspec’en bør derfor definere, hvordan I får hjælp, og hvordan leverandøren sikrer fortsat drift ved fejl.
Supportkrav, der kan måles
- Supportvinduer: fx 08–16 hverdage + event-vagt ved kritiske events.
- Respons-SLA: P1 inden for 15 min, P2 inden for 1 time, P3 inden for 1 arbejdsdag.
- Kanaler: telefon for P1, ticket/email for øvrige; tydelig eskalation.
- Statusside: offentlig eller delt statusside med incident-historik.
- Post-mortem: skriftlig rapport ved P1/P2 med årsag og forebyggelse.
Failover-plan: konkret og dokumenterbar
Failover-plan er leverandørens plan for at fortsætte drift ved nedbrud: redundant hosting, database-replikering, backupprocedure og genopretning. Kræv mindst følgende begreber afklaret: RPO (hvor meget data må gå tabt) og RTO (hvor hurtigt skal systemet være oppe). For en check-in løsning kan RTO fx være 15–60 minutter, mens RPO ofte bør være tæt på 0 for transaktionelle events—men afhænger af offline-flow og synk.
Faldgrube: Backups uden restore-test. Kræv dokumentation for regelmæssige gendannelsestests (fx kvartalsvis) og hvem der godkender resultaterne.
Mini-konklusion: Support og failover er ikke “ekstra”. De er driftens sikkerhedsnet, og de skal beskrives i tal, processer og ansvar.
Vendor questions: spørgsmål du bør stille før du vælger leverandør
- Kan I vise en konkret oversigt over datafelter, formål og retention, og kan vi slå felter fra uden udvikling?
- Hvordan håndterer I sletning/anonymisering, og kan vi få dokumentation for udførte sletninger?
- Hvilke audit-events logger I som standard, og kan vi se et eksempel på en loglinje med før/efter-værdi?
- Hvad er jeres log-retention, og kan vi eksportere logs til revision?
- Hvilke eksportformater tilbyder I, og inkluderer eksporten stabile id’er (ticket-id/order-id/deltager-id)?
- Er eksport selvbetjent, og hvad er den forventede tid for fx 100.000 rækker?
- Har I API/webhooks til løbende dataudtræk, og hvordan versionerer I ændringer i API’et?
- Hvad betyder “offline-mode” hos jer helt konkret: cache, konflikter, synk-status, og kryptering på enheden?
- Kan I demonstrere en offline-test med to enheder og en konfliktsituation?
- Hvilke standardroller findes, kan vi lave egne roller, og kan rettigheder scoping-begrænses pr. event/lokation/kunde?
- Kan I levere white-label på eget domæne med DKIM/SPF, og kan vi styre flere brand-profiler?
- Hvad er jeres support-SLA for P1/P2/P3, og tilbyder I event-vagt uden for normal åbningstid?
- Har I en statusside og en incident-proces med post-mortem, og kan vi se et eksempel på en tidligere rapport?
- Hvad er jeres RTO/RPO, hvordan er jeres failover-setup bygget, og hvor ofte tester I restore/failover?
