Revisionsklar ISO 27001-risikovurdering til NIS2 og DORA

Kaffen på Sarahs skrivebord var blevet kold.

Som CISO i en hastigt voksende fintech-virksomhed var hun vant til pres. Virksomheden havde netop vundet en stor bankpartner, og due diligence-spørgeskemaet på hendes skærm burde have været en formalitet. De første spørgsmål var velkendte: fremlæg ISO/IEC 27001:2022-anvendelighedserklæringen (SoA), del det seneste risikoregister, forklar risikovurderingsmetodikken.

Så ændrede spørgeskemaet karakter.

Dokumentér, hvordan jeres risikostyringsprogram adresserer DORA. Forklar jeres forberedelse til NIS2-direktivet, herunder ledelsens ansvar og foranstaltninger vedrørende risiko i forsyningskæden. Fremlæg bevismateriale for, at kritiske IKT-leverandører vurderes, overvåges og er omfattet af hændelseshåndtering og planer for forretningskontinuitet.

Mandag morgen stod samme problem på dagsordenen i bestyrelsens risikoudvalg. ISO 27001-certificeringsaudit om otte uger. DORA-pres fra kunder i den finansielle sektor. NIS2-klassificeringsspørgsmål for en cloudbaseret tjenestelinje, der blev udvidet i EU. Indkøb sagde, at leverandørgennemgange fandtes, men bevismaterialet lå spredt på e-mail, i kontraktmapper og i et leverandørregneark. Jura sagde, at den regulatoriske kortlægning stadig var under udarbejdelse. Engineering sagde, at risikoregisteret stort set var færdigt.

Bestyrelsen stillede det eneste spørgsmål, der betød noget:

Kan vi dokumentere, at vores risikovurdering og risikobehandlingsplan er tilstrækkelige?

Det er den reelle udfordring for SaaS-, fintech-, managed service-, cloud- og digitale platformvirksomheder. Ikke om der findes et risikoregister. Ikke om Annex A-kontroller er kopieret ind i et regneark. Spørgsmålet er, om organisationen under revisions- og kundepres kan dokumentere, at dens ISO 27001-risikovurderingsproces er gentagelig, risikobaseret, godkendt af risikoejere, knyttet til behandlingshandlinger, kortlagt til retlige forpligtelser og operationelt levende.

Gennemført korrekt kan én ISO 27001-risikovurdering og én risikobehandlingsplan understøtte ISO/IEC 27001:2022-certificering, NIS2 Article 21-foranstaltninger til styring af cybersikkerhedsrisici, DORA-krav til styring af IKT-risici, GDPR-ansvarlighed, leverandørdokumentation, hændelsesberedskab og bestyrelsesrapportering.

Gennemført dårligt bliver det et regneark, som revisorer kan skille ad på tredive minutter.

Denne vejledning viser, hvordan Clarysec opbygger revisionsklart bevismateriale for ISO 27001-risikovurdering og risikobehandling ved hjælp af Zenith Blueprint: en revisors 30-trins køreplan, Clarysec-politikker og Zenith Controls: vejledningen til tværgående efterlevelse.

Hvorfor ISO 27001-risikovurdering nu er et knudepunkt for efterlevelse

EU’s regulatoriske landskab samler sig om ét princip: Cybersikkerhedsrisici skal styres, dokumenteres, testes og ejes.

ISO/IEC 27001:2022 fungerer allerede på denne måde. Klausul 4.1 til 4.4 kræver, at organisationen forstår sin kontekst, interessenter, ISMS-omfang og procesinteraktioner, før den vurderer risiko. Klausul 6.1.2 og 6.1.3 kræver en defineret proces for informationssikkerhedsrisikovurdering og risikobehandling. Klausul 8.2 og 8.3 kræver, at organisationen udfører risikovurderinger og implementerer behandlingsplanen, samtidig med at dokumenteret information bevares.

NIS2 og DORA gør den samme risikobaserede logik mere presserende.

