Flere NIS2‑kunder med forskellige krav: én test eller flere?

En leverandør med mange kunder kan få flere forskellige NIS2-krav. Den ene kunde vil have en årlig penetrationstest af portalen, den anden vil se dokumentation for fjernsupporten, og den tredje vil selv vælge testeren. Kravene ligner hinanden, men de er ikke ens, og ingen af kunderne kender de andres.

Én fælles test af den del, kunderne deler, kan dække en stor del af kravene. Forudsætningen er, at afgrænsningen er beskrevet, så hver kunde kan se, at netop deres leverance er med. Der, hvor en kunde har sin egen opsætning, sin egen integration eller sine egne krav til testeren, skal den fælles test suppleres eller erstattes.

Hvorfor kravene ikke er ens

Hver omfattet kunde vurderer selv den risiko, jeres leverance udgør for kundens systemer. SAMSIK’s vejledning om anvendelsesområdet beskriver i afsnit 8, at den vurdering kan føre til forholdsmæssige krav til leverandøren. Vejledningen om foranstaltninger anbefaler i afsnit 4 en risikobaseret tilgang, hvor kravene står i forhold til leverancens betydning for den enkelte kunde.

To kunder kan derfor nå frem til forskellige krav til den samme leverance. En kunde i sundhedssektoren, der bruger flere moduler, vurderer måske risikoen højere end en kunde i engroshandlen, der kun bruger en enkelt funktion. Kravene afspejler kundernes forskelle, ikke nødvendigvis forskelle i jeres løsning.

Saml kravene ét sted

Start med at samle kundernes krav, så I kan sammenligne dem. Notér for hver kunde de punkter, der har betydning for testen.

Omfang · hvilken del af leverancen kravet gælder.
Hyppighed · årlig, ved ændringer eller før fornyelse af aftalen.
Tester · om kunden stiller krav til uafhængighed eller vil godkende valget.
Aflevering · rapport, resumé, erklæring eller kundens eget skema.
Fund · krav om besked og frister for rettelser.

Når kravene står side om side, bliver det tydeligt, hvor de overlapper. Det kan vise sig, at mange af kravene gælder den samme fælles platform, og at forskellene ligger i tidspunkt og form på dokumentationen.

Hvad en fælles test kan dække

En fælles test af den platform, alle kunder bruger, kan svare på det, der er fælles. Det kræver, at testen er planlagt med flere kunder for øje. Afgrænsningen bør nævne de funktioner og roller, kunderne bruger, og rapporten bør forklare, hvilken version og hvilken opsætning der blev testet.

Vælg tidspunktet, så det passer med flest mulige kunders behov. Har tre kunder krav om dokumentation i løbet af foråret, kan en test i begyndelsen af året dække alle tre. Har en fjerde kunde en anden rytme, kan det være lettere at aftale med den kunde, at den får det seneste resultat, end at teste særskilt. → Et testprogram over flere år

Et tænkt eksempel: En leverandør af et system til dokumenthåndtering har fem NIS2-kunder på samme platform. Fire af dem kan godtage en fælles test med et kundetilpasset resumé. Den femte har en særlig integration til sit eget sagssystem. Leverandøren lægger integrationen ind som et tillæg til den fælles test, så kunden får både den fælles del og sin egen.

Når én test ikke er nok

Der er situationer, hvor den fælles test ikke kan stå alene. Det gælder, når en kunde har sin egen opsætning, som ikke findes på den fælles platform, eller en integration, som kun den kunde bruger. Det gælder også, når en kunde kræver en bestemt tester, som ikke passer med de andre kunders krav, eller selv vil lade teste. → Kundespecifik opsætning eller fælles platform · → Kunden vil selv teste

Endelig kan en kunde kræve dokumentationen i sit eget format. Det betyder ikke nødvendigvis en ny test, men det kræver, at resultatet af den fælles test bliver oversat til kundens skabelon. → Kundens skabelon

Er I en driftsleverandør med mange kunder, gælder de samme overvejelser i større skala. → MSP’ens fælles testplan

Fortæl kunderne om planen

Kunder accepterer lettere en fælles test, når de ved, at den kommer, og hvad den omfatter. Send en kort beskrivelse af planen til de kunder, der har stillet krav: hvornår testen ligger, hvilke dele af platformen den dækker, og hvilken dokumentation de får bagefter. Spørg samtidig, om kunden har dele, der skal med ud over det fælles.

Beskrivelsen giver kunderne mulighed for at gøre indsigelse, før testen er bestilt, og ikke bagefter. Den kan også erstatte en række enkeltstående samtaler, fordi den samme tekst kan sendes til alle med en tilføjelse til de kunder, der har noget særligt.

Når en ny kunde kommer til, kan planen vises som svar på kundens spørgsmål om test. Kunden ser dermed, at testen er en fast del af jeres drift og ikke noget, der bliver sat i gang, fordi kunden spurgte.

Én rapport, flere modtagere

En fælles test giver en rapport, der handler om jeres platform og ikke om den enkelte kunde. Den bør ikke indeholde andre kunders navne eller oplysninger. Nogle leverandører laver derfor et resumé pr. kunde, som henviser til den fælles test og nævner det, der er særligt for den kunde. → Samme rapport til flere kunder

Viser testen et fund, der rammer alle kunder, skal alle have besked i den form, de hver især har aftalt. → Fund, der rammer flere kunder

Det skal I lade være med

At lade den strengeste kunde bestemme alt · ét krav om ugentlig rapportering skal ikke gælde alle.
At sende den samme rapport ukritisk til alle · tjek, at den ikke afslører andre kunder.
At gå ud fra, at den fælles test dækker alles opsætning · kundespecifikke dele skal nævnes.
At teste særskilt for hver kunde uden grund · det giver flere forstyrrelser og mindre sammenhæng.
At glemme at fortælle kunden, hvad den fælles test dækker · kunden skal kunne se sin del.

Hvad kan og ikke kan konkluderes

En fælles test kan dokumentere, at den platform, flere kunder bruger, er afprøvet på et bestemt tidspunkt, og den kan bruges over for hver kunde, hvis afgrænsningen passer til kundens leverance. Det gør dokumentationen mere ensartet og lettere at holde ved lige.

Den siger ikke noget om kundespecifikke dele, der ikke var med. Om en fælles test opfylder en bestemt kundes krav, afgør kunden ud fra sin aftale med jer og sin egen risikovurdering.