TLPT Deliverables: Findings, Evidence & Retesting

What should the report prove?

Your TLPT report should explain the failed control and the demonstrated consequence, not just assign a severity. Look for authority-validated scope, threat-led scenarios and closure evidence, reproducible observations and affected owners. Coverage gaps and untested consequences must remain visible so the report supports a defensible decision.

Build the evidence throughout the test

A useful TLPT evidence set connects the scope and threat assumptions to the actions performed, the defenders’ observations and the resulting improvements. Agree templates, access controls and responsibilities during preparation.

Output	Purpose	Responsibility to agree
Scope and governance records	Trace critical functions, dependencies, authorisation and safety controls.	Financial entity and control team, with authority validation of the scope.
Targeted threat intelligence	Explain threat relevance, exposure and scenario selection.	Threat intelligence provider and the relevant review participants.
Red-team test plan and report	Describe planned scenarios, execution, evidence and control outcomes.	Red-team testers, with control-team and authority coordination.
Blue-team report	Document what defenders observed, detected and did.	Financial entity’s blue team and control team.
Replay and purple-team learning	Reconcile attack and defence observations and explore improvement opportunities.	Control team, blue team and testers.
Test summary and remediation plan	Summarise findings, actions and the basis for closure.	Financial entity, supported by providers; submitted through the authority process.

Reporting for more than one audience

Technical teams need a reproducible account of events and evidence. Management needs the implications for critical functions, the reasons for material gaps and accountable improvement decisions. The authority needs the required documentation in the appropriate form.

Agree which information belongs in each output. Test reports can contain sensitive security information. Use restricted distribution and a secure transfer mechanism; do not attach them to the public enquiry form.

Make remediation trackable

Describe the weakness and the affected function or control.
Assign an accountable owner and an achievable target date.
Record dependencies and interim mitigations.
Define evidence of completion and any validation work.
Escalate unresolved risk through the entity’s governance process.

Retesting and follow-up validation must be specified in the engagement or a separately agreed extension. They are not silently assumed to be included indefinitely.

What an attestation does—and does not—mean

DORA provides for an attestation to support mutual recognition. Its issuance and acceptance belong to the relevant authority process. The test provider does not certify the organisation’s entire DORA compliance or guarantee that all future attacks will fail.

See the reporting and remediation guide for practical preparation.

Primary sources

General information, not legal advice. Confirm the applicable requirements and test arrangements with your relevant authority.