NIS2 Article 20 kræver, at ledelsesorganer i væsentlige og vigtige enheder godkender foranstaltninger til styring af cybersikkerhedsrisici, fører tilsyn med implementeringen og gennemfører cybersikkerhedstræning. Article 21 kræver passende og proportionelle tekniske, operationelle og organisatoriske foranstaltninger til at styre risici for net- og informationssystemer. Disse foranstaltninger omfatter risikoanalyse, hændelseshåndtering, forretningskontinuitet, sikkerhed i forsyningskæden, sikker udvikling, sårbarhedsstyring, vurdering af effektivitet, cyberhygiejne, kryptografi, HR-sikkerhed, adgangsstyring, aktivstyring og multifaktorgodkendelse eller sikret kommunikation, hvor det er relevant.

DORA lægger et tilsvarende pres på finansielle enheder. Articles 5 og 6 kræver, at ledelsesorganet definerer, godkender, fører tilsyn med og fortsat er ansvarligt for ordninger for styring af IKT-risici. DORA forventer en dokumenteret ramme for styring af IKT-risici, som er integreret i den samlede risikostyring og understøttes af politikker, procedurer, protokoller, værktøjer, intern revision, afhjælpning, kontinuitet, test, hændelseshåndtering og styring af IKT-tredjeparter.

Konklusionen er praktisk og uundgåelig: Risikoregisteret er ikke længere et arbejdsark for det tekniske team. Det er governance-bevismateriale.

Clarysecs Enterprise Politik for risikostyring gør denne forventning eksplicit:

En formel risikostyringsproces skal opretholdes i overensstemmelse med ISO/IEC 27005 og ISO 31000 og omfatte risikoidentifikation, analyse, evaluering, behandling, overvågning og kommunikation.

Fra Enterprise Politik for risikostyring, afsnittet “Styringskrav”, politikklausul 5.1.

Den samme politik definerer det revisionsklare resultat:

At opretholde et centraliseret, versionsstyret risikoregister og en risikobehandlingsplan, der afspejler aktuel risikostatus, kontroldækning og fremdrift i risikoafbødning.

Fra Enterprise Politik for risikostyring, afsnittet “Mål”, politikklausul 3.3.

Formuleringen “aktuel risikostatus, kontroldækning og fremdrift i risikoafbødning” er forskellen mellem en statisk efterlevelsesfil og et risikoprogram, der kan forsvares.

Start med omfang, forpligtelser og risikokriterier

Mange svage ISO 27001-risikovurderinger starter med en kontrolliste. Det er den forkerte rækkefølge.

ISO 27001 kræver, at organisationen fastlægger kontekst, interessentkrav, ISMS-omfang, ledelsesansvar og risikoplanlægning, før kontroller vælges. ISO/IEC 27005:2022 understøtter dette ved at anbefale, at organisationer identificerer interessenternes grundlæggende krav, før risiko vurderes. Disse krav kan komme fra ISO-standarder, sektorregulering, national lovgivning, kundekontrakter, interne politikker, tidligere behandlingsaktiviteter og leverandørforpligtelser.

For en EU-rettet SaaS- eller fintech-virksomhed bør risikoprocessen begynde med en fortegnelse over efterlevelseskrav og forpligtelser.

For SMV’er fastsætter Clarysecs Politik for juridisk og regulatorisk efterlevelse - SMV udgangspunktet:

Den administrerende direktør skal opretholde et enkelt, struktureret efterlevelsesregister, der angiver:

Fra SMV Politik for juridisk og regulatorisk efterlevelse, afsnittet “Styringskrav”, politikklausul 5.1.1.

Dette enkle register er en bro mellem efterlevelse og risikostyring. Hvis det viser, at GDPR gælder, fordi der behandles personoplysninger fra EU, at NIS2 kan gælde, fordi organisationen leverer digitale eller administrerede tjenester, eller at DORA er relevant gennem kunder i den finansielle sektor, skal disse forpligtelser påvirke risikokriterier og behandlingsprioriteter.

Zenith Blueprint er direkte på dette punkt i risikostyringsfasen, trin 10, “Etablering af risikokriterier og konsekvensmatrix”:

Overvej også juridiske/regulatoriske krav i jeres acceptkriterier. Nogle risici kan være uacceptable uanset sandsynlighed på grund af lovgivning.

Fra Zenith Blueprint, risikostyringsfasen, trin 10.

Den giver også en praktisk regel for workshops:

“Enhver risiko, der kan føre til manglende efterlevelse af gældende lovgivning (GDPR osv.), er ikke acceptabel og skal afbødes.”

Fra Zenith Blueprint, risikostyringsfasen, trin 10.

