Når Microsoft går i sort, hvad holder din organisation i gang?

Når en stor cloud provider har et nedbrud, spørger alle det samme: “Hvordan kunne det ske?”

Det bedre spørgsmål er: “Hvad fortsatte med at køre – og hvad frøs?”

For smerten er sjældent, at én applikation er nede. Smerten er, at samlingerne mellem applikationer kollapser: identitet, email, device trust, workflows og den menneskelige vane med “bare at logge ind igen”. Når samlingerne ryger, stopper arbejdet de steder, du ikke havde mærket som “IT-kritiske”.

Den danske hændelse beskrevet i Microsoft-nedbrud rammer hele Danmark: »Den centrale nerve i kommunikationen er ramt« er nyttig af én grund. Den komprimerer en langsomt opbygget risiko til én enkelt dag. Kommuner, regioner og private virksomheder mærkede det alle – men ikke ens. Den forskel er hele pointen.

Her er en skabelon, jeg ville bruge til at køre post-mortem’en – og derefter omsætte den til arkitektur og kontrakter, der fejler blødt, ikke “best effort”.

Det reelle nedbrud er typisk identitet – ikke apps

De fleste organisationer tror, de køber SaaS. I praksis køber de en dependency graph, og topnoden er identitet.

Når identitet er utilgængelig eller inkonsistent, sker tre ting hurtigt:

• Folk kan ikke komme i gang: de kan ikke autentificere sig til de værktøjer, hvor dagens opgaver ligger.
• Support kan ikke hjælpe: helpdesk-scripts bygger på den samme identity plane, som fejler.
• Lokale workarounds bliver blokeret: conditional access, MFA og device compliance stopper “brug bare din telefon”-løsninger.

Derfor rammer artiklens framing af Microsoft som “den centrale nerve i kommunikationen”. Det handler ikke kun om kommunikation. Det er tilladelseslaget for arbejdet.

Vil du have en skarpere intern samtale, så stop med at sige “Microsoft-nedbrud”, og begynd at sige: identity-plane-nedbrud. Den navngivning tvinger det rigtige opfølgningsspørgsmål frem: “Hvad bruger ellers den plane?”

Kortlæg afhængigheder per workflow – ikke per vendor

Concentration risk løses ikke ved at drysse en ekstra vendor ind. Den løses ved at vide, hvilke workflows der skal overleve – og derefter designe den minimale, levedygtige sti for hver.

En enkel måde at gøre det på er at vælge fem workflows, der holder organisationen sikker, compliant og cash-positiv. Spor derefter, hvad de kræver, end-to-end, på en normal dag.

I kommunale miljøer og industriservice samler de vigtigste afhængigheder sig typisk fire steder.

1) Identitet og adgang

• SSO og MFA
• Conditional access policies
• Password reset flows
• Privileged access tooling

Hvis jeres “break glass”-konti ligger i det samme identity-system, er de ikke break glass. De er teater.

2) Email og kalender (fordi det også er jeres workflow-bus)

Email er stadig dér, hvor godkendelser sker, incidents eskaleres, og ad hoc-koordinering opstår, når systemer er nede. Hvis mail er koblet til den samme identity-fejl, mister du din backup-kommunikationskanal, præcis når du har brug for den.

3) Device management og trust

Moderne endpoints er styret – med god grund. Men device management kan blive et skjult single point of failure: compliance checks, certifikatfornyelse, VPN-profiler og evnen til at pushe akut konfiguration.

Under et bredt nedbrud er det umiddelbare symptom ofte: “Min laptop er fin, men jeg kan ikke tilgå noget.” Den strukturelle årsag er, at enheden ikke længere betragtes som trusted.

4) SCADA-adjacent workflows (ikke control loop’et, men people loop’et)

I kritisk infrastruktur er kontrolsystemet ofte segmenteret. Det skrøbelige er alt omkring: vedligeholdelsestickets, alarmer der routes ind i collaboration tools, on-call-rosters, vagtskifte, vendor remote access-procedurer og rapportering.

Control loop’et kan godt fortsætte, men organisationen mister overblik og koordinering. Det er sådan, små fejl bliver til lange fejl.

En praktisk metode: For hvert workflow skal du skrive “Day Zero Minimum”. Det er det mindste sæt handlinger, I stadig skal kunne udføre, hvis identitet, mail og device management er påvirket i 24 timer.

Design til fail-soft: degraderede modes, I kan øve

Business continuity-planer kommer ofte til at lyde som ambitioner. Fail-soft design er noget andet. Det er engineering af en degraderet mode, der bevidst er mindre bekvem, men pålideligt tilgængelig.

Tre design patterns går igen.

Pattern A: Lokal autoritet, time-boxed

I skal have en måde, hvor et begrænset antal personer kan handle uden det centrale identity-system. Det betyder ikke “ingen sikkerhed”. Det betyder alternativ sikkerhed.

• Offline-kapable credentials opbevaret i en sikker fysisk proces (forseglet kuvert, dual control, audit log efterfølgende).
• Tidsbegrænsede lokale konti på nøglesystemer, som kan aktiveres via en manuel approval chain.
• Emergency access-procedurer, der øves kvartalsvis – ikke beundres én gang om året.

Pattern B: Alternate comms, der ikke deler samme failure domain

Hvis jeres incident-kanal er Teams, og jeres identitet er Entra, er det ét domain. Hvis jeres telefonsystem er cloud-managed gennem de samme admin-konti, kan det også være samme domain.

