Behörigheter och loggning i finanssystem: så uppfyller ni kraven

Det här tittar tillsynen på – och därför är behörigheter och loggning en compliance-fråga

Finansinspektionens webbplats tar bland annat upp cybersäkerhetshot från avancerad AI och nya nationella rekommendationer. FI har startat en kartläggning av hur finansiella företag använder AI och hanterar teknikens möjligheter, risker och utmaningar (publicerat 2026-09-03). FI driver också forumet Nationell riskbedömning av penningtvätt och finansiering av terrorism. Där redogör myndigheten för identifierade risker och prioriterade risker i penningtvättstillsynen under året.

Vilka regelverk ni omfattas av beror på verksamhetstypen. En svensk leverantör av granskningsinfrastruktur uppger att lösningen riktar sig till banker, försäkringsbolag, värdepappersinstitut, kryptotjänsteleverantörer och deras kritiska ICT-leverantörer. Den ska täcka krav från bland annat Finansinspektionen, EBA och ESMA.

DORA – Europaparlamentets och rådets förordning (EU) 2022/2554 om digital operativ motståndskraft för finanssektorn – trädde i kraft den 17 januari 2023 och tillämpas från och med den 17 januari 2025. Någon övergångsperiod efter tillämpningsdatumet finns inte. För banker, försäkringsbolag, värdepappersbolag, betaltjänstleverantörer och kryptotjänsteleverantörer innebär det att IKT-risk ska hanteras lika strikt som finansiell risk.

Den engelska benämningen är Digital Operational Resilience Act. IKT-riskhanteringen enligt förordningen omfattar styrning, ramverk, klassificering av IKT-tillgångar, kontinuerlig riskbedömning, kontinuitetsplanering och säkerhetsåtgärder. Behörigheter och loggning hör hemma i styrningen och i säkerhetsåtgärderna.

DORA är lex specialis i förhållande till NIS2 och cybersäkerhetslagen: när DORA är tillämplig på en finansiell enhet går den före NIS2:s motsvarande krav. Förordningen gäller direkt i Sverige utan nationell implementeringsakt och kompletteras av Finansinspektionens föreskrifter och tillsyn. Europeiska finansmarknadsmyndigheter bereder tekniska standarder som kompletterar förordningen.

Förordningen tillämpas med proportionalitetsprincipen: kraven står i proportion till den finansiella enhetens storlek, och mikroföretag omfattas av lindrigare krav. Kravområdena omfattar IKT-riskhantering, incidentrapportering, motståndskraftsprovning och tredjepartsriskhantering. Bestämmelserna om organiseringen av IKT-riskhanteringen är delvis mer detaljerade än tidigare.

Oavsett leverantör är första steget detsamma: identifiera vilka av FI:s föreskrifter (FFFS) som gäller er. De publiceras i FI:s egen FFFS-samling och är den text tillsynen utgår från. Utgå från verksamhetstypen i inventeringen, inte från vilka system ni råkar ha.

FI:s föreskrifter söks i FFFS-samlingen och beslut publiceras i FI:s diarium. Det är där numren på de föreskrifter som gäller er verksamhetstyp finns.

Tillsynen får ekonomiska konsekvenser. I september 2026 beslutade FI om en anmärkning och en sanktionsavgift på 2 miljoner kronor mot AIFM Capital AB. FI avslutar samtidigt undersökningar löpande – under 2026 bland annat undersökningar av MedMera Banks och Ica Bankens kreditprövningar.

FI avslutade undersökningen av Infinipi AB och reglerna om kapitalkrav för betalningsinstitut (2026-08-27). FI undersöker Steven AB och lagen om elektroniska pengar (2026-06-17). FI genomför dessutom en fördjupad analys av bankers interna likviditetsstresstester (2026-07-02) och av korrespondentförbindelser i banksektorn (2026-06-30).