For Sarahs fintech-virksomhed ændrer det scoringsmodellen. En API-sårbarhed hos en leverandør kan have lav sandsynlighed, men hvis udnyttelse kan udløse en større DORA IKT-relateret hændelse, en væsentlig NIS2-hændelse, en GDPR-vurdering af brud, et brud på en kunde-SLA eller eskalering til bestyrelsesniveau, er konsekvensen høj eller kritisk. Efterlevelseseksponering bliver en del af risikologikken, ikke et separat regneark.

Opbyg et risikoregister, som revisorer kan teste

Revisorer spørger ikke kun, hvad jeres største risici er. De tester, om jeres metode er defineret, gentagelig, sporbar og fulgt.

De vil spørge:

• Hvordan identificerede I disse risici?
• Hvilke aktiver, tjenester, leverandører, datatyper og processer var omfattet?
• Hvilke kriterier blev anvendt for sandsynlighed og konsekvens?
• Hvem ejer hver risiko?
• Hvilke eksisterende kontroller reducerer risikoen?
• Hvorfor blev behandlingsbeslutningen valgt?
• Hvor findes bevismaterialet for, at behandlingen er gennemført?
• Hvem godkendte restrisikoen?
• Hvornår bliver risikoen revurderet?

Clarysecs Politik for risikostyring - SMV beskriver minimumskravet til en revisionsklar risikopost:

Hver risikopost skal omfatte: beskrivelse, sandsynlighed, konsekvens, score, ejer og behandlingsplan.

Fra SMV Politik for risikostyring, afsnittet “Styringskrav”, politikklausul 5.1.2.

For enterprise-programmer udvider Zenith Blueprint risikostyringsfasen, trin 11, “Opbygning og dokumentation af risikoregisteret”, strukturen. Den anbefaler kolonner som risiko-ID, aktiv, trussel, sårbarhed, risikobeskrivelse, sandsynlighed, konsekvens, risikoniveau, eksisterende kontroller, risikoejer, behandlingsbeslutning, behandlingsplan eller kontroller og status.

En stærk risikopost ser sådan ud:

Dette er væsentligt anderledes end “Tredjepartsrisiko, høj, afbød”. Den revisionsklare version forbinder aktiv, trussel, sårbarhed, konsekvens, eksisterende kontroller, ejer, regulering, bevismateriale og governance.

Omsæt risikobehandling til en plan for bevismateriale

En risikobehandlingsplan skal besvare fire operationelle spørgsmål:

1. Hvad skal vi gøre?
2. Hvem ejer det?
3. Hvornår er det gennemført?
4. Hvordan dokumenterer vi, at det reducerede risikoen?

ISO/IEC 27001:2022 Klausul 6.1.3 kræver, at organisationen vælger behandlingsmuligheder, fastlægger nødvendige kontroller, sammenholder dem med Annex A for at undgå udeladelser, udarbejder en anvendelighedserklæring (SoA), formulerer en behandlingsplan og indhenter risikoejerens godkendelse af planen og restrisici. Klausul 8.3 kræver derefter implementering af behandlingsplanen og bevaret dokumenteret information om resultaterne.

Enterprise Politik for risikostyring gør dette praktisk:

Den risikoansvarlige skal sikre, at behandlinger er realistiske, tidsbundne og kortlagt til ISO/IEC 27001 Annex A-kontroller.

Fra Enterprise Politik for risikostyring, afsnittet “Krav til implementering af politikken”, politikklausul 6.4.2.

SMV-politikken præciserer også, at accept ikke er en genvej:

Acceptér: Begrund, hvorfor der ikke kræves yderligere handling, og registrér restrisikoen.

Fra SMV Politik for risikostyring, afsnittet “Krav til implementering af politikken”, politikklausul 6.1.1.

Accept skal begrundes i forhold til kriterier, godkendes af den rette ejer og overvåges. Under NIS2 og DORA kan ikke-godkendt restrisiko blive et governance-svigt.

En komplet behandlingsplan bør indeholde disse felter:

For Sarahs R-042 bliver behandlingsplanen til en tværgående handlingsliste for efterlevelse.

Denne plan er stærk, fordi den skaber en direkte linje fra ét risikoscenarie til ISO 27001-kontroller, NIS2-forpligtelser, DORA-artikler, ejere og bevismateriale.

