Vi bruger cookies

Vi bruger nødvendige cookies til at få hjemmesiden til at fungere. Med dit samtykke bruger vi også cookies til statistik, præferencer og eventuel markedsføring. Du kan acceptere alle, afvise ikke-nødvendige cookies eller tilpasse dit valg.

Cookiepolitik Privatlivspolitik

KHALEGI DIGITAL

DIGITALISERING I PRAKSIS

FAQ

Velkommen til KHALEGI DIGITAL FAQ

FAQ’en samler mine erfaringer, observationer og spørgsmål inden for IT, teknologi, indkøb, kontrakter og rådgivning.

Brug søgefeltet til at søge efter konkrete spørgsmål eller nøgleord. Du kan også indsnævre resultaterne ved at filtrere på hovedområde, emne og målgruppe, så det bliver lettere at finde de svar, der er relevante for din situation.

FAQ’en indeholder aktuelt 200 spørgsmål og svar fordelt på ni hovedområder:

  • Cloud: Cloudstrategi og udbud, pris og økonomi, governance og compliance, service level agreements (SLA), leverandørvalg samt forandring og exit-strategi.
  • IT-udbud: Strategi, leverandørskifte, evaluering, kontrakt, governance, compliance og konkurrence i forbindelse med IT-udbud.
  • IT-sikkerhed: NIS2 og øvrige krav, lovgivning og certificering, data og lokation, internationale overførsler, myndigheder og roller, kravspecifikationer, kontraktforhold, dokumentation, standarder, governance og modenhed.
  • IT-kontrakter: Procedure og evaluering, krav og specifikationer, kontraktændringer, økonomi og forhandling, kontrakthåndtering samt compliance og samfundsansvar.
  • IT-strategi: Strategiske valg og prioritering, gennemførelse af strategien, portefølje- og produktansvar samt cloud, data og sikkerhed.
  • Ledelsesrådgivning: Ledelsesbeslutninger og mandat, gevinstrealisering og samarbejde, forankring og rådgivning samt beredskab og ledelsesstyring.
  • Analyser: Behov og datagrundlag, analysemetoder og beslutningsstøtte, alternativer og økonomi samt analyseleverancer og opfølgning.
  • Bid management: Tilbudsbeslutninger og strategi, tilbudsteam og dokumentation, tilbudsleverance og kvalitet samt læring og tilbudsstyring.
  • Market entry: Markedsvalg og kunder, markedstest og pipeline, adgang og lokal levering samt markedsstyring og skalering.

FAQ’en er lavet som et praktisk opslagsværk og bliver løbende udbygget og opdateret med nye spørgsmål, svar og emner.

Hvis du har forslag til nye spørgsmål eller emner, er du velkommen til at kontakte mig.

Nulstil

80 svar fundet · side 2 af 7

Hvad skal en databehandleraftale afklare i en IT-kontrakt?

Databehandleraftalen skal passe til den faktiske behandling og rollefordeling. Den bør blandt andet konkretisere instrukser, sikkerhed, underdatabehandlere, bistand, kontrol og håndtering af oplysninger ved ophør efter de gældende regler.

Kortlæg først, hvilke personoplysninger leverandøren behandler for kunden, og hvilke behandlinger der eventuelt sker til egne formål. Sammenhold aftalen med teknisk dokumentation, supportadgang og leverandørkæde. Afklar også eventuelle tredjelandsoverførsler. En underskrevet standardskabelon giver ikke alene sikkerhed for lovlig behandling, hvis bilagene er tomme eller beskriver en anden løsning end den, der faktisk leveres.

Kilder og faglig baggrund: Datatilsynet: Dataansvarlig og databehandler · Datatilsynet: Cloud

Hvad skal planlægges ved overgangen til en cloudleverandør?

Overgangen skal planlægges som en leverance med egne acceptkriterier. Det er ikke tilstrækkeligt at aftale en dato for driftsstart. Data, integrationer, brugere og support skal fungere sammen, og der skal være en kontrolleret håndtering af fejl.

Opdel forløbet i forberedelse, prøveflytning, validering, produktionsskifte og afslutning. Angiv ansvar for hver aktivitet, tilbagefaldsbetingelser og beslutningskompetence ved problemer. Afstem også betaling for parallel drift og assistance fra den afgående leverandør. Afslut først, når aftalte kontroller og dokumentation er accepteret, og gamle adgange og kopier er håndteret.