Vælg mindst én kanal, der er operationelt adskilt. Det kan være så simpelt som et forhåndsaftalt SMS-tree for incident-roller, understøttet af en printet roster. Målet er ikke elegance. Målet er en sti, der overlever samme blast radius.

Pattern C: Dataadgang, der ikke kræver hele productivity stack’en

Når “den centrale nerve” rammes, er de umiddelbare blokeringer ofte banale: kontaktlister, procedurer, asset-registre, aktuelle work orders og hvem der er on call.

Gør et lille udsnit tilgængeligt i read-only – offline eller alternate-hosted. Fejlen er at forsøge at replikere alt. Gevinsten er at gøre de 20 sider, der holder organisationen koordineret, tilgængelige når resten forsvinder.

Jeg har engang set en connected product-organisation opdage, under en identitetsforstyrrelse, at det største operationelle tab ikke var dashboards. Det var, at de ikke kunne få fat i den rigtige field technician med den rigtige kontekst. Systemerne var “oppe nok”. Arbejdet var det ikke. Det ændrede, hvordan vi behandlede kontaktdata, rolle-rosters og on-call-overdragelser. Ikke som admin-trivia, men som produktionsinput.

Kontraktér recovery, I kan teste – ikke løfter, I kan citere

Cloud-kontrakter forhandles typisk som procurement. Concentration risk kræver, at man forhandler som risk owner.

Fire klausuler betyder mere end endnu et rabatpoint.

1) Eksplicitte failure modes og support-escalation

Når ting går galt, skal der være klarhed om, hvad I får at vide, hvor hurtigt, og via hvilken kanal – en kanal, der ikke kræver det samme identity-system. “Status page” er ikke nok, hvis adgangen til jeres admin center er brudt.

2) RTO og RPO dér, hvor I faktisk har brug for dem

De fleste organisationer skriver generiske tal, der ser professionelle ud og ikke ændrer noget. Bind targets til de workflows, I kortlagde tidligere. Hvis procurement ikke kan sende purchase orders, eller en region ikke kan koordinere bemanding, er det ikke en “mindre degradering”.

3) Exit og portabilitet, der også dækker identitet og device posture

Exit-planer fokuserer ofte på dataeksport. I reelle nedbrud er identitet og device posture choke points. Jeres exit-rettigheder bør inkludere det, I skal bruge for at genetablere authentication, endpoint trust og admin-adgang et andet sted – under tidspres.

4) Retten til at øve

Man kan ikke påstå robusthed, man aldrig har øvet. Indbyg retten til at køre planlagte tests af jeres degraderede modes. Ikke chaos engineering for sin egen skyld. En kontrolleret rehearsal: “I to timer antager vi, at identitet er utilgængelig. Bevis Day Zero Minimum.”

Hvis det her lyder som mere arbejde, end det er værd, så husk alternativet. I kommer til at lave arbejdet alligevel – bare midt under et nedbrud, med pressede mennesker og politisk varme.

En post-mortem-skabelon, I kan køre i næste uge

Brug nedbruddet som en forcing function. Også selv om I ikke blev ramt direkte – behandl det som jeres near-miss.

1. Skriv tidslinjen i menneskelige termer: Hvornår opdagede folk det først? Hvad prøvede de? Hvad fejlede først? Hvilket arbejde stoppede?
2. Vælg 5 workflows, der skal kunne overleve 24 timer. Navngiv en workflow owner for hver.
3. Spor afhængigheder: identitet, mail, device management, ticketing, comms, filadgang, on-call tooling.
4. Definér Day Zero Minimum for hvert workflow i ét afsnit. Ingen jargon.
5. Design én degraderet sti per workflow – også selv om den er manuel.
6. Udpeg én accountable person til at gøre det virkeligt: dokumentation, adgang, øvelse.
7. Forhandl kontrakt-deltaerne, der gør den degraderede sti mulig at understøtte, inkl. rehearsal-rettigheder og escalation-kanaler.

Det er her, mange organisationer opdager en ubehagelig sandhed: Deres “resilience story” er i høj grad underforstået. Underforstået er det samme som uden ejer.

Hvis du vil have en beslægtet mental model, kan jeg godt lide at spørge “hvad knækker først?” fordi det tvinger præcision frem i stedet for slogans. Jeg bruger samme tilgang i market infrastructure, hvor failure cascades ikke er teoretiske. Det er det samme spørgsmål bag What breaks first in 24/7 tokenized equities: halts or dividends?

Min holdning: fail-soft er et ledelsesvalg – ikke en cloud feature

Målet er ikke at være uafhængig af store providers. For de fleste organisationer er det urealistisk og unødvendigt.

Målet er at være uafhængig af én fejl. Identitet går ned, og I kan stadig koordinere. Email er forsinket, og I kan stadig godkende. Device management er degraderet, og I kan stadig nå kritiske systemer. SCADA-adjacent workflows går ned i tempo, men de gør jer ikke blinde.

Det er sådan “cloud concentration risk” ser ud i virkeligheden. Ikke en linje i et risk register. En tirsdag, hvor folk ikke kan passe deres job.

Designer I til den tirsdag, er I ikke bare mere robuste. I bliver også hurtigere resten af året, fordi I endelig forstår, hvad jeres organisation reelt afhænger af.