Hoe beheer je DORA-risico's van derde partijen op het gebied van ICT met behulp van AI

Overzicht

Je leert hoe je de vereisten voor het beheer van ICT-risico's van derde partijen onder de artikelen 28-30 van DORA kunt implementeren met behulp van AI. Deze gids behandelt het opbouwen en onderhouden van het register van ICT-leveranciers van derde partijen, het uitvoeren van precontractuele beoordelingen, het opnemen van verplichte contractclausules, het beoordelen van concentratierisico's, het ontwikkelen van exitstrategieën en het instellen van doorlopende monitoring, met specifieke ISMS Copilot-prompts voor het genereren van elke component.

Voor wie is dit bedoeld

Deze gids is bedoeld voor:

• Risicomanagers voor derde partijen en professionals op het gebied van leveranciersbeheer bij financiële entiteiten
• Inkoop- en juridische teams die verantwoordelijk zijn voor contracten met ICT-dienstverleners
• CISO's en CRO's die toezicht houden op ICT-toeleveringsketenrisico's
• Compliance officers die ervoor zorgen dat regelingen met derde partijen voldoen aan de DORA-vereisten
• Consultants die financiële entiteiten adviseren over het beheer van DORA-risico's van derde partijen
• ICT-dienstverleners van derde partijen die de verplichtingen van hun klanten willen begrijpen

Voordat je begint

Je hebt het volgende nodig:

• Een ISMS Copilot-account (gratis proefversie beschikbaar)
• Je ICT-activiteiteninventaris uit Hoe bouw je een DORA ICT-risicomanagementraamwerk met behulp van AI (identificeert welke activa afhankelijk zijn van leveranciers van derde partijen)
• Een lijst van je huidige ICT-leveranciers van derde partijen en de diensten die zij leveren
• Toegang tot bestaande ICT-dienstcontracten voor beoordeling
• Inzicht in welke ICT-diensten je kritieke of belangrijke functies ondersteunen
• Toegang tot je juridische, inkoop- en leveranciersbeheerteams

Inzicht in de vereisten voor ICT-risico's van derde partijen onder DORA

Artikel-voor-artikel overzicht

DORA Hoofdstuk V, Sectie I (Artikelen 28-30) introduceert het meest uitgebreide regime voor het beheer van ICT-risico's van derde partijen in de EU-financiële regelgeving:

Article

Title

Key requirements

Key deliverables

Art 28

Algemene principes

Beleid voor ICT-risico's van derde partijen, register van alle leveranciers, precontractuele beoordeling, doorlopende monitoring, verantwoordelijkheid van het managementorgaan

Beleid voor ICT-risico's van derde partijen, leveranciersregister, beoordelingsprocedures

Art 29

Voorlopige beoordeling van ICT-concentratierisico

Beoordeling van concentratierisico voordat nieuwe regelingen worden aangegaan, overweging van vervangbaarheid, datalocatie, operationele risico's van concentratie

Beoordeling van concentratierisico, afhankelijkheidsanalyse

Art 30

Belangrijke contractuele bepalingen

Verplichte contractclausules: SLA's, auditrechten, datalocatie, incidentondersteuning, exitbepalingen, controles op onderaanneming

Contractclausulebibliotheek, checklist voor contractbeoordeling, sjablonen voor wijzigingen

De reikwijdte van ICT-risico's van derde partijen onder DORA

DORA hanteert een brede definitie van ICT-risico's van derde partijen. De vereisten zijn van toepassing op alle ICT-diensten die van derde partijen worden verkregen, niet alleen op uitbestedingsregelingen. Dit omvat:

• Clouddiensten: IaaS-, PaaS-, SaaS-providers (AWS, Azure, Google Cloud, Salesforce, enz.)
• Leveranciers van kernsysteem: Kernbankieren, betalingsverwerking, handelsplatforms
• Managed services: Beheerde beveiliging (SOC), beheerde IT-operations, beheerde netwerkdiensten
• Datadiensten: Data-analyse, marktdata-providers, kredietscoringdiensten
• Communicatiediensten: SWIFT, betalingsnetwerken, berichtenplatforms
• Softwareleveranciers: Bedrijfstoepassingen, beveiligingstools, regelgevingstechnologie
• Infrastructuurleveranciers: Datacentercollocatie, netwerkconnectiviteit, CDN-diensten

