TLPT Completion Evidence: Why a DDoS Report Is Not the Whole Test

Does a DDoS test report satisfy DORA TLPT?

A standalone DDoS test report does not establish that an institution has completed a DORA threat-led penetration test. It may provide useful evidence about a particular availability control, but TLPT is an end-to-end process with a defined scope, targeted intelligence, controlled testing, reporting, learning and closure. The question is not whether the DDoS report is good. The question is which part of the required process it evidences and which parts it does not.

This guide helps control teams assemble and review a completion evidence package without confusing individual technical tests with the full engagement. It is particularly useful when existing supplier reports, resilience exercises and penetration tests are being considered as supporting evidence. The examples are fictional and the suggested registers are practical management tools, not substitutes for the current regulation or the responsible authority’s process.

Our DORA TLPT service is scoped around the financial function and the evidence needed to understand its resilience. For a broader explanation of the process, see the DORA TLPT RTS guide. Here the focus is narrower: how to make the final package explain what was actually done, what was learned, what remains uncertain and who owns the next action.

Separate a control test, a scenario and a completed exercise

A control test asks a bounded question. For example, it may measure how a contracted service handles an agreed volume pattern under controlled conditions. A scenario connects a starting position, adversary behaviour and a business objective across a sequence of actions. A completed TLPT requires evidence of the applicable process surrounding those scenarios. These are related layers, but a strong result at one layer does not automatically establish the others.

A supplier report may be technically excellent while covering only the supplier’s infrastructure, a particular time window or a narrow traffic profile. Before relying on it, identify its scope, assumptions, permissions, dependencies and limitations. Ask whether it addresses the financial institution’s actual function and operating arrangement. A service-level observation should not be expanded into a claim about the resilience of every application or operational process that depends on that service.

Use Delegated Regulation (EU) 2025/1190 to identify the applicable deliverables and closure process. Its reporting structure covers scenarios, successful and unsuccessful paths, assistance, defensive actions and findings. Treat supporting test reports as evidence within that structure where appropriate, rather than renaming them to imply completion of activities they did not contain.

Create a completion index before the end of testing

Build the evidence index during preparation, then maintain it through the exercise. Waiting until the final week makes it harder to recover missing decisions, versions or approvals. The index should identify the expected documents, their owners, controlled locations, versions and review status. It should also show dependencies: a final report may rely on an accepted scope, a scenario decision and an operational timeline.

Keep the index concise enough to use. It is not necessary to duplicate every file or log entry. Point to controlled evidence collections and explain what each collection supports. Separate documents intended for broad governance review from operational material that requires tighter access. This allows the board or risk committee to understand the outcome without circulating detailed techniques, identities or sensitive system information.

Give every material decision a stable reference. Scope changes, approved assistance, stop decisions and unresolved constraints should be traceable from the final narrative. If the report says a path was not exercised because of a production limitation, the reader should be able to locate the decision that established that limitation. Otherwise the narrative can look like an after-the-fact explanation rather than an accurate account of controlled delivery.

Assign ownership for missing evidence early. A red team cannot reconstruct every defensive action without the institution’s support, and a control team cannot explain every technical action without the testers’ records. The completion plan should identify who supplies each contribution and how disagreements are resolved. That is a delivery dependency, not an administrative detail.

Follow each scenario from rationale to result

For each selected scenario, preserve the link between the intelligence rationale, the planned objective, the authorised operational approach and the observed result. The final account should state what happened to the scenario rather than merely listing the vulnerabilities discovered along the way. A scenario may reach its objective, be blocked by a control, require assistance, change through approval or remain incomplete. Each outcome carries different learning.

Use a scenario ledger with the planned starting condition, relevant function, key milestones, objective status and evidence references. Record unsuccessful actions as well as successful ones where they explain the result. A report containing only successes can exaggerate attacker capability; a report containing only findings can hide effective controls. The useful conclusion explains the path and the boundary that mattered.

Do not combine separate runs into an apparently uninterrupted attack chain. If the team restarted with a different account, received access assistance or used a modified environment, state that clearly. Those actions may be entirely appropriate within the approved process, but their role affects interpretation. A reader should be able to distinguish what the testers independently achieved from what was supplied to enable further learning.

Make the technical timeline usable by another team

Agree time conventions before correlating records. Preserve the source timestamp, time zone and any known clock difference. A central timeline can use UTC while retaining the original values for traceability. Do not silently correct records without documenting the adjustment. Small timing differences can matter when interpreting whether a defensive action preceded or followed a particular testing event.

Connect the action, the observed response and the relevant system state. A screenshot of a success message may not show whether a backend operation completed. A log record may show a request without proving its business effect. Use the minimum evidence needed to support the claim and explain the relationship between the records. Avoid collecting excessive sensitive data merely to make the evidence pack look comprehensive.

