DORA ICT Third-Party Risk Management: Article 28 Implementation Guide

What DORA Article 28 Actually Asks Of Financial Entities

DORA is a regulation, not a directive. It applies directly across the European Union from 17 January 2025, without national transposition. Twenty categories of financial entity sit inside the scope: credit institutions, payment institutions, electronic money institutions, investment firms, crypto-asset service providers, central securities depositories, central counterparties, trading venues, trade repositories, managers of alternative investment funds, management companies of UCITS, data reporting service providers, insurance and reinsurance undertakings, insurance intermediaries, institutions for occupational retirement provision, credit rating agencies, administrators of critical benchmarks, crowdfunding service providers, securitisation repositories, and ICT third-party service providers themselves where the Lead Overseer regime applies.

Article 28 sets the management body of the financial entity as accountable for the ICT third-party risk management strategy. The strategy is a documented artefact, reviewed periodically, and aligned to the overall risk appetite. The strategy is not a template; it is a board-level statement of how the entity assesses, contracts with, monitors, and exits ICT third-party service providers across the function tiers it operates. Article 28 then codifies the operational obligations: the maintenance of the register of information, the pre-contractual assessment, the contractual content, the ongoing monitoring, and the exit strategies for arrangements supporting critical or important functions.

For a CISO, GRC owner, vendor risk lead, or chief operating officer at an in-scope financial entity, the practical DORA Article 28 posture is a recurring ICT TPRM record per arrangement, reconcilable to the register that goes to the competent authority, defensible against a national or European Supervisory Authority that asks to read it, and operable by an internal team that does not scale linearly with the third-party portfolio. The work is the work; what changes is the audit-readiness discipline behind it.

Article 28 In Operational Terms: The ICT TPRM Lifecycle

The cleanest way to read Article 28 is as a lifecycle that wraps each ICT third-party arrangement from intent through exit. Five phases produce the evidence stack the regulation expects, and each phase produces artefacts that land in the same engagement record so the next phase reads from the prior one rather than reconstructing it.

The Register Of Information: Article 28(3) And The RTS

The register of information is the single most visible Article 28 artefact and the one most likely to be miscast as the whole of the regulation. The register captures every ICT third-party arrangement the financial entity holds, at the individual, sub-consolidated, and consolidated levels where group reporting applies, with a structured taxonomy the European Supervisory Authorities have standardised through the regulatory technical standards. The register is submitted to the competent authority at a frequency the national authority sets and on request, and it is the data set the ESAs aggregate to identify critical ICT third-party service providers across the financial system.

The register taxonomy is a regulatory artefact, not a CRM field set. The data model needs to live in the operational record the ICT TPRM team works in every week, not in a separate spreadsheet that gets rebuilt the week before the competent authority asks for it. Financial entities that hold the register apart from the operational record produce a register that is always slightly stale at submission time and a regulator that reads the staleness as a control weakness.

The Article 30 Contract: What Every Arrangement Must Contain

Article 30 is the contractual provisions article and the one that drives the most legal redrafting work in scope. Article 30(2) lists the provisions that every ICT third-party arrangement must contain. Article 30(3) lists the additional provisions arrangements supporting critical or important functions must contain. The two layers are cumulative; the CIF list extends the base list rather than replacing it.