Vid en sådan granskning behöver ni kunna visa två saker: en aktuell behörighetsmatris och en logg som visar faktisk användning. Saknas någon av dem tvingas ni rekonstruera händelseförlopp i efterhand, vilket tar tid och lämnar utrymme för tolkning.

Roller, attestflöden och minsta nödvändiga åtkomst

Börja med en funktionskartläggning, inte en systemlista. Beskriv arbetsuppgifterna i kedjan från ansökan eller transaktion till beslut och bokföring: handläggare som registrerar och bereder, attestant eller beslutsfattare som godkänner, systemförvaltare som konfigurerar regler och behörigheter, och externa parter som leverantörer, konsulter eller samarbetspartner.

Gå sedan till varje system och översätt varje funktion till de behörigheter den kräver. Resultatet är en matris med funktion i raderna och system/behörighetsnivåer i kolumnerna, där varje cell antingen är motiverad av en arbetsuppgift eller tas bort.

Skilj på personliga konton och systemkonton. Varje systemkonto ska ha en namngiven ägare och tas med i matrisen på samma sätt som en roll.

Dela upp behörigheter i nivåer efter vad någon faktiskt behöver göra: läsrättighet till uppgifter, rätt att registrera, rätt att attestera eller besluta, rätt att ändra regler och parametrar samt rätt att administrera behörigheter. Separera den som registrerar ett ärende från den som attesterar det. Ingen ska kunna både lägga in och godkänna samma transaktion eller samma kreditbeslut. Behörigheten att ändra i behörighetssystemet ska ligga hos en liten, namngiven grupp och loggas separat.

Hantera undantagen lika strukturerat som grundfallen. Tillfällig förhöjd åtkomst (till exempel felsökning i produktion) ska vara tidsbegränsad, knuten till ett ärendenummer och avslutas automatiskt när tiden går ut. Externa leverantörers åtkomst ska ske via namngivna konton, aldrig via delade inloggningar, och kopplas till ett uppdrag med start- och slutdatum. Vid rollbyte eller avslut ska den gamla behörigheten stängas samma dag som ändringen registreras i HR-systemet – annars ligger kvarvarande åtkomst kvar och syns först vid nästa genomgång.

Samma ärende ska ge samma utfall – oavsett vem som handlägger

Beslutskonsistens innebär att lika ärenden behandlas lika. Tekniskt bygger det på att beslutsregler – tröskelvärden, kontrollpunkter och vilka uppgifter som måste finnas på plats – ligger i systemet i stället för i den enskilde handläggarens huvud.

En svensk leverantör beskriver sitt granskningslager som en plattform för beslutskonsistens, med formuleringen att samma ärende ska ge samma utfall. Oavsett om ni bygger eller köper funktionen är principen densamma: reglerna ska vara dokumenterade, versionerade och kopplade till den behörighet som krävs för att ändra dem.

Behörighetsstyrningen och granskningslagret hänger ihop i två led. Först ser behörighetsmodellen till att bara rätt roll kan fatta eller ändra ett beslut. Sedan jämför granskningslagret det fattade beslutet mot vad reglerna förutsåg för den ärendetypen och flaggar avvikelser.

Det gör att ni kan svara på om avvikelsen beror på att regeln var fel, att underlaget var ofullständigt eller att någon agerat utanför sin behörighet. Det är tre olika orsaker som kräver tre olika åtgärder.

För att detta ska fungera i praktiken behöver varje beslut bära med sig spårbara fakta: vilken regelversion som tillämpades, vilket underlag som låg till grund, vem som fattade beslutet och vem som attesterade. Gör återkommande stickprovskontroller där samma typ av ärende plockas ut över tid och jämförs, och logga även själva kontrollen.

Loggning när någon begär kontouppgifter eller transaktionsdata

Varje begäran om kontotransaktioner eller kontouppgifter ska lämna ett spår som går att läsa utan att läsaren känner till systemet. Loggposten bör minst innehålla vem som begärde: namn eller systemidentitet, roll och organisation. Den bör också innehålla tidpunkt med tidsstämpel, tidszon och synkroniserad klocka mellan systemen, samt ärendenummer eller motsvarande uppdrag och grunden för begäran.

