Sikkerhetskulturprogram

Statsforvalterens fellestjenester skal anskaffe et skybasert sikkerhetskulturprogram som inkluderer verktøy/gjennomføring av phishingtester og opplæring/bevisstgjøring for ansatte (ca. 2900). Løsningen skal støtte kontinuerlige phishing-simuleringer og læringsaktiviteter, rapportering av mistenkelige e-poster, tilbakemeldinger/veiledning, brukerhåndtering/SSO mot Microsoft Entra ID, statistikk/eksport, samt oppfyllelse av personvern- og informasjonssikkerhetskrav. Kontrakt iht. Statens standardavtale SSA-L (løpende tjenestekjøp over internett).

• Leverandør skal være registrert i foretaksregister, faglig register eller handelsregister i den staten leverandøren er etablert.

  Dokumentasjon: Norske selskaper: firmaattest. Utenlandske selskaper: godtgjørelse på at selskapet er registrert i tilsvarende register.

  Kilde: Pkt. 5.1 Egnethet (registrering, autorisasjoner mv.)
• Leverandør skal ha økonomisk og finansiell kapasitet til å utføre kontrakten.

  Dokumentasjon: Kredittvurdering basert på siste kjente regnskapstall. Rating A, B eller C hos Creditsafe skal være tilstrekkelig. Oppdragsgiver innhenter kredittopplysninger (creditsafe.no). Alternativ dokumentasjon ved saklig grunn.

  Kilde: Pkt. 5.2 Økonomisk og finansiell kapasitet
• Ved støtte på kapasitet fra andre virksomheter: leverandør kan støtte seg på andre virksomheters kapasitet for økonomisk/finansiell kapasitet og/eller tekniske/faglige kvalifikasjoner.

  Dokumentasjon: Forpliktelseserklæring fra støttende virksomhet (mal vedlegg B) og separate ESPD-skjema for virksomheten(e).

  Kilde: Pkt. 5.3 Støtte fra andre virksomheter

• ESPD-skjema skal fylles ut og leveres sammen med tilbudet; alternativt separate ESPD-skjema for støttende virksomheter og/eller deltakende leverandører i fellesskap.Kilde: Pkt. 4.1 Generelt om ESPD og pkt. 8.3 Innhold og struktur (0. Utfylt ESPD-skjema)
• Tilbudsbrev skal fylles ut, signeres av person med fullmakt til å pådra leverandøren forpliktelser, og leveres innen tilbudsfristen (benytt mal vedlegg A).Kilde: Pkt. 8.3 Innhold og struktur (1. Tilbudsbrev) samt Vedlegg A Tilbudsbrev
• Dersom leverandør støtter seg på andre virksomheters kapasitet: Forpliktelseserklæring skal leveres (mal vedlegg B).Kilde: Pkt. 8.3 Innhold og struktur (2. Forpliktelseserklæring)
• Forbehold og avvik: leverandøren skal levere liste over avvik/forbehold basert på mal i vedlegg C; vesentlige avvik medfører avvisning.Kilde: Pkt. 8.3 Innhold og struktur (3. Forbehold og avvik) og Vedlegg C
• Sladdet tilbud og egenerklæring/begrunnelse ved taushetsbelagte opplysninger (mal vedlegg D).Kilde: Pkt. 8.3 Innhold og struktur (4. Sladdet tilbud) og Vedlegg D
• Dokumentasjon/besvarelse av tildelingskriterier: Leverandør skal besvare krav i vedlegg E (med unntak av pris).Kilde: Pkt. 8.3 Innhold og struktur (5. Dokumentasjon på oppfyllelse av tildelingskriterier)
• Utfylt prisskjema (vedlegg F) med alle etterspurte felter.Kilde: Pkt. 8.3 Innhold og struktur (6. Utfylt prisskjema) og Vedlegg F
• Innlevering av tilbud skal skje via KGV (ikke e-post/papir) innen tilbudsfrist; tilbudet kan revideres helt opp til fristen.Kilde: Pkt. 8.1 Innlevering av tilbud

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

05.10.2026

Språk

norsk, English

Elektronisk katalog

Ikke tillatt