• All arrangements (Article 30(2)).Description of service, locations of service provision and data processing, data protection terms (linked to GDPR and any sector-specific data regulations), service-level commitments and the consequences for breach, cooperation with incident response, assistance with incident reporting, security requirements proportional to the function, termination rights, participation in the financial entity is awareness and training programmes, and the rules on sub-outsourcing where it applies.
• Critical or important functions only (Article 30(3)).Full description of the function and any sub-outsourced parts, locations of data processing and storage including the third country flag and data transfer mechanism, the obligation to notify material developments, the exit strategy and transition assistance, the contingency plan and continuity requirements, the security testing participation, the access, inspection, and audit rights for the financial entity and the competent authorities, the unrestricted right to audit, and the right to terminate on material breach or supervisory request.
• Subcontracting controls (RTS on subcontracting).For arrangements supporting critical or important functions, the contract sets the conditions under which the third party may subcontract any part of the CIF, the scope of subcontracted activity allowed, the geographic constraints, the notification obligation to the financial entity before any material change in the subcontracting chain, and the financial entity is right to object. The regulatory technical standards on subcontracting refine the conditions and the evidence the financial entity keeps on file.
• Termination rights as operating leverage.Termination rights are not boilerplate. They are the operating leverage that makes the exit strategy executable. The contract enumerates the conditions (material breach, repeated SLA failure, regulatory non-compliance, material risk change, sanctions or supervisory intervention) and the notice periods that allow the financial entity to execute the exit without the third party withholding services or data during the transition.
• Audit and access rights as recurring evidence.The access and audit rights enable the financial entity to read the third party is delivery, security posture, and incident handling at a cadence proportionate to the function. The contract names the access path, the audit cadence, the third-party right to use pooled audits, and the obligation to provide evidence on supervisory request without unreasonable delay.

Article 30 is the article most likely to require a contract repapering programme on existing arrangements that were signed before DORA was in force. The repapering work is the work; the register read of repapering status is the evidence the supervisory authority looks for at programme review.

Critical Or Important Functions: The Classification That Drives Everything

The Article 28 obligations stack heaviest on arrangements that support critical or important functions (CIFs). The CIF classification is a financial-entity decision driven by the function the third party performs rather than a property of the third party itself. The same third-party service might support a CIF in one financial entity and not support a CIF in another, depending on how the financial entity uses it.

• Critical functions. Functions whose disruption would materially impair the financial soundness or continuity of the entity is services and activities, or whose discontinuation, defective performance, or failure of execution would result in material harm to the entity is clients or counterparties.
• Important functions. Functions whose disruption would have an impact on the entity is regulatory obligations, its ability to meet supervisory expectations, or its ability to continue its core operations within acceptable performance bounds. The line between critical and important is set by the financial entity is operating risk appetite and recovery objectives.
• Other functions. Functions that do not meet the critical or important thresholds still belong on the register with the same identifiers and metadata, but they do not attract the Article 30(3) extended contract provisions or the Article 28(8) exit-strategy obligation.
• Reclassification triggers. The CIF classification is reassessed when the function changes (new use cases added, data class change, volume change), when the third-party operating posture changes, when the regulatory environment changes (new supervisory expectation, new sectoral regulation), and on a documented periodic cadence. The reclassification event lands in the register and triggers a review of the contractual provisions to confirm they still meet the new classification.

CIF classification is the gate that determines how heavy the Article 28 evidence pack runs per arrangement. Programmes that classify too liberally create unsustainable evidence overhead across the portfolio; programmes that classify too conservatively miss the obligations that supervisory authorities read most closely. The defensible posture is a documented classification methodology with named decision authority, applied consistently, reviewed at the cadence the management body sets.

Article 29 Concentration Risk And Substitutability

Article 29 sits next to Article 28 and asks the financial entity to assess concentration risk before entering or extending an arrangement. The concentration view operates at four levels: arrangement, function, third party, and (where the financial entity is in scope) sub-outsourcing chain. The substitutability analysis backs the concentration view with evidence about how quickly the entity could replace the third party if needed, what intra-group or external alternatives exist, and whether the alternative is genuinely executable in the time the function continuity requires.

• Single-provider concentration.Multiple critical functions concentrated on one third party (a cloud provider hosting compute, identity, and storage for separately criticised functions) is the single most common concentration pattern, and the one the management body has to read explicitly even when the provider passes every operational test individually.
• Sub-outsourcing concentration. Two ostensibly different providers sub-outsourcing the same downstream component is a hidden concentration the register reveals through the sub-outsourcing chain. The substitutability view depends on the downstream layer, not the top-layer provider.
• Geographic concentration. Multiple critical providers running data processing or recovery sites in the same region creates a regional concentration that geographic event scenarios (data centre power events, telecommunications outage, sanctions action) read against.
• Intra-group concentration. Group entities sharing a single internal provider for a critical function (a group IT entity hosting a function across multiple in-scope legal entities) is an intra-group concentration the management body reads at the group level even when the legal entity views are individually defensible.