Få anvendelighedserklæringen til at arbejde hårdere

Anvendelighedserklæringen behandles ofte som et certificeringsartefakt. Den bør være mere end det.

ISO/IEC 27001:2022 Klausul 6.1.3 kræver, at SoA omfatter nødvendige kontroller, begrundelse for medtagelse, implementeringsstatus og begrundelse for udeladelser. Vejledningen i ISO/IEC 27005:2022 understøtter behovet for at sammenholde valgte kontroller med ISO/IEC 27001 Annex A for at undgå udeladelser.

I et revisionsklart program bliver SoA broen mellem risikobehandling og tværgående bevismateriale for efterlevelse. Hvis en behandlingsplan kræver MFA, logning, leverandørovervågning, gendannelse fra backup, sikker udvikling, hændelseseskalering eller planlægning af cloud-exit, bør SoA vise, at de relevante Annex A-kontroller er medtaget, begrundet, implementeret eller planlagt og dokumenteret.

Dette hjælper også med at undgå en almindelig revisionsmangel: Risikoregisteret siger én ting, behandlingsplanen en anden, og SoA er tavs. Når disse artefakter ikke stemmer overens, mister revisorer hurtigt tillid.

Kortlægning af ISO 27001-risikobehandling til NIS2, DORA og GDPR

ISO 27001 erstatter ikke NIS2, DORA eller GDPR. Standarden giver en struktureret mekanisme til at producere bevismateriale for dem.

Nøglen er at indbygge kortlægning i risikoprocessen i stedet for at tilføje den bagefter.

Denne kortlægning er særligt vigtig, hvor reguleringer overlapper. DORA er den sektorspecifikke IKT-robusthedsordning for mange finansielle enheder, mens NIS2 fortsat kan være direkte relevant for visse udbydere, koordinering eller enheder uden for DORA’s anvendelsesområde. En fintech-virksomhed kan have behov for DORA som sin primære styringsramme for IKT-robusthed, mens en managed service provider, der understøtter denne fintech-virksomhed, kan være direkte omfattet af NIS2-forpligtelser.

Risikoregisteret skal kunne vise begge sider af denne afhængighed.

Brug Zenith Controls som kompas for tværgående efterlevelse

Clarysec bruger Zenith Controls som en vejledning til tværgående efterlevelse for at undgå den almindelige fejl, hvor ISO-kontroller, regulatoriske artikler og revisionsspørgsmål lever i adskilte universer. Den etablerer ikke et separat kontrolrammeværk. Den kortlægger kontrolområder i ISO/IEC 27001:2022 og ISO/IEC 27002:2022 til andre standarder, revisionsforventninger og efterlevelsesperspektiver.

For ISO 27001-risikovurdering og risikobehandling er disse referencer særligt vigtige:

Læringen fra tværgående efterlevelse er enkel. Hvis retlige forpligtelser ikke indgår i risikovurderingsmetoden, er jeres scoring ufuldstændig. Hvis scoringen er ufuldstændig, kan behandlingsprioriteterne være forkerte. Hvis prioriteterne er forkerte, bliver SoA og bestyrelsesrapportering upålidelige.

Zenith Blueprint gør samme pointe i risikostyringsfasen, trin 14, “Risikobehandlingspolitikker og regulatoriske krydshenvisninger”. Den anbefaler organisationer at oprette en kortlægningstabel med centrale regulatoriske sikkerhedskrav og tilhørende kontroller eller politikker i ISMS. Dette er ikke obligatorisk for ISO 27001-certificering, men det er meget nyttigt til at dokumentere, at sikkerhed styres i en retlig og kontraktlig kontekst.

Hvad forskellige revisorer vil spørge om

En certificeringsrevisor, NIS2-gennemgår, DORA-orienteret kunde, GDPR-gennemgår, NIST-vurderingspart eller COBIT-praktiker kan undersøge samme bevismateriale, men stille forskellige spørgsmål.

Derfor er bevisarkitektur vigtig. Den samme risikopost bør kunne spores fra forretningsmål til aktiv, trussel, sårbarhed, kontrol, ejer, regulatorisk driver, behandlingshandling, testresultat og ledelsesbeslutning.

Clarysec-politikker er designet til at understøtte denne arkitektur. Enterprise Politik for risikostyring angiver under afsnittet “Referencestandarder og rammeværker”:

