Avinor AS - K-193194 - Airport Work Management

Avinor skal anskaffe en digital «Airport Work Management»-løsning for planlegging, koordinering, godkjenning, overvåking og avslutning av arbeid som kan påvirke flyplassoperasjoner (terminal, landside og airside). Løsningen skal støtte felles operativ oversikt, saks-/casehåndtering med roller (innmelder, koordinator, SME, godkjenner, arbeidsleder/site manager) og arbeidsflyt for arbeidstillatelser, inkludert dokumentasjon av regulatoriske og sikkerhetsmessige krav. Leveransen omfatter leveranse/implementasjon/ drift for Airport Concept A (OSL) som første del, samt skalering til Concept B (internasjonale flyplasser utenom OSL) innen 3 år, og opsjoner for Concept C–E.

• Leverandør skal gi innsendt «Completed ESPD self declaration» i TendSign.

  Dokumentasjon: Utfylt ESPD-selvdeklarasjon i TendSign.

  Kilde: Annex 1 – Request for participation («Completed ESPD self declaration in TendSign»)
• Dersom leverandøren støtter seg på andre enheter for å oppfylle kvalifikasjonskrav, skal disse levere «Sub-Contractor Declaration»/underleverandører-klæring og ESPD selvdeklarasjon.

  Dokumentasjon: Sub-Contractor Declaration (om relevant) og fullført ESPD for underleverandør.

  Kilde: Annex 1 – Request for participation (avsnitt om Sub-Contractor Declaration) / Annex 3 – Sub-Contrator Declaration
• Leverandør skal ha erfaring fra relevante og sammenlignbare leveranser (work management system) og liste de tre (3) mest relevante referansene siste fem (5) år.

  Dokumentasjon: Utfylte referanser inkl. verdi (evt. estimat), varighet, omfang/innhold, leverandørrolle/ansvar og kontaktperson (e-post/telefon).

  Kilde: Annex 6 - References – Airport Work Management (jf. «Section 1.2.5.4» i tender documentation)
• Bekreftelse av Avinors «Agreement on Responsible Business Conduct» skal gis som del av deltakelsen/innsendte dokumenter.

  Dokumentasjon: Confirmation of Avinor’s Agreement on Responsible Business Conduct.

  Kilde: Annex 1 – Request for participation («Confirmation of Avinor’s Agreement on Responsible Business Conduct»)
• Bekreftelse av Avinors personvernstatement for anskaffelser (Annex 5) skal gis.

  Dokumentasjon: Confirmation of Avinor’s privacy statement (Annex 5).

  Kilde: Annex 1 – Request for participation («Confirmation of Avinor’s privacy statement (Annex 5)» )

• Sende inn forespørsel om å delta / forespørselsskjema for deltakelse i anbudskonkurransen for «Airport Work Management».Kilde: Annex 1 – Request for participation («We hereby request to participate…»)
• Forespørsel om deltakelse skal inneholde/vedlegge: utfylt ESPD, evt. Sub-Contractor Declaration (om relevant), dokumentasjon for kvalifikasjonskrav/utvelgelseskriterier («Tender documentation – two steps»), samt bekreftelser knyttet til ansvarlig forretningsutførelse og personvernstatement.Kilde: Annex 1 – Request for participation (liste «Enclosed find…»)
• Leverandøren skal levere «Tender cover letter» for «Airport Work Management» og bekrefte at alle betingelser/krav aksepteres med evt. forbehold i tabell.Kilde: Annex 2 – Tender cover letter (Reservations and Deviations)
• Konfidensialitet: Leverandør skal velge alternativ og evt. fylle ut tabell over informasjon som skal holdes tilbake fra offentlighet, samt gi self-declaration om slik avgrensning.Kilde: Annex 4 - Confidential Information (avsnitt «PLEASE CHECK ONE BOX ONLY» og tabell)

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

19.08.2026

Språk

English, norsk

Elektronisk katalog

Ikke tillatt