The concentration analysis lands in the register through dedicated fields (substitutability classification, alternative providers identified, last concentration-risk review) and it lands in the management body papers as a recurring discussion item rather than a one-time analysis. The supervisory expectation is that concentration is a continuous control rather than a point-in-time observation.

Articles 31 And 32: Critical ICT Third-Party Service Providers

Articles 31 and 32 introduce a regulatory novelty: a category of third-party providers (critical ICT third-party service providers, CTPPs) that the European Supervisory Authorities designate based on aggregated register data, and that a Lead Overseer can supervise directly. The designation criteria include systemic importance, the number of in-scope financial entities relying on the provider, the substitutability, the providers reliance on a parent relationship, and the operating footprint. The designation is not a property of the contract; it is a regulatory determination that affects how the financial entity reads the third-party relationship for as long as the designation lasts.

• CTPP designation and consequences.When a third party is designated a CTPP, the financial entity continues to hold the primary contractual relationship and the Article 28 obligations continue to apply. The Lead Overseer regime adds a direct supervisory channel to the third party, not a substitute for the financial entity is own oversight.
• Lead Overseer recommendations. The Lead Overseer may issue recommendations the third party is expected to address and the financial entity is expected to read against its own arrangement. A Lead Overseer recommendation is operating evidence the financial entity factors into the arrangement is contractual review and into the management body reads.
• Information sharing through ICT TPRM forums.The regulatory environment supports information sharing between financial entities about CTPPs and their wider risk posture. The financial entity is ICT TPRM programme reads that information into its own risk assessment and monitoring cadence; the management body reads the aggregated picture.
• Third-country CTPPs. CTPPs established in third countries operate within a specific designation framework that the Commission and ESAs maintain. The financial entity reads this dimension through its register geographic fields and through the contractual access and audit rights that have to operate across the jurisdictional boundary.

The CTPP regime does not change the Article 28 obligations on the financial entity. It adds a regulatory layer that reads the same third-party provider from a system-wide perspective and gives the supervisory community a tool the individual financial entity could not exercise alone.

Proportionality: Small And Non-Interconnected Entities

DORA applies proportionately. The regulation, the regulatory technical standards, and the implementing technical standards each consider the size, nature, scale, and complexity of the financial entity and the criticality of the functions supported. Small and non-interconnected entities operate a lighter posture across many of the obligations, though Article 28 does not disappear for them. The proportionality posture is a documented decision the management body takes rather than a default; auditors and supervisors expect to read why the entity sized its programme the way it did.

• Register scope. Small entities still maintain a register; the depth of the structured taxonomy and the submission cadence reflect the smaller portfolio and the lower aggregate risk.
• Contractual provisions. The Article 30 baseline applies to all arrangements; the Article 30(3) extended provisions still apply where a function supports a CIF, regardless of entity size. The proportionality is in the operating overhead, not in the regulatory substance.
• Monitoring cadence. The continuous monitoring obligation under Article 28(8) reads proportionate to the function criticality. Small entities operate a tighter cadence on the CIF portfolio than on the wider portfolio.
• Exit rehearsals. Arrangements supporting critical or important functions still carry an exit strategy. Small entities may rehearse exits less often than large entities, with the rehearsal cadence documented and proportionate.

Proportionality is not a bypass. It is a documented sizing decision the entity takes, supported by evidence, and read by the supervisory authority as a governance position the management body has owned.

DORA, NIS2, And The Same Vendor Read Two Ways