Kilder og faglig baggrund: Digitaliseringsstyrelsen: K04 – IT-drift · Datatilsynet: Cloud

Hvilke cloudomkostninger bliver let overset?

Cloudtilbud bliver misvisende, hvis beregningen alene omfatter servere og lager. Den samlede økonomi kan også påvirkes af dataoverførsel, sikkerhedstjenester, logopbevaring, support, backup, licenser og leverandørens arbejde med ændringer.

Bed om en prisberegning for et konkret driftsforløb, inklusive gendannelse, større datatræk og ophør. Beskriv mængder og forudsætninger, så tilbuddene kan sammenlignes. Kontrollér særligt, om en tjeneste afregnes flere steder i leverancekæden. Registrér usikre poster som intervaller i business casen, og knyt hver usikkerhed til en afklaring eller en ansvarlig ejer.

Kilder og faglig baggrund: FinOps Foundation: Framework

Hvilke elementer bør en cloud-SLA indeholde?

En SLA bør knytte servicekrav til brugerens behov og gøre måling og opfølgning entydig. Centrale emner er tilgængelighed, svartid, support, hændelsesklassifikation, gendannelse og rapportering. Det er afgørende, hvor i leverancekæden målingen foretages.

Angiv måleperiode, datakilde, undtagelser, planlagt vedligehold og procedure ved uenighed. Skeln mellem første svar, påbegyndt fejlsøgning og faktisk genetablering. Beskriv også kundens medvirken og afhængigheder til andre leverandører. Gennemregn et realistisk nedbrud, så parterne på forhånd ved, om servicekravet er brudt, og hvad der følger derefter.

Kilder og faglig baggrund: Digitaliseringsstyrelsen: K04 – IT-drift

Hvilke faldgruber bør undgås ved valg af cloudleverandør?

En almindelig faldgrube er at vælge ud fra en demonstration eller en lav startpris uden at undersøge den samlede leverance. Andre er uklare kundeopgaver, svage eksportmuligheder og antagelser om, at standardvilkår dækker særlige behov.

Lav en sammenlignelig vurdering af funktion, drift, sikkerhed, økonomi og ophør. Markér hvert punkt som dokumenteret, afprøvet eller uafklaret. Kræv en konkret afklaring af væsentlige usikkerheder, før kontrakten indgås. En kort pilot kan være værdifuld, men dens resultater skal knyttes til de belastninger og arbejdsgange, som den fremtidige drift faktisk skal håndtere.

Kilder og faglig baggrund: Datatilsynet: Cloud · FinOps Foundation: Framework

Hvilke fejl opstår ofte i IT-udbuddets SLA-bilag?

Et SLA-bilag bliver vanskeligt at anvende, når hændelsesklasser, målemetoder og ansvar ikke hænger sammen. Et eksempel er et krav om hurtig genetablering uden adgang til kundens systemer eller uden en defineret start på tidsmålingen.

Gennemgå bilaget sammen med driftsorganisationen og test flere fejlscenarier. Kontrollér, at servicemål, rapportering, eskalation og eventuel bod bruger samme begreber. Afklar også afhængigheder til øvrige leverandører. Beskriv kundens medvirken, men undgå brede undtagelser, som gør målene indholdsløse. Bilaget skal kunne bruges ved en faktisk hændelse, også uden for normal arbejdstid.

Kilder og faglig baggrund: Digitaliseringsstyrelsen: K04 – IT-drift

Hvilke risici bør afklares før et IT-udbud?

Risici vedrører både anskaffelsen og den efterfølgende anvendelse. Typiske områder at undersøge er uklare data, integrationsafhængigheder, urealistisk tidsplan, manglende interne ressourcer og ukendt økonomi ved ændringer eller ophør. Listen skal tilpasses den konkrete løsning.

Lav et risikoregister med hændelse, årsag, konsekvens, sandsynlighed, ejer og behandling. Undersøg, hvilke risici der kan reduceres før udbud, og hvilke der skal håndteres i krav eller kontrakt. Test især overgangsforløbet fra gammel til ny løsning. En risiko bliver ikke væk, fordi kontrakten placerer ansvaret hos leverandøren.

Kilder og faglig baggrund: NIST: Cybersecurity Framework 2.0 · Udbudsloven, LBK nr. 116 af 3. februar 2025

