ICT Third-Party Risk Management
A DORA guide to ICT third-party risk as one chain from selection to exit, showing why a supplier dependency stays with the financial entity throughout the contract.
Home / Guides / Page 3
All guides A-Z
258 guides across 20 lines. Each one opens with a service check: the regime reference, the obligation, the start date and who has to act. Page 3 of 7, guides 83 to 123.
Identifying ICT Risk
Identifying ICT risk under DORA means mapping the systems, data and suppliers behind a service and naming the threats that could interrupt it, before protection or recovery is designed.
Identifying Important Business Services
How firms identify important business services by the harm a disruption would cause to customers, markets and the wider system, service by service, before tolerances are set.
Important Services and Outsourced Services
Why outsourcing does not transfer an important service, and how to identify services whose delivery depends on suppliers, processors and platforms, and what stays with the firm.
Important Services in Insurance
Which insurance services count as important: reporting and handling claims, maintaining cover, and the servicing customers rely on after a loss occurs.
Important Services in Payments
Which payment services count as important, from everyday transfers and card payments to settlement, and how timing and irrevocability shape the harm they cause.
Important Services in Retail Banking
Which retail banking services count as important: access to deposits, cash, payments from accounts, and the support customers need when access fails suddenly.
Important Services Shared Across the Firm
When a shared function such as authentication, customer data or a contact centre counts as important in its own right, and how its failure spreads across services.
Incident Communication to Customers
How to tell customers about an ICT incident in plain language: what to say early, how to update as facts change, and what to avoid saying before it is known.
Incident Communication to the Board
What the board needs to hear during and after a major ICT incident, how that differs from the technical account, and how board reporting supports oversight without slowing the response.
Incident Logs and Evidence
What an incident log should capture, how evidence is preserved during a live incident, and why a log written at the time is worth more than a reconstruction afterwards.
Incident Reporting Phases Under DORA
The phases of DORA incident reporting explained in order: what each phase is for, what it should contain, and how later phases correct or complete earlier ones.
Incident Reporting Timelines Explained
How DORA reporting timelines work in practice: why phases have their own timing, what to do when facts are still emerging, and how to avoid delaying an early report until it is perfect.
Incident Reporting to Multiple Authorities
When a major ICT incident must be reported to more than one authority, how to keep those reports consistent, and how to coordinate when different authorities ask different questions.
Incident Response Teams and Roles
The roles that make up an incident response under DORA: who leads, who owns the service, who keeps the log, and how those roles work together during a live incident.
Incident Severity and Escalation
How severity levels and escalation routes work together during an ICT incident, when an incident should move up a level, and who decides that it moves.
Incidents Caused by Third Parties
When an ICT incident starts with a provider, what stays the firm's responsibility, how to get information from the provider during the incident, and how to report an incident you did not cause.
Internal Audit of Resilience
What internal audit adds when it tests resilience from inside the firm: independence from the teams it reviews, a service-by-service scope, and findings that lead to owned change.
Intolerable Harm Explained
What intolerable harm means in operational resilience: the point at which a service disruption causes harm that a firm should not accept, judged before an incident happens.
Joint Examination Teams Explained
How joint examination teams carry out oversight work on critical ICT providers, and what their findings mean for financial entities using those providers.
Keeping a Service Map Current
Keeping a service map current ties every service change to a map update, with an owner and a check, so the next incident follows a route that still exists.
Keeping Continuity Plans Usable
Keeping continuity plans usable: short action sequences, current contacts, plain language, version discipline and feedback from every test and incident.
Keeping the Register Current
Keeping the DORA register current is the habit that prevents drift: naming an owner, capturing changes as they happen, and reconciling the record against contracts and live services.
Lead Overseer Role Explained
What the Lead Overseer does within DORA oversight of critical ICT providers, and how that role differs from supervising a financial entity for a designated provider.
Learning from Exercises
How learning from exercises becomes real change, through honest debriefs, owned actions, retesting and sharing lessons without blame or softening findings.
Learning from Incidents Without Blame
How to run an incident review that finds real causes and real fixes, without turning the review into a search for someone to blame, and why blame free review finds more.
Legacy ICT Systems and Risk
Legacy ICT systems under DORA carry risk from age, weak support and poor documentation, and need a service-based plan for protection, recovery and eventual replacement.
Live Exercises Without Harming Customers
How live exercises test real systems and people safely, using ring fencing, stop criteria, rollback plans and customer impact checks before and during the test.
Management Body Strategy and Oversight
Strategy and oversight under DORA link board direction to everyday ICT risk work. This guide explains how a management body sets direction, monitors it, and revises it when evidence changes.
Mapping Across a Group
Mapping across a group traces a service that spans entities, shared platforms and central teams, so a failure in one part is not mistaken for a local problem.
Mapping Backup and Recovery Dependencies
Mapping backup and recovery dependencies shows what recovery itself needs: copies, tools, people and suppliers, so restoration does not fail for want of its own support.
Mapping Data Centres and Networks
Mapping data centres and networks records where a service physically runs and how it connects, so a site or network failure has a known alternative route.
Mapping Data Flows and Data Stores
Mapping data flows and data stores follows the information a service reads, transforms and writes, including copies, so recovery knows which data is authoritative.
Mapping Dependencies After a Merger
Mapping dependencies after a merger reconciles two service maps into one, resolving duplicate systems, suppliers and owners before an incident exposes the overlap.
Mapping External Dependencies and APIs
Mapping external dependencies and APIs traces every outside interface a service calls, what it expects in return, and what it does when that interface fails.
Mapping for a Single Service First
Mapping for a single service first starts narrow, proves the method on one service, and only then extends it, instead of mapping everything all at once.
Mapping Fourth-Party Dependencies
Mapping fourth-party dependencies looks one layer beneath a direct supplier, where a hidden provider can halt a service the firm never contracted with directly.
Mapping ICT Systems and Integrations
Mapping ICT systems and integrations traces the applications, platforms and links a service runs on, so a fault in one component can be followed to its impact.
Mapping People and Teams
Mapping people and teams names who operates, supports and decides for a service, including cover, so an incident never waits for one unavailable person.
Mapping Processes and Manual Workarounds
Mapping processes and manual workarounds records how a service normally runs and what people do by hand when a system fails, including its limits and reconciliation afterwards.
Mapping Service Users and Harm
How to map who uses a service and what harm a disruption would cause each group, starting from the user journey rather than from internal systems and structures.