Label missing telemetry and uncertainty. If a log source was unavailable, expired or outside the agreed collection scope, state that limitation. Do not interpret the absence of a record as proof that no event occurred. Similarly, a detection visible to the control team may not establish that the operational defender received, understood and acted on it. Those are separate observations that require separate evidence.

Preserve an unmodified source copy where appropriate and create redacted working extracts for wider review. Record who prepared the extract and what was removed. The report should remain readable while authorised reviewers can examine the underlying basis if necessary. This balances confidentiality with the ability to challenge and reproduce the conclusion.

Reconstruct defensive behaviour without inventing hindsight

The defensive account should explain what the blue team observed and did during the exercise, with the applicable confidentiality and process arrangements respected. Separate contemporaneous actions from what defenders learned during replay or discussion. An analyst who identifies the path after being shown the red team timeline has contributed useful learning, but that is not the same as detecting it during the covert activity.

Map observations to operational steps: telemetry generated, alert produced, alert received, investigation started, decision made and containment attempted. These stages may be handled by different teams or suppliers. A delay can arise from missing context, authority, staffing or a technical control. The final recommendations should address the actual failure mechanism rather than assuming every missed objective requires a new detection rule.

Include effective responses. If a control blocked progression or an analyst escalated an ambiguous event correctly, preserve that evidence. The institution needs to know which capabilities are reliable as well as which require improvement. A balanced report is more useful for investment decisions than a narrative that treats the exercise as a competition to maximise the number of successful attacks.

Where the red and blue accounts disagree, retain the disagreement until it is resolved through evidence or explicitly bounded. Do not smooth it away for presentation. A differing interpretation may reveal an important telemetry gap or ownership problem. Record the agreed facts, the remaining uncertainty and the follow-up needed to improve confidence.

Evaluate supporting supplier reports on their own terms

For a DDoS or other supplier report, begin with its purpose and contractual boundary. Which service, endpoint, region and operating mode were tested? Which conditions were deliberately excluded? Were dependencies and upstream arrangements representative? Was the result measured at the supplier boundary or at the business application? These questions determine how much of the evidence can support your own resilience conclusions.

Check the relationship between the tested configuration and the current service. A report from a previous architecture or contract period may still provide background, but its limitations should be visible. Ask what changed after the test and whether those changes affect reliance. Do not assume that a current document date means every technical observation reflects the current environment.

Record what the supplier report does not address. It may say little about identity compromise, transaction integrity, recovery decisions or the institution’s own response process. That does not make the report worthless. It means the evidence belongs in a bounded part of the package. The control team should identify remaining questions rather than stretching the report’s language to make the file appear complete.

Avoid commissioning disruptive activity simply to fill a perceived evidence gap. Any additional testing needs appropriate permission, risk assessment and process alignment. If a question cannot be tested safely within the engagement, document that constraint and the planned alternative. A transparent limitation is preferable to an unsafe exercise or an unsupported completion claim.

Turn replay and purple teaming into specific improvements

Learning sessions should produce more than a presentation of the attack path. Select the points where different evidence or decisions could have changed the outcome. Ask which telemetry was available, which context was missing and who had authority to act. Then define a bounded improvement and a way to verify it. This converts the technical narrative into work that an operational owner can perform.

Use replay carefully. A replay may demonstrate whether a proposed detection or process change recognises a known pattern. It does not recreate every uncertainty of the original exercise. Record the conditions, information supplied and changes already made. The result is valuable, but its interpretation should reflect the fact that participants now know more than they did during the initial activity.

Prioritise recurring root causes across scenarios. Several findings may trace back to inconsistent identity ownership, weak approval boundaries or incomplete telemetry. Addressing each symptom separately can create expensive duplication. Group related actions while preserving the specific acceptance criteria for each affected control. The remediation plan should make the shared dependency visible without losing accountability.

Keep the learning environment constructive. The purpose is to improve resilience, not to assign blame to an individual analyst who faced ambiguous information. Examine the system of tools, procedures and authority around that person. This produces recommendations that remain useful after staff changes and avoids turning the final report into a story about exceptional individual performance.

Write remediation actions that can actually be closed

A remediation action needs an owner, a defined change, dependencies, a target date and acceptance evidence. “Improve monitoring” is too broad. A stronger action identifies the relevant event path, expected alert context, investigation owner and a controlled verification case. The exact technical implementation belongs to the responsible team, but the desired outcome must be clear enough to test.

Distinguish a completed implementation from a verified outcome. A ticket marked done may show that a configuration was changed; it may not show that the original path is now constrained or detected. Ask what evidence demonstrates the intended effect and what negative check confirms that legitimate business activity still works. Availability and usability matter alongside restriction.