Loggposten bör också visa vad som begärdes: vilka konton eller kontonummer, vilken tidsperiod och vilket urval. Den bör visa via vilket stöd begäran gjordes: manuell sökning i handläggningssystemet, integration, API eller automatiskt system, och vad som returnerades. Om uppgifterna fördes vidare till någon annan i handläggningen ska även det framgå.

Koppla loggen till rätten att invända. I Finland finns ett övervakningssystem för bank- och betalkonton, och i regeringens proposition RP 49/2026 rd föreslås att den som ansöker om en förmån ska kunna förbjuda att en begäran om uppgifter om kontotransaktioner görs via övervakningssystemet. Oavsett vilken rättslig grund som gäller hos er visar exemplet vilken typ av invändning ni behöver hantera: en registrerad invändning måste vara sökbar i loggen, och det måste framgå att ingen begäran gjorts i strid med den.

Bygg rutinen så att invändningen har samma status som en spärr. Registrera datum, vem som begärde den, vilket konto eller vilken ärendetyp den avser och vem som beslutat att lägga in den. Lägg en kontroll som stoppar begäran i systemet om en invändning finns.

Logga även blockerade försök – ett stoppat försök är bevis på att kontrollen fungerar, inte en incident. Vid uppföljning ska ni per konto kunna visa tre saker: vilka begäranden som gjorts, vilka som stoppats av en invändning och vilka invändningar som är aktiva just nu.

Från rå logg till underlag som håller vid en granskning

Skilj på händelselogg och ändringslogg. Händelseloggen svarar på vem som gjorde vad och när; ändringsloggen visar vad som ändrades, från vilket värde till vilket, och av vem. Båda behövs, men de används olika: händelseloggen för att följa ett ärende eller ett konto, ändringsloggen för att följa en regel, en parameter eller en behörighet över tid. Samla dem centralt i stället för att lämna dem kvar i respektive system, så att ni kan söka tvärs över system vid en förfrågan.

Skydda loggen mot de personer den beskriver. Loggen ska vara skrivskyddad för handläggare och systemförvaltare, och behörigheten att läsa eller exportera loggdata ska ligga hos en separat funktion, till exempel internrevision eller compliance. Tekniskt innebär det vanligen append-only-skrivning, hashning eller signering av loggposter och en separat åtkomstkontroll för loggplattformen. Gallring ska följa en dokumenterad policy som utgår från ändamålet med loggen, så att ni kan förklara både varför data sparas och varför den tas bort.

Gör underlaget begripligt innan någon begär det. Bestäm en rapportmall som kan filtreras på ärende, person, konto och tidsperiod, se till att fältnamnen är begripliga för en extern läsare och dokumentera datamodellen så att kolumnerna betyder samma sak i alla system. Testa mallen genom att plocka fram ett slumpvis valt ärende från begäran till beslut med enbart loggdata, och tidsätt övningen. Om framtagningen kräver manuellt detektivarbete mellan flera system är det den svagheten en granskning först hittar.

Motståndskraftsprovning är ett eget kravområde i förordningen. Det som provas ska gå att följa i efterhand: vilka system, vilka scenarier och vad resultatet blev.

Rapportering av IKT-relaterade incidenter är ett eget kravområde i DORA. Innehållet i rapporteringen och rapporteringens tröskelvärden anges närmare i den kompletterande regleringen. Loggen är det underlag som visar om en händelse når tröskelvärdet och vad som i så fall ska beskrivas.

De tekniska standarderna bereds i de europeiska finansmarknadsmyndigheternas arbetsgrupper och avsågs bli klara under hösten 2024. I takt med att de blir klara uppdateras tillsynsmyndigheternas föreskrifter och anvisningar.

AI-funktioner och kritiska ICT-leverantörer i behörighetsmodellen

