Anskaffelse av fagsystem for PPT

Dokumentet omhandler Statens standardavtaler for IT-anskaffelser (SSA-L 2018) – «Avtale om løpende tjenestekjøp over internett». Avtalen gjelder løpende nettbaserte “as a service”-tjenester, inkludert etablering, leveransemelding, godkjenningsprøve, dokumentasjon/opplæring, drift/vedlikehold, vederlag og prisbestemmelser, varighet/avbestilling/avslutning, samt regler for informasjonssikkerhet og personopplysninger, eiendoms- og disposisjonsrett til data, mislighold/sanksjoner (prisavslag, dagbot, heving, erstatning), force majeure, og øvrige kontraktsbestemmelser (bl.a. lønns- og arbeidsvilkår, taushetsplikt, tvisteløsning). I vedlegg 2 (Bilag til avtale) inngår kundens kravspesifikasjon for et skybasert fagsystem til Lillestrøm PP-tjeneste, med omfattende funksjonskrav (dashboard, saksbehandling, tekstbehandling, godkjenning, rapportering), tekniske/arkitekturkrav (API, uttak, hendelser, kryptering, SLA, databehandleravtale), integrasjoner (Folkeregister/KS SvarUt/eSignatur/arkiv m.m.), support/oppetid, sikkerhet og universell utforming, samt plan for implementering/migrering og videreutvikling.

• Alle rubrikker i «Bilag til avtalen» skal være krysset av (ja eller nei).Kilde: Vedlegg 1 - SSA-L.docx (Bilag til avtalen) / 1.2 Bilag til avtalen
• Leverandør skal beskrive hvordan krav oppfylles der krav er markert som M eller M+T (svarmal med JA/NEI og beskrivelse) i bilag til avtalen.Kilde: Vedlegg 2 - SSA-L Bilag.docx (Bilag 2: Leverandørens beskrivelse av tjenesten, gjennomgående kravtabell)
• Leverandør skal laste opp skjermbilder som understøtter besvarelsen for relevante krav (referert til konkurransegrunnlagets punkt 1.5.2.1 / 1.5.2).Kilde: Vedlegg 2 - SSA-L Bilag.docx (flere krav, f.eks. krav 1.1, 1.2, 2.1, 3.1, 5.1 osv.)
• Valgt databehandleravtale skal fremlegges og besvares som en del av tilbudet (databehandleravtale eller DFØ sin standardmal aksepteres).Kilde: Vedlegg 2 - SSA-L Bilag.docx (Krav 8.3 Skytjenester)

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

14.10.2026

Språk

norsk, English

Elektronisk katalog

Tillatt