Article 5: Pålægger en dokumenteret ramme for styring af IKT-risici, som er fuldt dækket af denne politiks struktur, herunder SoA-kortlægning og KRI’er.

Det gør politikken fra et statisk dokument til revisionsbevismateriale, der viser, at styring af IKT-risici er designet bevidst med DORA for øje.

Almindelige konstateringer, der svækker risikoprogrammer

Når Clarysec gennemgår bevismateriale for ISO 27001-risikovurdering og risikobehandling, dukker de samme konstateringer op igen og igen.

For det første ignorerer risikokriterier retlige, regulatoriske, kontraktlige, leverandørmæssige og privatlivsmæssige konsekvenser. Det fører til svag scoring. Et brud på persondatasikkerheden eller et kritisk leverandørsvigt kan vurderes som middel, fordi sandsynligheden er lav, selv om konsekvensen for GDPR, NIS2, DORA eller kunder bør gøre risikoen høj eller kritisk.

For det andet er risikoejere generiske. “IT” er ikke en risikoejer. En risikoejer bør være en rolle eller person, der er ansvarlig for behandlingsbeslutninger, budget, timing og restrisiko.

For det tredje er behandlingsplaner ikke tidsbundne. “Forbedr overvågning” er ikke en plan. “Implementér alarmer for privilegerede sessioner i SIEM for administratorkonti i produktionsmiljøet senest 30. juni, ejet af SOC Manager, testet gennem simuleret administratorlogin, med alarmbevismateriale vedlagt” er en plan.

For det fjerde er SoA afkoblet fra behandlingen. Hvis behandlingsplanen kræver leverandørovervågning, backuptest, hændelseseskalering, MFA eller logning, bør SoA afspejle de relevante kontroller og implementeringsstatus.

For det femte er restrisiko ikke godkendt. ISO 27001 kræver risikoejerens godkendelse af behandlingsplanen og restrisici. NIS2 og DORA gør dette endnu vigtigere, fordi ledelsens ansvar er eksplicit.

For det sjette behandles leverandørrisiko som indkøbsadministration. Under NIS2 Article 21(2)(d) og DORA Articles 28 og 30 skal leverandør- og IKT-tredjepartsrisiko være en del af risikostyringen, ikke et årligt spørgeskema, der opbevares isoleret.

For det syvende mangler der bevismateriale for effektivitet. ISO 27001 Klausul 6.1.1 kræver, at planlagte handlinger evalueres for effektivitet. NIS2 omfatter vurdering af effektivitet i Article 21(2)(f). DORA forventer test og afhjælpning. En kontrol, der findes, men aldrig testes, er svagt bevismateriale.

SMV Politik for risikostyring - SMV fastsætter forventningen klart:

Den administrerende direktør og risikokoordinatoren skal sikre, at risikostyringsaktiviteter er revisionsklare. Risikoregisteret og relaterede handlinger er omfattet af intern og ekstern revision.

Fra SMV Politik for risikostyring, afsnittet “Håndhævelse og efterlevelse”, politikklausul 8.2.1.

Bestyrelsesrapportering uden at drukne ledelsen

NIS2, DORA og ISO 27001 peger alle mod ledelsesansvar, men bestyrelser har ikke brug for hver eneste risikorække. De har brug for rapportering, der understøtter beslutninger.

En god risikopakke til bestyrelsen bør vise:

• Høje og kritiske risici fordelt på domæne
• Forfaldne behandlingshandlinger
• Regulatoriske risici, der involverer NIS2, DORA, GDPR eller kontrakter
• Leverandørrisici, der påvirker kritiske eller vigtige tjenester
• Tendenser for hændelser og nærved-hændelser
• Restrisici, der afventer accept
• Testresultater for kontroleffektivitet
• Væsentlige ændringer i omfang, leverandører, teknologi eller lovgivning
• Konstateringer fra intern revision og korrigerende handlinger

Clarysec anbefaler normalt månedlige operationelle risikogennemgange og kvartalsvise ledelsesgennemgange. Månedlige gennemgange fokuserer på gennemførelse af behandling. Kvartalsvise gennemgange fokuserer på accept, finansiering, prioritering, regulatorisk eksponering og strategiske risikobeslutninger.