AI-stöd i handläggningen är en ny åtkomstväg och ska behandlas som en sådan. Ett AI-verktyg som får läsa ärendedata behöver ett eget, avgränsat konto eller en egen integration – aldrig ett delat användarkonto och aldrig åtkomst till mer data än uppgiften kräver. AI-funktionen ska inte kunna attestera eller fatta beslut; den kan föreslå, och förslaget ska granskas av en namngiven handläggare.

Logga AI-anropen som andra begäranden: vilken modell eller tjänst som anropades, vilken data som skickades in, vilken tidpunkt, inom vilket ärende och vilken utdata som kom tillbaka till handläggningen. Då kan ni i efterhand visa om ett beslut byggde på AI-stöd och på vilket underlag. Bestäm också i förväg vilka ärendetyper AI-stödet får användas i och dokumentera det i behörighetsmodellen.

FI startade 2026-09-03 en kartläggning av hur finansiella företag använder AI och hanterar teknikens möjligheter, risker och utmaningar. Loggningen av AI-anropen är det underlag som gör användningen beskrivbar.

Kritiska IKT-tredjepartsleverantörer är ett eget begrepp i DORA. Förordningen ställer enhetliga krav på finansiella enheter och deras kritiska IKT-tredjepartsleverantörer, och tredjepartsriskhantering är ett av kravområdena. Leverantörsledet blir därmed en del av er egen efterlevnad, inte enbart en avtalsfråga.

Kritiska ICT-leverantörer behöver komma in i systemen på villkor ni kontrollerar. I er modell betyder det: namngivna konton per leverantör och person, åtkomst begränsad till de system och miljöer uppdraget avser, tidsbegränsning med automatiskt avslut och loggning av varje session med uppdragsreferens. Ställ avtalskrav på att leverantören lämnar ut sin egen åtkomstlogg vid begäran, och följ upp att åtkomsten faktiskt stängs när uppdraget är slut – inte bara att den planerades stängas.

Löpande uppföljning: behörighetsgenomgång, avvikelser och åtgärder

Sätt en fast kadens och en fast agenda för behörighetsgenomgången. Vid varje tillfälle: lista samtliga konton och roller per system, stäm av varje behörighet mot en aktuell person och en aktuell arbetsuppgift, stäng det som inte längre är motiverat och dokumentera vem som genomfört genomgången och när. Lägg särskild vikt vid behörigheter som inte går via den vanliga rolltilldelningen – tillfälliga konton, break-glass-åtkomst och externa användare. En genomgång utan signering är ingen genomgång; avsaknaden av dokumentation gör att ni inte kan visa att rutinen följs.

Bygg larmregler för avvikelser som faktiskt betyder något och knyt dem till loggen. Larma på åtkomst till kontouppgifter utan kopplat ärendenummer och på begäranden i strid med registrerad invändning. Larma också på ovanligt hög uttagsvolym från en enskild användare, åtkomst utanför normal arbetstid, upprepade misslyckade inloggningsförsök och åtkomst från platser eller enheter som inte använts tidigare. Varje larm ska ha en namngiven mottagare och en definierad svarstid, annars blir larmlistan bara brus.

Dokumentera varje avvikelse och brist så att den går att följa över tid: datum, vad som hände, vilket ärende eller konto det gällde, orsak, vilken åtgärd som vidtogs, ansvarig person och datum för åtgärden. För in slutsatserna i behörighetsmodellen – om en avvikelse berodde på en för bred roll ska rollen ändras, inte bara ärendet stängas. Rapportera sammanställningen till ledning och compliance med jämna mellanrum, så att ni vid tillsyn kan visa både rutinen och att den tillämpats över tid.

Rapporteringen till ledningsorganet ska visa både genomgångens resultat och de avvikelser som ännu inte är åtgärdade. Underlaget ska visa vad ledningen fått och när.

Enligt DORA bär ledningsorganet det yttersta ansvaret för IKT-riskhanteringen. Rapporteringen till ledning och compliance är därför inte bara intern styrning, utan ett led i att uppfylla förordningens krav.