Financial entities in scope of DORA frequently sit alongside NIS2 essential or important entities in the same group, share third-party vendors, and read similar control expectations through two separate regulatory lenses. DORA applies lex specialis to financial entities for ICT-risk matters, so where DORA sets a more specific rule it prevails over NIS2 on the same point. The practical implication is that the ICT TPRM programme reads against DORA for the in-scope financial entities and against NIS2 for non-financial group entities, on the same underlying register where the group operates the third-party inventory centrally.

• Same vendor, two readings. A cloud provider that serves a credit institution (DORA) and a healthcare subsidiary (NIS2) is read against DORA Article 28 for the credit institution arrangement and against NIS2 Article 21 for the healthcare arrangement. The contract terms, the incident cooperation cadence, and the audit rights need to satisfy the strictest of the regimes that apply, rather than the average.
• Incident reporting clocks. DORA incident reporting and NIS2 incident reporting operate against different authorities and different timelines. The third-party arrangement contract clauses on incident notification need to support both reads on the same underlying incident, with the financial entity timing the DORA channel and the non-financial entity timing the NIS2 channel.
• Sub-outsourcing chain. DORA RTS on subcontracting and NIS2 supply-chain expectations both read the sub-outsourcing chain. A group-level ICT TPRM programme maintains one chain view that both regulations read against rather than two parallel views that drift apart.
• Operational testing. DORA Article 26 threat-led penetration testing for significant financial entities reads against the same in-scope ICT systems that NIS2 testing expectations may cover at the non-financial group entities. The TLPT programme is run by the in-scope financial entity, but the third-party arrangements that share technology stacks across the group benefit from one coherent testing posture.

Groups that operate a single ICT TPRM record across both regulatory lenses produce a defensible read for both authorities and avoid the failure mode of two parallel programmes that say slightly different things about the same vendor.

The Evidence Pack Per Arrangement

The Article 28 evidence pack is the set of artefacts a financial entity holds against each ICT third-party arrangement. The supervisory authority reads the pack as the operating evidence behind the register entry. A defensible pack is structured, dated, signed, and held in a retrievable record rather than scattered across email threads and shared drives.

• Pre-contractual assessment record.The structured assessment, the management body decision to enter the arrangement, the alternatives considered, the substitutability analysis, the concentration risk view at signing.
• Signed contract and amendments. The executed agreement, every executed amendment, the Article 30 provisions mapping (which clauses meet which Article 30 paragraphs), the governing law and dispute resolution choice.
• Onboarding artefacts. The communication of contractual terms to the operational owners, the access path setup evidence, the data-flow mapping, the security configuration baseline, the data protection terms confirmation.
• Operational monitoring outputs. The SLA performance reports, the incident records, the security assessment evidence (third-party reports, penetration test attestations, vulnerability scan summaries), the contractual compliance reviews, the cooperation evidence during incidents.
• Periodic assessment outputs. The annual or other periodic reassessment, the CIF classification confirmation or reclassification record, the contract review summary, the renewal decision evidence, the substitutability update.
• Exit strategy and rehearsal. The documented exit strategy for CIF arrangements, the rehearsal records where applicable, the alternative provider feasibility evidence, the data return and deletion plan, the transition timeline.
• Register submission evidence. The register snapshots at each submission date, the submission acknowledgements from the competent authority, the data quality review findings, the reconciliation between the operational record and the register submission.

Programmes that hold the pack as one structured record per arrangement read cleanly at supervisory review and at internal audit. Programmes that reconstruct the pack from email threads and shared drives every six months pay for the reconstruction in operating overhead and lose the evidence chain that makes the register submission defensible.

DORA, NIST SP 800-161, ISO 27036, And ISO 27001 In Practice

DORA Article 28 is not in isolation. Most in-scope financial entities already operate a vendor risk programme that reads against ISO 27001 Annex A 5.19 to 5.23 (supplier relationships), ISO 27036 (information security for supplier relationships), and (for US-anchored groups) NIST SP 800-161 (cybersecurity supply chain risk management). The defensible posture is one ICT TPRM programme that produces evidence each regulation reads, rather than three parallel programmes.