• Leverandør skal levere tjenesten i henhold til bilag 1 (kundens kravspesifikasjon) og bilag 2 (leverandørens beskrivelse) innen frister i bilag 3, og oppfylle krav til tjenestenivå i bilag 4. Drift av tjenesten er inkludert i vederlaget.Kilde: Vedlegg 1 - SSA-L.docx (punkt 2.1 Leverandørens ansvar for tjenesten) / Innhold pkt. 2.1
• Godkjenningsprøve: Kunden undersøker tjenesten i 10 virkedager (dersom ikke annet er avtalt i bilag 3) etter leveransemelding. Leveringsdag fastsettes etter kundens godkjenning/underkjenning og fristregler. A- og B-feil er vesentlige (med unntak beskrevet), C-feil kan være uvesentlige etter vilkår.Kilde: Vedlegg 1 - SSA-L.docx (3.3 godkjenningsprøve og Leveringsdag) / avtalens kap. 3
• Dokumentasjon/opplæring: Leverandøren skal levere standard produktbeskrivelse/brukerveiledning og annen dokumentasjon (på norsk med mindre annet er avtalt), datert siste versjon. Dokumentasjon leveres senest når godkjenningsprøven starter (med mindre annet avtalt). Leverandør skal bistå med opplæring i den grad avtalt; priser for opplæring fremgår av bilag 6.Kilde: Vedlegg 1 - SSA-L.docx (3.4 Dokumentasjon og opplæring)
• Vedlikehold/oppgradering: Standardoppgraderinger og alminnelig vedlikehold inngår i vederlaget med mindre annet er angitt i bilag 6. Leverandøren skal teste og gjennomføre nødvendige standardoppgraderinger for å oppfylle avtalte krav/tjenestenivå. Standardoppgraderinger i tredjepartsleveranser kan utløse leverandørens plikt til test etter endringer.Kilde: Vedlegg 1 - SSA-L.docx (3.5 Oppgradering/vedlikehold etter Leveringsdag)
• Pris og betaling: Alle priser eks. mva (med mindre annet i bilag 6), betalingstid: faktura forfaller 30 kalenderdager etter leveringsdag (første gang). Krav om elektronisk faktura i godkjent standardformat. Forsinkelsesrenter etter forsinkelsesrenteloven. Heving ved betalingsmislighold etter varsel og frister.Kilde: Vedlegg 1 - SSA-L.docx (4.2 Faktureringstidspunkt og betalingsbetingelser; 4.4 Betalingsmislighold; 4.3 Forsinkelsesrenter)
• Varighet: Ikrafttredelse på undertegnelsesdato. Standard varighet 3 år fra leveringsdag; automatisk fornyelse 1 år med oppsigelsesfrister (3 mnd før fornyelse ved kundens oppsigelse; 12 mnd før fornyelse ved leverandørens oppsigelse) dersom ikke annet i bilag 5.Kilde: Vedlegg 1 - SSA-L.docx (5.1 Varighet)
• Avbestilling: Kunden kan avbestille med 3 måneders skriftlig varsel. Kunden betaler gjennomført del, nødvendige dokumenterte direkte kostnader (omdisponering/utlegg m.m.), samt avbestillingsgebyr 10 % av vederlag fakturert siste 3 måneder før avbestilling (med mindre annet i bilag 6).Kilde: Vedlegg 1 - SSA-L.docx (5.2 Avbestilling)
• Oppetid/SLA og tilhørende mislighold: Dagbot ved forsinkelse (automatisk, 0,15 % av avtalt vederlag for de seks første månedene per kalenderdag innenfor maks 100 dager; kan avvikes i bilag 3). Kunden kan kreve prisavslag/økonomisk kompensasjon ved brudd på tjenestenivå iht. bilag 4. Kunden kan ikke heve så lenge dagbot løper (med unntak ved forsett/grov uaktsomhet).Kilde: Vedlegg 1 - SSA-L.docx (9.2.3 Dagbot; 9.2.4 Økonomisk kompensasjon for brudd på avtalt tjenestenivå)
• Informasjonssikkerhet: Leverandør skal iverksette forholdsmessige tiltak for konfidensialitet/integritet/tilgjengelighet, hindre tap/uønsket endring/sletting og angrep. Data skal holdes atskilt fra tredjepartsdata. Leverandør skal påse at tredjepartsleverandører sikrer Kundens data.Kilde: Vedlegg 1 - SSA-L.docx (6.1 Informasjonssikkerhet) / kapittel 6
• Personopplysninger: Ved behandling på vegne av kunden skal leverandør beskrive hvordan tilfredsstillende behandling oppnås iht. personvernregelverket (inkl. innebygd personvern). Leverandør skal dokumentere sikkerhetstiltak (tilgjengelig for kunde/revisorer og relevante tilsyn). Underleverandører krever kundens tillatelse; overføring utenfor EØS krever overføringsgrunnlag og dokumentasjon. Databehandleravtale må være inngått før behandling.Kilde: Vedlegg 1 - SSA-L.docx (6.2 Personopplysninger)
• Eiendomsrett til data og tilbakeholdsrett: Kunden beholder eiendomsrett til data som overlates for behandling. Leverandøren har ikke tilbakeholdsrett i kundens data. Ved tap/ødeleggelser skal leverandør gjenopprette/rekonstruere data uten ugrunnet opphold (med kostnadsregler og unntak for tredjepartsleveranser).Kilde: Vedlegg 1 - SSA-L.docx (7.2 Eiendomsrett til data; 8 Rekonstruksjon av data)
• Oppsigelse/avslutning: Ved avslutning skal tjenesten forbli fullverdig i avslutningsperioden. Leverandør skal bistå oppfølgende i inntil 30 dager etter at tjenesten er etablert hos ny leverandør eller hos kunden, samt legge til rette for overføring av data, lisenser/disposisjonsrett, andre kontrakter og oversikt over brukere. Kunden kan holde tilbake siste betalingstermin inntil 1 måned ved behov for sanksjonering.Kilde: Vedlegg 1 - SSA-L.docx (5.3 Avslutning av avtalen)
• Konfidensialitet: Taushetsplikt for taushetsbelagt info; ikke hindre utlevering ved lovpålagt offentlighet/innsyn. Taushetsplikt gjelder også etter opphør og opphører etter 5 år (med lovunntak).Kilde: Vedlegg 1 - SSA-L.docx (11.3 Taushetsplikt)
• Lønns- og arbeidsvilkår: Leverandør skal sikre ikke-dårligere lønns- og arbeidsvilkår enn allmenngjort/lokal landsomfattende tariff, gjennomføre tilsvarende betingelser i underleverandøravtaler, og dokumentere via bilag 5 (egenerklæring/tredjepartserklæring). Ved brudd kan kunden holde tilbake deler av kontraktssummen.Kilde: Vedlegg 1 - SSA-L.docx (11.2 Lønns- og arbeidsvilkår)