Stap 1: Bouw je register van ICT-leveranciers van derde partijen (Artikel 28)

Het register aanmaken

Artikel 28(3) vereist dat financiële entiteiten een register bijhouden en bijwerken van informatie met betrekking tot alle contractuele regelingen voor ICT-diensten. Dit register moet op verzoek beschikbaar worden gesteld aan de bevoegde autoriteit en jaarlijks worden gerapporteerd via gestandaardiseerde sjablonen.

1. Open je DORA-werkruimte in ISMS Copilot

2. Genereer het registersjabloon:

   "Maak een sjabloon voor het register van ICT-leveranciers van derde partijen dat voldoet aan DORA Artikel 28(3) en de bijbehorende Regulatory Technical Standards. Voeg velden toe voor: identificatie van de leverancier (rechtsnaam, LEI, jurisdictie, moedermaatschappij), contractidentificatie (contractreferentie, startdatum, verlengingsdatum, opzegtermijn), dienstbeschrijving (verleende ICT-diensten, dienstcategorie, leveringsmodel), ondersteunde functie (kritieke of belangrijke functie: ja/nee, naam van de bedrijfsfunctie), dataclassificatie (soorten verwerkte gegevens, datalocatie inclusief land en regio, gegevensoverdrachtsmechanismen), onderaanneming (gebruikte onderaannemers, locatie van onderaannemers, details van onderaannemingsdiensten), samenvatting van risicobeoordeling (risicobeoordeling, datum laatste beoordeling, belangrijkste bevindingen), contractcompliancestatus (DORA-verplichte clausules aanwezig: ja/deels/nee), exitstrategiestatus (exitplan ontwikkeld: ja/nee, datum laatste test), en datum laatste beoordeling. Voeg begeleidende notities toe voor elk veld en geef voorbeeldvermeldingen voor gangbare leverancierstypen (cloud, kernbankieren, beheerde beveiliging)."

3. Vul het register systematisch in:

   "Help ons alle ICT-leveranciers van derde partijen voor ons register te identificeren en te categoriseren. Wij zijn een [entiteitstype] dat de volgende ICT-diensten gebruikt: [lijst van bekende diensten en leveranciers]. Help ons voor elke leverancier te classificeren: of zij kritieke of belangrijke functies ondersteunen, de gegevens die zij verwerken en de locatie daarvan, onderaannemingsregelingen die wij moeten onderzoeken, risicobeoordeling op basis van dienstkritikaliteit en leveranciersafhankelijkheid, en prioriteit voor contractbeoordeling. Identificeer ook categorieën van leveranciers die wij mogelijk over het hoofd hebben gezien: DNS-providers, certificeringsinstanties, betalingsverwerkers, marktdatafeeds, tools voor regelgevingsrapportage, backup- en DR-providers, identiteitsproviders en telecommunicatiedragers."

Onderhoud en rapportage van het register

Het register is geen eenmalige oefening. Stel doorlopende onderhoudsprocedures in:

"Maak een procedure voor het onderhouden en bijwerken van het register van ICT-leveranciers van derde partijen onder DORA. Inclusief: triggers voor registerupdates (nieuwe contracten, contractwijzigingen, leverancierswijzigingen, wijzigingen in onderaanneming, risicobeoordeling), verantwoordelijkheden en workflow voor updates, kwaliteitsborgingscontroles, jaarlijks uitgebreid beoordelingsproces, rapportagevereisten aan de bevoegde autoriteit (jaarlijkse indiening volgens RTS-formaat), rapportage aan het managementorgaan (samenvatting van de registerstatus, risicoconcentraties, complianceknelpunten), en integratie met inkoopprocessen (registerupdate als verplichte stap bij nieuwe ICT-inkoop). Geef een jaarlijkse checklist voor registerbeoordeling."

Stap 2: Voer precontractuele beoordelingen uit (Artikel 28)

Due diligence-raamwerk

Voordat een regeling voor ICT-diensten wordt aangegaan of verlengd, vereist DORA een grondige beoordeling van de leverancier en de regeling. De diepgang van de beoordeling moet evenredig zijn aan de kritikaliteit van de ondersteunde functie.

