DORA-förordningen för fintech: IKT- och tredjepartsrisk

Vad det är

DORA är en förordning och gäller därför direkt i medlemsstaterna, med stöd av tekniska standarder. Den vilar på fem pelare. IKT-riskhantering kräver ett dokumenterat ramverk som omfattar identifiering, skydd, upptäckt, respons och återställning, lärande och kommunikation, där ledningsorganet har det yttersta ansvaret. Hantering av IKT-relaterade incidenter kräver klassificering av incidenter och rapportering av större incidenter till behörig myndighet inom fastställda tidsramar. Testning av digital operativ motståndskraft kräver ett testprogram som står i proportion till entiteten; vissa entiteter som utsetts av myndigheterna måste dessutom genomgå hotbaserade penetrationstester enligt särskilda regler. Hantering av IKT-tredjepartsrisker kräver ett informationsregister över alla avtal om IKT-tjänster, riskbedömning före avtalsslut, särskilda avtalsvillkor och exitstrategier. Informationsutbyte om hot uppmuntras inom betrodda grupper. Proportionalitet gäller genomgående, och en fastställd lista över mindre entiteter, till exempel små och icke-sammanlänkade värdepappersföretag samt vissa undantagna betalningsinstitut och institut för elektroniska pengar, får tillämpa det förenklade ramverket för IKT-riskhantering i artikel 16.

Vem det är för

Guiden riktar sig till:

• Betalnings-, e-pengar-, kryptotillgångs-, värdepappers- och andra tillståndspliktiga fintechbolag som omfattas av DORA:s förteckning över finansiella entiteter
• Ansvariga för regelefterlevnad, risk och teknik som bygger upp eller granskar ett DORA-program
• IKT-leverantörer och programvaruleverantörer som betjänar finansiella entiteter och får avtalskrav kopplade till DORA
• Grundare som behöver förklara DORA:s förväntningar för investerare eller styrelser

Vad det hjälper till att klargöra

Att gå igenom pelarna hjälper till att klargöra:

• Vilka kritiska eller viktiga funktioner verksamheten stöder och vilka IKT-system de är beroende av
• Om ert tredjepartsregister och era avtal innehåller det som DORA förväntar sig
• Vad ert testprogram för motståndskraft bör omfatta med hänsyn till storlek och riskprofil
• Var tekniska belägg saknas som stöd för styrdokumenten

Vad ingår

• Styrning: bekräfta att ledningsorganet godkänner och övervakar ramverket för IKT-risk, och dokumentera roller
• Kartläggning av tillgångar och funktioner: identifiera kritiska eller viktiga funktioner och de system, data och leverantörer som ligger bakom dem
• Skydd och upptäckt: granska åtkomstkontroll, MFA, loggning och övervakning för dessa system
• Incidenthantering: definiera klassificeringskriterier, beslutsfattare och arbetsflöde för rapportering av större incidenter
• Kontinuitet: testa säkerhetskopiering, återställning och återställningsmål för kritiska funktioner
• Testprogram: planera sårbarhetsbedömningar, scenariotester och penetrationstester i proportion till risken
• Tredjepartsregister: lista alla IKT-avtal med funktion, data, plats och uppgifter om underleverantörer
• Avtal: kontrollera att föreskrivna villkor finns, som tjänstebeskrivningar, dataplats, rätt till revision och åtkomst, stöd vid incidenter och villkor för avslut
• Exitstrategier: dokumentera hur ni skulle lämna en kritisk leverantör
• Koncentrationsrisk: notera var flera kritiska funktioner är beroende av en och samma leverantör

Vad som inte ingår

• Juridisk rådgivning eller regulatorisk tolkning för ert specifika tillstånd
• Hotbaserade penetrationstester enligt ett ramverk som utsetts av tillsynsmyndigheten
• Inlämning av incidentrapporter eller register till myndigheter
• Certifiering eller godkännande av regelefterlevnad

När det passar att välja den

Använd guiden när ni förbereder eller granskar ert DORA-program, innan ni förnyar avtal med viktiga IKT-leverantörer och innan den årliga testplanen fastställs. Om er behöriga myndighet har gett ut särskild vägledning eller ställt särskilda krav, följ dem först. Leverantörer som betjänar finansiella entiteter bör använda avsnittet om tredjeparter för att förutse förfrågningar om avtal och revision. Den här artikeln är allmän information och inte juridisk rådgivning.

Vår strategi

De flesta fintechbolag upptäcker att dokumentationen finns men att de tekniska beläggen är tunna. Börja med att kartlägga kritiska funktioner mot system och leverantörer; den enda övningen driver registret, testomfattningen och kontinuitetsplaneringen. Samla sedan belägg för hur centrala kontroller faktiskt fungerar. Vår tjänst Security Baseline Review kan ge en skriftlig bild av överenskomna tillgångar, klassad efter allvarlighetsgrad, som visar var konfiguration och åtkomstkontroller står. För testning av applikationer och API:er inom testprogrammet för motståndskraft arbetar vår tjänst Penetration Testing utifrån skriftlig omfattning och auktorisering och levererar fynd klassade efter allvarlighetsgrad, med omtest av överenskomna fynd där det ingår. Båda kompletterar hotbaserade tester som utsetts av tillsynsmyndigheten, juridisk rådgivning och godkännande av regelefterlevnad, som följer egna processer. Datera varje belägg och koppla det till den funktion det stöder, så att ledningens granskningar och tillsynsfrågor kan besvaras utifrån dokumentation snarare än minne.

Security Baseline Review

Vanliga frågor

Relaterade artiklar