• Dokumentutdraget viser ikke selve tildelingskriteriene (navn/vekt) eller prisleverandørens evalueringsformel utover at kravtyper «M+T»/«B+T» indikerer evaluering innen relevante kriterier.
• Kvalifikasjonskrav (i betydningen leverandørens kvalifikasjoner som avvisnings-/utvelgelseskriterier) er ikke presentert i utdraget; teksten domineres av kontraktsvilkår og funksjonelle/tekniske krav i bilag 1/2.
• «Bilag 4» (tjenestenivå med standardiserte kompensasjoner) og «Bilag 5» (administrative bestemmelser) inneholder detaljer som ikke fremgår av utdraget utover varighetspassasje og henvisninger; derfor er konkrete SLA-kompensasjonsnivåer ikke utledet.
• Oppetid/SLA-krav er bare delvis gjengitt (krav 8.7 i vedlegg 2), mens avtalens konkrete SLA-unntak og rapporteringsmekanisme ikke er dokumentert i utdraget.
• Dokumentet «Vedlegg 3 - Veiledning sladding» omhandler innsynsrett/sladding, men inneholder ingen konkrete krav til leverandørutforming utover generelle rettslige henvisninger.

Punkter der konkurransedokumentene åpner for tolkning, og der en presisering fra oppdragsgiver kan ha betydning for prising og risiko. Spørsmål kan stilles innen fristene som er angitt i konkurransegrunnlaget.

1. I krav 1.1 (Saksbehandler dashboard, M+T) og 1.2 (tilpasning av dashboard, B+T) ber dere leverandør laste opp skjermbilder og beskrivelse, og dere viser til evalueringsbeskrivelse i punkt 1.5.2.1. Kan dere bekrefte hva dere vil vektlegge i evalueringen av disse to kravene (f.eks. hvilke elementer i dashboard som er mest styrende), og hva som er minimum forventet innhold i skjermbildene?

   Hvorfor det er verdt å spørre: Ulik tolkning av hva som evalueres i dashboard kan gi feil opplysningsnivå og feil dokumentasjonsformat i tilbudet.

   Kilde: Bilag 1, krav 1.1 og 1.2 (henviser til konkurransegrunnlaget punkt 1.5.2.1)

2. I krav 2.2 (send ut hoveddokument med vedlegg til både offentlige og private instanser, M) ber dere om funksjon som støtter utsending, men utdraget sier ikke hvilke kanaler/protokoller dere forventer. Kan dere presisere hvilke utsendingskanaler som skal støttes (f.eks. KS SvarUt/annen postløsning, e-post, og/eller integrasjon mot konkrete offentlige mottak), og om det finnes krav til format/vedleggshåndtering?

   Hvorfor det er verdt å spørre: For å prise riktig må leverandøren vite hvilken utsendingsintegrasjon og hvilke leveranseformater som ligger i kravet.

   Kilde: Bilag 1, krav 2.2

3. I krav 3.6–3.7 (lydopptak/transkribering og KI/støttefunksjoner for tekstbearbeiding, begge B+T) ber dere leverandør beskrive om funksjonene er KI-baserte. Kan dere avklare hvilke personvern- og informasjons­sikkerhetsforutsetninger som gjelder spesifikt for KI-funksjonalitet i denne løsningen (f.eks. datagrunnlag/om input brukes til modelltrening, og om det finnes egne kommunespesifikke begrensninger), slik at tilbudet kan utformes korrekt?

   Hvorfor det er verdt å spørre: KI-funksjoner kan medføre ekstra risiko og kostnader; leverandøren må vite hvilke KI-personvernforutsetninger som forventes dokumentert før tilbud.

   Kilde: Bilag 1, krav 3.6 og 3.7

4. I krav 5.1 (statistikk/rapporter, M+T) og 5.2 (visuelle oversikter, B+T) beskriver dere hvilke rapporttyper dere ønsker, men dere viser igjen til evalueringsbeskrivelse i punkt 1.5.2.1. Kan dere konkretisere hvilke rapporter/parameterkombinasjoner dere anser som «eksempelvis» og hva som er minimum nødvendig for å anses oppfylt, samt hvordan «egne variabler» skal forstås i evalueringen?

   Hvorfor det er verdt å spørre: Utydelig avgrensning mellom må- og evalueringsrelevant funksjonalitet kan gi ufullstendig rapportoppsett i tilbudsbeskrivelsen.

   Kilde: Bilag 1, krav 5.1 og 5.2 (henviser til konkurransegrunnlaget punkt 1.5.2.1)