1. Genereer het beoordelingsraamwerk:

   "Maak een raamwerk voor de precontractuele beoordeling van ICT-leveranciers van derde partijen voor DORA Artikel 28. Inclusief beoordelingsgebieden: financiële stabiliteit en levensvatbaarheid van de leverancier, ICT-beveiligingscapaciteiten en certificeringen (ISO 27001, SOC 2, CSA STAR), incidentbeheer- en meldingscapaciteiten, bedrijfscontinuïteit en disaster recovery-capaciteiten, naleving van gegevensbescherming en privacy (GDPR-alignment), onderaannemingspraktijken en transparantie, naleving van regelgeving in het verleden, geografische risicobeoordeling (datalocatie, jurisdictie, politieke stabiliteit), exit- en transitieondersteuningscapaciteiten, en reputatie en marktpositie van de leverancier. Voor elk gebied, geef: beoordelingsvragen, aan te vragen bewijsmateriaal, scoringscriteria (adequaat, verbetering nodig, onvoldoende), en rode vlaggen. Maak twee beoordelingsniveaus: standaardbeoordeling (voor niet-kritieke diensten) en uitgebreide beoordeling (voor diensten die kritieke of belangrijke functies ondersteunen). Geef een sjabloon voor een beoordelingsrapport."

2. Maak een vragenlijst voor beveiligingsbeoordeling van leveranciers:

   "Maak een gedetailleerde vragenlijst voor de beoordeling van ICT-beveiliging om derde partijen ICT-leveranciers onder DORA te evalueren. Onderwerpen: governance en organisatie (beveiligingsleiderschap, beleid, certificeringen), toegangsbeheer (authenticatie, autorisatie, bevoorrechte toegang), gegevensbescherming (versleuteling in rust en tijdens transport, sleutelbeheer, gegevensclassificatie), netwerkbeveiliging (segmentatie, monitoring, indringingsdetectie), incidentbeheer (detectiecapaciteiten, responsprocedures, meldingstermijnen), bedrijfscontinuïteit (BCP/DRP, RTO/RPO-capaciteiten, testfrequentie), kwetsbaarheidsbeheer (scannen, patchen, hersteltermijnen), wijzigingsbeheer (testen, goedkeuring, terugdraaien), personeelsbeveiliging (achtergrondcontroles, training, bewustwording), fysieke beveiliging (datacentersbeveiliging, omgevingscontroles), en onderaanneming en risico's van vierde partijen. Inclusief zowel ja/nee- als open vragen. Geef richtlijnen voor scoring."

Beoordeling van leveranciersrisico's vóór betrokkenheid

Gebruik ISMS Copilot om specifieke leveranciers of leverancierstypen te evalueren:

"We overwegen [leveranciersnaam/type] voor [dienstbeschrijving] ter ondersteuning van [kritieke/belangrijke/standaardfunctie]. Voer een precontractuele risicobeoordeling uit die is afgestemd op DORA. Overweeg: het vermogen van de leverancier om te voldoen aan de contractclausulevereisten van DORA (Artikel 30), implicaties van datalocatie en -overdracht, transparantie van onderaanneming, afstemming van incidentmeldingscapaciteit met onze 4-uurs DORA-meldingsdeadline, controleerbaarheid (recht op audit, toegang tot rapporten), exithaalbaarheid (dataportabiliteit, transitieondersteuning, lock-inrisico's), implicaties van concentratierisico (zijn we al afhankelijk van deze leverancier of zijn moedermaatschappij voor andere kritieke diensten?), en regelgevingsoverwegingen voor onze bevoegde autoriteit. Geef een risicogewogen beoordeling met een aanbeveling of we moeten doorgaan."

Stap 3: Implementeer verplichte contractclausules (Artikel 30)

Inzicht in de vereisten van Artikel 30

Artikel 30 specificeert verplichte elementen die moeten worden opgenomen in contracten voor ICT-diensten. De vereisten zijn nog gedetailleerder voor diensten die kritieke of belangrijke functies ondersteunen. Dit is vaak het meest arbeidsintensieve aspect van het beheer van DORA-risico's van derde partijen.

