Praktisk gjenopprettingsplan for småbedriftens nettsted

Skriv opp funksjonene som holder den daglige driften i gang, ikke alle tekniske deler. En restaurant kan prioritere åpningstider, meny og bordbestilling. En dyreklinikk kan trenge telefonnummer og akuttinformasjon først. Et marint verksted kan være avhengig av skjemaet og informasjon om dekningsområde. Rangér funksjonene, og avtal en midlertidig løsning som ansatte kan aktivere.

Sett to realistiske grenser: hvor lenge bedriften kan klare seg uten funksjonen, og hvor mye nylig innhold eller data fra henvendelser som kan gjenskapes. Dette er forretningsvalg, ikke garantier fra leverandøren. De hjelper webpartneren med å velge kopieringsfrekvens og rekkefølge. Ikke kopier målene til et stort konsern hvis ingen har testet eller finansiert dem.

Lag et privat register over domeneregistrar, DNS, webhotell, nettstedplattform, analyse, skjemalevering og bedriftens e-post. Noter intern kontoeier, leverandør, fornyelsesdato, gjenopprettingsmetode og hvor instrukser er lagret. Ikke legg passord i planen; bruk et administrert passordhvelv og flerfaktorautentisering der tjenesten tilbyr dette.

Gi domenet en egen linje. ICANN beskriver registranten som personen eller virksomheten som har rettighetene til det registrerte domenet, og minner om at registreringen må fornyes for å beholde tilknyttede tjenester. Bruk en adresse bedriften kontrollerer, hold kontaktdata oppdatert, slå på påminnelser og utpek en stedfortreder. Nasjonale toppdomener kan følge sitt lokale registers rutiner.

Et komplett sett kan omfatte nettstedfiler eller kildekode, database, bilder og dokumenter, konfigurasjon, DNS-poster, videresendinger, skjemainnstillinger og en liste over tilknyttede tjenester. Et øyeblikksbilde hos webhotellet dekker kanskje ikke domenet, eksterne skjemaer eller innhold på en annen plattform. Be leverandøren beskrive nøyaktig innhold, hyppighet og hvor lenge versjoner beholdes.

ENISA beskriver 3-2-1-metoden: tre kopier på to typer lagring, med én kopi et annet sted. NCSC anbefaler å holde sikkerhetskopier adskilt fra systemene de beskytter, slik at samme hendelse ikke enkelt rammer begge. Tilpass metoden til plattformen. En synkronisert mappe er praktisk, men kan også synkronisere en feilaktig sletting eller skadelig endring.

En melding om vellykket sikkerhetskopiering viser at systemet forsøkte å lage en kopi, ikke at nettstedet kan gjenopprettes. Planlegg en kontrollert test i et eget testmiljø. Kontroller sider, bilder, språkversjoner, skjemaer, videresendinger og administratortilgang. Registrer hvilken kopi som ble brukt, tidsbruk, mangler og hvem som godkjente resultatet.

Gjør en lett kontroll etter store plattformendringer og en full øvelse så ofte som bedriften faktisk kan opprettholde. Overskriv aldri det offentlige nettstedet bare for å teste. Hvis leverandøren gjør jobben, be om et forståelig resultat og åpne mangler. Planen må endres når et skjema svikter eller en DNS-innstilling mangler.

Førstesiden skal være kort nok til å brukes under press. Den må si hvem som leder, kontakter webpartneren, informerer kunder og noterer beslutninger. Begynn med å bevare spor og bekrefte symptomene fra en enhet og forbindelse dere stoler på. Ikke slett logger, bygg opp alt på nytt eller oppgi en årsak før den er fastslått.

NCSC anbefaler å forberede, identifisere hva som skjer, løse hendelsen, rapportere til relevante parter og lære etterpå. Kortet bør inneholde leverandørens akuttkontakt, intern eskalering, en godkjent midlertidig kundemelding og riktig nasjonal rapporteringsvei. Krav varierer etter land og hendelse; hent kvalifisert lokal rådgivning når de kan være aktuelle.

Hvert kvartal kan bedriftseieren og webpartneren bruke 20 minutter på å bekrefte kontoeiere og kontakter, kontrollere fornyelse av domene og webhotell, finne den nyeste separate kopien, gjennomgå store endringer og prøve den midlertidige kontaktveien. Hvert punkt skal ha navn og dato, ikke bare den uklare teksten «IT ordner det».

Etter et avbrudd noterer dere hva kundene opplevde, hva som virket, hva som forsinket gjenopprettingen og hvilken instruks som manglet. Oppdater planen og fjern gammel tilgang. Resultatet er én privat side støttet av konto- og sikkerhetskopiregistre. Den fjerner ikke all risiko, men gir et lite team en ordnet og testbar vei tilbake.