Timer og dager kan forsvinne når en leverandør holder igjen administratorrettigheter, nøkler eller brukertilgang – bevisst eller ubevisst. Det kan gjelde alt fra domene og e-post til Microsoft 365, regnskapssystem, betalingsløsning, nettbutikk, CRM eller kassasystem. Noen ganger skjer det fordi leverandøren ønsker å sikre betaling eller kontrollere endringer, andre ganger fordi eierskap og roller ikke var tydelig avklart fra start.
Det gode nyheten er at forsinket tilgang kan forebygges med en kombinasjon av smarte kontraktspunkter, tydelig ansvarsmatrise og praktiske, tekniske grep. Nedenfor får du en konkret steg-for-steg tilnærming som både reduserer risiko og forkorter tiden fra bestilling til du har full kontroll.
Hvorfor leverandører kan forsinke tilgang
Tre hovedårsaker går igjen: uklart eierskap til kontoer/tenants (f.eks. domene eller Microsoft 365), manglende overleveringsrutiner (f.eks. ingen definert admin-handover), og økonomiske/kommersielle insentiver (f.eks. utestående faktura eller leverandørens ønske om å binde kunden).
- Uklart eierskap: Tjenesten er satt opp i leverandørens kundeportefølje eller på leverandørens konto (f.eks. domene registrert på byrået, ikke på selskapet ditt).
- Teknisk avhengighet: API-nøkler, SSO, DNS eller betalingsintegrasjoner er bundet til leverandørens systemer – og tåler ikke rask flytting uten avbrudd.
- Prosessfeil: Ingen tydelig sjekkliste for overlevering, eller manglende definisjon av hva «tilgang» faktisk betyr (bruker vs. administrator vs. eierskap).
- Konflikter: Uavklarte krav, reklamasjoner eller utestående betaling tas «gisler» i form av tilbakeholdt tilgang.
Det meste av dette kan ryddes opp i før oppstart – og mye av resten kan fjernes ved å velge riktig kontostruktur og rettslig rammeverk.
Avtalefesting før kjøp og oppstart
Få på plass kontraktsvilkår som eksplisitt beskriver rettigheter, frister og konsekvenser. Dette er spesielt viktig i oppstart og ved bytte av leverandør.
- Definer «tilgang» eksplisitt: Eierskap, global administrator, API-nøkler, SSO, DNS, database, backups og loggtilgang. Skill mellom bruker og administrator, og mellom administrator og eier.
- Frister og milepæler: Skriv inn konkrete datoer/SLAs for når administratorrettigheter og nøkler skal leveres. Knytt betaling til at milepæler er oppfylt.
- Exit-klausul og step-in-rett: Ved oppsigelse eller tvist skal du kunne tre inn og overta drift midlertidig. Krav om bistand til rimelig timepris.
- Dataportabilitet: Format (f.eks. SAF-T for regnskap, CSV/JSON for eksport), kompletthet, og frist for utlevering. Sikre rett til kontinuerlig eksport ved behov.
- Underleverandører: Leverandøren må opplyse om underleverandører og sikre at dine rettigheter også gjelder der (flow-down).
- Sanksjoner ved forsinkelse: Dagmulkt eller servicekreditter hvis tilgang ikke er levert innen avtalt tid.
- Sikkerhet og roller: Krav om rollebasert tilgang (RBAC), minst to uavhengige administratorer hos deg, og tidsbegrenset «privileged access» for leverandør.
Sørg også for at leverandøren kun får delegert administratortilgang, ikke eierskap, der plattformen støtter det (f.eks. partner delegated admin i Microsoft 365). Det gjør bytte enklere uten nedetid.
Tekniske eierskap du alltid bør beholde
Forretningskritiske nøkler og «root»-kontoer må ligge hos selskapet ditt – aldri hos leverandøren. Her er de viktigste områdene.
Domene og DNS
- Du skal være registrant: Registrer .no-domenet i selskapets navn og organisasjonsnummer. Se regler hos Norid.
- Registrarkonto i eget navn: Ha egen konto hos registrar; gi leverandøren begrenset tilgang. Oppbevar autorisasjonskode (EPP) i passordhvelv.
- DNS-kontroll: Bruk egen DNS-løsning eller konto; gi leverandøren rollebasert rettighet.
E-post, Microsoft 365 og Google Workspace
- Opprett tenant selv: Selskapet oppretter selve leietakeren/tenanten. Leverandøren får kun delegert admin.
- Minst to globale administratorer fra selskapet. Opprett «break-glass»-konto med MFA og sikker lagring.
- Lisenskjøp uavhengig: Kjøp lisenser slik at de kan flyttes uten leverandørlås.
Skytjenester (AWS, Azure, GCP)
- Root-eierskap: Selskapet eier root/subscription. Leverandøren får tidsbegrensede roller gjennom IAM.
- Landing zone og separasjon: Skill miljøer (prod/test) og prosjekter slik at bytte påvirker minst mulig.
- Automatisert infrastruktur: IaC (f.eks. Terraform) lagres i ditt repo. Gi leverandøren contributor-rolle, ikke owner.
Regnskap og betalingsintegrasjoner
- Konto opprettes i selskapets navn: Ikke la byrå stå som eier i økonomisystemet.
- Standardiserte eksportformater: Sørg for SAF-T, SIE/CSV/JSON-eksport uten leverandørbistand.
- Autopay/Bankintegrasjoner: Hovedavtale signeres av selskapet. Regnskapsfører får rolle, ikke eierskap.
Bank og Altinn
- Roller i nettbank: Tildel roller selv. Ryddig struktur for attestasjon og betalingsflyt fra dag 1.
- Altinn-roller: Styreleder/daglig leder skal ha tilgangsstyring og nødvendige tjenestetilganger. Ikke la byrå være eneste portvokter.
Med disse grepene kan leverandøren jobbe effektivt uten at selskapet gir fra seg nøklene til butikken.
Kjøp av hylleselskap: sikring av tilganger dag 1
Ved kjøp av hylleselskap bør overleveringen være ekstremt tydelig. Be om en konkret plan for når du får roller i Altinn, tilgang til bankoppsett og kontroll på domene/e-post dersom dette inngår. Digitale endringer som navneendring har et gebyr på kr 1276, og tidspunktene påvirker ofte når systemtilganger kan ferdigstilles.
- Overleveringsmøte dag 0–1: Overfør alle nøkler og roller. Bekreft skriftlig.
- Administratortilgang dag 1: Minst to personer hos dere skal ha full admin på e-post, domene/DNS og eventuelle systemer satt opp av leverandøren.
- Uavhengige konti: Alle tjenester opprettes i selskapets navn og betaling skjer fra selskapets kort/faktura.
Usikker på hvilken leverandør som håndterer overlevering ryddigst? Det kan lønne seg å sammenligne hylleselskaper på forhånd for å se hva som faktisk inngår i prisen og hvor raskt du får reell kontroll.
Husk også at eventuelle midlertidige løsninger (f.eks. midlertidig e-postdomene) bør fases ut innen en avtalt dato, slik at dere ikke låses til leverandørens infrastruktur unødvendig lenge.
Steg-for-steg onboarding som forebygger forsinkelser
- 1) Forklar målbildet: Beskriv hvordan eierskap og roller skal se ut når alt er levert. Del ansvarsmatrise (RACI).
- 2) Etabler uavhengige konti: Opprett domene/registrar, lisensportaler, skykontoer og betalingsprofiler i selskapets navn før leverandøren starter.
- 3) Delegér, ikke overlat: Gi leverandøren tidsbegrenset og sporbart admin via roller; unngå delte «superadmin»-brukere.
- 4) Sikre nøkler og hemmeligheter: Bruk passordhvelv (f.eks. Entra/Azure Key Vault/1Password Business). Del via sikre «vaults», ikke e-post.
- 5) Bekreft milepæler skriftlig: Når administratorrettigheter er på plass, kvitteres det i prosjektloggen – og først da utløses delbetaling.
- 6) Test exit tidlig: Flytt en ikke-kritisk komponent (f.eks. en test-tenant eller sandkasse) for å verifisere at dere kan bytte uten nedetid.
- 7) Dokumenter alt: Lag en driftsbok: arkitektur, roller, nøkler, integrasjoner, backup, kontaktpunkter og eskaleringsvei.
Onboarding er ikke komplett før dere faktisk har logget inn med egne admin-brukere, validert eksportmuligheter og fått bekreftet at leverandørens tilgang kan fjernes uten at noe stopper opp.
Kontroll i drift: revisjon og beredskap
- Kvartalsvis tilgangsrevisjon: Gå gjennom alle admin- og eierroller. Fjern gamle kontoer og juster rettigheter.
- Loggføring og alarmer: Overvåk privilegerte handlinger (opprettelse av brukere, API-nøkler, DNS-endringer).
- Break-glass og MFA: Test at nødkontoer fungerer. Oppbevar MFA-reservekoder sikkert.
- Backup og gjenoppretting: Ta uavhengige backuper og test gjenoppretting jevnlig (tabletop + teknisk restore).
- Årlig exit-øvelse: Simuler leverandørbytte. Hvor lang tid tar det, og hva koster nedetid?
Denne typen internkontroll koster lite, men reduserer risikoen dramatisk for driftsstans og konflikter.
Hvis tilgang stopper opp: hurtigsjekk og nødrutiner
- 1) Fakta først: Hva mangler konkret (eierskap, admin, passord, API)? Logg alt skriftlig.
- 2) Formell henvendelse: Send skriftlig krav med henvisning til kontraktens frister/SLA. Sett en kort frist (f.eks. 24–48 timer).
- 3) Eskalér: Kopi til leder hos leverandøren. Vurder å holde tilbake betaling i tråd med avtale.
- 4) Sikre drift: Aktiver backupløsning, pek DNS til midlertidig side, stans automatiske jobber som kan skade data.
- 5) Ta tilbake kontroll: Bytt passord og trekke tilbake delegert admin der det er mulig. Kontakt registrar/leverandørens plattformstøtte ved eierskapskonflikt.
- 6) Juridiske steg: Varsle mislighold. Dokumentér tap og tiltak. Involver advokat ved behov.
Ha denne listen tilgjengelig i driftsboken, med kontaktinformasjon og mal for varselbrev.
Maler og sjekklister du kan kopiere
- Overleveringsprotokoll: Kontoer, roller, nøkler, domene/DNS, SSO, API, backup, logger. Signeres begge veier.
- Tilgangsmatrise (RACI): Hvem eier hva, hvem kan administrere, og hvem har lesetilgang.
- Exit-sjekkliste: Hvordan eksportere data, fjerne leverandørtilgang, og sette opp ny leverandør uten nedetid.
- Teknisk baselining: Krav til MFA, loggføring, backup, eksportformater og tidsfrister.
- Betalings- og milepælplan: Delbetalinger utløses først ved dokumentert admin/eierskap levert.
Med en slik verktøykasse reduserer du friksjon, kutter risiko for nedetid og står sterkere i både oppstart, drift og ved bytte av leverandør.