1. Genereer de contractclausulebibliotheek:

   "Maak een uitgebreide DORA Artikel 30 contractclausulebibliotheek voor ICT-dienstovereenkomsten. Voor elke verplichte vereiste, geef: de DORA-artikelverwijzing, een modelcontractclausule (klaar voor juridische beoordeling), toelichtende notities en onderhandelingsrichtlijnen. Dek alle Artikel 30-vereisten: duidelijke dienstbeschrijving met kwantitatieve en kwalitatieve prestatiedoelen, dataverwerkingslocaties (inclusief opslag-, verwerkings- en back-uplocaties) met voorafgaande melding van wijzigingen, gegevensbescherming en vertrouwelijkheidsverplichtingen, garanties voor gegevensbeschikbaarheid, authenticiteit, integriteit en toegankelijkheid, service level agreements (SLA's) met meetbare metrics, incidentmeldingsverplichtingen (afgestemd op DORA-meldingstermijnen, waarbij van de leverancier wordt verlangd dat hij binnen tijdsbestekken meldt die onze 4-uursdeadline ondersteunen), samenwerking van de leverancier met bevoegde autoriteiten, auditrechten (recht om audits en inspecties uit te voeren, inclusief ter plaatse, of vertrouwen op certificeringen van derden), beëindigingsbepalingen en adequate overgangsperioden, deelname aan bewustwordingstraining voor ICT-beveiliging. Voor diensten die kritieke of belangrijke functies ondersteunen, voeg verbeterde clausules toe voor: volledige dienstbeschrijving met duidelijke functies en subfuncties, prestatiedoelen met bijbehorende sancties, verplichtingen voor bedrijfscontinuïteit en disaster recovery en testen, rapportageverplichtingen (regelmatige rapportage over dienstprestaties, beveiliging en materiële wijzigingen), verplichtingen voor exitondersteuning (gegevensretour, transitieondersteuning, migratiehulp), onderaannemingsvereisten (voorafgaande goedkeuring, doorwerking van DORA-clausules, recht van bezwaar), en onbeperkt recht van de financiële entiteit om doorlopend te monitoren."

2. Maak een checklist voor contractbeoordeling:

   "Maak een compliancechecklist voor contractbeoordeling van DORA Artikel 30 voor bestaande ICT-dienstovereenkomsten. Voor elke Artikel 30-vereiste, geef: de vereiste beschrijving, compliant/deels/niet-compliant beoordeling, specifieke clausuleverwijzing in het bestaande contract (indien aanwezig), gapbeschrijving (indien deels of niet-compliant), aanbevolen wijzigingsformulering, en prioriteit (kritiek voor diensten die kritieke/belangrijke functies ondersteunen, standaard voor andere). De checklist moet bruikbaar zijn voor juridische en inkoopteams die bestaande contracten systematisch beoordelen. Inclusief een samenvattend scoringsmechanisme om te identificeren welke contracten onmiddellijke heronderhandeling vereisen."

Onderhandelingsstrategieën

Gebruik ISMS Copilot om je voor te bereiden op contractonderhandelingen:

"Maak een DORA-contractonderhandelingsstrategie voor gesprekken met onze [leverancierstype, bijv. grote cloudprovider / leverancier van kernsysteem / beheerde beveiligingsprovider]. Ga in op veelvoorkomende tegenwerpingen van leveranciers: 'We kunnen niet aan elke klant individuele auditrechten verlenen' (bespreek vertrouwen op SOC 2/ISO 27001-rapporten, gezamenlijke audits en certificering door derden volgens Artikel 30(3)), 'We kunnen geen specifieke datalocaties garanderen' (DORA-vereisten, regelgevingsverwachtingen, alternatieve benaderingen), 'Onze standaard SLA's zijn niet onderhandelbaar' (minimale DORA-vereisten, escalatiebenaderingen), 'We accepteren geen onbeperkte aansprakelijkheid' (evenredige benaderingen, onderhandelingen over limieten), 'Onze meldingstermijnen zijn 24-48 uur' (noodzaak om de 4-uurs DORA-deadline te ondersteunen, getrapte meldingsbenadering). Voor elke tegenwerping, geef: de wettelijke DORA-vereiste, alternatieve benaderingen die aan de regelgeving voldoen, compromisposities en escalatiestrategieën."

Stap 4: Beoordeel en beheer concentratierisico (Artikel 29)

Inzicht in ICT-concentratierisico

Artikel 29 vereist dat financiële entiteiten ICT-concentratierisico beoordelen voordat zij ICT-dienstregelingen aangaan en op doorlopende basis. Concentratierisico ontstaat wanneer overmatige afhankelijkheid van één enkele leverancier (of een kleine groep leveranciers) systemische kwetsbaarheid creëert.