• ISO 27001 Annex A 5.19 to 5.23.The supplier relationship controls (5.19 Information security in supplier relationships, 5.20 Addressing information security within supplier agreements, 5.21 Managing information security in the ICT supply chain, 5.22 Monitoring, review and change management of supplier services, 5.23 Information security for use of cloud services) provide the control language the ISMS reads. The DORA register and contracts produce the evidence the ISO controls read against.
• ISO 27036. The information security for supplier relationships standard (parts 1 to 4) sets the operational practice for supplier security across the lifecycle. ISO 27036 reads naturally against the Article 28 lifecycle described earlier; the artefacts the standard expects sit in the same evidence pack.
• NIST SP 800-161. The cybersecurity supply chain risk management practices (Tier 1 enterprise C-SCRM strategy, Tier 2 mission and business plan, Tier 3 system level) provide a strategic spine that wraps the operational ICT TPRM record. Groups with operations in both the EU and the US frequently operate the C-SCRM strategy as the top-of-house frame and read DORA Article 28 as the operating execution at the EU financial-entity level.
• SOC 2 and SSAE 18 third-party reports.SOC 2 Type 2 reports from third-party providers, ISAE 3402 reports, and equivalent jurisdictional reports continue to play their role as evidence the financial entity reads into its monitoring cadence. The supervisory authority reads SOC 2 reports as one input alongside the financial entity is direct monitoring; SOC 2 alone does not satisfy Article 28.
• EBA, EIOPA, and ESMA guidelines.The pre-DORA sectoral outsourcing guidelines (EBA Outsourcing Guidelines, EIOPA Outsourcing to Cloud Service Providers, ESMA Outsourcing to Cloud Service Providers) remain relevant where they go beyond DORA on the same point. DORA largely supersedes the sectoral guidelines on ICT-risk matters but does not erase the institutional memory those guidelines built.

One ICT TPRM programme, multiple regulatory and standard reads, one evidence record per arrangement. That posture is operationally efficient and supervisory defensible.

Failure Modes Financial Entities Run Into

Across financial entities first establishing DORA-aligned ICT TPRM programmes in 2025 and 2026, a handful of failure modes appear repeatedly. The patterns below are the ones supervisory authorities and internal audit pick up most often.

• DORA as a register-submission exercise.Entities that treat the regulation as the data set the register submission consumes, rather than the operating discipline the register reads, produce a register that is always reconstructed and a programme that has no operating record behind the register. The fix is to operate the ICT TPRM record day to day and produce the register submission as a query against that record.
• Contract repapering without function mapping.Entities that update contract terms to Article 30 wording without mapping each clause to the function and the data class the third party supports produce a contract that says the right words and an operating record that does not read the clauses correctly when the supervisory authority asks.
• Exit strategy as a document, not a rehearsal.Entities that file an exit strategy at signing and do not revisit it across the contract life inherit the failure mode the strategy is supposed to prevent. The defensible posture rehearses exit feasibility for arrangements supporting critical functions at a cadence the management body sets.
• CIF classification by intuition.Entities that classify functions as critical or important based on operator feel rather than a documented methodology produce inconsistent classifications across the portfolio. The fix is a methodology with named decision authority and a periodic review cadence.
• Concentration view as one-time analysis.Entities that produce a concentration assessment at programme inception and do not revisit it produce a programme that misses the concentration drift the register is supposed to surface. The fix is concentration as a recurring management body agenda item with the register as the data source.
• Sub-outsourcing chain ignored.Entities that capture the top-layer provider and treat sub-outsourcing as the top-layer provider is problem inherit a sub-outsourcing chain they cannot read. The RTS on subcontracting expects the financial entity to maintain visibility deeper than the contractual counterparty.
• Two parallel records (DORA and NIS2).Groups that maintain a DORA record for the financial entities and a separate NIS2 record for the non-financial entities, with the same vendors in both, produce drift between the two records that supervisory authorities read as a programme weakness. The fix is one record with two regulatory reads on top.
• Monitoring as scheduled questionnaires only.Entities that operate monitoring as a once-a-year vendor questionnaire and treat the questionnaire response as the monitoring evidence miss the continuous part of Article 28(8). The fix is monitoring as an event-driven and cadence-driven discipline, with the questionnaire as one input rather than the whole.