Hvilken dokumentation bør efterspørges om NIS 2?

Begynd med at afklare, om kunden eller leverandøren er omfattet af NIS 2-reglerne, og hvilken sektorregulering der gælder. En erklæring om ”NIS 2-compliance” er ikke i sig selv tilstrækkelig dokumentation for relevante foranstaltninger.

Bed om en afgrænset beskrivelse af ansvar, risikovurdering, hændelseshåndtering og styring af leverandørkæden, når det er relevant for leverancen. Efterspørg beviser for faktisk anvendelse, eksempelvis øvelser og opfølgning på mangler. Aftal opdatering ved væsentlige ændringer. Dokumentationskravene bør følge risikoen og må ikke forveksles med en generel certificeringsordning.

Kilder og faglig baggrund: SAMSIK: NIS 2

Hvilken myndighedsvejledning er relevant for dansk cybersikkerhed og NIS 2?

Brug den aktuelle myndighedsfordeling frem for automatisk at henvise alle spørgsmål til tidligere organisationsnavne. Styrelsen for Samfundssikkerhed, SAMSIK, samler vejledning om NIS 2, mens tilsyn og sektorspecifikke spørgsmål afhænger af organisationens område.

Afklar sektor og aktiviteter, og identificér den kompetente myndighed og relevante kontaktvej. Registrér kilden og datoen i organisationens beredskabsdokumentation, så kontaktoplysninger kan vedligeholdes. Leverandørens rådgiver eller certifikat erstatter ikke myndighedsafklaring af anvendelsesområdet. Ved konkrete hændelser skal de gældende underretningskanaler og eventuelle særregler kontrolleres, før en intern kontaktliste betragtes som tilstrækkelig.

Kilder og faglig baggrund: SAMSIK: NIS 2

Hvilket ansvar har ledelsen efter NIS 2?

For organisationer omfattet af de relevante NIS 2-regler har ledelsen en aktiv rolle i godkendelse og tilsyn med cybersikkerhedsforanstaltninger. Ansvaret kan ikke reduceres til, at IT-afdelingen køber et værktøj eller bestiller en årlig rapport.

Ledelsen bør få et forståeligt billede af væsentlige risici, afhængigheder og mangler og sikre kompetencer og opfølgning. Aftal beslutningspunkter, rapportering og håndtering af accepterede risici. Den præcise pligt afhænger af den regulering, organisationen er omfattet af; SAMSIKs ledelsesvejledning er et relevant udgangspunkt for den konkrete afklaring.

Kilder og faglig baggrund: SAMSIK: Ledelsens rolle og opgaver

Hvor præcist skal en offentlig evalueringsmetode beskrives?

Udbudslovens § 160 kræver, at ordregiver fastlægger og beskriver evalueringsmetoden i udbudsmaterialet. Tilbudsgiverne skal kunne forstå, hvordan tilbuddene bliver sammenlignet. Beskrivelsen bør derfor hænge sammen med kriterier, vægtning, prisgrundlag og den valgte vurderingsmodel.

Gennemgå materialet fra tilbudsgiverens perspektiv og afprøv modellen med forskellige pris- og kvalitetsniveauer. Ret uklarheder før offentliggørelse. Efterfølgende anvendelse skal følge det offentliggjorte grundlag; en intern regnearksmodel kan ikke supplere materialet med skjulte regler. Den konkrete beskrivelsespligt skal vurderes i lyset af den valgte metode og gældende praksis.

Kilder og faglig baggrund: Udbudsloven, LBK nr. 116 af 3. februar 2025

Hvordan balanceres funktionskrav og tekniske krav?

Funktionskrav beskriver det resultat, løsningen skal skabe, mens tekniske krav fastlægger bestemte egenskaber eller rammer. Brug funktionskrav, hvor markedet kan tilbyde flere veje til målet, og tekniske krav, hvor nødvendige integrationer, sikkerhed eller drift kræver præcision.

Beskriv eksempelvis, hvilken opgave en bruger skal kunne gennemføre, før et bestemt skærmbillede kræves. Markér tekniske bindinger med en begrundelse og undersøg alternativer. I offentlige udbud skal kravene udformes i overensstemmelse med reglerne om tekniske specifikationer, konkurrence og dokumentation, herunder relevant håndtering af tilsvarende løsninger.

Kilder og faglig baggrund: Udbudsloven, LBK nr. 116 af 3. februar 2025