RFI - Anskaffelse av styringssystem for informasjonssikkerhet og personvern (ISMS og PIMS) for Buskerud fylkeskommune (BFK)

RFI for markedsdialog om anskaffelse av et styringssystem for informasjonssikkerhet og personvern (ISMS og PIMS) som skybasert hyllevare/konfigurerbar løsning for Buskerud fylkeskommune (ca. 3000 ansatte). Formålet er å samle inn informasjon for å utarbeide kravspesifikasjon og senere gjennomføre anskaffelse. Løsningen skal bygge på ISO/IEC 27002:2022 og ISO/IEC 27701:2025, støtte regulatoriske krav (bl.a. NSM, IKT-forskriften, personopplysningsloven, mfl.) og ha kontroll/samsvar, integrasjoner (API) og rapportering på tvers av moduler. Det omtales også mulig integrasjon/kommunikasjon mot system for kvalitet og internkontroll samt EU-taksonomi-krav for bærekraftige datasentre innen ett år fra kontraktsignering.

• Leverandøren bes sertifisering oppgitt: ISO/IEC 27001 og/eller ISO 27701 (ja/nei; hvis ja, oppgi scope)

  Dokumentasjon: Opplysninger om eventuelle sertifikater og scope på sertifikatet

  Kilde: Del 1, spørsmål 1 (RFI: «Er leverandøren sertifisert…?»)

• Svar på RFI: leverandørens beskrivelse av løsning/oppfyllelse for evalueringspunkter (Del 1)Kilde: Del 1 (RFI: «Del 1: Informasjonssikkerhet» spørsmål 1-4)
• Dersom ikke sertifisert: redegjørelse for hvordan styringssystemet tilsvarer ISO 27001 og/eller ISO 27701, inkl.: risikovurderinger, revisjoner og oppfølging av avvik samt grad av støtte til tredjepartsrevisjoner og tilgang til revisjonsrapporterKilde: Del 1, spørsmål 2-4
• Redegjøre for ISMS-moduler listet i kapittel 4.2 del 2 (inkl. at moduler med overlapp/ikke-passer inn skal forklares). Det bes også om at alle moduler og tilhørende beskrivelser som leverandøren legger ved dekkes med gode referanser.Kilde: Del 2 (RFI: «Tilbyder må redegjøre for følgende moduler…» samt «modulstruktur… gode referanser»)
• Beskrive funksjonalitet for hver oppgitt modul (Governance, GAP-analyser, kontroller, risikovurderinger, trusselvurderinger/trusselkatalog, eiendelsregister, samsvar/compliance, avvik og forbedringsforslag, hendelseshåndtering, sikkerhetsrevisjoner/rapportering, awareness/opplæring, kontinuerlig forbedring, GDPR/DPIA/DTIA/FRIA, behandlingsprotokoll, etterlevelseskontroll av databehandlere, rapporter som omfatter alle moduler)Kilde: Del 2, moduloversikt (RFI: «Modul for …»)
• Beskrive øvrig funksjonalitet utover moduler: tilgangskontroll/autentisering, brukervennlighet, skjerming av personopplysninger, ytelse/responstid, integrasjon med eksisterende systemer, skalerbarhet, KI-styring og kontroll, samt sikkerhetsfunksjoner (inkl. Privacy by Design/OWASP m.m.)Kilde: «I tillegg bør ISMS…» og «Sikkerhetsfunksjoner»
• Beskrive teknisk arkitektur og integrasjon (systemarkitektur, plattformkrav, driftsmodell, API-integrasjoner uten merkostnad for dataopplesing/overføring, standarder for datautveksling/autentisering/autorisering), samt støtte for oppdateringer/videreutvikling/vedlikehold som del av support- og driftsmodellKilde: «Teknisk arkitektur og integrasjon»
• Beskrive implementeringsprosess (faser, tidsintervaller, bistand/involvering fra BFK, prosjektplan, hvilke elementer bistand inkluderer, opplæring/superbruker-roller)Kilde: «Implementeringsprosess»
• Oppgi kostnadsstruktur: lisens- og prisoppsett for ca. 1000–3000 brukere (inkl. modul-/rollepriser), etablering/etableringskostnader (år 1) og årlige kostnader for drift/oppdateringer/support (år 2+). Inkludert oppsett av priselementer og timepriser for konsulenter, samt at test/akseptanseperiode skal være inkludert/avklares i kontrakt.Kilde: «Kostnadsstruktur» (prispunkter 1.1-1.7 og 2.1-2.3; samt år 2 pr år fremover)
• Besvare krav om databehandleravtale (ønske om DFØ-mal, og eventuell redegjørelse ved innvendinger)Kilde: «Databehandleravtale»
• Beskrive service og support: tilgjengelige supporttjenester, responstider, SLA, garantier, lokal support og vedlikeholdstjenester (med ansvarsdeling 1./2./3. linje og SLA-oppetid/RTO/RPO m.m.)Kilde: «Service og support»
• Beskrive oppfyllelse av bærekraftskrav (EU-taksonomi for datasentre): hvordan krav innfris/etterleves, og at leverandør aksepterer kravet ved innlevering av tilbud og kan fremlegge dokumentasjon etter ett årKilde: «Bærekraft – EU-taksonomi»
• Beskrive integrasjon mot systemstøtte for kvalitet og internkontroll: deling av dokumentasjon, samordnet håndtering av risiko/avvik/tiltak, felles rapportering til ledelse, samordnet revisjon/kontroll, åpne/dokumenterte integrasjonsgrensesnitt (API) uten merkostnad, sporbarhet/konsistens; beskrive native vs API-integrasjon, integrasjonsstandarder, modul vs helhetlig plattform, felles datamodell vs mapping, eksempler og eventuelle begrensningerKilde: «Systemstøtte for kvalitet og internkontroll»
• Oppgi om leverandør har egne standardvilkår for SSA-lille sky (og om de skal legges inn i bilag 10)Kilde: «Kontrakt/Standardavtale»

