Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Table of Contents
maxLevel2
indent10px
stylenone

Info

Den tidigare arbetsytan för Tillitsstruktur som låg här har flyttas till Leveransteam Tillitsstruktur.

Tanken är att vi här istället dokumenterar resultatet av arbetet, det vill säga själva leveransen.

Table of Contents
maxLevel3

Inledning

När två parter behöver utbyta information kan det vara så är det ofta krav på att respektive sida först behöver säkerställa att motparten är den den utger sig att vara, och att denne är behörig att ta del av den information som delas. Det är informationsägaren som ansvarar för att säkerställa att man är behörig innan informationen kan lämnas ut. Det finns fall där man inte alls ställer särskilda krav på behörighet - till exempelvis för öppen data. I andra dessa fall kan krävs det krävas säkerställd information om vem organisationen, systemet och/eller individen som begär åtkomst är och , samt vad som berättigar åtkomsten - till exempelvis att man har ett tilldelat uppdrag, . Exempelvis kan organisationen vara en myndighet, region, eller kommun, och användaren agerar utifrån ett tilldelat uppdrag. Det kan också ställas krav på att användaren har en specifik kvalifikation, eller liknandeagerar i en legitimerad yrkesroll. Man kan förenklat säga att det är en skala från inget behov alls till hög tillförlitlighet till underlaget som ger behörighet. Var på skalan man är för en specifik åtkomst står normalt i direkt proportion till informationens känslighet.Inom ramen  

Inom ramen för detta dokument beskrivs ett ramverk för att ge skapa tillit till att till att förmedling och hantering av identiteter och behörighetsgrundande information sker på ett säkert sätt. Detta ramverk Ramverket ska minimera risken för obehörig åtkomst till information. I dagens komplexa samverkan, där man ofta behöver hämta och behandla information från flera parter för att stödja verksamhetsbehov, behöver också tilliten upprätthållas i flera led mellan alla parter som tar fram det underlag som behövs för åtkomstbeslut. För att möjliggöra korrekta åtkomstbeslut krävs att tillit kan skapas till alla inblandade parter och komponenter - detta är målet med Enas tillitsramverkEnas tillitshantering, vilken innehåller en tillitsmodell och en realisering av denna modell för Enas federationsinfrastruktur.

Drivkrafter och principer

  • Ramverket ska skapa en struktur för bred återanvändning av gemensamma, generella och överenskomna nivåer av tillit. 
    • Oavsett tillämpningar/sektorer/domäner eller typen av information.
    • En gemensam grund som alla kan acceptera och känna igen sig i.
  • Ramverket ska möjliggöra aktiv vidareutveckling och förvaltning av tillitsmärken 
    • När digitala tjänster med krav som skiljer sig avsevärt från andras, ska det gå att ta fram nya tillitsmärken inom ramverket.
    • När nya säkerhetsambitioner, eller nya säkerhetshot, uppkommer ska ramverket stödja aktiv livscykelhantering för existerande tillitsmärken.
  • Det ska vara lätt för befintliga digitala tillämpning i samhället att relatera till Ena tillitsramverk och se eventuella förflyttningar som krävs för att kunna erbjuda tillämpningar inom Ena.

...

Summering

...

...

Förslag på tillitsmodell

Den föreslagna modellen utgår ifrån att de olika komponenter som deltar i en samverkan med utbyte av skyddsvärd information, bidrar med olika förmågor vid hantering av metadata, identiteter och behörighetsgrundande information. En grundsten i modellen är tillitsmärken som signalerar tillit och tilldelas komponenterna efter att specifika tillitsskapande krav kopplade till tillitsmärket är uppfyllda. En komponent kan även realisera förmågor med hjälp av under- eller bakomliggande komponenter och representerar då dessa förmågor i infrastrukturen. Vilka tillitsmärken som en specifik komponent således behöver ansöka om att få tilldelade beror på vilka förmågor som den realiserar i infrastrukturen.


draw.io Diagram
borderfalse
diagramNameMetamodell
simpleViewerfalse
linksauto
tbstyleinline
lboxtrue
diagramWidth406
height306
revision13
Image Removed

IAM-förmågor och tillitsfull information

En IAM-förmåga innefattar här både en tekniska förmåga inom identitets- och behörighetsområdet och de verksamhetsprocesser som behövs för att upprätta och underhålla förmågan. IAM-förmågor realiseras av specifika tekniska komponenter och fungerar som byggstenar som byggstenar för tillit vid samverkan som kräver säker hantering av identiteter och åtkomstbeslut.