5. I krav 6.3 (folkeregister/KRR og hendelsesbasert oppdatering) angir dere flere konkrete funksjonsforutsetninger: låsing av felt/objekt, overstyring med lokal verdi og ivaretakelse for adressekode. Kan dere spesifisere hvilke «hendelser» dere forventer at integrasjonen baserer seg på, og hvordan dere ønsker at leverandøren skal beskrive håndteringen av tilfeller der KRR/folkeregisterdata endrer seg i konflikt med lokal overstyring?

   Hvorfor det er verdt å spørre: Integrasjonslogikk ved konflikter og hendelsesmodell påvirker både løsningsdesign og tilbudt leveranseomfang.

   Kilde: Bilag 1, krav 6.3

6. I krav 7.6 (inkrementelle uttrekk) og 7.6.1 (identifisere slettede data) ber dere beskrive mekanisme, men dere angir ikke om slettinger må leveres som «tombstones»/markeringer eller om det skal håndteres på annen måte. Kan dere opplyse hvilken forventet semantikk dere legger til grunn for slettinger, og hvilke typer entiteter (persondata, dokumenter, journalposter m.m.) som må inngå i inkrementelle uttrekk?

   Hvorfor det er verdt å spørre: Uten semantikk for slettinger og avgrensning av entiteter er det vanskelig å prise riktige løsninger og sikre korrekt datakvalitet i uttrekk.

   Kilde: Bilag 1, krav 7.6 og 7.6.1

7. I krav 7.7 (kommunen skal ha mulighet til uttrekk av bevaringsverdig dokumentasjon) ber dere leverandør beskrive hvilke uttrekksformat som støttes. Kan dere avklare hvilke uttrekksformater dere forventer (f.eks. strukturert eksport i spesifikke standarder/metadata-format), og om dere har krav til format for journal-/sak- og dokumentmetadata separat fra dokumentinnhold?

   Hvorfor det er verdt å spørre: Formatkrav bestemmer både utvikling/konvertering og kostnader; leverandøren trenger presisering for å vurdere innsats.

   Kilde: Bilag 1, krav 7.7

8. I krav 8.7 (oppetid minst 99,7% målt per kalendermåned og per år) ber dere leverandør redegjøre for måling og rapportering samt standard SLA og eventuelle unntak. Kan dere bekrefte hvilke hendelser som kan gi unntak fra oppetid/tilgjengelighet (f.eks. planlagt vedlikehold, force majeure, angrep/DoS, kundespesifikke forhold), og hvilke målemetrikker dere forventer brukt (f.eks. antall minutter utilgjengelig, definisjon av «utilgjengelighet»)?

   Hvorfor det er verdt å spørre: SLA-måling og unntak kan gi vesentlig risiko for leverandøren; tydelig definisjon er nødvendig før tilbudsprising.

   Kilde: Bilag 1, krav 8.7 (og henviser indirekte til Bilag 4 standard SLA)

9. I krav 10.2 (RBAC) og 10.3 (Entra ID/SAML/OIDC, MFA og Windows Hello for Business) ber dere beskrive effekt innen 60 minutter etter oppdatering i IAM. Kan dere presisere hvordan dere måler «senest innen 60 minutter» (fra hendelse i Entra ID til faktisk rolle-/tilgangseffekt i løsningen), og hva som anses som leverandørens ansvar vs. hva som ligger på kundens side (f.eks. conditional access, synk-timing)?

   Hvorfor det er verdt å spørre: Tidskravet kan tolkes ulikt; leverandøren må forstå målepunkt og ansvarsdeling for å levere korrekt og prise riktig.

   Kilde: Bilag 1, krav 10.2 og 10.3

10. I krav 11.7 (integrasjon til arkivkjerne Documaster) ber dere beskrive hvordan journalføring/overføring trigger, og at dere foretrekker KS Fiks arkivintegrasjon. Kan dere bekrefte hvilken arkivintegrasjonsmetode som skal være standard i konkurransen (KS Fiks vs. alternativ), hvilke konkrete triggere som forventes for arkivering (f.eks. når dokument signeres, godkjennes, eller når sakkyndig vurdering ferdigstilles), og hvordan dere ønsker at feilretting/feilhåndtering skal fungere ved arkivoverføring?

    Hvorfor det er verdt å spørre: Arkivintegrasjon er ofte ressursdrivende; tydelige triggere og feilhåndteringsforventninger gjør tilbudsinnsats og pris mer korrekt.

    Kilde: Bilag 1, krav 11.7