How Long Does DORA TLPT Take? Beyond the 12-Week Phase

The decision this guide helps you make

The minimum active red-team period is only one part of the schedule. Procurement, scope validation, intelligence preparation, access readiness and closure also take time. A credible timetable identifies those dependencies and ownership rather than promising a complete TLPT in twelve weeks.

Twelve weeks is one phase, not the whole programme

The TLPT RTS requires the active red-team testing phase to last at least 12 weeks. That does not mean a complete DORA TLPT can be booked, executed and closed within 12 weeks. Preparation, procurement, threat intelligence, planning, reporting and closure all require time.

The overall timetable depends on scope, participants, operational constraints and the authority process. A fixed total duration quoted before those factors are understood should be treated as an assumption to investigate.

What needs to happen before active testing

Preparation includes the control team, authority engagement, proposed scope, provider selection and contractual arrangements. Threat intelligence and red-team planning then turn that scope into relevant scenarios and controlled activity.

Third-party participation and cross-border coordination can be significant scheduling dependencies. So can the availability of named specialists, the quality of function mapping and the process for reviewing proposed documents. These should be visible on the programme plan rather than hidden as contingency.

Protect the active-testing window

Under RTS Article 11(5), the active red-team phase has a minimum of 12 weeks. Scheduling should respect the applicable requirements for the phase and any permitted methodology decisions. Limited purple teaming has a specific role under the RTS; it is not an informal workaround for an undersized engagement.

Agree escalation paths, operational restrictions and the handling of genuine incidents. A testing calendar that ignores production change or key participant availability can create unnecessary risk and delays.

Reserve time for closure and remediation planning

The RTS includes deadlines and report content requirements. For example, the red-team report is due within four weeks after the active phase; the blue-team report has a separate deadline linked to receipt of that report and no later than ten weeks after active testing ends.

Further timing requirements apply to the test summary and remediation plans. Some are triggered by authority notifications, so they cannot all be calculated simply by adding a fixed number of weeks to the first day of testing. Read Articles 12 and 13 with the authority’s operating process.

What a credible schedule shows

• Phase boundaries and the assumptions behind them.
• Who reviews each document and the expected review window.
• Procurement, third-party and authority dependencies.
• Active testing, reporting, replay and purple-team participation.
• Remediation planning and follow-through responsibilities.

Build backward from known constraints, but do not compress mandatory activity to fit an arbitrary deadline. A scoping conversation should produce a timetable with named dependencies and explicit uncertainty.

Expose the dependencies behind the dates

Build the working schedule around decisions that unlock the next activity: governance established, proposed scope prepared, provider responsibilities agreed, participation confirmed and operating safeguards ready. Name the owner and input for each dependency. A date without an accountable owner is not a reliable planning control. Distinguish the applicable framework's requirements from the organisation's estimated preparation time, and validate the plan with the relevant test managers.

The bank pentest procurement scope guide offers a useful way to make access and evidence assumptions explicit. Those practical inputs also matter during TLPT preparation, although the advanced exercise has its own process and scheduling requirements.

Protect time for evidence reconciliation and treatment

Closure requires people to compare observations, explain defensive decisions and translate lessons into accountable actions. Identify those participants early and make sure operational owners can attend the relevant work. A late discovery that the necessary log owner or supplier cannot support reconciliation can reduce the usefulness of the evidence. Plan for unresolved observations and scope limitations rather than assuming every question will be answered by the end of technical activity.

For product teams delivering changes during the wider programme, the fintech release and retest guide explains how to preserve version context. Use that discipline to avoid comparing observations from different system states as though they were equivalent. The final schedule should make dependencies, assumptions and required decisions visible, with dates treated as a managed plan rather than an unsupported promise of a universally fixed duration.

Continue your preparation

• The phases of the engagement
• Discuss your testing window