IAM-förmågorna skapar, behandlar, eller förmedlar information som är strukturerad och man behöver ha tillit till. De idag identifierade typerna av sådan tillitsfull information är:

  • Metadata - information om komponent, publicerad av kontrollerad och betrodd part i federationen
  • Intygsbegäran - en begäran om intygande om identitet, behörighetsstyrande attribut, eller behörighet. 

  • Intyg - betrodda påståenden om en användare, såsom identitet, behörighetsstyrande information, eller behörighet. 

I modellen som visas i nedanstående bild och efterföljande tabell beskrivs de olika typer av tekniska komponenter och vilka , vilka IAM-förmågor som de realiserar, samt hur dessa relaterar till olika typer av tillitsfull information

Status
titleTODO
Intygsutfärdade => Intygsutfärdande i bilden


draw.io Diagram
borderfalse
diagramNameIAM-Förmågor och komponenter
simpleViewerfalse
width
linksauto
tbstyleinline
lboxtrue
diagramWidth857
height761
revision9
Image Removed


KomponentBeskrivningIAM-förmågaBeskrivning
Tillitsankare
Tillitsankartjänst

Ett

Tillitsankare

Tillitsankartjänst är en komponent som utgör den yttersta källan till tillit i en federationsinfrastruktur och publicerar signerad metadata som omfattar godkända underordnade entiteter, som

tex Anslutningspunkter och Tillitsmärkesutfärdare

tex Anslutningstjänster och Tillitsmärkestjänster.

Det möjliggör validering av tillitskedjor genom kryptografisk signaturvalidering.

Parter vars metadata ingår i en tillitskedja som kan valideras upp till samma

Tillitsankare

Tillitsankartjänst anses ingå i samma federation och omfattas av den tillit som

Tillitsankaret

Tillitsankartjänsten representerar.

Betrodd

metadatapubliceringBetrodd metadata är information om parter som är kontrollerad och publicerad av en betrodd aktör i federationen.Anslutningspunkt

Metadatapublicering

Metadatapublicering är en IAM-förmåga som innebär att en komponent på ett kontrollerat, säkert och tillförlitligt sätt publicerar signerad metadata om sig själv – och i vissa fall även om andra entiteter – inom ramen för en federation. Publiceringen sker för att möjliggöra teknisk tillit, interoperabilitet och korrekt tolkning av entitetens roll och kapacitet i federationen.

Den metadata som publiceras kan inkludera:

  • Komponentens unika identifierare (entityID)

  • Kryptografiska nycklar för signering och kryptering

  • Endpoints för t.ex. tokenutbyte, autentisering, attributleverans

  • Kontaktuppgifter för teknisk och administrativ hantering

  • Policyinformation och tillitsskapande krav (t.ex. tillitsnivåer, accepterade identitetsintyg)Information om eventuella underordnade entiteter (t.ex. vid hierarkisk federation)

Funktionen är central för att federationens övriga parter ska kunna validera, lita på och kommunicera med komponenten på ett säkert sätt.

Anslutningstjänst

En Anslutningstjänst

En Anslutningspunkt

är en mellanliggande komponent i federationsinfrastrukturen som publicerar signerad metadata för underordnade entiteter som tex Legitimeringstjänster, Auktorisationstjänster, E-tjänster och API:er

Den möjliggör en delegerad och skalbar struktur för förmedling av tillitsinformation genom att fungera som ett tekniskt och organisatoriskt gränssnitt för anslutning av nya

federationsparter

federationstjänster till ett eller flera

Tillitankare

Tillitsankartjänst.

Tillitsmärkesutfärdare
Tillitsmärkestjänst

En

Tillitsmärkesutfärdare

Tillitsmärkestjänst är en komponent i federationsinfrastrukturen som utfärdar tillitsmärken till entiteter som uppfyller definierade krav kopplade till specifika IAM-förmågor.

Tillitsmärkesutfärdaren

Tillitsmärkestjänster publicerar signerad metadata som innehåller dessa tillitsmärken och agerar som betrodd part inom ramen för den federativa tillitsmodellen.

Uppslag och verifieringstjänst

En Uppslag- och verifieringstjänst är en komponent i federationsinfrastrukturen som används för att slå upp, hämta och verifiera metadata för andra entiteter inom en federation.