Denne kadence understøtter også løbende forbedring. Risikovurderinger bør opdateres, når hændelser opstår, sårbarheder fremkommer, nye aktiver introduceres, teknologien ændres, leverandører ændres, lovgivningen ændres, kundeforpligtelser ændres, eller risikovilligheden ændres.

Clarysecs implementeringsforløb

Et samlet risikoprogram undgår adskilte regneark for ISO, NIS2, DORA, GDPR og kundeassurance. Den praktiske fremgangsmåde er:

1. Bekræft ISMS-omfang, tjenester, aktiver, leverandører, jurisdiktioner og kundeforpligtelser.
2. Opbyg eller opdatér efterlevelsesregisteret med Politik for juridisk og regulatorisk efterlevelse - SMV, hvor det er relevant.
3. Definér risikometodik, acceptkriterier, sandsynlighedsskalaer, konsekvensskalaer og regler for regulatorisk konsekvens.
4. Opbyg risikoregisteret med Zenith Blueprint-risikostyringsfasen og Clarysecs metode for opbygning af risikoregister og SoA.
5. Identificér aktivbaserede og scenariebaserede risici, herunder leverandør-, cloud-, privatlivs-, kontinuitets-, hændelses-, sårbarheds-, sikker udviklings- og adgangsscenarier.
6. Score risici med kriterier, der omfatter retlige, regulatoriske, kontraktlige, operationelle, privatlivsmæssige, leverandørmæssige og finansielle konsekvenser.
7. Vælg behandlingsmuligheder: afbøde, undgå, overføre eller acceptere.
8. Kortlæg nødvendige kontroller til ISO/IEC 27001:2022 Annex A og ISO/IEC 27002:2022-vejledning.
9. Opret eller opdatér anvendelighedserklæringen.
10. Kortlæg behandlinger til NIS2 Article 21, DORA-forventninger til styring af IKT-risici og tredjeparter, GDPR-ansvarlighed og kunders kontraktlige forpligtelser.
11. Indsaml bevismateriale, validér kontroleffektivitet, og indhent godkendelse af restrisiko.
12. Forbered en revisionspakke organiseret efter risiko, kontrol, regulering og bevisartefakt.
13. Indfør resultaterne i ledelsesgennemgang, intern revision, korrigerende handling og løbende forbedring.

Dette er ikke papirarbejde for papirarbejdets skyld. Det er operativsystemet for forsvarlig cybergovernance.

Opbyg en revisionsklar pakke for risikobehandling

Sarahs historie ender godt, fordi hun holdt op med at behandle ISO 27001, NIS2 og DORA som separate efterlevelsesprojekter. Hun brugte ISO 27001-risikovurdering som den centrale motor, indlejrede regulatoriske forpligtelser i risikokriterierne, kortlagde behandlingshandlinger til Annex A og EU-krav og indsamlede bevismateriale, som kunder, revisorer og bestyrelsen kunne forstå.

Jeres organisation kan gøre det samme.

Brug Zenith Blueprint: en revisors 30-trins køreplan til at definere risikokriterier, opbygge risikoregisteret, oprette risikobehandlingsplanen og krydshenvise regulatoriske krav.

Brug Zenith Controls: vejledningen til tværgående efterlevelse til at forbinde ISO/IEC 27001:2022 Annex A-kontrolområder med governance, juridisk efterlevelse, assurance og revisionsperspektiver.

Brug Clarysecs Politik for risikostyring, Politik for risikostyring - SMV og Politik for juridisk og regulatorisk efterlevelse - SMV til at standardisere ejerskab, registre, behandlingsbeslutninger og revisionsklart bevismateriale.

Det hurtigste praktiske næste skridt er at tage jeres ti største risici og teste dem mod fem spørgsmål:

1. Er den regulatoriske konsekvens synlig?
2. Er behandlingsplanen tidsbundet og ejet?
3. Er hver behandling kortlagt til Annex A og SoA?
4. Er relevansen for NIS2, DORA, GDPR eller kunder dokumenteret, hvor det er relevant?
5. Findes der bevismateriale for, at kontrollen virker?

Hvis svaret er nej, kan Clarysec hjælpe med at omsætte jeres risikoregister til et forsvarligt, tværgående risikobehandlingsprogram for efterlevelse, som revisorer, tilsynsmyndigheder, kunder og bestyrelser kan have tillid til.