Et bureau har bygget dit website. Hvem har ansvaret nu?

Sitet blev leveret, det så flot ud, alle var glade. To år efter går noget galt — og så viser det sig, at spørgsmålet om, hvem der egentlig skulle holde øje med det i mellemtiden, aldrig rigtig blev besvaret af nogen.

En bemærkning, inden vi går i gang: det her er en praktisk beskrivelse af, hvordan den slags aftaler typisk fungerer, ikke juridisk rådgivning. Både databeskyttelsesreglerne og din egen kontrakt spiller ind, de peger ikke altid samme vej, og står der rigtige penge eller rigtige kundedata på spil, er en halv time hos en advokat godt givet ud.

Det er en af de mest almindelige situationer i mindre virksomheder, og det er næsten aldrig nogens skyld. Det er et hul, der åbner sig stille mellem tre parter, som hver især tror, at en anden står i det.

Hvad de tre parter typisk tænker

Bureauet byggede det, der var aftalt, leverede det og gik videre til næste projekt. I deres forståelse var opgaven løst og afleveret. Har du ikke en aftale om løbende support, står dit site ikke på nogens liste, og ingen får penge for at tænke på det.

Hostingudbyderen holder serveren kørende. De opdaterer serverens eget styresystem, holder maskinen online og tager backup, hvis det er med i din aftale. Det, de ikke gør, er at kigge ind i dit website: de aner ikke, om den software, dit site er bygget af, er forældet, for det ligger på din side af stregen.

Du går med rimelighed ud fra, at når der både er et professionelt bureau og et professionelt hostingfirma inde over, så holder nogen øje.

Alle opfører sig fornuftigt. Ingen holder øje.

Hvad der faktisk falder ned i hullet

Det er de her ting, der ender uden ejer, og listen er værd at læse igennem, for hver enkelt har givet nogen en dårlig uge:

• Den software, sitet er bygget af, bliver ældre. Et website er sat sammen af en masse færdige dele, og de var tidssvarende den dag, det blev lanceret. Det er de ikke nu. I nogle af dem er der siden offentliggjort sikkerhedsproblemer — offentligt, med vejledning.
• Et plugin bliver forladt eller trukket tilbage. Der ændrer sig ingenting på dit site, der kommer ingen advarsel, og den del holder stille og roligt op med at få rettelser.
• Certifikater udløber. Det, der får browsere til at vise dit site som sikkert, har en udløbsdato. Når den passeres, får dine besøgende en advarsel i fuld skærm om, at dit site er usikkert.
• Adgange bliver aldrig lukket. Udvikleren, der byggede det, freelanceren, der lavede én opgave, den bureaumedarbejder, der stoppede sidste år — hver af dem kan stadig have et administratorlogin.
• Testversionen bliver liggende. Testsites bliver ofte stående, nogle gange med rigtige kundedata, af og til indekseret af Google.
• Ingen aftalte, hvem der får mailen. Når noget så går i stykker, går beskeden til en adresse hos bureauet eller til en person, der ikke arbejder der længere.

Ingen af dem melder sig selv. Det er hele vanskeligheden: et site med hvert eneste af de her problemer ser fuldstændig normalt ud for en besøgende — og for dig — lige indtil det ikke gør.

Den ubehagelige del: efter databeskyttelsesreglerne lander ansvaret hos dig

Folk går ud fra, at når bureauet har bygget det, så er det også bureauets ansvar. I praksis fungerer det sjældent sådan, af to grunde.

Kontrakten siger som regel ingenting. De fleste aftaler om webudvikling beskriver, hvad der skal bygges, og hvornår det bliver leveret. Mange indeholder en afhjælpningsperiode — nogle måneder, hvor bureauet retter det, der ikke virker som aftalt. Efter vores erfaring siger de færreste noget som helst om årene derefter, for når man skriver under, tænker ingen på år tre. Er kontrakten skrevet på en standardskabelon, er der større chance for, at der er et vedligeholdelsesbilag — det er værd at tjekke, før du går ud fra, at der ikke er.

Én undtagelse er værd at kende. Det her handler om vedligeholdelse — årene efter. Var noget allerede i stykker eller allerede kendt usikkert den dag, sitet blev afleveret, er det en mangel, og en mangel er bureauets problem, uanset om du har en vedligeholdelsesaftale eller ej. Der er som regel en frist for at reklamere, så tror du, det er din situation, så sig det skriftligt med det samme i stedet for at lade det ligge.

