DORA — EU Regulation 2022/2554 — became applicable on 17 January 2025 and moved from a transition year into active enforcement in 2026. It creates a new set of audit-adjacent revenue lines for cyber-attest practices willing to build the specific capability the regulation requires, and a new set of independence considerations for practices that already run SOC 2 examinations for financial-entity clients. It also creates a new competency accreditation regime (TLPT, threat-led penetration testing) that is genuinely different from the audit-firm skill set most CPAs, QSAs, and ISO 27001 lead auditors carry today. This is what the DORA-shaped opportunity actually looks like from the cyber-attest practice seat, the specific competencies required to bid on the work, and the independence questions that decide which pieces of DORA a firm can serve on which clients.
What DORA-adjacent work actually looks like for a cyber-attest firm
DORA is not itself an audit regime the way SOC 2 or ISO 27001 is. It is an operational-resilience regulation that generates audit-adjacent workload in five specific places for the financial-entity customers who are directly subject to it. Understanding which of those workloads a cyber-attest firm can serve — and under what independence posture — is where the practice-planning decision lives.
- TLPT (Threat-Led Penetration Testing) — Articles 26-27 + RTS 2025/1190.: The largest audit-adjacent revenue line. TLPT is mandatory every three years for entities the NCA designates against sector-specific thresholds (G-SIIs and O-SIIs automatically; credit institutions above ~€30bn total assets; payment institutions above ~€120bn annual transaction volume; larger insurers; dominant trading venues; CCPs and CSDs). Engagement cycle 9-14 months. Delivered by external testers who meet Article 7 RTS 2025/1190 criteria: red-team manager with ≥5 years experience, additional testers with ≥2 years each, structural separation from the threat-intelligence provider, cannot be the tested entity's current blue team. In practice this means TIBER-EU accreditation via a national TIBER cell (TIBER-DE, TIBER-NL, TIBER-FR, TIBER-LU, TIBER-BE, TIBER-IE, TIBER-IT are the active ones).
- ICT third-party register audit — Article 28(3) + ITS 2024/2956.: Every financial entity submits a machine-readable Register of Information to the NCA annually in xBRL-CSV format (first cycle April 2025, second cycle March 2026, every 30 April thereafter). Data quality was the dominant supervisory finding from the first cycle. The audit-adjacent workload: pre-submission review of register completeness and accuracy, testing against contract inventory, subcontractor-chain verification, LEI reconciliation. Sits inside the cyber-attest firm's traditional third-party-risk practice; requires no new accreditation.
- Incident classification + reporting audit — Articles 17-23 + supporting RTS.: Retrospective testing of the financial entity's incident classification methodology against the RTS seven criteria (clients/counterparties affected, geographic spread, data losses, criticality of services, duration/downtime, economic impact, reputational impact). Sample incidents; test that 'major' classifications match the RTS thresholds; test submission timeliness against the 4-hour / 24-hour / 72-hour / 1-month cascade. New audit territory — no established SSAE-18/ISAE-3402 procedure yet published by IAASB or AICPA specific to DORA incident reporting — but the methodology maps cleanly onto existing internal-audit-style testing.
- Article 30 contract review.: Financial entities have been renegotiating ICT third-party contracts since 2024 against the Article 30 mandatory clause set (baseline + enhanced for critical/important functions). The audit-adjacent workload: sample contract review to test whether the FE's ICT third-party arrangements actually contain the required clauses; whether the classification of 'critical or important function' is defensibly documented; whether subcontractor notification workflows are operating. Legal-adjacent work; some cyber-attest firms partner with the FE's outside counsel, others build the capability in-house.
- Digital operational resilience testing programme audit — Articles 24-25.: The broader annual testing programme that sits below TLPT (vulnerability assessments, OSINT, network security assessments, gap analyses, scenario-based testing, source-code reviews where feasible). Testing must be signed off by an independent party; internal test teams must be organizationally separated from the tested function. Audit-adjacent workload: verify the FE has an annual testing programme, sampled evidence of independence, sampled evidence of remediation. Traditional cyber-attest scope with a DORA-specific evidence taxonomy on top.
Of the five workload areas above, TLPT is the highest revenue per engagement (£150-300K per test, every three years for designated entities) but requires an offensive-security capability most cyber-attest firms do not have in-house. The Register-of-Information audit, incident-classification testing, Article 30 contract review, and resilience-testing-programme audit are lower revenue per engagement but map onto existing cyber-attest firm competencies with no new accreditation required. A traditional CPA-firm cyber-attest practice can enter DORA work in weeks by adding the register-and-contract-review capability; TLPT is a 12-24 month capability build (or a partnership with a TIBER-EU-accredited red team).
TLPT — the accreditation, the market, the fit
TLPT is where the audit-firm market meets the offensive-security market. The RTS on TLPT (Delegated Regulation (EU) 2025/1190, adopted 13 February 2025, applicable 8 July 2025) sets specific team-composition criteria that a cyber-attest firm without in-house red-team capability cannot meet without either building or partnering.
The practical market shape: TLPT execution in 2026 is dominated by TIBER-EU-accredited specialist boutiques (NCC Group, WithSecure, Orange Cyberdefense, Mandiant, Fox-IT, Nettitude) and the Big 4's offensive-security units (PwC, Deloitte, KPMG, EY each maintain internal red teams). The gap in the market: mid-sized cyber-attest firms that hold SOC 2 CPA credentials and QSA accreditation but do NOT hold TIBER-EU red-team accreditation. Those firms either partner with a red-team specialist for TLPT execution while retaining the surrounding audit-adjacent workload (register audit, contract review, incident-classification testing, resilience-testing-programme audit), or build the red-team capability over a 12-24 month horizon. The right choice depends on the practice’s client book — if fewer than 5 clients per year cross the TLPT threshold, partner; if 20+, build.
The Register-of-Information audit — where existing firms have immediate footing
Article 28(3) requires every financial entity to submit an annual Register of Information to the NCA in the structured xBRL-CSV format defined by ITS 2024/2956. The first cycle (April 2025) produced consistent supervisory feedback: register data quality was the dominant finding. Vendor metadata was inconsistent across the ICT stack, contract inventories were incomplete, subcontractor chains were unclear, and financial entities routinely discovered they could not turn structured data around fast enough from their own vendors. Deloitte’s 2025 DORA survey found 46% of financial entities named the Register of Information as the single most challenging DORA requirement.
For a cyber-attest firm, this is the immediate footing. Pre-submission review of register completeness and accuracy is audit-adjacent work in the traditional third-party-risk practice, requires no new accreditation, and maps to standard sampling procedure. What the review actually covers:
- Population completeness testing.: Reconcile the register against the FE's contract management system, expense-management system, and IT asset inventory. Look for ICT arrangements that appear in one of those systems but not the register. Sample enough to establish confidence the register captures the full contractual population.
- Critical-or-important function classification testing.: For each register entry classified as supporting a critical or important function, test whether the FE's classification methodology was applied consistently. For each entry classified as NOT critical or important, test whether the classification is defensible against the FE's own criticality criteria. Misclassifications drop the arrangement out of the enhanced Article 30 contract regime, which is a supervisory red flag.
- Subcontractor chain verification.: For each critical/important-function arrangement, test whether the register accurately captures the subcontracting chain at least one level below the direct provider. This was a consistent 2025 first-cycle finding — entities knew their direct vendors but not the material subcontractors underneath.
- LEI reconciliation.: Test each ICT third-party provider's Legal Entity Identifier against the GLEIF public database. Missing or incorrect LEIs are the most common data-quality flag in the xBRL-CSV submission and the easiest to remediate before submission.
- Data-location and cross-border flag testing.: Sample-test whether the register's data-processing and data-storage location entries match the actual contractual and operational reality, and whether cross-border transfer flags are complete.
The engagement shape: 40-120 hours per FE annually, timed to complete before the 30 April NCA submission window. Fee sits alongside the FE's existing third-party-risk audit budget. For a cyber-attest firm with an existing book of EU financial-entity clients, this is a natural extension — the same senior manager running the client’s SOC 2 II can run the register review with a modest DORA-specific training addition.
Incident classification audit — new methodological territory
The DORA incident-classification cascade (Article 19 + supporting RTS) creates a specific retrospective-testing scope: was the FE’s classification of each ICT-related incident during the covered period consistent with the RTS thresholds? Did the FE submit within the mandated timelines (4-hour initial notification within 24 hours of awareness, 72-hour intermediate report, 1-month final report)?
This is genuinely new methodological territory. No established SSAE-18 or ISAE-3402 procedure has yet been published by IAASB or AICPA specifically for DORA incident reporting. But the methodology maps cleanly onto existing internal-audit-style testing:
Population definition
Every ICT-related incident the FE recorded during the covered period, at all severity levels. Cross-reference against IT ticketing system, security incident tracking system, business continuity invocations, and press-monitoring for public disclosures.
Sample selection
Judgmentally-informed random sample stratified by (a) FE's own severity classification and (b) whether the incident was reported to the NCA. Include a specific over-sample of incidents the FE classified as NOT major but which cross the RTS 7-criteria boundary — these are the ones where classification error creates supervisory exposure.
Testing procedure
For each sampled incident, walk the RTS 7-criteria classification against the incident’s actual impact. Test the FE's classification-methodology documentation. If reported to the NCA, test submission timeliness against timestamps. Document the auditor’s classification conclusion and any variance from the FE's.
Conclusion
Rate of classification variance. Rate of submission-timeliness variance. Root-cause analysis on any material variance. Recommendations to strengthen the classification methodology or the submission workflow. Deliverable is a management letter, not a formal opinion (until IAASB or AICPA publishes DORA-specific attestation standards).
The independence question — DORA vs AICPA
A firm running SOC 2 II examinations for an EU financial-entity client and considering picking up DORA-adjacent work for the same client hits the same independence question every multi-service cyber-attest practice has always had to navigate. The specifics under DORA:
The practical resolution: for a firm serving EU financial-entity clients on SOC 2 examinations, adding Register-of-Information audit, incident-classification testing, and Article 30 contract review on the same client is manageable under AICPA rules (these are audit-adjacent testing procedures, not management-responsibility activities). Adding TLPT is the harder call — DORA permits it under the RTS separation requirements, but AICPA independence rules would generally require either a segregated service line with true independence (informational firewalls, separate personnel, separate P&L) or a partner arrangement with an unaffiliated red-team firm.
Where DORA fits in a multi-accreditation cyber-attest practice
For the multi-accreditation cyber-attest firms serving enterprise clients across SOC 2, ISO 27001, ISO 42001, PCI DSS, HITRUST, FedRAMP, and CMMC (the profile documented in the multi-framework audit-firm console piece), DORA extends the framework list rather than replacing anything. Cross-framework control overlap with ISO 27001 Annex A and SOC 2 Trust Services Criteria runs 40-60% on the ICT-risk-management, access-control, encryption, incident-response, and change-management domains (Vanta, Drata, ISMS.online, BARR Advisory coordinated-audit mapping). The DORA delta not covered by SOC 2/ISO 27001: board-level accountability (Art. 5), mandatory ICT third-party contract clauses (Art. 30), the Register of Information (Art. 28), TLPT (Arts. 26-27), regulator incident reporting (Art. 19), and CTPP oversight regime.
The practical positioning: DORA is an adjacent practice for the readiness/gap-assessment/register-build/incident-workflow portions; TLPT is a fundamentally different practice requiring offensive-security capability that traditional CPA/QSA/HITRUST-assessor firms typically do not carry in-house. Firms holding both CPA/QSA AND TIBER-EU authorization are essentially the Big 4 today — the traditional independence firewall inside each firm is what makes this workable. Outside the Big 4, holding both a QSAC listing and named TIBER-EU red-team accreditation appears to be a genuine market gap.
Building or acquiring DORA capability
The build-versus-partner-versus-acquire decision depends on the practice’s existing client book and its multi-year positioning in EU financial services. The realistic paths:
- Register + contract + incident audit capability — buildable in weeks.: Existing senior managers can extend into DORA-specific testing procedures with a modest DORA-training addition and a set of tested workpaper templates. No new accreditation required. Right first move for any cyber-attest firm with 5+ EU financial-entity clients.
- Resilience-testing-programme audit — buildable in months.: Extends the firm's existing IT audit / security-testing scope with a DORA-specific evidence taxonomy. Requires senior-manager-level familiarity with the RTS on DORA testing but not new accreditation. Fits alongside the register-and-contract-audit workload.
- TLPT execution — buildable in 12-24 months, or partnerable indefinitely.: Build path: hire a red-team manager (≥5 years experience), 2+ additional testers (≥2 years each), acquire CREST or equivalent certifications, apply for TIBER-country accreditation, obtain PI insurance for live-systems testing. Partner path: standing relationship with a TIBER-EU-accredited red-team specialist, joint go-to-market on client engagements, revenue-share model. The partner path is faster and lower-capital; the build path captures more revenue per engagement and creates a competitive moat over 5-year horizons.
- TIBER-EU accreditation itself.: No pan-EU TLPT provider register exists; NCAs maintain their own via the national TIBER cells (TIBER-DE, TIBER-NL, TIBER-FR, TIBER-LU, TIBER-BE, TIBER-IE, TIBER-IT active). Getting on multiple national lists is a country-by-country application process. For firms with concentrated client geography (e.g. Germany-heavy book), starting with TIBER-DE gets the biggest market coverage per application cycle.
- Acquisition — for firms building toward TLPT scale.: Several mid-tier assessor firms have acquired small red-team boutiques in 2024-2026 specifically to bring TIBER-EU accreditation and offensive-security capability in-house. Typical acquisition price for a small TIBER-EU-accredited boutique (~15-30 people): USD 8-25M. This is the fastest path to a multi-country TIBER accreditation for firms with the capital to deploy.
The first formal DORA fines are expected in the second half of 2026 (per DLA Piper, Simmons & Simmons, HSFK 2025 analyses). That timing creates a competitive window for cyber-attest firms whose EU financial-entity clients are staring at the transition-year-to-active-enforcement handoff. Firms that ship the register-audit + contract-review + incident-classification-audit capabilities in Q3 2026 catch the entire 2027 Register-of-Information submission cycle (30 April 2027 deadline). The TLPT capability compounds more slowly — three-year cadence, high per-engagement fees, sticky client relationships — but the register-and-audit-adjacent revenue is available immediately for firms that build it now.
The bottom line
DORA is not the biggest revenue line the modern cyber-attest practice will build in the next five years, but it is a real one, and it is one where the specific mix of capabilities matters more than raw firm size. The Register-of-Information audit, contract review, incident-classification testing, and resilience-testing-programme audit are immediate opportunities for any cyber-attest firm with EU financial-entity clients — buildable in weeks, deliverable at existing senior-manager fee rates, no new accreditation required. TLPT is the higher-revenue but higher-capability opportunity: build the offensive-security capability, partner with a specialist, or acquire a TIBER-EU-accredited boutique. Every path is viable; the wrong path is inaction while the 2026 first-formal-fine cycle produces the first client conversations demanding "our auditor is asking whether our Register is complete — what does your firm do here?"
Run the DORA-adjacent audit workload from the same console
vCISO Lite for Auditors supports the register-audit, contract-review, and incident-classification-audit workload alongside SOC 2, ISO 27001, ISO 42001, PCI DSS, HITRUST, and FedRAMP work — same cross-framework book view, same cross-cycle drift detection, same extraction-lineage IPE, same hash-chained evidence integrity. Built for cyber-attest firms whose EU financial-entity client work now includes a DORA layer.
If you’re scoping the DORA-adjacent capability build for the 2027 Register-of-Information submission cycle, or evaluating the partner-versus-build decision on TLPT, visit firm.vcisolite.com to see the console.