• Leverandøren skal gjennomføre og levere tjenesten i tråd med krav og beskrivelser i vedlegg (Appendix 1 og 2), innen frister fastsatt (Appendix 3) og med oppfyllelse av servicenivåkrav (Appendix 4).Kilde: SSA-L 2026, clause 2.1 («The Supplier is responsible…») / SSA-L 2026 «Scope of the Agreement»
• Ved tredjepartsleveranser: vilkår for kundens tilgang/bruk skal vedlegges (Appendix 9), og leverandør er ikke ansvarlig for feil oppstått etter leveringsdato i tredjepart, med mindre leverandør kunne/ burde begrense omfang/konsekvenser.Kilde: SSA-L 2026, clause 2.2
• Leverandøren skal ha plan for etableringsfase (dersom det kreves) og levere tjeneste innen oppgitt frist; kunden skal gjennomføre godkjenningstest i 10 virkedager etter leveringsmelding.Kilde: SSA-L 2026, clause 3.1-3.3
• Dokumentasjon og (evt.) opplæring: standarddokumentasjon leveres/tilgjengeliggjøres i norsk språk (med mindre annet avtales), og opplæring støttes i den grad avtalt i vedlegg.Kilde: SSA-L 2026, clause 3.4
• Oppgraderinger/vedlikehold etter leveringsdato inngår som standard (med mindre annet avtales), og leverandør skal teste og gjøre nødvendige standard-oppgraderinger i avtaleperioden.Kilde: SSA-L 2026, clause 3.5
• Databehandling/personvern: Leverandør må beskrive hvordan regelverket etterleves (inkl. krav om overføringsmekanismer) og det kreves databehandleravtale før oppstart av behandling av personopplysninger når relevant.Kilde: SSA-L 2026, clause 6.2
• Informasjonssikkerhet: leverandør skal iverksette tiltak for konfidensialitet, integritet, tilgjengelighet/robusthet, separasjon av kundedata, beskyttelse mot uautorisert tilgang/sletting og sikre at tredjepartsleverandører ivaretar kundedata.Kilde: SSA-L 2026, clause 6.1
• Ansvarlig forretningsdrift: Leverandør skal etterleve Avinors «Supplier Conduct Principles» og etablere rutiner/policy for due diligence senest 6 måneder etter oppstart, samt speile krav nedover i leverandørkjeden og håndtere avvik (forbedringsplan/tiltak uten kostnad for oppdragsgiver).Kilde: Annex 7 - Agreement on responsible business conduct, clauses 1.1, 1.3, 1.5, 1.11-1.12
• Avvik/behandlingsplikt ved manglende etterlevelse innen egen organisasjon: korrigeres uten kost for oppdragsgiver, med forbedringsplan og frister akseptert av oppdragsgiver; enkelte brudd kan normalt lede til oppsigelse/avslutning.Kilde: Annex 7 - Agreement on responsible business conduct, clauses 1.11-1.12
• Konfidensialitet og offentlighet: Konfidensialitetsplikt etter SSA-L fortsetter etter avtaleutløp, men avskjæres ved lovpålagt innsyn; tilleggskrav om utfylling av «Confidential Information» ved tilbud.Kilde: SSA-L 2026, clause 11.3 / Annex 4 - Confidential Information
• Opphør/sanksjoner: Ved vesentlig mislighold kan kunde terminere (umiddelbar virkning etter varsel og rimelig frist for retting), og leverandør har plikt til å legge til rette for overlevering av data ved terminering (inkl. at kundens data ikke skal kunne holdes tilbake).Kilde: SSA-L 2026, clause 5.3 / clause 9.2.5
• Hele avtalen/leveransen gjelder «as-a-service» via internett; pris og endringer reguleres via vedlegg og prisjustering etter indeks/regulatoriske endringer.Kilde: SSA-L 2026, clause 1.1 / clause 4.1-4.5

• Dokumentteksten inneholder ikke eksplisitte tildelingskriterier (navn/vekt/beskrivelse). Tildelingskriterier kan ligge i deler av konkurransegrunnlaget som ikke er inkludert her.
• Tekstutdrag fra «Appendix 1» viser kravklassifisering (Shall/Evaluation/Informational) men inkluderer ikke selve komplette evalueringskriterier eller evalueringsmetode.
• Detaljerte kontraktsvilkår om servicenivå (Appendix 4) og funksjonelle krav-tabeller (SSA-L Appendix 1 Attachment 1-3 / Appendix 2) er ikke vedlagt i tekstutdraget, kun omtalt.

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. For protokollen OpenIDConnect: Hvilke nøyaktige claim-krav skal vår løsning validere og bruke i autorisasjon (utover kravene i Avinor Federation Guidelines, f.eks. nonce/aud/iss/iat/exp), og hvilke konkrete verdier/parametere må vi konfigurere for deres STS (audience/app-ID, issuer-endepunkt, evt. krav til MFA/gruppe-/rolleclaims)?

   Hvorfor det er verdt å spørre: For å prise og dimensjonere utvikling og testarbeid trenger leverandøren å vite hvilke claim- og autorisasjonsregler Avinor faktisk forventer utover generelle verifiseringspunkter.

   Kilde: 5.1.3 og 5.1.4 (id_token/access_token), 4.7 (authorization claim)

2. Dere krever at SLO (Single Logout) skal implementeres for OpenIDConnect, SAML 2.0 og WS-Fed. Hvilke konkrete SLO-mønstre forventer dere at leverandøren implementerer for hver protokoll (f.eks. hvilke endepunkter/redirects, og hvordan vi skal håndtere tilbakespill/feilhåndtering ved delvis logout)?

   Hvorfor det er verdt å spørre: SLO-implementasjon kan variere betydelig mellom protokoller og leverandør-rammeverk; avklaring gir riktig omfang og reduserer risiko.

   Kilde: 5.3 (Single Logout Protocol (SLO))

3. For ADFS “Preferred Primary Solution” (Relying Party Trust): Hvilket FQDN-format skal vi bruke for Avinor-brukdedikert URL, og gir dere en liste over hvilke DNS-alternativer som faktisk er tillatt for denne anskaffelsen (f.eks. applikasjonsnavn.avinor.no vs. avinor.applikasjonsnavn.com), samt hvem som bekoster og administrerer DNS/sertifikater?

   Hvorfor det er verdt å spørre: Dedikert FQDN påvirker kost, fremdrift og avhengigheter; i anbud trengs tydelighet om hvem som gjør hva.

   Kilde: 4.4.1 (ADFS Preferred Primary Solution), inkl. tabellen med gyldige URL-konfigurasjoner