For accepted residual risk, record the decision owner, rationale, compensating measures and review condition. Do not describe an accepted risk as remediated. Likewise, a deferred action remains open even when it has a future project date. Clear status language protects the institution from believing that every item has been technically resolved when the real decision was to tolerate or postpone it.

Close the operational footprint as well as the report

Maintain an inventory of temporary accounts, access paths, tools, infrastructure and data created or acquired during testing. Use it to support the agreed restoration and disposal process. The final report is not the only deliverable: the institution needs confidence that the exercise has not left unintended access or sensitive material behind. Assign owners and evidence requirements for each relevant cleanup item.

Confirm changes with the appropriate system owners. A provider can report that a temporary tool was removed, while an owner may need to confirm the expected state of the affected service. Where a credential was exposed during testing, follow the agreed handling and rotation process rather than assuming that deleting the tester’s copy removes the risk. Preserve enough evidence to explain completion without retaining the secret itself unnecessarily.

Consider delayed effects and backups. A test artefact may remain in a restored image, a scheduled task or a retained copy even after the active host is cleaned. The appropriate response depends on the environment and the agreed procedures. Record the known locations and decisions so that future restoration does not accidentally reintroduce an operational test artefact.

Complete the communications closeout. Confirm which recipients hold sensitive reports, what retention applies and who remains responsible for follow-up questions. Remove temporary collaboration access when no longer needed under the agreed arrangements. A technically complete exercise can still leave an information-handling problem if its working spaces remain broadly accessible indefinitely.

Prepare the summary for governance without hiding limitations

The governance summary should explain the scoped functions, the principal scenarios, the important outcomes and the actions that require management attention. It should be concise enough to support decisions while pointing to the detailed evidence. Do not turn it into a list of vulnerability counts. Counts alone say little about whether a critical function was affected, a defensive control worked or a shared root cause remains unresolved.

The ECB’s Test Summary Report guidance provides a useful reference for summarising the scope, scenarios and test context. Use the applicable authority’s requirements and the agreed process to determine the final form. Keep the summary consistent with the technical reports, particularly on assistance, unreached objectives and material constraints.

Separate completion of the exercise from completion of remediation. Management may need to acknowledge a finished test while significant follow-up work remains. Show those states clearly. Similarly, do not describe authority interaction, mutual recognition or attestation as something a testing provider can simply guarantee through its own report. Follow the actual process and identify the responsible decision maker.

A good executive discussion ends with decisions: which risks require urgent action, which investments are justified, which owners need support and when progress will be reviewed. Provide the evidence necessary for those decisions without exposing operational detail unnecessarily. That is the practical value of a completion package: it turns a complex exercise into an accountable improvement programme.

Check one complete chain through the evidence package

Choose a material scenario and trace it from the accepted scope through intelligence, planning, execution, reporting and remediation. Confirm that the identifiers and conclusions agree. An assistance decision should appear where it affects interpretation; a limitation should not disappear from the summary; a remediation action should refer to the actual observed boundary. This sample review often finds inconsistencies that a document-by-document proofreading pass misses.

Then select a scenario that did not reach its objective. Verify that the package explains whether a control blocked it, an operational constraint limited it or the available time ended. Those outcomes are different. A reader should not need to infer the reason from missing evidence. Record the corrections and ask the relevant owners to confirm the final wording. The exercise is complete only in the sense established by the applicable process; the evidence package should make that meaning clear rather than relying on an ambiguous success label.

A final readiness review before submission or closeout

Run a short cross-check with the document owners. Confirm that the accepted scope, scenario names, dates, assistance records and finding identifiers agree across the package. Check that every material conclusion has a supporting reference and that every unresolved limitation appears in the appropriate summary. Inconsistencies often arise from different teams drafting at different times rather than from poor technical work, but they still reduce confidence.

Verify that the recipient package contains only what the recipient is authorised and expected to receive. Operational details, personal information and sensitive supplier records may require separate handling. Use the agreed secure delivery channel, confirm receipt where appropriate and retain the submission record. Do not attach the complete evidence archive to an ordinary email merely because the final review deadline is approaching.

If you are unsure whether existing reports support a planned TLPT, describe the reports and their boundaries through our TLPT scoping brief or contact Atlant Security. We can help identify the missing workstreams and evidence questions before a proposal is prepared. Begin with scope and objectives; agree confidentiality and secure exchange before sharing sensitive material.

This guide was reviewed on 25 October 2026. It offers practical evidence-management recommendations, not a legal opinion or regulatory completion decision. A DDoS test, application assessment or supplier report can be valuable supporting evidence. Its value increases when its boundaries are stated honestly and connected to the wider process, rather than being presented as proof of a full TLPT that did not occur.