1. Genereer het raamwerk voor concentratierisicobeoordeling:

   "Maak een raamwerk voor de beoordeling van ICT-concentratierisico voor DORA Artikel 29. Inclusief: definitie en reikwijdte van ICT-concentratierisico, beoordelingsmethodologie met betrekking tot: afhankelijkheid van één enkele leverancier (hoeveel kritieke functies zijn afhankelijk van één leverancier), afhankelijkheid van een leveranciersgroep (analyse van moedermaatschappij, dochteronderneming en gelieerde leveranciers), afhankelijkheid van een technologiestack (afhankelijkheid van één enkel technologieplatform), geografische concentratie (alle kritieke diensten in één regio of datacenter), vervangbaarheidsbeoordeling (gemak van het vervangen van elke kritieke leverancier), toeleveringsketenconcentratie (meerdere leveranciers afhankelijk van dezelfde vierde partij), marktconcentratie (beperkt aantal alternatieve leveranciers in een dienstcategorie). Voor elke dimensie, geef: beoordelingscriteria, meetmetrieken, risicobeoordelingsdrempels (laag, gemiddeld, hoog, kritiek), en mitigeringsstrategieën. Maak een concentratierisicodashboard-sjabloon voor rapportage aan het managementorgaan."

2. Voer een concentratierisicoanalyse uit:

   "Op basis van ons register van ICT-leveranciers van derde partijen, voer een concentratierisicoanalyse uit. Onze leveranciers omvatten: [lijst van belangrijke leveranciers en diensten]. Analyseer: welke leveranciers meerdere kritieke functies ondersteunen (concentratie bij één enkele leverancier), of leveranciers moedermaatschappijen of infrastructuur delen (groepsconcentratie), geografische concentratie van onze kritieke ICT-diensten, marktbeschikbaarheid van alternatieve leveranciers voor elke kritieke dienst, potentieel systemisch risico als onze meest kritieke leverancier een grote storing zou ondervinden, en afhankelijkheden van vierde partijen (bijv. meerdere leveranciers die hetzelfde cloudplatform gebruiken). Beoordeel het concentratierisico voor elke geïdentificeerde afhankelijkheid en beveel mitigerende maatregelen aan."

Mitigatie van concentratierisico

Wanneer concentratierisico's worden geïdentificeerd, ontwikkel mitigerende strategieën:

"Voor elk hoog of kritiek concentratierisico dat in onze beoordeling is geïdentificeerd, ontwikkel mitigerende strategieën. Overweeg: strategieën met meerdere leveranciers (het verdelen van kritieke diensten over meerdere leveranciers), multi-cloud of hybride benaderingen, het handhaven van interne capaciteiten als back-up, contractuele beschermingen (verbeterde SLA's, verplichtingen voor bedrijfscontinuïteit, escrowregelingen), technologische overdraagbaarheidsmaatregelen (vermijden van propriëtaire lock-in, gebruik van overdraagbare formaten en standaarden), geografische diversificatie van kritieke diensten, beheer van risico's van vierde partijen (ervoor zorgen dat leveranciers hun eigen concentratierisicomitigatie hebben), en geleidelijke diversificatieroadmaps waar directe verandering niet haalbaar is. Voor elke mitigerende strategie, geef: implementatiestappen, tijdschatting, kostenoverwegingen, restrisico na mitigatie, en beslispunten voor het managementorgaan."

Stap 5: Ontwikkel exitstrategieën (Artikel 28)

Vereisten voor exitstrategieën

DORA vereist dat financiële entiteiten exitstrategieën hebben voor ICT-diensten die kritieke of belangrijke functies ondersteunen. Exitstrategieën moeten ervoor zorgen dat het beëindigen of overstappen van een leverancier de diensten niet verstoort, gegevens niet in gevaar brengt of de naleving van regelgeving vermindert.