• Kontraktsvilkår: SSA-L – Statens standardavtale for løpende tjenestekjøp over internett (med bilag).Kilde: Pkt. 1.3 Avtalevilkår
• Varighet: 2 år fra 1. desember 2026 til 30. november 2028, med opsjon for oppdragsgiver på forlengelse 1 år to ganger (1+1).Kilde: Pkt. 1.4 Varighet og opsjon
• Økonomisk ramme: ytre kostnadsramme 2,2 millioner kroner eks. mva. for hele avtaleperioden (4 år). Tilbud over rammen aksepteres ikke.Kilde: Pkt. 1.5 Økonomisk ramme
• Krav til leveransen (utdrag): norsk sluttbrukergrensesnitt, løpende phishing-simuleringer og læringsaktiviteter gjennom året, tilbakemelding/veiledning ved feilhandlinger, støtte for rapportering/klassifisering av mistenkelige e-poster, SSO mot Microsoft Entra ID, statistikk og eksport (Excel/CSV/PDF), rollebasert tilgang, logging av relevante hendelser, etablert sårbarhetshåndtering/sikkerhetsoppdateringer/hendelseshåndtering og varsling av oppdragsgiver.Kilde: Vedlegg E Bilag 1 (krav 1.1, 2.1–2.5, 3.1–3.3, 5.1–5.2, 6.2, 6.3, 8.1–8.5, m.fl.; alle A- og B-krav skal besvares)

• Dokumentteksten angir ikke fullstendig alle tildelings- og kravreferanser fra vedlegg E (kun deler er gjengitt).
• Det fremgår ikke her hvilke spesifikke SLA-tjenestenivåkrav som skal inngå i tilbudt SLA (kun at SLA skal vedlegges som dokumentasjon, jf. krav 9.3 B).
• Databehandleravtalens bilag A–C er ikke komplett gjengitt for lokasjon/tilsyn utover det som fremgår; eventuelle konkrete underdatabehandlere/lokasjoner listes ikke i utdraget.
• Det fremgår ikke hvilke konkrete kredittvurderingskriterier som gir avvisning utover at Creditsafe rating A–C er tilstrekkelig.

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. Vedlegg 1 (krav 2.1) krever at løsningen skal støtte et kontinuerlig læringsløp med regelmessige phishing-simuleringer og læringsaktiviteter gjennom året. Kan dere presisere hva som menes med “regelmessige” i denne konkurransen (f.eks. antall simuleringer per måned/kvartal og om krav omfatter også læringsaktiviteter som eget opplegg mellom simuleringene), slik at vi kan prise korrekt?

   Hvorfor det er verdt å spørre: Usikkerhet om faktisk frekvens og volum påvirker både kapasitet og pris, og kan gi risiko for avvik mot A-krav 2.1.

   Kilde: Vedlegg E, krav 2.1

2. Vedlegg E (krav 2.4) krever løpende oppdatering av phishing-simuleringer og læringsinnhold i tråd med aktuelle phishingmetoder og utviklingen i trusselbildet. Hvilke konkrete elementer skal oppdateres (maler, domener/avsendere, variantenivå, læringsinnhold, analyser/tilbakemeldingslogikk), og hvor ofte forventes oppdatering (f.eks. per måned/kvartal eller ved endringer i trusselbildet)?

   Hvorfor det er verdt å spørre: Pris og leveransemodell avhenger av om oppdatering er “kontinuerlig” eller hendelsesstyrt, og hva som faktisk inngår.

   Kilde: Vedlegg E, krav 2.4

3. Vedlegg E (krav 2.2) krever at simuleringer og læringsaktiviteter kan tilpasses brukere basert på tidligere handlinger. Kan dere beskrive hvilke “tidligere handlinger” dere forventer at løsningen skal bruke som trigger/inputs (f.eks. klikk på lenke, åpning av e-post, feilrapportering, testscore, gjennomført læringsmodul), og om tilpasningen skal skje i sanntid eller kan være batch/ved neste kampanje?

   Hvorfor det er verdt å spørre: Tilpasningsreglene påvirker krav til datamodell, integrasjoner og innholdsmotor, og er avgjørende for å levere riktig funksjonalitet innen A-krav 2.2.

   Kilde: Vedlegg E, krav 2.2