Efter databeskyttelsesreglerne ligger ansvaret strukturelt hos dig. Det er den del, der er værd at forstå ordentligt. Indsamler dit website oplysninger om kunder, er det dig, der har besluttet at indsamle dem og til hvad — og det gør dig til dataansvarlig efter GDPR. Et bureau, der behandler de data på dine vegne, er normalt databehandler — med sine egne forpligtelser og en skriftlig databehandleraftale, det skal have med dig. Så pænt er det ikke altid: begynder bureauet at bruge dine kundedata til sine egne formål, er det ikke længere bare databehandler. Men i det almindelige tilfælde ligger ansvaret for hele arrangementet hos dig. Lækker kundedata på grund af en fejl i kode, som en anden har skrevet, er det stadig dig, der skal vurdere det og — hvis det sandsynligvis udgør en risiko for de berørte — anmelde det til Datatilsynet, normalt inden for 72 timer. Ikke enhver hændelse skal anmeldes, men vurderingen er din. Og det er dine kunder, hvis tillid det går ud over.

Det er ikke en grund til at mistro dit bureau. Det er en grund til at være præcis med dem, for konsekvenserne fordeler sig ikke, som folk går ud fra.

Én ting er let at overse: at skulle anmelde et brud er ikke det samme som at skulle bære regningen for det. Har bureauet forårsaget det, kan du efter databeskyttelsesreglerne kræve deres andel dækket, og din kontrakt kan sige mere. Anmeldelsen er din opgave. Hvem der skal betale for en andens fejl, er et andet spørgsmål — og ikke et, du skal gå ud fra, at du har tabt på forhånd.

De spørgsmål, du skal stille — og hvornår

Det bedste tidspunkt er før underskrift. Det næstbedste er nu, i en helt almindelig mail, uden at vente på, at noget går galt.

• Hvem lægger sikkerhedsopdateringer på sitet, hvor ofte, og er det med i prisen eller en ekstraregning? Det vigtigste enkeltspørgsmål — og det, der oftest afslører, at svaret er "ingen".
• Bliver der offentliggjort et sikkerhedsproblem i noget, mit site bruger — hvem opdager det, og hvordan får jeg besked?
• Ejer jeg koden, og hvor ligger den? Hvis bureauet forsvandt i morgen, kunne en anden så tage over? Bed om koden — hvor den ligger, og adgang til den — og hosting-loginet, på skrift.
• Hvem har adgang lige nu, og hvad sker der, når en af dem stopper?
• Når sitet går ned klokken 20 en fredag — hvad sker der så helt konkret? Er der et nummer, en svartid og et menneske, eller er det "skriv en mail, så kigger vi på det"?
• Findes der en supportaftale, og hvad dækker den præcis? "Support" betyder ofte hjælp, når du selv beder om den, ikke at nogen holder øje på dine vegne. Det er to meget forskellige produkter.

Sådan tager du det op, uden at det lyder som en anklage

Det er værd at tænke over, for grunden til, at samtalen bliver udskudt, er som regel, at den føles som en klage over et arbejde, du var glad for.

Det hjælper at fremstille det som et hul og ikke en forsømmelse, for det er dét, det er: "Vi fik aldrig aftalt, hvem der passer på sitet efter lanceringen, og jeg er blevet klar over, at jeg ikke kender svaret. Kan vi få det skrevet ned?" Et godt bureau bliver lettet — de har båret rundt på en uudtalt forventning, de aldrig har givet pris på, og de vil hellere have den defineret. Er svaret vagt, er det også nyttigt at vide — ikke et bevis på ond vilje, men et tegn på, at aftalen aldrig rigtig blev defineret.

Det fungerer bedst, når I begge kigger på det samme. En fælles, dateret rapport over, hvad der rent faktisk er galt, er et langt bedre udgangspunkt end en samtale om, hvorvidt der overhovedet er noget. Så holder det op med at handle om tillid og bliver til en liste.

Hvis bureauet er væk

En almindelig og stressende variant: bureauet lukkede, freelanceren gik videre, eller samarbejdet sluttede bare — og nu er der ingen, der ved, hvordan sitet virker.