Tjänsten möjliggör tillitsvalidering genom att rekonstruera tillitskedjor, kontrollera signaturer och säkerställa att metadata uppfyller definierade policykrav.

Parter vars metadata kan verifieras via en Uppslag- och verifieringstjänst till ett gemensamt Tillitsankare anses omfattas av samma tillit och därmed ingå i federationen

Metadatavalidering

Metadatavalidering är en IAM-förmåga som innebär att en komponent kan hämta, tolka och kryptografiskt verifiera signerad metadata

för

från andra entiteter inom en federation. Denna förmåga är avgörande för att säkerställa att tilliten mellan parter i federationen är tekniskt grundad och uppdaterad.

Funktionen omfattar flera moment:

  • Inhämtning av metadata från specificerade källor

  • Kontroll av signaturer och certifikat för att säkerställa att metadata är äkta och oförändrad.

  • Tolkning av metadataformat och extraktion av relevant information

  • Uppdatering av lokal cache enligt angivna regler för livslängd och uppdateringsintervall.

Metadatavalidering skapar teknisk tillit genom att identifiera och autentisera entiteter innan någon interaktion sker, och används som grund för vidare beslut inom t.ex. åtkomstbegäran och åtkomstkontroll.

Legitimeringstjänst

En Legitimeringstjänst är en komponent i federationsinfrastrukturen som ansvarar för att autentisera en användare.

Tjänsten utfärdar digitalt signerade intyg som kan innehålla behörighetsgrundande information, såsom användarens identifierare eller autentiseringsnivå.

Intygsutfärdande
Digitalt signerade

Intygsutfärdande är en IAM-förmåga som innebär att en komponent på ett tillförlitligt och säkert sätt kan skapa och leverera digitalt signerade intyg. Dessa intyg innehåller påståenden om en användare eller klient,

såsom

exempelvis vilken nivå av autentisering som

skett

har genomförts, vilka

behörighetsgrundande

attribut som

gäller

är giltiga och aktuella, eller vilka

rättigheter användaren tilldelats

åtkomsträttigheter användaren är tilldelad.

Funktionen utgör en kärna i federativ åtkomsthantering, där beslut om åtkomst ofta baseras på dessa intyg. Förmågan inkluderar inte enbart den tekniska akten att signera data, utan även processer för att säkerställa:

  • att innehållet i intyget bygger på tillförlitlig information,

  • att syftet med intyget är tydligt definierat,

  • att leveransen sker på ett säkert sätt till rätt mottagare.

Auktorisationstjänst

En Auktorisationstjänst är en komponent som beslutar om och utfärdar information om användares åtkomsträttigheter till digitala resurser, baserat på tillgänglig identitets- och attributinformation.

Den skapar intyg som beskriver vilka resurser en användare har rätt att använda, och på vilka villkor.

Attributkälla

En Attributkälla är en komponent som tillhandahåller information om användare, exempelvis roller, organisatorisk tillhörighet eller andra behörighetsgrundande attribut.

Den fungerar som en betrodd källa till information som används av andra komponenter, som legitimerings- och auktorisationstjänster.

Attributhantering

Attributhantering är

förmågan

en IAM-förmåga som innebär att en organisation har kapacitet att säkert förvalta, kvalitetssäkra och tillgängliggöra användarattribut som används

för identitets- och åtkomstbeslut.

som underlag för identitetsverifiering, åtkomstbeslut eller intygsutfärdande. Förmågan omfattar både

teknisk leverans och ansvar för att informationen är korrekt, relevant och aktuell

den tekniska leveransen och det verksamhetsmässiga ansvaret för att attributinformationen är:

  • Korrekt – baserad på tillförlitliga källor och uppdaterad i rätt tid.

  • Relevant – anpassad efter den aktuella användningen och inte mer omfattande än nödvändigt.

  • Aktuell – uppdaterad i takt med att användarens status, roll eller rättigheter förändras.

Attributhantering omfattar hela attributets livscykel: från skapande och uppdatering, via lagring och styrning, till selektiv utlämning i rätt sammanhang. Förmågan bygger ofta på samverkan mellan tekniska system (t.ex. katalogtjänster, IAM-lösningar, HR-system) och organisatoriska rutiner (t.ex. kontroll av rolltilldelning och uppdrag)


Resursserver (API)En Resursserver är en komponent som tillhandahåller åtkomst till skyddade digitala resurser, och som kontrollerar åtkomst baserat på presenterade intyg eller behörigheter.Åtkomstkontroll