4. Vedlegg E (krav 3.4) er et “Bør krav” om at brukeren skal få tilpasset tilbakemelding når e-poster fra forhåndsdefinerte domener rapporteres som phishing. Hvordan ønsker dere at tilbakemeldingen skal “tilpasses” (f.eks. tekst, læringsaktivitetens type, varighet, anbefalt neste trinn), og finnes det et forventet omfang av antall domener/kategorier som skal støttes per virksomhet?

   Hvorfor det er verdt å spørre: Tilpasningsdybde og forventet domene-/regelvolum påvirker løsningsdesign og kostnader, og kan påvirke score på B-krav 3.4.

   Kilde: Vedlegg E, krav 3.4

5. Vedlegg E (krav 5.1) krever statistikk/rapporter filtrerbar etter virksomhet, organisatoriske enheter og tidsperioder. Kan dere bekrefte hva som regnes som “organisatoriske enheter” i løsningen for denne avtalen (f.eks. nivåer/roller i STAF-strukturen), og om det også forventes rapportering per “embete”/enhet utover filtrering (f.eks. aggregering, rangering, eksport av spesifikke KPI-er)?

   Hvorfor det er verdt å spørre: Krav til datagranularitet og rapporteringsstruktur må forstås for å kunne levere riktig funksjonalitet og kostnadsestimere utvikling/konfigurasjon.

   Kilde: Vedlegg E, krav 5.1

6. Vedlegg E (krav 6.1) krever at løsningen skal håndtere STAF og de 10 statsforvaltervirksomhetene som egne virksomheter, med egen organisasjonsstruktur og nivåer, og at STAF skal administrere sentralt. Kan dere gi en kort oversikt over hvordan organisasjonsstrukturen er ment å speiles (hvilke nivåer finnes, forventet dybde, og eventuelle krav til navngivning/skalering), slik at vi kan svare korrekt i tilbudet?

   Hvorfor det er verdt å spørre: Organisasjonskartet påvirker konfigurering av roller, tilgang og rapportering, og er sentralt for A-krav 6.1.

   Kilde: Vedlegg E, krav 6.1

7. Vedlegg E (krav 6.2) krever SSO og henting av brukeropplysninger fra Microsoft Entra ID, samt automatisk opprettelse, oppdatering og deaktivering. Hvilke konkrete attributter fra Entra ID skal vi forvente at dere ønsker brukt (f.eks. displayName, mail, userPrincipalName, department, jobTitle, manager), og finnes det krav til mapping/standardisert organisasjonsdata for å understøtte deres organisasjonsstruktur?

   Hvorfor det er verdt å spørre: Feil attributt/mapping kan gi avvik i brukerlifecycle og tilgang, og kan gjøre A-krav 6.2 vanskelig å oppfylle.

   Kilde: Vedlegg E, krav 6.2

8. Vedlegg E (krav 8.3) krever at løsningen logger relevante sikkerhets- og administratorhendelser. Kan dere presisere hvilke hendelseskategorier dere anser som “relevante” (f.eks. innlogging/SSO, mislykkede pålogginger, endringer i konfigurasjon, opplæringspublisering, eksport/aksess til rapporter, brukeradministrasjon) og om dere forventer at hendelseslogger kan hentes/eksporteres (og i så fall i hvilke formater)?

   Hvorfor det er verdt å spørre: Presisering av loggtyper og tilgjengelighet påvirker implementasjon og kan være avgjørende for å oppfylle A-krav 8.3.

   Kilde: Vedlegg E, krav 8.3

9. Vedlegg E (krav 9.2) krever at løsningen skal kunne fungere uten å gjøre unntak i sikkerhetsfilter. Kan dere forklare hva dere legger i “sikkerhetsfilter” i praksis (f.eks. sikre e-postgatewayregler/URL-scanning/anti-phishing-produkter), og om dere forventer at dere selv allerede har forhåndsgodkjent domener/IP-er for phishing-lenker (slik at ingen ekstra allowlisting/unntak trengs)?

   Hvorfor det er verdt å spørre: Dette kravet kan ha stor leveranserisiko hvis det i realiteten krever allowlisting; presisering er nødvendig for å unngå kontraktsmessige avvik.

   Kilde: Vedlegg E, krav 9.2