1. Genereer sjablonen voor exitstrategieën:

   "Maak sjablonen voor exitstrategieën voor naleving van DORA Artikel 28, voor ICT-diensten die kritieke of belangrijke functies ondersteunen. Voor elke kritieke leverancier/dienst moet de exitstrategie het volgende omvatten: triggergebeurtenissen voor exit (leveranciersfalen, contractbreuk, concentratierisico, strategische wijziging, regelgevingsvereiste), transitieplanning (doelopties: alternatieve leverancier, intern, hybride), transitiestappen en mijlpalen (realistisch voor de complexiteit van de dienst), datamigratieplan (data-extractie, formaatconversie, validatie, verwijdering bij de leverancier), kennisoverdrachtvereisten (documentatie, training, operationele overdracht), parallelle looptijd (minimale duur, acceptatiecriteria voor transitie), resourcevereisten (intern team, externe ondersteuning, budget), communicatieplan (klanten, regelgevers, andere belanghebbenden), testen en validatie van alternatieve regelingen vóór volledige transitie, contractuele bepalingen ter ondersteuning van exit (transitieondersteuningsperiode, gegevensretourverplichtingen), en risicobeoordeling van het exitproces zelf (transitierisico's, mitigerende maatregelen). Maak sjablonen voor veelvoorkomende scenario's: exit van cloudprovider, vervanging van kernsysteem en transitie van beheerde dienst."

2. Stel exitstrategietesten in:

   "Maak procedures voor het testen van exitstrategieën voor kritieke ICT-leveranciers van derde partijen. Inclusief: testfrequentie (minstens jaarlijkse beoordeling, testen van belangrijke componenten), testtypen (tabletop review van exitplan, gedeeltelijke data-extractietest, proof of concept met alternatieve leverancier, volledige transitiesimulatie), testscenario's (geplande exit met medewerking, noodexit met beperkte leveranciersmedewerking, leveranciersfaillissementsscenario), succescriteria voor elk testtype, documentatie en rapportage van testresultaten, rapportage aan het managementorgaan over exitstrategiegereedheid, en herstel van geïdentificeerde tekortkomingen. Geef een testschema dat is afgestemd op ons algehele DORA-resilientietestprogramma."

Stap 6: Stel doorlopende monitoring in (Artikel 28)

Continue leveranciersmonitoring

DORA vereist doorlopende monitoring van ICT-leveranciers van derde partijen, niet alleen beoordelingen op een bepaald moment. De intensiteit van de monitoring moet evenredig zijn aan de kritikaliteit van de dienst:

1. Genereer het monitoringsraamwerk:

   "Maak een raamwerk voor doorlopende monitoring van ICT-leveranciers van derde partijen voor DORA Artikel 28. Inclusief monitoringsactiviteiten: SLA-prestatiebewaking (beschikbaarheid, responstijden, incidentoplossing, ten opzichte van contractuele doelen), bewaking van beveiligingsstatus (onderhouden van certificeringen, kwetsbaarheidsmeldingen, openbare inbreukmeldingen), financiële stabiliteitsbewaking (kredietbeoordelingen, financiële rapporten, marktnieuws, overnameactiviteiten), incidentmeldingen van leveranciers (tijdigheid, volledigheid, afstemming met DORA-vereisten), wijzigingen in onderaanneming (nieuwe onderaannemers, wijzigingen in locatie van onderaannemers), regelgevingsontwikkelingen die de leverancier beïnvloeden (handhavingsacties, licentiewijzigingen, aanwijzing als kritieke leverancier), en materiële wijzigingen in dienstverlening (technologiewijzigingen, datacentermigraties, personeelswijzigingen). Voor elke monitoringsactiviteit, specificeer: frequentie (continu, maandelijks, driemaandelijks, jaarlijks), gegevensbronnen, verantwoordelijke rol, escalatiecriteria (wanneer monitoringsbevindingen herbeoordeling of contractbeoordeling activeren), en documentatievereisten. Maak een sjabloon voor een monitoringsdashboard."

2. Definieer procedures voor prestatiebeoordeling van leveranciers:

   "Maak een procedure voor prestatiebeoordeling van ICT-leveranciers van derde partijen voor naleving van DORA. Inclusief: beoordelingsfrequentie (kwartaal voor kritieke leveranciers, halfjaarlijks voor belangrijke, jaarlijks voor standaard), sjabloon voor beoordelingsagenda (SLA-prestaties, beveiligingsstatus, incidenten en meldingen, onderaanneming, materiële wijzigingen, nalevingsstatus), deelnemers (leveranciersrelatiemanager, beveiliging, compliance), escalatieprocedures voor onderprestatie (herstelverzoeken, verbeterde monitoring, melding aan het managementorgaan, triggers voor contractbeëindiging), documentatievereisten (notulen van beoordeling, actiepunten, toezeggingen van leveranciers), en jaarlijkse samenvattende rapportage voor het managementorgaan en de bevoegde autoriteit. Geef een sjabloon voor een rapport over prestatiebeoordeling van leveranciers."