The shared pattern across failure modes is that DORA Article 28 punishes programmes that operate compliance as an artefact production exercise and rewards programmes that operate compliance as a consequence of how the ICT TPRM team works every week.

A 90-Day Programme Stand-Up Sequence

For financial entities establishing or significantly upgrading the ICT TPRM programme, the 90-day sequence below produces a defensible base that an internal audit or supervisory authority can read against by the end of the window. The sequence assumes the strategy and the governance posture are already in place at programme inception.

• Days 1 to 15: Inventory and CIF classification.Build the comprehensive inventory of ICT third-party arrangements across the legal entities in scope. Apply the CIF classification methodology to each arrangement and confirm the classification with the named decision authority. Document the methodology and the classification rationale per arrangement.
• Days 16 to 30: Register gap analysis.Map the inventory to the register taxonomy. Identify which fields are populated, which are partially populated, and which are missing. Build the data quality remediation plan. Identify the source-of-truth system for each field (contract management, ITSM, asset inventory, vendor risk platform).
• Days 31 to 45: Contract repapering prioritisation.Read each contract against the Article 30 provisions checklist. Identify the clauses that need adding or strengthening, prioritised by function criticality. Build the repapering plan with the legal owners. Communicate the plan to the third parties whose contracts need updating.
• Days 46 to 60: Operational monitoring cadence.Set the monitoring cadence per arrangement, proportionate to the CIF classification. Stand up the SLA review, the incident cooperation handshake, the security evidence cadence (SOC 2 refresh, pentest attestation refresh, vulnerability scan summary). Wire the outputs into the operating record so the next phase can read them.
• Days 61 to 75: Exit strategy for CIF arrangements.Document an exit strategy for every arrangement supporting a critical or important function. Confirm the alternative providers, the in-house bridge capacity, the data return and deletion plan, the transition timeline. Plan the first rehearsal for the highest-criticality arrangement.
• Days 76 to 90: Register submission readiness.Generate the register from the operating record and reconcile the data quality against the RTS taxonomy. Run an internal pre-submission review with the named accountability owner. Resolve outstanding data gaps. Submit the register on the cadence the competent authority sets. Capture the submission acknowledgement.

The 90-day sequence produces the operating base. The recurring discipline that keeps the base alive is the work behind the work; the programme that does the work every quarter does not need a 90-day reset every two years.

For CISOs, GRC, And Vendor Risk Teams

DORA Article 28 reads slightly differently from the seat of each team that operates it. The shared programme produces one record; the team-level lenses anchor on different parts of that record.

• CISO and security leadership. Read the register as the third-party portfolio risk view that feeds the management body. Read concentration risk as a recurring agenda item. Read the CIF classification methodology as a governance artefact rather than an operating detail. Read the relationship between Article 28, Article 26 TLPT, and Articles 17 to 23 incident reporting as one coherent operational resilience programme rather than three parallel programmes.
• GRC and compliance. Operate the policy stack (the ICT TPRM policy, the CIF classification methodology, the substitutability methodology, the exit strategy template) and the periodic attestation cadence. Reconcile the operating record to the supervisory register submission. Run the internal audit interface that reads the Article 28 obligations against the operating evidence.
• Vendor risk and procurement.Operate the pre-contractual assessment, the contract repapering, the access and audit rights exercise, the SLA reviews, the security evidence cadence, and the onboarding and offboarding mechanics. Read the substitutability evidence into the procurement decision rather than treating procurement as a pure commercial decision.
• Operational technology and ICT operations.Operate the day-to-day relationship with the third party. Surface the operating-quality signal that feeds the monitoring cadence. Hold the data flow map, the access path, the security configuration baseline, and the continuity plan that the contractual provisions require to be executable rather than aspirational.
• Legal and the contract owners.Operate the contractual side: the Article 30 mapping, the access and audit rights, the termination rights, the governing law and dispute resolution, the sub-outsourcing controls. Read the management body decision into the contractual record so the legal artefacts and the operational artefacts read as one programme.

