DORA (Regulation (EU) 2022/2554, the Digital Operational Resilience Act) imposes operational-resilience, ICT-third-party-risk-management, incident-reporting, and digital-operational-resilience-testing obligations on financial entities operating in the European Union, with extended application to critical third-party ICT service providers. The regulation entered into force in January 2023, applied from January 2025, and is enforced by national competent authorities under the coordination of the European Supervisory Authorities (the EBA, ESMA, and EIOPA). DORA covers approximately twenty categories of financial entities — credit institutions, payment institutions, electronic-money institutions, investment firms, crypto-asset service providers, central counterparties, trade repositories, central securities depositories, trading venues, insurance and reinsurance undertakings, insurance intermediaries, institutions for occupational retirement provision, credit-rating agencies, administrators of critical benchmarks, crowdfunding service providers, securitization repositories, account information service providers, and others. The regulation also designates a small number of ICT service providers as "critical third-party providers" (CTPPs) subject to direct supervision by the European Supervisory Authorities.
From a customer-success and testimonial-wall perspective, a DORA compliance milestone is structurally different from the SOC 2 audit, ISO 27001 certification, PCI DSS certification, HIPAA attestation, FedRAMP authorization, and NIS2 compliance milestones covered elsewhere in this series. Five structural differences drive distinct testimonial-wall risks. First, DORA imposes regulatory-grade obligations directly on financial entities and indirectly on their ICT service providers through contractual flow-down requirements, so a ProofShow customer may be subject to DORA either as a regulated financial entity or as a service provider to one. Second, the threat-led penetration testing (TLPT) regime under DORA's Articles 26-27 creates testing-evidence that is statutorily confidential and cannot be referenced in customer-facing testimonials. Third, the ICT-third-party register required under Article 28 is supervisory-reportable and creates an attestation-by-omission risk if a testimonial implies the customer has not registered a provider it actually has. Fourth, the incident-reporting timelines under Article 19 are different from the NIS2 and other-framework timelines, which creates terminology-precision risk. Fifth, the "critical third-party provider" designation under Article 31 is supervisory-controlled and creates a designation-claim risk if a testimonial implies CTPP status without the formal designation.
This guide separates the DORA compliance journey into five phases, explains what changes for the testimonial wall in each phase, and provides per-phase playbooks. The phases are structured around the gap-assessment phase, the ICT-risk-management framework implementation phase, the third-party-risk register and contractual remediation phase, the digital-operational-resilience-testing program phase, and the ongoing incident-reporting and supervisory-engagement phase.
The five phases of DORA compliance
A DORA compliance journey, from gap assessment to first-cycle supervisory engagement, typically runs twelve to twenty-four months across the five phases.
Phase 1: Gap assessment. The customer determines whether it is in scope of DORA (and in which entity category), maps the current state of its ICT risk management, third-party risk management, incident reporting, and resilience testing against DORA's requirements, and produces a gap-remediation plan. The phase is characterized by legal-and-technical scoping work and produces a compliance roadmap.
Phase 2: ICT-risk-management framework implementation. The customer implements the ICT risk management framework required by Articles 5-15 — covering governance, risk identification and classification, ICT systems and tools, business continuity, ICT operations, ICT change management, ICT projects, and learning-and-evolving processes. The phase is characterized by capability-building and produces the operational evidence base for supervisory engagement.
Phase 3: ICT-third-party-risk register and contractual remediation. The customer builds the register of ICT third-party arrangements required by Article 28, classifies each arrangement by the criticality of the supported function, renegotiates contracts to incorporate the mandatory contractual provisions of Article 30 (including audit and access rights, exit strategies, sub-outsourcing controls, and termination triggers), and notifies competent authorities of any planned arrangements supporting critical or important functions before contract execution. The phase is characterized by procurement-and-legal coordination work and produces the third-party-risk evidence base.
Phase 4: Digital-operational-resilience-testing program. The customer establishes the resilience-testing program required by Articles 24-25, including the testing methodology, the testing scope, the personnel and providers performing the tests, and the remediation tracking. Larger financial entities also undergo threat-led penetration testing (TLPT) under Articles 26-27, conducted by certified TLPT providers under the supervision of the TLPT authority of the home member state. The phase is characterized by testing-execution work and produces the resilience-evidence base.
Phase 5: Ongoing incident reporting and supervisory engagement. The customer enters a steady-state operational mode of major-incident initial-notifications (typically within 24 hours of incident classification), intermediate-reports (within 72 hours), and final-reports (within one month), along with significant-cyber-threat voluntary notifications and ongoing supervisory engagement. The phase has no end-date and produces a stream of compliance-event evidence.
Each phase has its own testimonial-wall risks. The biggest mistake is to treat DORA like a certification (SOC 2 / ISO 27001 / PCI DSS) and to publish a "the customer is DORA certified" testimonial — DORA has no certification mechanism, it is a regulation with continuous compliance obligations, and the framing creates credibility-and-legal risk.
Per-phase playbook for the testimonial wall
Phase 1: Gap assessment
During gap assessment, the testimonial wall faces a scope-disclosure risk, an entity-classification risk, and a remediation-roadmap-disclosure risk.
First, treat the gap assessment as supervisory-grade confidential. The customer's DORA gap assessment will identify deficiencies against regulatory requirements. Gap inventories for a regulated financial entity are extraordinarily sensitive — they may be reviewable by competent authorities during supervisory engagement, and they map the customer's current resilience-posture deficiencies in a way that creates information-disclosure risk if leaked.
The remediation is to defer any DORA-related testimonial publication until at least the Phase 2 framework implementation phase, when the customer's posture has been remediated rather than catalogued. Even Phase 2 publication should avoid any reference to the prior gap state.
Second, do not publish the entity classification without coordination. The customer's classification as a particular DORA entity category (credit institution, payment institution, investment firm, etc.) is supervisory information, and even though the classification may be public via the customer's licensing register, the testimonial framing of the classification can imply scope claims the customer has not approved. A testimonial that describes the customer as "a DORA-regulated credit institution" should be coordinated with the customer's legal-and-compliance team.
The remediation is to use generic phrasing ("the customer is a DORA-regulated financial entity") and let the customer's own public materials establish the specific entity-category classification.
Third, do not reference the remediation roadmap. The customer's gap-remediation plan identifies specific deficiencies and remediation timelines. References to the roadmap in a testimonial — even at the level of "the customer is on a twelve-month remediation track" — create supervisory-engagement risk if competent authorities interpret the public reference as inconsistent with the supervisory communications.
The remediation is to defer any temporal-claim language until Phase 5 when the customer has reached steady-state operations.
Phase 2: ICT-risk-management framework implementation
During framework implementation, the testimonial wall faces a capability-overstatement risk, a governance-claim risk, and a framework-terminology risk.
Capability-overstatement risk. Framework implementation is iterative — governance, risk-identification, business-continuity, and operational-process capabilities are stood up, tested, refined, and re-tested over many months. A testimonial published in mid-implementation that characterizes the customer's posture as "complete" or "mature" will overstate the actual capability state and may be revisited unfavorably during competent-authority supervision in Phase 5.
The remediation is to defer capability-claim testimonials until the customer has completed at least one supervisory engagement cycle that has validated the framework externally. Mid-implementation testimonials should focus on the customer's commitment, governance structure, and program scope rather than on capability-level claims.
Governance-claim risk. DORA Article 5 requires the management body of the financial entity to bear ultimate responsibility for ICT risk management — including approving the digital-operational-resilience strategy, allocating budget, and overseeing the third-party risk strategy. Testimonials that name specific management-body members or that quote board-level commitments create personal-liability considerations for the named individuals and should be coordinated with the customer's legal team and the named individuals themselves.
The remediation is to use institutional phrasing ("the customer's management body has approved the resilience strategy") rather than personal phrasing ("CEO [name] has committed to..."), unless the named individuals have explicitly approved their inclusion.
Framework-terminology risk. DORA's framework vocabulary has specific definitions that differ from the vocabulary used in NIS2, ISO 27001, and SOC 2. For example, "ICT-related incident" in DORA has a different scope than "security incident" in NIS2 and "security event" in SOC 2. "Critical or important function" in DORA has a precise meaning in Article 3(22) that does not map cleanly to "business-critical process" in BCP/DR literature. A testimonial that uses cross-framework vocabulary loosely will read as imprecise to DORA-knowledgeable readers and may create attestation-misalignment risk.
The remediation is to use DORA's actual vocabulary when referring to DORA obligations and to use other frameworks' vocabulary when referring to those frameworks. Cross-framework comparisons should be explicit ("the customer's DORA ICT-risk-management framework builds on the foundation established for ISO 27001 certification").
Phase 3: ICT-third-party-risk register and contractual remediation
During third-party-risk-register and contractual remediation, the testimonial wall faces three particularly elevated risks for ProofShow specifically — register-membership-claim risk, contractual-remediation-disclosure risk, and supplier-attestation risk. If ProofShow is itself in the customer's ICT-third-party register supporting a critical or important function, these risks compound.
Register-membership-claim risk. The customer's Article 28 register classifies each ICT third-party arrangement by criticality. A testimonial that implies ProofShow (or any other named provider) is or is not in the register, or is or is not classified as supporting a critical or important function, creates an attestation-by-omission or attestation-by-commission risk depending on the actual register state.
The remediation is to avoid any reference to register membership or to register classification in the testimonial. If ProofShow needs to communicate that it is a DORA-aware provider, the communication should be in marketing collateral about ProofShow's capabilities, not in a customer-attributed testimonial.
Contractual-remediation-disclosure risk. DORA's Article 30 imposes mandatory contractual provisions on ICT third-party arrangements, and renegotiating contracts to incorporate the provisions is one of the heaviest workstreams of the entire DORA compliance journey. A testimonial that references the contractual renegotiation in any specificity — for example, "we successfully renegotiated our ICT contracts to incorporate DORA Article 30 provisions" — discloses contracting practices that the customer may prefer not to make public, and may create relative-disclosure issues if the customer has not completed the renegotiation with all of its providers.
The remediation is to avoid any reference to the contractual renegotiation workstream. Generic phrasing ("the customer has aligned its third-party arrangements with DORA requirements") is acceptable for marketing purposes if the customer has approved the phrasing; specific contract-clause references should not appear.
Supplier-attestation risk. A testimonial in which a regulated financial entity vouches for ProofShow's contribution to its DORA compliance can be read as an attestation by the financial entity that ProofShow's services meet DORA's expectations for the supported function. Such attestations have legal weight in the supervisory engagement context and may be subject to retraction if the supervisory engagement identifies issues with the arrangement.
The remediation is to constrain the testimonial language to attributable customer experience ("ProofShow provided responsive support during our DORA-readiness work") rather than attestation language ("ProofShow's platform meets DORA requirements"). The customer is in a position to describe its experience but is not in a position to issue a regulatory-grade attestation on ProofShow's behalf.
Phase 4: Digital-operational-resilience-testing program
During resilience-testing program execution, the testimonial wall faces a TLPT-confidentiality risk, a testing-finding-disclosure risk, and a testing-scope-claim risk. The TLPT-confidentiality risk is the single most consequential testimonial-wall risk in the entire DORA compliance journey and is the reason DORA compliance milestones require the most stringent testimonial review of any compliance framework covered in this series.
TLPT-confidentiality risk. Threat-led penetration testing under DORA Articles 26-27 is conducted under strict confidentiality. The TLPT report contains adversarial-simulation findings that map the financial entity's vulnerabilities at a level of specificity that would be operationally dangerous if disclosed. The TLPT report is shared between the financial entity, the TLPT provider, and the TLPT authority of the home member state, and disclosure beyond that triangle is statutorily restricted.
A testimonial that references a TLPT — even at the level of "we recently completed our DORA TLPT" — discloses the existence of a testing event and the relative timing of the next testing cycle, both of which are information adversaries can use to time attacks. The remediation is to categorically exclude TLPT references from any customer-facing testimonial. The exclusion applies to the existence, the timing, the scope, the findings, and the remediation of any TLPT, regardless of how generic the reference might appear.
Testing-finding-disclosure risk. Beyond TLPT specifically, the broader resilience-testing program under Article 24 produces findings that are sensitive even when not statutorily restricted. A testimonial that references specific findings ("our resilience testing identified gaps in our backup-restore procedures, and we have remediated them") discloses prior posture deficiencies and may create regulatory-engagement concerns.
The remediation is to focus testimonial language on testing-program existence and program governance ("the customer has implemented a DORA-aligned resilience-testing program") rather than on findings.
Testing-scope-claim risk. The resilience-testing program covers a defined scope of ICT systems supporting critical or important functions. A testimonial that overstates the scope ("we have tested all of our ICT systems") creates an attestation-misalignment risk if the actual scope is narrower than the testimonial implies.
The remediation is to avoid scope-magnitude claims and to use generic-but-accurate language ("the customer's resilience-testing program covers ICT systems supporting critical and important functions, in accordance with DORA Article 24").
Phase 5: Ongoing incident reporting and supervisory engagement
During steady-state operations, the testimonial wall faces an incident-reference risk, a supervisory-engagement-disclosure risk, and a regulatory-stability-claim risk.
Incident-reference risk. DORA's Article 19 incident-reporting regime is one of the most demanding in the EU regulatory landscape — initial notification within 24 hours of classifying an incident as major, intermediate report within 72 hours, and final report within one month, with specific data elements at each stage. A testimonial that references a specific incident — even at the level of "we successfully managed a major ICT-related incident last year" — discloses the existence and the rough timing of a reported incident in a way that creates regulatory and public-perception risks.
The remediation is to categorically exclude incident references from customer-facing testimonials, even when the incident has been fully remediated and the supervisory engagement has been closed.
Supervisory-engagement-disclosure risk. Competent-authority supervisory engagements with regulated financial entities are conducted under confidentiality protocols. A testimonial that references supervisory engagement — even favorably ("our competent authority commended our DORA implementation") — discloses the existence and substance of supervisory communications in a way that may breach confidentiality protocols and may be misinterpreted by the competent authority.
The remediation is to categorically exclude supervisory-engagement references from customer-facing testimonials.
Regulatory-stability-claim risk. DORA is a relatively recent regulation, and the regulatory technical standards (RTS) and implementing technical standards (ITS) that operationalize the regulation are still being clarified by the European Supervisory Authorities through Q&A processes, industry guidance, and supervisory actions. A testimonial that claims long-term DORA compliance ("the customer's DORA compliance is durable") overstates the regulatory stability and may be revisited unfavorably if the regulatory clarifications shift the compliance bar.
The remediation is to use point-in-time phrasing ("as of [year], the customer has implemented a DORA-aligned framework") rather than durability claims, and to update the testimonial as the regulatory landscape evolves.
Cross-references and related guidance
DORA compliance is one of several EU regulatory frameworks that interact in the ProofShow customer base. For the broader EU cybersecurity directive that applies to a wider set of organizations, see the NIS2 compliance guide. For the legacy financial-sector compliance frameworks that DORA layers on top of, see the SOC 2 audit, ISO 27001 certification, and PCI DSS certification guides. For the testimonial framework foundations that apply across all compliance milestones, see how to collect testimonials from customers.
The single most important takeaway for DORA-related testimonials is the TLPT exclusion. Among all compliance frameworks covered in this series, DORA is the only one with a regulatory-grade testing regime whose existence, timing, and findings are statutorily protected from disclosure. A testimonial program that fails to enforce the TLPT exclusion creates risks that no other compliance framework's testimonial program creates — and the risk is highest in the period immediately after a TLPT cycle, when the customer-success team may not realize that a recent positive customer interaction was anchored on TLPT findings.