4. For ADFS “Preferred Secondary Solution”: Hvilken løsning velger dere i dette tilfellet dersom Avinor ikke kan få dedikert DNS/host header, og hvilke konkrete data/enheter må dere og vi utveksle over HTTPS (FederationMetadata.xml) (inkl. forventet format/omfang og hvordan dere ønsker at vi tester HRD-cookie-livsløpet)?

   Hvorfor det er verdt å spørre: Secondary-løpet innebærer HRD-cookie og ekstra test/operasjon; leverandøren må forstå hva som kreves i praksis for å prise riktige aktiviteter.

   Kilde: 4.4.2 (ADFS Preferred Secondary Solution)

5. Dere beskriver at applikasjonen ikke skal hardkode OIDC-endepunkter, og at OpenIDConnect Metadata Endpoint skal brukes. Hvilke konkrete metadata-URL-er/parametere får vi tilgang til (AAD/ADFS), og er det forventet at vi støtter både automatisert metadata-oppdatering ved endringer og caching (hvis ja: hvilke intervall/krav)?

   Hvorfor det er verdt å spørre: Metadata/caching påvirker både implementasjon og drift/vedlikehold; avklaring er nødvendig for riktig tilbudsberegning.

   Kilde: 5.1.1 (OpenIDConnect Metadata Endpoint), 5.1.2/5.1.3/5.1.4

6. For WS-Fed/SAML: FederationMetadata.xml innebærer krav om automatisk overvåkning og at token signing certificate skal håndteres med “Primary/Secondary” uten avbrudd. Kan dere spesifisere hvordan dere forventer at leverandøren skal gjøre dette (f.eks. daglig polling vs. annen metode), og om dere har forventninger til verifikasjonstest før sertifikatbytte (inkl. forventet nedetidsakseptanse)?

   Hvorfor det er verdt å spørre: Dette er en sentral teknisk risiko i federasjon og direkte kostdriver; leverandøren må vite forventet metode og akseptkriterier.

   Kilde: 5.2.2 og 5.2.2.1 (FederationMetadata.xml, Token Signing Certificate / primary-secondary)

7. Når det gjelder kryptering av “Security Token” cookie i WS-Fed/SAML: Hvilke konkrete krav gjelder for sertifikatnavn, nøkkelalgoritme og livsløp i denne konkurransen (navnekonvensjon, SHA256RSA eller høyere, CA-type), og hvordan forventer dere at vi gjennomfører automatisk oppdatering ved fornyelse (API/prosess/ansvar)?

   Hvorfor det er verdt å spørre: Krypteringssertifikat kan medføre både engangskonfigurasjon og løpende vedlikehold; leverandøren trenger å avklare ansvar og operasjonelt opplegg.

   Kilde: 5.2.2.2 (Application Token Encryption Certificate)

8. For identitetsprovisjonering: Hvilken integrasjonsmetode skal vi levere for denne anskaffelsen (Avinor IDM – SCIM/REST som primær, Avinor IDM – SOAP som sekundær), og hvilke SCIM-ressurser/operasjoner må støttebeskrivelsen omfatte (User/Group, CRUD, Search, Bulk)?

   Hvorfor det er verdt å spørre: Provisjoneringsomfanget bestemmer utviklings- og testinnsats; leverandøren må vite nøyaktig hvilke SCIM funksjoner dere forventer.

   Kilde: 4.6 (Provisioning of identities), 4.6.1 (Supported Protocols), 4.6.2.3/4.6.2.4 (User/Group Operations), samt Appendix 9 (SCIM API)

9. Dere krever at program/leverandørens løsning støtter B2B guest brukere med spesial-UPN-format og SCIM-synk. Hvilke scenarier vil dere bruke i dette oppdraget (invitation via Graph vs self-service access package), og hvilke mappingregler forventer dere mellom tenant/e-post og SCIM userName/externalId?

   Hvorfor det er verdt å spørre: Mappingregler for UPN og SCIM-felter kan bli komplekse og påvirker både korrekthet og tid til test/feilsøking.

   Kilde: 4.3.4 (Azure AD B2B Guest Users), 4.6.2 (SCIM attributes overview)

10. Tildelingskriterier og evalueringsmetode er ikke synlig i utdraget: Kan dere bekrefte hvilke kriterier som faktisk evalueres (inkl. eventuelle vekt/poengskala), og om kompetanse/leveransemetode innenfor federation/PKI/SCIM (f.eks. dokumentert etterlevelse av TLS/SLO/certifikat-rotation) inngår som egne underkriterier?

    Hvorfor det er verdt å spørre: Uten eksakt evalueringsoppsett er det vanskelig å prioritere riktig kost/innhold i tilbudet og utforme dokumentasjon som faktisk gir poeng.