The teams operate slightly different lenses on the same Article 28 record. The programme stands on the shared record rather than on parallel team-level records that drift apart.

How SecPortal Supports A DORA Article 28 ICT TPRM Record

SecPortal is not a regulator-submission interface, a contract management platform, or a vendor risk questionnaire engine. It is the operating record where the third-party security work happens, the evidence lands, and the audit chain stays intact. Financial entities running Article 28 programmes use it for the parts of the lifecycle that produce structured findings and recurring evidence; legal contract management and competent-authority submission interfaces sit alongside it rather than inside it.

Related Reading And Adjacent Topics

DORA Article 28 reads against a wider operational resilience programme and against a wider supplier-security stack. The pages below cover the connected decisions.

• DORA framework reference covers the regulation as a whole, including the four other pillars (ICT risk management, incident reporting, operational resilience testing, information sharing) that Article 28 reads alongside.
• NIST SP 800-161 framework reference covers the C-SCRM strategy spine that wraps the ICT TPRM record for groups with US-anchored operations.
• Third-party vendor risk assessment guide covers the general TPRM programme structure that DORA Article 28 sits inside for financial entities and runs in parallel for non-financial peers.
• Cyber insurance readiness guide covers the insurance-policy lifecycle that reads against the same ICT TPRM evidence pack at underwriting and renewal.
• M&A cybersecurity due diligence guide covers the transactional discipline that inherits a target is third-party portfolio and reads the DORA register at closing where the target is in scope.
• Vendor security questionnaire response workflow covers the customer-facing read where the financial entity itself is read as a third party by its institutional clients.
• Customer security evidence room use case covers the proactive evidence packaging that supports the customer-facing read alongside the supervisory-facing read.
• Breach notification and regulator readiness use case covers the parallel notification queue that reads against DORA Articles 17 to 23 alongside Article 28 cooperation obligations.
• Control mapping cross-framework crosswalks covers the canonical control library that lets the DORA record read against ISO 27001, SOC 2, NIST, and NIS2 without parallel evidence chains.
• Audit evidence retention and disposal covers the lifecycle policy that governs how long each Article 28 artefact stays in the record across the arrangement life and beyond.
• NIS2 covers the parallel cybersecurity regime for non-financial entities that shares vendors with DORA-scoped financial entities at the group level.
• ISO 27001 covers the ISMS frame that holds the supplier relationship controls (Annex A 5.19 to 5.23) the DORA programme produces evidence for.
• SecPortal for CISOs and SecPortal for GRC and compliance teams cover the persona-side reading paths into the ICT TPRM record.

Scope And Limitations

This guide describes the structure and operational shape of the DORA ICT third-party risk management regime as Regulation (EU) 2022/2554 and the associated regulatory technical standards and implementing technical standards read at the time of writing. Specific implementation details, the harmonised templates, the in-force RTS and ITS texts, the register submission interfaces, and the Lead Overseer operating mechanics evolve over time. The authoritative reference for the in-force obligations and implementation guidance remains the published text of the regulation, the supporting Commission acts, and the guidance the European Supervisory Authorities and national competent authorities publish.

Nothing in this guide constitutes legal advice; DORA programme decisions should be reconciled with qualified legal counsel and, where applicable, with the national competent authority and the Lead Overseer. The references to ISO standards, NIST publications, NIS2, and other frameworks describe relationships rather than authoritative implementations of those standards. The references to SecPortal product capabilities describe verified features at the time of writing; the platform continues to develop and the current product surface should be confirmed in the product documentation.