Kort svar: Når et kundesite kompromitteres, er rollerne: bureauet tager teknikken (isolér sitet, skift adgange, ryd op, dokumentér) og koordineringen; kunden tager forretningsbeslutningerne og er som dataansvarlig den, der skal vurdere og evt. anmelde brud på persondatasikkerheden til Datatilsynet inden 72 timer; hostingudbyderen leverer logs, isolering og infrastruktur. Skriv rollefordelingen ind i driftsaftalen FØR hændelsen – midt i branden er det for sent at forhandle om, hvem der holder slangen.
Sikkerhedshændelser på kundesites har to spor, og det tekniske er det nemme. Det svære spor er ansvaret: kunden er i panik, myndighedsfrister løber, og alle kigger på dig. Selve oprydningen har vi dækket i akutguiden og malware-oprydningen – her handler det om ROLLERNE: hvem gør hvad, hvornår, og hvad du som bureau skal have på plads, inden det sker.
Uanset hvordan hændelsen opdages (overvågning, kunde, Google-advarsel): 1) Bekræft, at der faktisk er sket noget – og tag skærmbilleder/log-kopier FØR du rører noget. 2) Isolér: sæt sitet i vedligeholdelsestilstand eller bloker trafikken, skift ALLE adgange (WordPress, hosting, FTP, database), og tjek de øvrige sites på samme konto – din adgangsstyring afgør, hvor stor blastradius er. 3) Varslé kunden med det samme, også før du kender omfanget: „vi har opdaget X, sitet er isoleret, vi undersøger og vender tilbage kl. Y“. Kunden må ALDRIG høre om hændelsen fra andre end dig – det øjeblik koster mere tillid end selve hacket.
Bureauet ejer teknikken og koordineringen: undersøgelse, oprydning, gendannelse, dokumentation af forløbet (tidslinje med klokkeslæt – den får du brug for) og én samlet kommunikationskanal til kunden. Kunden ejer forretningen: beslutninger med omkostninger (lukke shoppen? gendanne fra backup med tab af X timers ordrer?), information til DERES kunder – og myndighedssporet, se næste afsnit. Hostingudbyderen ejer infrastrukturen: server-logs, isolering på platformsniveau og svar på, om hændelsen kommer derfra. Vælg derfor et hosting-lag med rigtige mennesker og hurtig reaktion – på Hostious’ bureau-hosting står driftteamet klar, når du står midt i en hændelse. Og skriv HELE fordelingen ind i SLA’en/driftsaftalen, inklusive hvad akut-arbejde koster, hvis hændelsen skyldes noget uden for din kontrol.
Er der persondata på sitet (kundekonti, ordrer, formulardata – det er der næsten altid), skal hændelsen vurderes som muligt brud på persondatasikkerheden. Rollerne er faste: KUNDEN er dataansvarlig og skal anmelde bruddet til Datatilsynet uden unødigt ophold og inden 72 timer, hvis der er risiko for de registrerede; DU er typisk databehandler og skal underrette kunden straks og levere den tekniske redegørelse (hvad skete, hvilke data var berørt, hvad er gjort). Den fordeling – og din underretningspligt – skal stå i jeres databehandleraftale; læs mere i artiklen om bureauets databehandlerrolle. Hjælp kunden med at nå fristen, men lad beslutningen om anmeldelse være deres – på skrift.
Tre regler: fast kadence („ny status hver anden time, også hvis intet er nyt“ – stilhed avler panik), ærlighed uden spekulation (sig, hvad I VED, og hvad I undersøger – gæt aldrig på årsag eller omfang, før I kan dokumentere det), og ét sprog uden jargon („der er placeret fremmed kode, som sender besøgende videre“ slår „JS-injection i header.php“ – jf. jargon-artiklen). Og påtag dig aldrig skylden, før årsagen er fundet – men lov ejerskab: „vi finder ud af det, og vi løser det“ er det, kunden har brug for at høre.
Når sitet er rent og oppe: skriv en kort hændelsesrapport til kunden (tidslinje, årsag, berørte data, udbedring, forebyggelse) – den lukker sagen professionelt og ER samtidig dokumentationen, hvis Datatilsynet spørger. Gennemfør derefter hærdningen, så samme dør ikke står åben (opdateringer, 2FA, oprydning i plugins og adgange), og tag læringen med ind i jeres standardopsætning, så ALLE kundesites får gavn af den. En håndteret hændelse med ordentlig rapport styrker paradoksalt nok ofte relationen – kunden har nu SET, hvad de betaler for.
Beredskab, der aldrig øves, findes kun på papir: kør én årlig skrivebordsøvelse, hvor teamet spiller en hændelse igennem på en time – hvem opdager, hvem isolerer, hvem ringer til kunden, hvor ligger tidslinje-skabelonen? Øvelsen afslører hullerne (den mistede adgang, det forældede telefonnummer), mens de er gratis at lukke.
Det afhænger af årsagen og aftalen: bureauet tager teknik og koordinering, kunden er dataansvarlig over for myndighederne, hosten tager infrastrukturen. Derfor skal fordelingen stå i driftsaftalen på forhånd.
Hvis persondata kan være berørt og der er risiko for de registrerede: ja, af den dataansvarlige (kunden) inden 72 timer. Bureauet underretter kunden straks og leverer den tekniske redegørelse.
Aftal det FØR: mange driftsaftaler dækker hændelser forårsaget inden for bureauets ansvar, mens hændelser uden for (kundens egne ændringer, genbrugte kodeord) faktureres som akutarbejde til aftalt takst.