Tre ting, i rækkefølge. Få kontrol over kontiene — domænet, hostingen og sitets eget administratorlogin. Domænet betyder mest: alt andet kan bygges op igen, og et domæne, du har mistet adgangen til, er et reelt vanskeligt problem. Find ud af, hvad det er bygget på, for du kan ikke hyre nogen til at vedligeholde noget, ingen kan beskrive. Beslut derefter bevidst, om du vil finde en ny til at passe det, flytte til en enklere platform eller bygge om. Alle tre er fine. At lade det sejle er den mulighed, der ender skidt.

Pointen

Ingen i den her historie har gjort noget forkert. Bureauet byggede det, der blev bedt om. Hostingudbyderen holdt serveren kørende. Du gik ud fra, at nogen blev ved med at holde øje — og det lå aldrig i nogens opgave.

Løsningen er ikke at finde en at bebrejde bagefter. Den er at gøre hullet synligt nu, i én mail blive enige om, hvem der står i det, og have noget til at holde øje i mellemtiden — så svaret på "hvor længe har det været sådan?" aldrig bliver "det ved vi ikke".

Har mit webbureau ansvaret for sikkerheden, efter websitet er leveret?

Dit bureau har kun ansvaret for sikkerheden efter leveringen, hvis det står i din kontrakt — og det gør de færreste webkontrakter. De beskriver, hvad der skal bygges, og hvornår det bliver leveret, ofte med en afhjælpningsperiode — nogle måneder, hvor bureauet retter det, der ikke virker som aftalt, og siger ingenting om årene derefter. Har du ikke en løbende support- eller vedligeholdelsesaftale, er der ingen på bureauet, der får penge for at tænke på dit site — og så har opdateringer, udløbende certifikater og nyoffentliggjorte sikkerhedsproblemer ingen ejer.

Hvem har ansvaret, hvis mit website bliver hacket?

Efter databeskyttelsesreglerne er det som regel dig — også når en anden har bygget sitet. Indsamler dit website oplysninger om kunder, er det dig, der har besluttet at indsamle dem og til hvad, og det gør dig til dataansvarlig. Et bureau, der håndterer de data på dine vegne, er normalt databehandler med sine egne forpligtelser, men det er den dataansvarlige — altså dig — der skal vurdere et brud og anmelde det til Datatilsynet. At anmelde er ikke det samme som at betale: har bureauet forårsaget det, kan du efter omstændighederne kræve deres andel dækket. Det er en generel beskrivelse og ikke juridisk rådgivning; det er din kontrakt, der afgør din sag.

Hvad bør jeg spørge mit webbureau om løbende vedligeholdelse?

Seks spørgsmål dækker det meste af det, der betyder noget ved løbende vedligeholdelse. Hvem lægger sikkerhedsopdateringer på, hvor ofte, og er det med i prisen eller en ekstraregning? Bliver der offentliggjort et sikkerhedsproblem i noget, sitet bruger — hvem opdager det, og hvordan får jeg besked? Ejer jeg koden, og hvor ligger den? Hvem har adgang, og hvad sker der, når en af dem stopper? Hvad sker der helt konkret, når sitet går ned uden for kontortid? Og betyder supportaftalen, at nogen holder øje, eller kun at de hjælper, når jeg beder om det — for det er to meget forskellige ting.

Hvad gør jeg, hvis bureauet, der byggede mit website, er væk?

Er bureauet, der byggede dit website, væk, så gør tre ting i rækkefølge. Få kontrol over kontiene — domænet, hostingen og sitets administratorlogin — med domænet først, for alt andet kan bygges op igen, og et mistet domæne er reelt svært at få tilbage. Find derefter ud af, hvad sitet er bygget på, eftersom du ikke kan hyre nogen til at vedligeholde noget, ingen kan beskrive. Beslut så bevidst, om du vil finde en ny til at passe det, flytte til en enklere platform eller bygge om. At lade det sejle er den mulighed, der ender skidt.

Hvor TrustCtrl passer ind

Det er præcis det hul, TrustCtrl er bygget til at stå i. Det holder øje med de ting, der ikke har nogen ejer efter lanceringen — om sitet og checkout rent faktisk virker, om certifikater er ved at udløbe, om softwaren bag har kendte problemer, om nogen efterligner dit brand, og om modtagerne kan stole på dine mails — og forklarer hvert fund i et almindeligt sprog, med en teknisk udgave, du kan sende videre til den, der passer sitet.

Det erstatter ikke dit bureau. Det giver jer begge den samme daterede liste at kigge på, og det giver en betydeligt lettere samtale end den, der starter med "jeg tror måske, der er noget galt".