Innleveringsvilkår fra kunngjøringen

Språk

norsk

• EU-taksonomi: datasentrene som benyttes for tjenesten skal operere i henhold til EU-taksonomiens rammeverk for bærekraftige datasentre. Kravet gjelder innen ett år fra signering av kontrakt og ut kontraktsperioden. Leverandør skal godta kravet ved innlevering av tilbud og etter ett år kunne fremlegge gyldig dokument fra uavhengig tredjepart.Kilde: «Bærekraft – EU-taksonomi»
• Støtte for oppfyllelse av regulatoriske krav og etterlevelse/kontroll: løsningen skal ha krav til kontroll for samsvar mot regulatoriske og organisatoriske krav (ISO/IEC 27002:2022, ISO/IEC 27701:2025, NSM grunnprinsipper, IKT-forskriften, beskyttelsesinstruksen, ny digitaliseringslov, personopplysningsloven m.fl.).Kilde: Introduksjon (ISMS/PIMS-rammeverk) + «Det stilles krav til kontroll…»
• Datasikkerhet/leveringskrav nevnt i RFI: kryptering av kommunikasjon (TLS/SSL), tilgangsstyring (RBAC e.l.), håndtering av API-integrasjoner, zero trust/verifikasjon, SDL (security-by-design i utvikling), lagvis beskyttelse, applikasjonstesting, brukeradministrasjon (SCIM), Entra ID; samt data lagres på lokasjoner godkjent innen EU/EØS.Kilde: «Sikkerhetsfunksjoner» (kryptering, tilgangsstyring, API, Zero trust, SDL, SCIM/Entra ID, EU/EØS-lagring)
• Drift/support-SLA forventninger (konkrete krav angitt i RFI): oppetid minimum 99,5 % pr. måned; planlagt nedetid varsles minst 5 arbeidsdager; uforutsett nedetid varsles normalt innen 30 minutter; RTO: kritisk <2 timer, høy <12 timer, normal <2 arbeidsdager; RPO: kritisk <1 time, øvrige <24 timer; automatisk eskalering dersom SLA brytes; kvartalsvis rapportering på SLA, avvik og tilgjengelighet.Kilde: Supplerende SLA-krav (oppetid/RTO/RPO/rapportering)
• Kundeansvar: Kunden er ansvarlig for systemadministrasjon samt 1. og 2. nivå sluttbrukerstøtte; leverandør 3. linje skal støtte 2. linje og korrigere feil i løsning/oppgraderinger (betalbart ved større tilpasninger).Kilde: «Service og support» (ansvarsdeling 1./2./3. linje)
• Kontraktvilkår: Oppdragsgiver vurderer bruk av Statens Standardavtale SSA-lille sky, der tilbyders egne standardvilkår skal inn i bilag 10; leverandøren bes opplyse om de har egne standardvilkår.Kilde: «Kontrakt/Standardavtale»

• Dokumentet er en RFI; endelige tildelingskriterier, vekting og formelle kvalifikasjonskrav fremgår ikke som tildelingsmodell i teksten.
• Kravspesifikasjon er ikke inkludert; modulstruktur refereres til «kapittel 4.2 del 2», men selve kapittelet/vedlegg er ikke vedlagt i utdraget.
• Krav om integrasjoner mot internkontroll/kvalitet er formulert som beskrivelses-/markedsdialogspørsmål, ikke som bindende kontraktskrav i teksten.
• Omfang og nøyaktig definisjon av rollebaserte lisenspriser og hvilke krav som «skal» oppfylles vs «bør» oppgis er delvis uklart (blanding av bør/skal).