Toezicht op onderaanneming

DORA vereist toezicht op onderaannemingsketens. Je monitoring moet verder gaan dan je directe leveranciers:

"Maak een procedure voor toezicht op onderaanneming voor naleving van DORA. Inclusief: contractuele vereisten voor transparantie van onderaanneming (voorafgaande melding of goedkeuring, recht van bezwaar), verplichtingen van de leverancier om onderaannemers en hun rollen bekend te maken, beoordelingscriteria voor materiële onderaannemers (zelfde criteria als voor de primaire leverancier), monitoring van wijzigingen in de onderaannemingsketen, procedures wanneer leveranciers nieuwe onderaannemers toevoegen (beoordeling, risico-evaluatie, goedkeuring of bezwaar), risicobeoordeling van vierde partijen (onderaannemers van onderaannemers), doorwerking van DORA-relevante contractvereisten naar onderaannemers, en escalatieprocedures wanneer onderaannemingsregelingen het concentratierisico verhogen. Geef een sjabloon voor een onderaannemingsregister en een beoordelingsworkflow."

Stap 7: Governance en rapportage aan het managementorgaan

Beleid voor ICT-risico's van derde partijen

Artikel 28(2) vereist een beleid voor het gebruik van ICT-diensten die kritieke of belangrijke functies ondersteunen. Dit beleid moet worden goedgekeurd door het managementorgaan:

"Maak een beleid voor het beheer van ICT-risico's van derde partijen voor DORA Artikel 28(2). Inclusief: doel, reikwijdte en toepasselijkheid van het beleid, verantwoordelijkheden van het managementorgaan voor toezicht op ICT-risico's van derde partijen, risicobereidheid voor ICT-diensten van derde partijen (aanvaardbare concentratieniveaus, geografische beperkingen, leveranciersnormen), vereisten voor precontractuele beoordeling (triggercriteria, beoordelingsdiepgang naar kritikaliteit), contractuele normen en verplichte clausules, verplichtingen voor doorlopende monitoring en beoordeling, vereisten voor exitstrategieën en bedrijfscontinuïteit, rollen en verantwoordelijkheden (risicomanager voor derde partijen, CISO, juridisch, inkoop, bedrijfseigenaren), escalatie- en uitzonderingsprocedures, frequentie van beleidsbeoordeling en -update (minstens jaarlijks), en integratie met het algehele ICT-risicomanagementraamwerk. Maak het geschikt voor goedkeuring door het managementorgaan."

Rapportage aan het managementorgaan

Houd het managementorgaan op de hoogte van ICT-risico's van derde partijen via gestructureerde rapportage:

"Maak een rapportagepakket voor het managementorgaan over ICT-risico's van derde partijen onder DORA. Inclusief: samenvatting van het leveranciersregister (totaal aantal leveranciers, leveranciers die kritieke functies ondersteunen, nieuwe/beëindigde regelingen), concentratierisicodashboard (belangrijke afhankelijkheidsmetrieken, wijzigingen ten opzichte van de vorige periode), nalevingsstatus van contracten (percentage contracten met volledige naleving van DORA Artikel 30, voortgang van herstel), samenvatting van leveranciersprestaties (SLA-prestatiecijfers, materiële incidenten bij leveranciers, wijzigingen in beveiligingsstatus), beoordeling van exitstrategiegereedheid, belangrijkste risico's en opkomende kwesties (financiële instabiliteit van leveranciers, regelgevingsacties, technologische wijzigingen), en aanbevolen besluiten voor het managementorgaan. Geef een sjabloon voor kwartaalrapportage en een sjabloon voor een jaarlijkse uitgebreide beoordeling."

Stap 8: Aanpak van grensoverschrijdende en groepsoverwegingen

Beheer van ICT-risico's van derde partijen op groepsniveau

Als je entiteit deel uitmaakt van een financiële dienstverleningsgroep, moet het beheer van ICT-risico's van derde partijen onder DORA op groepsniveau worden gecoördineerd:

