Ny digital forretning: hvornår skal ledelsen kræve en test?

Når virksomheden åbner en ny digital kanal, flytter en del af forretningen ud på internettet, hvor alle kan nå den. Om ledelsen skal kræve en sikkerhedstest, afhænger af to forhold: hvad den nye løsning håndterer af kunder, data og penge, og hvor meget det vil koste forretningen, hvis den svigter i de første måneder. Er svaret på begge spørgsmål “meget”, bør testen være en betingelse for at gå i luften, ikke et punkt, der kan skæres væk, når projektet bliver presset.

Det er en ledelsesbeslutning, fordi det er ledelsen, der har sat projektet i gang, godkendt budgettet og skal stå inde for løsningen over for kunderne. Projektlederen kan foreslå en test, men det er ikke nødvendigvis projektlederen, der kan flytte en lanceringsdato.

Hvad gør en ny digital forretning anderledes?

En ny kundeportal, en webshop eller en digital ydelse til samarbejdspartnere er mere end et IT-projekt. Den ændrer, hvem der kan komme i kontakt med virksomheden, og hvad de kan gøre, når de er der.

Kunderne logger ind · personoplysninger, ordrer og aftaler bliver tilgængelige udefra.
Pengene bevæger sig · betalinger, kreditter eller fakturaer håndteres i en løsning, der er åben døgnet rundt.
Partnerne kobles på · systemer hos andre virksomheder taler direkte med jeres.
Løftet er offentligt · lanceringen er annonceret, og kunderne forventer, at det virker og er sikkert.

Hver af disse ændringer flytter noget, virksomheden værdsætter, tættere på dem, der kunne have interesse i at misbruge det. → Kronjuvelerne

Ikke alle nye digitale tiltag kræver det samme. En informationsside om virksomhedens produkter uden login og uden kundedata er en anden sag end en portal, hvor erhvervskunder ser deres priser, kontrakter og ordrehistorik. Ledelsen kan bruge et enkelt spørgsmål som filter: hvis løsningen blev misbrugt i den første uge, hvem ville så ringe til direktøren? Er svaret kunder, banken eller en samarbejdspartner, hører testen med i beslutningen.

Testen som betingelse, ikke som pynt

En test, der lægges ind som en mulighed, risikerer at blive den første ting, der falder ud, når udviklingen trækker ud. En test, ledelsen har gjort til en betingelse, bliver planlagt. Forskellen ligger i, hvordan beslutningen formuleres fra starten.

Formuler det som et krav til projektet: løsningen går ikke i luften, før den er testet, og før ledelsen har set et resumé af resultatet og taget stilling til eventuelle alvorlige fund. Så er der ingen tvivl om, hvem der skal godkende, og projektet ved, at tid til test og rettelser skal med i planen. → Ledelsens godkendelse

Betingelsen bør også sige, hvad der sker, hvis testen finder noget alvorligt kort før lanceringen. Skal datoen flyttes, skal en del af løsningen vente, eller kan ledelsen acceptere en kendt risiko i en kort periode? Det er lettere at aftale, før presset opstår.

Hvornår i projektet skal ledelsen tage stilling?

Den vigtigste beslutning træffes ikke, når løsningen er færdig, men når projektet godkendes. Det er her, budgettet og tidsplanen bliver lagt, og hvis testen ikke er med fra begyndelsen, mangler både penge og tid senere. → Sikkerhedstest i projektbudgettet

Den praktiske placering af testen i projektforløbet, og hvordan en webshop eller en portal planlægges baglæns fra lanceringen, er forklaret på penetrationtest.dk. Ledelsens opgave er at sikre, at planen findes, og at den indeholder luft til at rette det, testen finder.

Er løsningen allerede ved at blive bygget, uden at testen er med, er det ikke for sent. Bed projektet om at lægge testen ind nu og vise, hvad det betyder for datoen. → Teste nu eller vente til efter omlægningen?

Hvis det er en leverandør, der bygger løsningen

Nogle virksomheder får deres nye digitale forretning bygget af et bureau eller en softwareleverandør. Det ændrer ikke, at det er jeres forretning og jeres kunder. Leverandørens egne test kan være gode, men ledelsen bør vide, hvad de dækker, og om resultatet kan forelægges.

Skriv i aftalen, at løsningen skal kunne testes af en uafhængig part, at leverandøren skal medvirke, og at alvorlige fund skal rettes inden for aftalte rammer. Det er langt sværere at forhandle bagefter, når løsningen er leveret. → Spørgsmål til softwareleverandøren

Hvad ledelsen skal have at vide før lanceringen

Ledelsen har ikke brug for den tekniske rapport. Den har brug for svar på nogle få spørgsmål, som kan besvares på én side.

Hvad blev testet, og hvad blev ikke?
Blev der fundet noget, der kan ramme kunder, data eller betalinger?
Er de alvorlige fund lukket, og har nogen efterprøvet lukningen?
Hvilke kendte forhold går løsningen i luften med, og hvem har accepteret dem?
Hvornår ses der på løsningen igen?

Det sidste spørgsmål er vigtigt. En ny digital forretning kan udvikle sig efter lanceringen. Nye funktioner kommer til, og det billede, testen gav ved lanceringen, ældes.

Tænk også over, hvem der skal kunne se svarene. Bestyrelsen vil måske gerne vide, at den nye forretning er undersøgt, før den annonceres. Større kunder kan bede om dokumentation, allerede inden de tager portalen i brug. Aftal derfor fra begyndelsen, hvilken form resultatet skal have, så det ikke først skal skrives om, når nogen spørger. Et kort resumé til ledelsen og en mere detaljeret rapport til projektet kan være to forskellige ting, og begge bør være bestilt.

Det skal I lade være med

At lade testen være valgfri i projektplanen · så forsvinder den, når tiden bliver knap.
At bestille testen, når lanceringsdatoen er fastlåst · uden tid til rettelser er resultatet kun en liste over kendte problemer.
At nøjes med leverandørens forsikring om sikkerhed · bed om grundlaget, og om retten til selv at teste.
At godkende lanceringen uden et resumé · ledelsen skal vide, hvad den står inde for.
At glemme løsningen efter lanceringen · nye funktioner ændrer billedet.

Hvad kan og ikke kan konkluderes

En test før lancering viser, hvordan løsningen stod i den udgave og med de funktioner, der blev testet. Den kan give ledelsen et grundlag for at sige ja til lanceringen. Den kan ikke garantere, at løsningen er sikker, og den dækker ikke det, der bygges bagefter. En ren lancering er et godt udgangspunkt, ikke en afsluttet opgave. Når kunderne spørger til sikkerheden, er det derfor vigtigt at kunne sige præcist, hvad der blev undersøgt. → Kunder spørger til sikkerhed