At IT-afdelingen administrerer et system, betyder ikke automatisk, at den må sikkerhedsteste det. Om en intern test er i orden, afhænger af, hvem der råder over systemet, om ledelsen har godkendt opgaven, og om aftaler med leverandører eller hensyn til medarbejdere sætter grænser.
Når de tre forhold er afklaret, kan en intern sikkerhedstest være et nyttigt supplement til den eksterne. Den erstatter dog ikke nødvendigvis en uafhængig test, hvis resultatet skal bruges over for kunder, revisorer eller andre. Teksten er generel købervejledning og ikke juridisk rådgivning.
Administratoradgang er ikke det samme som et mandat
En administrator har teknisk mulighed for at gøre meget i et system. Den daglige rolle er dog defineret af en opgave: at drive, vedligeholde og hjælpe brugerne. En sikkerhedstest er en anden opgave, fordi den bevidst afprøver, om kontroller kan omgås, og fordi den kan påvirke driften.
Straffelovens § 263 handler om uberettiget adgang til en andens datasystem eller data. For en intern test er spørgsmålet derfor ikke kun, om IT har adgangen, men om handlingerne er dækket af en beslutning hos den, der råder over systemet. Hvor ejerskab eller fuldmagter er uklare, bør en jurist se på det. → Er en penetrationstest lovlig?
Der er også et praktisk argument. En test, som ingen uden for IT kender til, kan udløse alarmer, forstyrre brugere eller blive forvekslet med et reelt angreb. En dokumenteret beslutning beskytter både virksomheden og de medarbejdere, der udfører testen.
Hvad er egentlig jeres eget?
Mange virksomheder bruger systemer, de ikke selv driver. Webshoppen kan ligge hos et hostingfirma, ERP-systemet kan være en tjeneste hos leverandøren, og kontornettet kan være sat op og drevet af driftsleverandøren. I alle tre tilfælde kan virksomheden eje sine data og have administrative rettigheder uden at råde over den platform, systemet kører på.
Lav derfor en kort oversigt over de systemer, den interne test skal omfatte, og notér for hvert system, hvem der driver det, og hvilke vilkår aftalen har for sikkerhedstest. Systemer på jeres eget udstyr i jeres egne lokaler er typisk de enkleste. Hostede løsninger og cloudtjenester kræver, at aftalen og leverandørens regler læses først. → Driftsleverandøren og testen
Er svaret uklart, så tag systemet ud af den interne test, indtil det er afklaret. Det er bedre at teste mindre med en tydelig ramme end at teste bredt på en antagelse.
Ledelsens godkendelse skal være skriftlig
En intern test bør godkendes af en person med ansvar for de berørte systemer og myndighed til at acceptere en mulig påvirkning af driften. I en mindre virksomhed kan det være direktøren. I en større kan det være systemejeren sammen med IT-chefen.
Godkendelsen bør beskrive, hvilke systemer der indgår, hvilke handlinger der er tilladt, i hvilket tidsrum testen foregår, og hvem der skal kontaktes, hvis noget går galt. Det er de samme punkter, en ekstern tester ville bede om, og der er ingen grund til at gøre det mindre præcist, fordi testeren er ansat. → Rules of engagement
Aftal også, hvad der sker med resultatet. Hvem får det at se, hvordan opbevares det, og hvem beslutter, hvad der skal rettes? En intern test uden en ejer af opfølgningen ender let som viden hos én medarbejder.
Overvej desuden, om godkendelsen skal gælde én opgave eller en løbende ramme. Mange IT-afdelinger kontrollerer opsætninger og opdateringer hver uge, og det ville være upraktisk at søge om lov hver gang. En løbende ramme kan beskrive de faste aktiviteter, mens nye og mere indgribende test stadig godkendes enkeltvis. Rammen bør have en dato for, hvornår den gennemgås igen, så den ikke stille vokser sig større end det, ledelsen oprindeligt tog stilling til.
Medarbejdere og personoplysninger
En teknisk test kan komme tæt på kollegers mails, filer og konti. Det rejser spørgsmål, som ikke besvares af en teknisk godkendelse alene. Hvis testen kan berøre personoplysninger, bør virksomheden vurdere grundlaget efter databeskyttelsesreglerne og sine egne interne retningslinjer. Datatilsynet har vejledning om behandling af personoplysninger i ansættelsesforhold.
Aktiviteter rettet mod mennesker, som at sende testmails til kolleger eller forsøge at få adgang til lokaler, bør aldrig udledes af en godkendelse til en teknisk test. De kræver deres egen beskrivelse og beslutning, og de er sjældent en naturlig opgave for den interne IT-afdeling.
Brug testkonti, hvor det er muligt, og undgå at åbne indholdet af rigtige brugeres data, når det ikke er nødvendigt for at besvare testens spørgsmål.
Intern test som supplement
En intern test har klare fordele. Medarbejderne kender systemerne, kan teste oftere og kan følge op hurtigt. Den løbende kontrol af kendte sårbarheder og opsætninger er ofte bedst forankret internt. → Sårbarhedsstyring og penetrationstest
Ulempen er, at den, der har bygget eller driver et system, vurderer sit eget arbejde. Det svækker ikke nødvendigvis resultatet, men det påvirker, hvordan andre kan bruge det. En kunde, der beder om en uafhængig test, vil sjældent acceptere en rapport fra den afdeling, der driver løsningen. → Uafhængig penetrationstest
Mange vælger derfor en fordeling, hvor den interne test bruges løbende og en ekstern test bruges, når der skal dokumenteres over for andre, eller når der er brug for nye øjne. → Intern eller ekstern tester
Det skal I lade være med
- At lade administratorrettigheder stå for en godkendelse · Den tekniske adgang afgør ikke, om testen er besluttet.
- At teste hostede systemer uden at læse aftalen · Platformen kan tilhøre leverandøren, selv om data er jeres.
- At holde testen skjult for driftsleverandøren · Uanmeldte aktiviteter kan forveksles med et angreb.
- At gå ind i kollegers data uden behov · Brug testkonti, og begræns adgangen til det nødvendige.
- At sende den interne rapport videre som uafhængig · Modtageren skal vide, hvem der lavede den.
- At lade resultatet blive hos én medarbejder · Opfølgningen skal have en ejer.
Hvad kan og ikke kan konkluderes
En godkendt intern test kan give virksomheden løbende viden om sine egne systemer og hurtig opfølgning på kendte svagheder. Den kan dokumentere, hvad den undersøgte, under de aftalte forhold.
Den kan ikke uden videre bruges som uafhængig dokumentation, og den afgør ikke spørgsmål om ejerskab, leverandørvilkår eller databeskyttelse. De skal være afklaret, før testen begynder. Et manglende fund i en intern test er heller ikke et bevis for, at systemet holder; det viser kun, at de valgte kontroller ikke afslørede noget.
Tjekliste før en intern sikkerhedstest
- ☐ Er det afklaret, hvem der råder over hvert system i testen?
- ☐ Er leverandøraftaler og cloudvilkår læst for hostede systemer?
- ☐ Har en ansvarlig leder godkendt testen skriftligt?
- ☐ Er systemer, handlinger, tidsrum og kontaktpersoner beskrevet?
- ☐ Er driftsleverandøren og eventuel overvågning orienteret?
- ☐ Er hensyn til medarbejdere og personoplysninger vurderet?
- ☐ Har opfølgningen en navngiven ejer?
Kilder
- Straffeloven, § 263: bestemmelsen om uberettiget adgang, som gør rådighed og tilladelse afgørende.
- Datatilsynet: myndighedens vejledninger om databeskyttelse, også når medarbejderes oplysninger berøres.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om penetrationstest
Læs også: Uafhængig penetrationstest · Rules of engagement
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