"Behandel groepsniveau-overwegingen voor het beheer van ICT-risico's van derde partijen onder DORA. Onze entiteit maakt deel uit van [groepsstructuur]. Help ons: het leveranciersregister te consolideren over groepsentiteiten (gedeelde leveranciers identificeren, concentratierisico's op groepsniveau), contractonderhandelingen te coördineren voor leveranciers die door meerdere groepsentiteiten worden gebruikt, precontractuele beoordelingsnormen binnen de groep op elkaar af te stemmen, monitoringsactiviteiten en bevindingen te delen, exitstrategieën te coördineren wanneer meerdere entiteiten afhankelijk zijn van dezelfde leverancier, en ICT-risico's van derde partijen op groepsniveau te rapporteren aan het managementorgaan van de moederentiteit. Geef een raamwerk voor groepscoördinatie."

Grensoverschrijdende vereisten voor datalocatie

DORA Artikel 30 vereist dat contracten de locaties voor gegevensverwerking specificeren. Voor grensoverschrijdende regelingen moeten de regelgevingsimplicaties worden aangepakt:

"Analyseer datalocatie en grensoverschrijdende overwegingen voor onze regelingen met ICT-leveranciers van derde partijen onder DORA Artikel 30. Onze leveranciers verwerken gegevens in [lijst van landen/regio's]. Beoordeel: naleving van vereisten voor openbaarmaking van datalocatie, GDPR-adequaatheidsbesluiten en overdrachtsmechanismen voor gegevensverwerking buiten de EU, regelgevingsbeperkingen op locaties voor gegevensverwerking van financiële gegevens in onze jurisdictie, risico's van gegevensverwerking in rechtsgebieden met zwakkere wettelijke bescherming, verplichtingen van leveranciers om wijzigingen in datalocatie te melden, en contractuele controles om naleving van datalocatie te handhaven. Geef aanbevelingen voor elke leverancier/dienst waarbij datalocatie een risico vormt."

Volgende stappen

Je beschikt nu over een uitgebreide capaciteit voor het beheer van DORA ICT-risico's van derde partijen:

• Volledig register van ICT-leveranciers van derde partijen met gestandaardiseerde gegevens
• Raamwerk voor precontractuele beoordeling met vragenlijst voor beveiligingsbeoordeling van leveranciers
• Uitgebreide bibliotheek van contractclausules met checklist voor naleving van Artikel 30
• Raamwerk voor beoordeling van concentratierisico en mitigerende strategieën
• Sjablonen voor exitstrategieën en testprocedures
• Raamwerk voor doorlopende monitoring met procedures voor prestatiebeoordeling
• Beleid voor ICT-risico's van derde partijen en rapportage aan het managementorgaan

Dit completeert de vijfdelige implementatiegidsreeks voor DORA. Bekijk de volledige reeks:

• Hoe begin je met de implementatie van DORA met behulp van AI -- Basis: scope, governance, gap-analyse, routekaart
• Hoe bouw je een DORA ICT-risicomanagementraamwerk met behulp van AI -- Pijler 1: Artikelen 6-16 raamwerk, beleid, controles
• Hoe implementeer je DORA-incidentrapportage met behulp van AI -- Pijler 2: Artikelen 17-23 classificatie, rapportage, oorzaakanalyse
• Hoe plan je DORA-resilientietesten met behulp van AI -- Pijler 3: Artikelen 24-27 testprogramma, TLPT, herstel
• Hoe beheer je DORA ICT-risico's van derde partijen met behulp van AI (deze gids) -- Pijler 4: Artikelen 28-30 leveranciers, contracten, concentratierisico

Voor kant-en-klare prompts die elk DORA-artikel behandelen, zie de DORA Compliance Prompt Library. Voor het volledige regelgevingsoverzicht, raadpleeg de DORA Compliance Guide for Financial Entities.

Hulp krijgen

Voor extra ondersteuning bij het beheren van DORA ICT-risico's van derde partijen:

• Vraag ISMS Copilot: Gebruik je DORA-werkruimte om leveranciersspecifieke beoordelingen, contractclausuleanalyses en concentratierisicorapporten te genereren
• Upload contracten: Ontvang gerichte Artikel 30-complianceanalyse door bestaande ICT-dienstovereenkomsten te uploaden voor clausule-voor-clausulebeoordeling
• Voorbereiding op onderhandelingen: Gebruik ISMS Copilot om standpunten en alternatieve clausulevoorstellen voor te bereiden voorafgaand aan leveranciersonderhandelingen
• Valideer outputs: Laat alle contractclausules door je juridische team beoordelen en verifieer beoordelingscriteria aan de hand van DORA Artikelen 28-30 en relevante Regulatory Technical Standards