Åtkomstkontroll är

förmågan att

en IAM-förmåga som innebär att en komponent kan fatta och tillämpa beslut om en användares eller klients rätt att få tillgång till en

viss

specifik digital resurs, baserat på tillgänglig identitets- och behörighetsinformation. Förmågan utgör ett centralt skydd mot obehörig åtkomst och realiserar själva åtkomstbeslutet, ofta i en federerad kontext.

Förmågan innebär att

kontrollera om

komponenten:

  • Mottar ett åtkomstintyg eller en

begäran uppfyller de krav som ställs för att åtkomst ska beviljas, och att därefter tillåta eller neka åtkomst.
  • åtkomstbegäran

  • Verifierar att det inkomna intyget är giltigt, korrekt signerat och inte förfalskat.

  • Utvärderar åtkomstintygets eller begärans innehåll mot definierade behörighetsregler och policyer (t.ex. rollbaserade eller attributbaserade regler).

  • I realtid avgörs om en begärd åtkomst ska beviljas eller nekas.

  • Dokumenterar eller loggar åtkomstbeslutet enligt gällande krav.

Förmågan kan implementeras både centralt (t.ex. i en auktorisationstjänst) eller lokalt (t.ex. i en resursserver eller applikation), beroende på arkitektur och säkerhetsmodell.



E-tjänst

En E-tjänst är en applikation som erbjuder funktionalitet till användare, ofta via en webbläsare.

Den fungerar som användarens direkta kontaktpunkt mot digitala tjänster och ansvarar för att initiera åtkomstförfrågningar och inhämta identitets- och behörighetsinformation.

Resurs Server (API)

Status
titleTODO

E-tjänst StatustitleTODO

Klient

En Klient är en fristående applikation

eller serverprogramvara

, eller en del av en E-tjänst som agerar å användarens vägnar,

ofta

ibland fristående och utan direkt användarinteraktion

via webbläsare

.

Den används exempelvis i automatiserade system, mobilappar eller verksamhetssystem som kommunicerar med

E-tjänster eller

API:er för att hämta information eller utföra åtgärder.

Åtkomstbegäran

Här,

Åtkomstbegäran är en IAM-förmåga som innebär att en komponent kan initiera en begäran om

identitet-

ett identitetsintyg eller ett åtkomstintyg,

innehållande avsett syfte med intyget, samt underlag för begärans behandling och för intygets utformning.

i syfte att möjliggöra fortsatt åtkomst till en digital resurs eller tjänst. Förmågan omfattar att formulera och skicka en strukturerad begäran som innehåller tydlig information om:

  • Syftet med begäran (exempelvis åtkomst till en specifik resurs, eller initiering av en autentisering)

  • Vilken typ av intyg som efterfrågas (t.ex. ID-token, attributintyg, access token)

  • Vilket underlag som behövs för intygsutfärdaren att behandla begäran (t.ex. redirect URI, scope, claims, klientidentitet)

Förmågan är viktig i federerade miljöer eftersom den formaliserar och initierar flöden som bygger på tillit och verifierbarhet. En korrekt utformad åtkomstbegäran möjliggör tillförlitlig intygsutfärdning, och är därmed en nyckelkomponent i säker och interoperabel åtkomsthantering

Tillitsmärken

Att en teknisk komponent tilldelas ett tillitsmärke innebär att komponenten (och den organisation och verksamhet som ansvarar för komponenten) uppfyller de krav tillitsskapande krav som krävs för att på ett tillitsfullt sätt kunna utföra eller erbjuda IAM-förmågor. För viss samverkan via digitala tjänster kan det finnas informationssäkerhetskrav som föranleder mer omfattande tillitskrav tillitsskapande krav och detta tänker vi oss ska representeras av nivåindelad tillitsmärkning.

...

Vi föreslår således tillitsmärken som mappar emot IAM-förmågor och tilldelas tekniska komponenter enligt nedanstående bild och tabell.image-2025-6-5_10-33-42.pngImage Removed

draw.io Diagram
borderfalse
diagramNameKomponenter och tillitsmärken
simpleViewerfalse
linksauto
tbstyleinline
lboxtrue
diagramWidth836
height440
revision3


KomponentTillitsmärken
Legitimeringstjänst

Ena Tillit Intygsutfärdande

Ena

