| Table of Contents |
|---|
Annonceringsramme
På vegne af OS2valghalla-samarbejdet annoncerer Foreningen OS2 - offentligt digitaliseringsfællesskab opgaven for hosting af løsningen OS2valghalla. Vi inviterer udvalgte leverandører til at byde på opgaven, som beskrives i det følgende. Tildeling af opgaven til leverandør sker på markedsmæssige vilkår efter indhentning af tilbud.
Definitioner
OS2valghalla-samarbejdet under OS2-fællesskabet benævnes også som kunden.
Kommuner, som benytter løsningen omtales også som anvendere.
Spørgsmål og dialog
...
| Table of Contents |
|---|
Annonceringsramme
På vegne af OS2valghalla-samarbejdet annoncerer Foreningen OS2 - offentligt digitaliseringsfællesskab opgaven for hosting af applikationen OS2valghalla. Vi inviterer udvalgte leverandører til at byde på opgaven, som beskrives i det følgende. Tildeling af opgaven til leverandør sker på markedsmæssige vilkår efter indhentning af tilbud.
Definitioner
OS2valghalla-samarbejdet under OS2 - offentligt digitaliseringsfællesskab benævnes også som kunden.
Kommuner, som benytter løsningen benævnes også som anvendere.
Leverandør, der skal varetage hosting af OS2valghalla benævnes Leverandør eller Driftsleverandør. Dette sker for at skelne mellem opgaverne med drift/hosting og udvikling, da den sidste opgave senere annonceres på en anden aftale.
Spørgsmål og dialog
Dialog er meget velkommen - særligt i forhold til dele af aftalen, som medfører høje udgifter, da der måske kan reguleres på krav. Spørgsmål kan stilles til OS2valghallas produktkoordinator Mogens Kjeldsen på mail movk@aarhus.dk eller tlf. 4187 3357, senest XX22.09.2023 kl. 12.
Anonymiserede spørgsmål og svar vil blive delt blandt de udvalgte leverandører løbende indtil deadline. Dette sker via et åbent dokument: https://aarhuskommune-my.sharepoint.com/:w:/g/personal/movk_aarhus_dk/ETl0OcquKPtGsA906_0KD8UBwJqCtQhWDICRt3xLLzRMOw?e=K9GULO
...
Send venligst jeres tilbud senest XXXdag XXfredag 29.09.2023 kl. 12 17 til movk@aarhus.dk.
Valg af leverandør
Senest XX06.0910.2023 forventes OS2valghallas styre- og koordinationsgruppe repræsentanter for OS2valghalla-samarbejdet at vælge en leverandør, og det vindende bud annonceres herefter til alle tilbudsgivere. Se tildelingskriterier til sidst i dette dokument.
...
De samarbejdende kommuner har besluttet at oprette et driftsfællesskab via OS2. Ved at have en samlet aftale om hosting med en driftsleverandør leverandør ønsker man at stabilisere driften og opnå fordele ved en samlet aftale med samlet administration og lignende.
Teknisk beskrivelse af OS2valghalla
OS2valghalla er et open source SaaS-produkt udviklet i .NET af udviklingsleverandøren Precio Fishbone (PF), som også har udviklet det svenske valgrekrutteringssystem Kaskelot Online. OS2valghalla er videreudviklet ud fra en kodebase, som også er blevet brugt til at lave en ny version af Kaskelot Online. Da dansk og svensk valgafvikling har væsentlige forskelle i den praktiske afvikling, har det været nødvendigt at lave to forskellige produkter.
...
En internt rettet webapplikation, som kommunens valgansvarlige medarbejdere benytter til administration af valgrekrutteringen
En eksternt rettet webapplikation, hvor deltagere kan se og tilmelde sig opgaver og eksterne teamansvarlige kan håndtere rekruttering blandt deres medlemmer. Denne del er stærkt begrænset i funktionalitet, når der ikke er aktive valg.
Hertil kommer driftsleverandørens mulighed for at opsætte og konfigurere de enkelte kommuners tenants på databaseniveau.
...
OS2valghalla er lavet som en multi-tenant løsning, hvor alle anvendere deler den samme instansinstallation på en server, men har hver deres separate udgave/tenant af OS2valghalla med egen opsætning og egne URL’er.
Precio Fishbones anbefalede hosting-krav
Da OS2valghalla er ved at blive færdigudviklet og indtil videre kun er afprøvet i et testmiljø, har PF givet deres bedste bud på anbefalede hosting-krav ud fra deres erfaring over 10 år med at hoste Kaskelot Online sammenholdt med deres viden om den nuværende OS2valghalla implementation.
Til oktober '23 følger en mere udbygget teknisk dokumentation af løsningen inkl. installationsvejledning.
Precio FishboneFishbones beskrivelse:
The OS2valghalla application is built to run in docker containers. The application requires 6 containers each with a separate role listed below:
Internal web application
External web application
Messages – schedules jobs
PostgreSQL – database
RabbitMG RabbitMQ – queue to handle batched tasks.
Nginx – to distribute incoming requests to right container.
Docker is running a VM with Linux. Based on our experience from Kaskelot Online the OS2Valghalla docker VM is expected to be able to run on with the following specs when:
not ongoing election: 2 vCPUs and , 4GB memory and 100GB HDD
ongoing election: 4 vCPUs and , 16GB memory memory and 200GB HDD
The CPU capacity is based on Azures Virtual CPU (vCPU) since we are hosting in Azure. Unfortunately, there is no official documentation of what a vCPU translates into. It seems like there is no one to one relationship between vCPU and cores in any virtualization software. A general estimation is that 1 vCPU = 1 Physical CPU Core. However, this is not entirely correct, as the vCPU is made up of time slots across all available physical cores, so in general 1vCPU is actually more powerful than a single core, especially if the physical CPUs have 8 cores.
Mulighed for justeringer
Da OS2valghalla ikke har været afprøvet i et produktionsmiljø eller udsat for høj belastning, kan der være behov for justeringer af de ovenstående anbefalinger i takt med, at Kunde og driftsleverandør sammen bliver klogere på OS2valghallas performance.
Integrationer
For at drifte OS2valghalla er det nødvendigt at integrere til en række eksterne systemer beskrevet herunder. Som en del af hosting-opgaven er det påkrævet at overvåge driftsstatus på disse integrationer for at sikre, at OS2valghalla virker eller at varsle behov for patches eller ny-udvikling af produktet til Kunden. Patches og videreudvikling varetages af en udviklingsleverandør.
Serviceplatformen/Støttesystemer
OS2Valghalla benytter nedenstående integrationer til Serviceplatformen, som skal samles i en serviceaftale, der indgås med hver enkelt kommune via det Fælleskommunale Administrationsmodul i Serviceplatformen:
CPR-nummer opslag: https://digitaliseringskataloget.dk/integration/sf1520
Afsendelse af Digital Post: https://digitaliseringskataloget.dk/integration/sf1601
Modtag status på Digital Post-afsendelse: https://digitaliseringskataloget.dk/integration/sf1461
Fælleskommunal adgangsstyring for brugere (Context handler): https://digitaliseringskataloget.dk/l%C3%B8sninger/adgangsstyring-brugere
NemLog-in
NemLog-in benyttes som MitID-broker. Der skal indgås aftale mellem leverandør og NemLog-in om brug.
SMS gateway
OS2Valghalla kan sende SMS via en SMS gateway, som leverandøren skal levere som del af aftalen. OS2valghalla kan integrere op imod Computopic’s SMS-gateway via deres API. Hvis leverandøren ønsker at benytte en anden udbyders SMS Gateway, må leverandøren selv tilrette OS2valghalla til at kunne dette.
Mailserver
OS2valghalla kan sende mail. Leverandøren skal derfor levere en mailserver som del af aftalen. Konfiguration af denne efter best practice er afgørende for at undgå, at mails fra OS2valghalla kategoriseres som spam. Erfaringen fra tidligere version af OS2valghalla er, at dette kan være en udfordring for et system, som kun udsender mails i begrænsede perioder og med store mellemrum.
Arkitekturtegning
Integrationerne er illustreret i denne arkitekturtegning:
...
Krav til hosting-løsning
Shared hosting ok eller ej?
Altså om det er ok, at OS2valghalla ligger på sin egen virtuelle server, men på samme fysiske server som andre kunder?
Har vi holdning til, om det er baseret på Cloud-løsning eller fysisk server?
Behandling af persondata og geografisk placering
Behandling af persondata skal ske af databehandlere og eventuelle underdatabehandlere in Azure. Unfortunately, there is no official documentation of what a vCPU translates into. It seems like there is no one to one relationship between vCPU and cores in any virtualization software. A general estimation is that 1 vCPU = 1 Physical CPU Core. However, this is not entirely correct, as the vCPU is made up of time slots across all available physical cores, so in general 1vCPU is actually more powerful than a single core, especially if the physical CPUs have 8 cores.
Mulighed for justeringer
Da OS2valghalla ikke har været afprøvet i et produktionsmiljø eller udsat for høj belastning, kan der være behov for justeringer af de ovenstående anbefalinger i takt med, at Kunde og driftsleverandør sammen bliver klogere på OS2valghallas performance. Derudover kan der også være behov for justeringer rent sikkerhedsmæssigt i setuppet - fx i forbindelse med gennemførelse af en penetrationstest i produktion.
Integrationer
For at drifte OS2valghalla er det nødvendigt at integrere til en række eksterne systemer beskrevet herunder. Som en del af hosting-opgaven er det påkrævet at overvåge driftsstatus på disse integrationer for at sikre, at OS2valghalla virker eller at varsle behov for patches eller ny-udvikling af produktet til Kunden. Patches og videreudvikling varetages af en udviklingsleverandør.
Serviceplatformen/Støttesystemer
OS2Valghalla benytter nedenstående integrationer til Serviceplatformen, som skal samles i en serviceaftale, der indgås med hver enkelt kommune via det Fælleskommunale Administrationsmodul i Serviceplatformen:
CPR-nummer opslag: https://digitaliseringskataloget.dk/integration/sf1520
Afsendelse af Digital Post: https://digitaliseringskataloget.dk/integration/sf1601
Modtag status på Digital Post-afsendelse: https://digitaliseringskataloget.dk/integration/sf1461
Fælleskommunal adgangsstyring for brugere (Context handler): https://digitaliseringskataloget.dk/l%C3%B8sninger/adgangsstyring-brugere
NemLog-in
NemLog-in benyttes som MitID-broker. Der skal indgås aftale mellem Digitaliseringsstyrelsen og de deltagende kommuner om brug af NemLog-in, som på den måde kan benyttes gratis. Kunden vil udarbejde en TU-risikovurdering, som fastlægger ønsket sikringsniveau i TU-løsningen. Sikringsniveauet skal i forbindelse med opkoblingen til broker sikres implementeret.
SMS gateway
OS2valghalla kan sende SMS via en fælles SMS-gateway, som benyttes af alle tenants. Leverandøren skal levere egen eller dansk underleverandørs SMS-gateway som en del af aftalen og under hensyn til behandling af persondata og bedste priser. I den forbindelse er det op til Leverandøren at tilrette OS2valghallas kildekode/konfiguration, så den fungerer med den valgte SMS-gateway.
Mailserver
OS2valghalla kan sende mail via en fælles mailserver, som benyttes af alle tenants. Leverandøren skal derfor levere en mailserver som del af aftalen. Konfiguration af denne efter best practice er afgørende for at undgå, at mails fra OS2valghalla kategoriseres som spam. Erfaringen fra tidligere version af OS2valghalla er, at dette kan være en udfordring for et system, som kun udsender mails i begrænsede perioder og med store mellemrum. Det er Leverandørens ansvar, at mails ikke blacklistes, så de faktisk når frem til deltagerne.
Arkitekturtegning
Integrationerne er illustreret i denne arkitekturtegning:
...
Krav til hosting-setup
Kunden har ikke nogen holdning til, om hostingen er baseret på en tredjepartsudbyders Cloud-infrastruktur eller Leverandørens egen, så længe kravene til behandling af persondata er overholdt.
Kunden accepterer shared cloud hosting forstået på den måde, at OS2valghalla kan hostes på en fysisk server, der deles med andre kunder. Dette sker under hensyn til krav om compliance som beskrevet i afsnittet om sikkerhed.
Regulering af driftsressourcer
Der ønskes en fleksibel allokering af server-ressourcer til OS2valghalla, da applikationen sjældent benyttes i perioden mellem valg. Det skal forstås sådan, at hosting-setuppet skal tage højde for de nødvendige ressourcer baseret på brug af applikationen. For at sikre at udgifterne ikke løber løbsk, er der angivet et loft for disse ressourcer i forskellige perioder i afsnittet serviceniveau.
Adgang til logfiler
OS2valghalla gemmer en logfil pr. kommune en gang i døgnet. Hver enkelt kommune skal have mulighed for at få adgang til sin egen logfil til videre stikprøvekontrol og analyse i egne værktøjer. Dette skal tilbydes via SFTP for de kommuner, som ønsker det. Antal kendes ikke på nuværende tidspunkt, men forventes at stige over tid som flere kommuner implementerer SIEM-systemer.
Behandling af persondata
Behandling af persondata skal ske af databehandlere og eventuelle underdatabehandlere i EU, EØS eller et tredjeland, der er erklæret sikkert i henhold til GDPR art. 45. Herudover må databehandleren og eventuelle underdatabehandlere ikke være koncernforbundet med moderselskaber i ikke-sikre tredjelande.
Pga. juridisk usikkerhed om opbevaring af persondata i tredjelande inkl. USA skal OS2valghalla driftes i et datacenter i EU ejet af et firma, der er beliggende i et EU-land. Dette ønskes, fordi databehandleraftale skal indgås med de enkelte kommuner, der skal benytte OS2valghalla, og der kan pga. Schrems II-dommen være strikse krav til hosting udenfor EU i de enkelte kommuner.
Supportmedarbejdere, udviklere og andre, der tænkes at have adgang til data, skal ligeledes være placeret i EU, EØS eller et tredjeland, der er erklæret sikkert i henhold til GDPR art. 45. Herudover må databehandleren og eventuelle underdatabehandlere , og må ligeledes ikke være koncernforbundet med moderselskaber i ikke-sikre tredjelande, f.eks. USA.
Pga. manglende juridisk afklaring om opbevaring af persondata i tredjelande inkl. USA skal OS2valghalla driftes i et datacenter i EU ejet af et firma, der er beliggende i et EU-land. Dette ønskes, fordi databehandleraftale skal indgås med de enkelte kommuner, der skal benytte OS2valghalla, og der kan pga. Schrems II-dommen være strikse krav til hosting udenfor EU i de enkelte kommuner.
Supportmedarbejdere, udviklere og andre, der tænkes at have adgang til data, skal ligeledes være placeret i EU, EØS eller et tredjeland, der er erklæret sikkert i henhold til GDPR art. 45, og må ligeledes ikke være koncernforbundet med moderselskab i et ikke-sikkert tredjeland eller have underleverandører i et sådant, hvis de på nogen måde kan få adgang til persondata i OS2valghalla.
Databehandleraftale
Som udgangspunkt indgås der en fælles databehandleraftale for alle de kommuner, der er medlem af ”Det fælleskommunale Databehandlersekretariat” (DBS). Aftalen laves med afsæt i sekretariatets skabelon. Det vil også være DBS der varetager årlig revision for disse kommuner.
For de kommuner der ikke medlem af DBS (for nuværende gælder det 7 ud af de 22 medvirkende kommuner) indgås der en direkte aftale mellem kommunen og leverandøren. Også denne bør tage udgangspunkt i DBS' skabelonmoderselskab i et ikke-sikkert tredjeland eller have underleverandører i et sådant, hvis de på nogen måde kan få adgang til persondata i OS2valghalla.
Databehandleraftale
Som udgangspunkt indgås der en fælles databehandleraftale for alle de kommuner, der er medlem af ”Det fælleskommunale Databehandlersekretariat” (DBS). Aftalen laves med afsæt i sekretariatets skabelon, som er baseret på Datatilsynets standard-databehandleraftale.
For de kommuner der ikke medlem af DBS (for nuværende gælder det 7 ud af de 22 medvirkende kommuner) indgås der en direkte aftale mellem kommunen og leverandøren. Også denne bør tage udgangspunkt i DBS' skabelon.
Revision af databehandling
Det vil også være DBS, der varetager årlig revision for deres medlemskommuner, mens resterende kommuner gør det ifølge egne procedurer.
Leverandør bør kunne levere en revisionserklæring af typen ISAE 3000 GDPR type 2 på sin databehandling for at sikre den lovpligtige gennemsigtighed, så der er mulighed for at føre et godt tilsyn på leverandøren. Er dette ikke muligt, skal Leverandør stille sig til rådighed for kommunernes revision som aftalt i databehandleraftale. Dette kan inkludere fysisk adgang til faciliteter.
Hvis der benyttes underdatabehandlere træffer Leverandøren som udgangspunkt valg om, hvordan revision af disse foretages. Nærmere detaljer kan findes i DBS' skabelon, bilag C.8.
Karakter af persondata
OS2valghalla indeholder både almindelige og følsomme personoplysninger, da der gemmes oplysning om nogle deltageres politiske overbevisning.
Serviceniveau
Det ønskede serviceniveau er fordelt på to perioder hhv. en peak periode optil, under og umiddelbart efter et valg; og en periode med normal drift imellem valg. Herunder beskrives de to serviceniveauer, der ønskes.
Normal drift | Peak periode |
|---|
...
Drift
...
Drift | Der ønskes et loft for driftsmiljøets ressourcer, så det kan imødekomme den lave aktivitet i systemet. I perioder med normal drift er de anbefalede ressourcer:
| Der ønskes et forøget loft for driftsmiljøets ressourcer, så det kan imødekomme den forøgede aktivitet i systemet. |
...
Anbefalede ressourcer
I peak perioder er de anbefalede ressourcer:
|
...
|
...
| |
Oppetid og genetablering | I |
...
perioder |
...
med normal drift ønskes en oppetid på 99% indenfor normal arbejdstid og mulighed for genetablering af fuld funktionalitet indenfor 8 timer indenfor normal arbejdstid. | Der ønskes en oppetid på 99.9% hele døgnet og mulighed for genetablering af fuld funktionalitet indenfor 1 time imellem 06:00 og 00:00. |
Nedetid og |
...
opdateringer | Planlagte nedetider til service og opdateringer ønskes lagt indenfor normal arbejdstid og med mindst 7 dages varsel. | Der ønskes ingen planlagt nedetid til service og opdateringer. |
Overvågning |
...
* | Der ønskes konstant overvågning af den virtuelle serverdrift og drift af selve applikationen, hvor udfald bliver rapporteret til kunden indenfor 10 minutter via mail. Leverandøren iværksætter selv genetablering af driften straks og afrapporterer via mail til kunden, når driften er genetableret. | Der ønskes konstant overvågning af den virtuelle serverdrift og drift af selve applikationen, hvor udfald bliver rapporteret til kunden indenfor 10 minutter via opkald. Leverandøren iværksætter selv genetablering af driften straks, og afrapporterer til kunden via opkald, når |
...
Leverandøren bedes beskrives, hvordan det overvåges, at løsningen fungerer.
Backup og gendannelse
...
driften er genetableret. | ||
Backup og gendannelse** | Der ønskes taget sikkerhedsbackups dagligt, hvor backup ligger på en anden lokation end driftsmiljøet og med en redundant backup i et tredje miljø. Gendannelse af seneste funktionelle backup ønskes indenfor 3 timer i tidsrummet imellem 08:00 og 16:00 på hverdage. Backups skal gemmes i 30 dage, og ældre backups skal slettes automatisk. | Der ønskes taget sikkerhedsbackup af det fulde driftsmiljø hver time, hvor backup ligger på en anden lokation end driftsmiljøet og med en redundant backup i et tredje miljø. |
...
Gendannelse af seneste funktionelle backup ønskes indenfor 1 time i tidsrummet imellem 06:00 og 00:00. Backups skal gemmes i 5 dage, og ældre backups skal slettes automatisk. | |
Brugere | I |
...
perioder med normal drift vil den administrative del af OS2valghalla have |
...
1-2 kommunalt ansatte brugere i gennemsnit pr. kommune. Den eksterne del, som er målrettet deltagerne i valgafviklingen, vil i de fleste tilfælde slet ikke have nogen brugere. | Den administrative del af OS2valghalla vil i gennemsnit have 4 kommunalt ansatte brugere pr. kommune. Den eksterne del, som er målrettet deltagerne i valgafviklingen, vil i de fleste tilfælde have 350 brugere i gennemsnit pr. kommune. Dog vil enkelte store kommuner som Odense, Aarhus og København have 1.000-3.000 brugere. |
SMS-forbrug |
...
Der sendes ingen eller mindre end 650 SMS’er pr. kommune pr. år i gennemsnit. | Der sendes ca. 1.300 SMS-beskeder for en gennemsnitlig kommune i en peak periode. Enkelte større kommuner vil sende mellem 4.000 og 6.000 SMS-beskeder. | |
Support |
...
Der ønskes administratorsupport over mail med en responstid på 8 timer indenfor normal arbejdstid på hverdage ved kritiske fejl og 24 timer ved mindre kritiske fejl. | Der ønskes telefonisk administratorsupport og en responstid på 15 minutter ved kritiske fejl og 30 minutter ved mindre kritiske fejl alle kalenderdage i tidsrummet imellem 06:00 og 00:00 |
...
Afrapportering
I peak perioder ønskes der en daglig afrapportering af driftsmiljøets oppetid, ressourceforbrug og ledig kapacitet.
Periode med normal drift
Drift
I perioder med normal drift ønskes der mulighed for at skrue ned for driftsmiljøets ressourcer, så det kan imødekomme den mindre aktivitet i systemet. Dette skal ske på opfodring af kunden. Reducering af driftsmiljøets ressourcer skal ske indenfor 12 timer af kundens henvendelse.
Anbefalede ressourcer
I perioder med normal drift er de anbefalede ressourcer 2 vCPUs, 4GB RAM og 100GB HDD
Oppetid og genetablering
I perioder med normal drift ønskes en oppetid på 99% indenfor normal arbejdstid og mulighed for genetablering af fuld funktionalitet indenfor 8 timer indenfor normal arbejdstid.
Nedetid og opdateringer
I perioder med normal drift ønskes planlagte nedetider til service og opdateringer lagt indenfor normal arbejdstid og med mindst 14 dages varsel.
Overvågning
I perioder med normal drift ønskes konstant overvågning af serverdriften, hvor udfald bliver rapporteret til kunden indenfor 10 minutter via mail. Leverandøren iværksætter selv genetablering af driften straks og afrapporterer via mail til kunden, når driften er genetableret.
Leverandøren bedes beskrives, hvordan det overvåges, at løsningen fungerer.
Backup og gendannelse
I perioder med normal drift ønskes der taget sikkerhedsbackups dagligt, hvor backup ligger på en anden lokation end driftsmiljøet og med en redundant backup i et tredje miljø. Gendannelse af seneste funktionelle backup ønskes indenfor 3 timer.
Brugere
I perioder med normal drift vil den administrative del af OS2valghalla have 1-2 kommunalt ansatte brugere i gennemsnit pr. kommune. Den eksterne del, som er målrettet deltagerne i valgafviklingen, vil i de fleste tilfælde slet ikke have nogen brugere.
SMS-forbrug
I perioder med normal drift sendes der ingen eller mindre end 650 SMS’er pr. kommune i gennemsnit.
Support
I perioder med normal drift ønskes der udvikler- og administratorsupport over mail med en responstid på 8 timer indenfor normal arbejdstid ved kritiske fejl og 24 timer ved mindre kritiske fejl.
Afrapportering
I perioder med normal drift ønskes der kvartalsvis afrapportering af driftsmiljøets oppetid, ressourceforbrug og ledig kapacitet.
Sikkerhed
Det forventes at leverandøren kan levere et driftsmiljø der lever op til fysiske og digitale sikkerheder, som beskrevet i enten ISO 27001 eller ISAE 3402.
Årligt efter endt revision fremsendes revisionserklæring til kunden.
Kryptering
Kryptering på alle datastrømme skal være minimum TLS 1.2
Installation af nye releases
Nye releases vil blive lavet af en udviklingsleverandør, som udgiver nye releases af OS2valghalla på GitHub med tilhørende release notes. Disse skal efter nærmere aftale mellem kunden og driftsleverandøren installeres på driftsmiljøet af driftsleverandøren.
Der vil som nævnt følge installationsvejledning.
. | ||
Afrapportering | Kvartalsvis afrapportering af driftsmiljøets oppetid, ressourceforbrug og ledig kapacitet. | Daglig afrapportering af driftsmiljøets oppetid, ressourceforbrug og ledig kapacitet. |
* - Leverandøren bedes beskrives, hvordan det overvåges, at løsningen fungerer.
** - Leverandøren bedes beskrive, hvordan og hvor ofte det testes, at backup fungerer.
Aftale om peak periode
Serviceniveauet for peak perioden iværksættes efter henvendelse fra Kunden. Kunden skal indrapportere både start- og slut-tidspunkt for peak perioden.
Datoen for nogle valgtyper som fx kommunalvalg og EU-parlamentsvalg er planlagt flere måneder i forvejen, mens folketingsvalg kan udskrives med 3 ugers varsel. Det betyder, at peak perioden nogle gange vil blive meldt ind 8-10 uger før et valg, mens det i andre tilfælde vil være med kort varsel.
Leverandøren skal reagere på en henvendelse om iværksættelse af peak periode, så serviceniveauet forøges indenfor 24 timer på hverdage.
Sikkerhed
Det forventes, at leverandøren kan levere et driftsmiljø, der lever op til fysiske og digitale sikkerheder, som beskrevet i ISO27001 og ISO27017 samt instruksen i databehandleraftalen.
Årligt efter endt revision fremsendes revisionserklæring til kunden. Leverandør bør kunne levere både ISAE 3000 og ISAE 3402 erklæringer som favner både ISO27001 annex A og ISO27017 til brug for revision. I det omfang at ISO27017 ikke indgår i en revisionserklæring, skal leverandøren være indstillet på at komme med en årlig egenerklæring på, hvordan sikkerheden løftes i særligt den virtualiserede del af infrastrukturen og driften med inspiration fra ISO27017, hvor eksempelvis ISO27001 annex A ikke er dækkende.
Kryptering
Kryptering på alle datastrømme skal være minimum TLS 1.3
Geo-blocking
OS2valghalla skal være blokeret geografisk, så den kun kan tilgås fra Danmark, Sverige og Tyskland.
Penetrationstest
Leverandøren skal kunne muliggøre en penetrationstest udført af en ekstern part. Penetrationstesten ønskes udført i 2024 for at sikre, at løsningen kører og er beskyttet korrekt i produktion, da det er et nyt system, og der mangles erfaring med produktionsmiljøet.
Penetrationstesten vil både være en ekstern og intern test. Eksternt hvor man blindt skyder på løsningen. Internt, hvor man har overtaget en bruger og med brugeroplysninger logger på systemet og indefra ser, om man kan overskride sine rettigheder. Både indenfor den enkelte kommunes tenant og på tværs af kommunerne for at sikre, der er korrekt segmentering og beskyttelse tenants imellem.
Installation af nye releases
Nye releases af OS2valghalla vil blive lavet af en udviklingsleverandør, som udgiver nye releases på GitHub med tilhørende release notes. Et release vil på forhånd være gennemtestet i et testmiljø, som varetages af udviklingsleverandøren.
Nye releases skal efter nærmere aftale mellem kunden og driftsleverandøren installeres på driftsmiljøet af driftsleverandøren. Kunden varetager koordination mellem drifts- og udviklingsleverandør ligesom bugs og udviklingsønsker vil kunne blive indrapporteret på OS2valghalla’s GitHub eller i prjektstyringsværktøjet Jira.
Der vil følge installationsvejledning med nye release, hvis der er afgørende forandringer til det eksisterende.
Stage-miljø
Leverandøren skal stille et stage-miljø til rådighed, hvor nye releases kan afprøves og godkendes af Kunden, inden de sættes i produktion. Stage-miljøet behøver kun være tilgængeligt i forbindelse med installation af nye releases.
Releaseplaner
Det vides endnu ikke, hvor ofte nye releases vil blive udgivet, men der forventes maximum maksimum tre årlige releases, hvortil der kan komme eventuelle hot fixes.
...
Nedenfor ses den ønskede tidsplan. På grund af den korte tidsfrist kan dele af denne diskuteres og tilrettes i samarbejde med leverandør.
Dato/periode | Aktivitet |
|---|
02. |
10.2023 | OS2valghalla frigives i version 3.0 på https://github.com/OS2Valghalla |
11.10.2023 - |
22.10.2023 | Installation og konfiguration af OS2valghalla og opsætning af integrationer til Serviceplatformen, NemLog-in, SMS-gateway, mailserver mv. Indgåelse af grundlæggende databehandleraftale |
23.10.2023 - |
19.11.2023 | Integrationstest i samarbejde med |
Københavns Kommune og Fredericia Kommune Forventet behov for tilrettelser i samarbejde med udviklingsleverandør |
20.11.2023 - 31.12.2023 | Udrulning til resterende kommuner |
Gyldighed
Varighed
Der ønskes en aftale med varighed på 4 år med optioner på 2 gange 12 måneders forlængelse.
...
Kunde og anvendere skal stille en (eller flere) e-mail adresser adresse eller flere til rådighed, hvor leverandøren kan sende driftsinformation vedrørende servicevinduer og lignende. Leverandøren skal sikre, at kunden holdes opdateret om alle driftsrelaterede hændelser via denne kanal.
...
Beskrivelse af leverandørens valgte hostingsetup/infrastruktur og efterlevelse af opgavens krav
Beskrivelse af erfaring med at hoste systemer med integrationer til KOMBIT’s fælleskommunale infrastruktur (Serviceplatformener og Støttesystemer) og NemLog-in
Beskrivelse af kompetencer blandt bemanding på opgaven
Pris opdelt som angivet herunder
Eventuelt nyt Tidsplan inkl. eventuelle forslag til tidsplanændringer
Eventuelle optioner som leverandøren finder relevante
...
Pris ønskes fordelt på flg. poster:
Basisimplementering af OS2valghalla: første installation, konfiguration og opsætning af integrationer
Integrationstest mod fællesoffentlig infrastruktur med en enkelt kommune (to kommuner
Dette er ekskl. udviklingstimer til eventuel nødvendig tilretning af
kildekoden, da denne vil blive udført af udviklingsleverandør
Engangsbeløb for installation og opsætning pr. kommune
Skal dække udgifter til dialog med kommune, oprettelse og konfiguration af tenant og lignende
Årlig samlet hostingpris baseret på antallet af tilsluttede kommunerhostingpris pr. kommune
tilbudsgiver tilbyderDer forventes i tilbuddet en skaleringsmodel, der tager højde for, at det er billigere at drifte systemet for mange kommuner på én gang. Forstået på den måde, at hostingprisen pr. ny tilsluttet kommune fx er lavere ved 40-50 kommuner end ved 20-30 kommuner. Trin kan fx være i 10 kommuner ad gangen.
Prisen for afsendelse af SMS-beskeder op til 30.000 beskeder ønskes inkluderet i den årlige hostingpris. Beskeder udover dette ønskes afregnet efter forbrug, som bedes angivet separat.
Timepris for udført arbejde udover det inkluderede:
Support
Udvikling
Tildelingskriterier
TBD
Forslag:
Kompetencer, der vurderes relevante og som kan nyttiggøres i opgavebeskrivelsen samt anvender metoder og værktøjer, der vurderes egnede i forhold til opgaveløsningen.
Eksisterende erfaringer med at hoste systemer med integrationer til KOMBIT’s fælleskommunale infrastruktur (Serviceplatformener og Støttesystemer) og NemLog-in
Mulighed for at imødekomme ønsket tidsplan
Den tilbudte supportorganisation besidder de for løsningen relevante kompetencer
Kendskab til open source-softwareprodukter
Pris
Inspiration for vurdering af kvalitet fra OS2udoglær udbud:
, end den er for de første 20 kommuner. Trin kan fx være i 10 kommuner ad gangen
Hostingprisen kan indeholde et minimumsbeløb, som er påkrævet for, at en aftale giver mening
Pris for afsendelse af SMS-beskeder efter forbrug
Pt. forventes det, at der sendes op til 30.000 beskeder pr. valg
Timepris for udført arbejde udover det inkluderede
Angiv eventuel forskel i pris ved hasteopgaver, arbejde udenfor almindelig arbejdstid og lignende.
Tildelingskriterier
Leverandørens tilbud vil blive vurderet ud fra disse tildelingskriterier:
Kvaliteten af Leverandørens foreslåede hostingsetup/infrastruktur
Leverandørens kompetencer, der vurderes relevante og som kan nyttiggøres i opgavebeskrivelsen samt anvender metoder og værktøjer, der vurderes egnede i forhold til opgaveløsningen.
tilbudsgiver har eksisterende erfaringer med XXX
Hvordan Tilbudsgiver tænker onboarding af nye kommuner på løsningen
Kriterie: Support og samarbejde
Det vægter positivt, at tilbudsgivers tilbudte support- og samarbejdsformer vurderes at understøtte kundens behov, herunder, men ikke udtømmende, at:
det sandsynliggøres, at den tilbudte supportorganisation besidder de for løsningen relevante kompetencer
den tilbudte samarbejdsform mellem Tilbudsgiver og Kunden vurderes at skabe de bedst mulige forudsætninger for anvendelsen af løsningen og tilbudsgivers opfyldelse af leveringskontrakten.
Tilbudsgiver bedes beskrive:
Hvordan supportorganisationen er sammensat.
Hvilke kompetencer medarbejderne besidder.
Hvilket support ticket-system, der stilles til rådighed for Kunden.Herunder kendskab til anvendte teknologier i OS2valghalla
Leverandørens eksisterende erfaringer med at hoste systemer med integrationer til KOMBIT’s fælleskommunale infrastruktur (Serviceplatformen og Støttesystemer) og NemLog-in
Leverandørens mulighed for at imødekomme ønsket tidsplan
Leverandørens sandsynliggørelse af, at den tilbudte supportorganisation besidder de for opgaven relevante kompetencer
Kendskab til open source-softwareprodukter og OS2-fællesskabet
Pris