Utfärdare, Ena LoT-

Tillitsnivå 1, Ena

LoT-

Tillitsnivå 2, Ena

LoT-

Tillitsnivå 3, eller Ena

LoT-

Tillitsnivå 4

Auktorisationstjänst

Ena Tillit Intygsutfärdande

Ena Tillitsnivå Utfärdare, Ena LoT- 1, Ena LoT-Tillitsnivå 2, Ena LoT-Tillitsnivå 3, eller Ena LoT-Tillitsnivå 4

Attributkälla

Ena Tillit Attributhantering

Ena

Källa, Ena LoT-

Tillitsnivå 1, Ena

LoT-

Tillitsnivå 2, Ena

LoT-

Tillitsnivå 3, eller Ena

LoT-

Tillitsnivå 4

Resursserver (API)Ena HanteringTillit Åtkomstkontroll 
E-tjänstEna HanteringTillit Åtkomstkontroll
KlientEna HanteringTillit Åtkomstbegäran


Info
titleNotera!
  • Vi föreslår i nuläget inte tillitsmärken för betrodd metadatapublicering och
-validering
  • metadatavalidering. Detta då dessa förmågor är grundläggande i tillitsinfrastrukturen och
det inte är vettigt att säkerställa dem genom specifik tillitsmärkning.
  • tilliten till dem antas signaleras på annat sätt än genom tillitsmärken. 
  • Ena Tillit Nivå
LoT-nivå
  • kan inte mappas rakt av mot Svensk e-legitimations LoA-nivåer, men en viss
LoT-nivå
  • tillitsnivå kan ställa krav på att legitimering av användare skett på ett visst sätt.

Utvikning kring tillitsnivåer

Vi föreslår att behov av en viss tillitsnivå grundar sig i klassningen av den information eller funktion som en digital tjänst behandlar. För detta utgår vi ifrån MSB:s stöd för informationsklassning (Ref: Klassningsmodell, MSB). Identitet och behörighet inom Ena är inte en del av den ursprungliga klassningen utan snarare en säkerhetsåtgärd, med det är rimligt att anta att en given klassning har likvärdiga nivåer på åtgärder och att identitet och behörighet skulle kunna skapa mer generella paketeringar och utgöra en bra grund. Det vill säga att utifrån en klassning av en verksamhets information faller säkerhetsåtgärder ut.

...

Detta kan synliggöras genom ställa upp värdena i en matris med konfidentialitet och riktighet på axlarna, där det högsta värdet styr utfallet.

K/R

1

2

3

4

44444
33334
22234
11234

Det vill säga att när antingen konfidentialiteten eller riktigheten överstiger ett visst värde så faller likvärdiga krav och säkerhetsåtgärder ut kopplat till identitet och behörighet.

https://metodstod-informationssakerhet.msb.se/globalassets/exempel-pa-matris-med-konsekvenskriterier-och-konsekvensnivaer-for-riskanalys.png

Vi föreslår att Ena baserar sina tillitsnivåer på stödet "Klassningsmatris A - Fyra nivåer" från MSB med en tolkning av nivåernas innebörd enligt tabellen nedan. 

Level of TrustLoT-LoT-LoT-LoT-

Tillitsnivå

När ska man kräva det och vad innebär det?

1

Ett riktmärke är att konsekvenser ligger på försumbar skada avseende konfidentialitet eller riktighet.

2

Ett riktmärke är att konsekvenser ligger på måttlig skada avseende konfidentialitet eller riktighet.

3

Ett riktmärke är att konsekvenser ligger på betydande skada avseende konfidentialitet eller riktighet.

4

Ett riktmärke är att konsekvenser ligger på allvarlig skada avseende konfidentialitet eller riktighet.

Att omfattningen av konsekvenserna endast är ett riktmärke beror på att samma information skulle kunna ge olika klassningar hos olika aktörer, vilket inte betyder att det är fel på något sätt men det behövs en jämkning. Exempelvis om man tar en ekonomisk skada uttryckt i fasta belopp så kommer organisationens totala omsättning rimligen att styra hur betydande man anser att skadan kan bli. Medans om man uttrycker det i procent skulle man rimligen hamna mer lika. Därav att det inte kan vara mer än ett riktmärke och att dialog mellan parterna i ett större sammanhang behövs där en gemensam bedömning görs.

Info
titleKrav på LoTnivå av tillit

Varje samverkanstillämpning bör kräva att alla komponenter som ingår i tillitskedjan har LoT-ett tillitsmärke motsvarande minst den utifrån informationsklassningen klassade nivåntillitsnivån.


Tillitsskapande krav

Tillitsskapande krav kan vara av olika karaktär. Inom Enas tillisarbete tillitsarbete har vi identifierat fyra huvudkategorier av tillitsskapande krav:

  • Organisatoriska krav
  • Administrativa krav
  • Fysiska krav
  • Tekniska krav

Vi har genomfört en analys och sammanställning av tillitskrav tillitsskapande krav ställda inom federationerna Sweden Connect, Sambi, Skolfederation, SITHS och HSA. Kraven överlappar De olika federationernas tillitsskapande krav överlappar till stor del och vi har föresatt oss att skapa en nettolista av krav i Enas terminologi och anpassade för kontexten identitets- och behörighetshantering för komponenter som hanterar identiteter och behörighetsgrundande information för samverkan via digitala tjänster inom Ena.

ALLA tillitsskapande krav som stipuleras av något tillitsmärke SKA finnas registrerade med unika identiteter per krav i en gemensam Ena Kravkatalog. Detta innebär att ett enskilt tillitsmärke blir en listning av identiteterna på de krav som omfattas, samt hur efterlevnadskontroll ska genomföras.

Målen med denna påbörjade men ännu inte färdiga övning är flera:

  • Verksamheter som redan genomgått tillitsgranskning för någon av de genomgångna tillitsramverken ska automatiskt kunna vara kvalificerade för att bli tilldelade nödvändiga tillitsmärken och kunna etablera samverkan via digitala tjänster i Ena.
  • Digitala tjänster som erbjuds inom någon av de genomgångna federationerna ska kunna erbjuda samma tjänst inom Ena till parter som är anslutna till Enas federationsinfrastruktur.
  • Existerande federationer ska på sikt kunna luta sig emot Enas tillitsmärken för existerande tillgång till digitala tjänster och därmed minska samhällets totala kostnad för återkommande tillitsgranskningar.
Info
titlepreliminär tidplan

Vi siktar på att kunna presentera en första version av Enas kravkatalog under Q3 2025.

Efterlevnadskontroll vid tilldelning och revision av tillitsmärken

Tanken bakom det sätt som strukturen med tillitsmärken och en central kravkatalog är uppbyggd är att alla granskningsaktiviteter ska anpassas utifrån vilka tillitsskapande krav som en organisation, verksamhet, eller teknisk komponent redan uppfyller baserat på redan tilldelade tillitsmärken. Ett steg i utfärdandet av ett tillitsmärke är att ta fram vilka tillitsskapande krav som ansökanden behöver granskas emot. Det vill säga gapet mellan aktuellt tillitsmärkes kravomfång och de krav som den tekniska komponenten och dess bakomliggande ansvariga verksamhet eller organisation redan uppfyller. 

För att påvisa efterlevnad av de tillitsskapande krav som omfattas av ett tillitsmärke krävs det initiala och periodiskt återkommande mekanismer för efterlevnadskontroll. Vi har identifierat nedanstående mekanismer som används idag i olika liknande sammanhang:

  • Lagstadgad efterlevnad - granskning av många myndigheters efterlevnad av lagstadgade krav genomförs dels av myndigheten intern och av utpekad

...

  • tillsynsmyndighet.
  • Självdeklarerad efterlevnad baserad på intern revision - parter granskar sin egen efterlevnad genom internrevision och redovisar granskningsresultatet till Ena i en självdeklaration.
  • Självdeklarerad efterlevnad baserad på extern revision - parter låter genomföra en externt kontrakterad revision och redovisar granskningsresultatet till Ena i en självdeklaration.
  • Granskning - en av ena godkänd part granskar efterlevnad

Vilken granskning som genomförs beror dels av vilken part det är som granskas, dels av vilket tillitsmärke granskningen gäller. Exakt utformning av regelverk för efterlevnadskontroll och tillhörande processer kvarstår att utforma. 

Info
titlepreliminär tidplan

Vi siktar på att kunna presentera en första version av Enas regelverk för efterlevnadskontroll för tillitsmärken under Q4 2025.


 Exempel på tillämpning av tillitsstrukturen

Status
colourYellow
titleTODO
Från möte 12/6 - det är bra om vi exemplifierar en eller flera tillämpningar av föreslagen struktur.

...