The decision this guide helps you make
Closure must explain the attack path, defensive response and implications for the tested functions. Preserve limits and untested consequences, then assign each treatment to an owner with a verifiable outcome. Reporting and remediation evidence need preparation throughout the test.
For the engagement owner. Connect the attack path, defensive observations and operating context to actions with owners and verifiable outcomes. Closure must preserve what the exercise could and could not establish.
Closure should explain outcomes, not just list weaknesses
A useful TLPT report connects the test’s objectives to the actions performed and the organisation’s response. It explains which controls prevented, detected or contained activity, where they did not, and what that means for the tested functions.
The RTS sets requirements for reporting and closure. Treat the reports as planned outputs from the start, with evidence collection and document ownership built into the engagement. Reconstructing events only after testing ends creates avoidable gaps.
Read diagram text
- Attack path
- Technical actions and conditions
- Defensive view
- Detection, escalation and response
- Treatment
- Owned changes with observable outcomes
Bring attack and defence accounts together
The red-team report records the tester’s perspective. The blue-team report describes what defenders observed and how they acted. Differences between those perspectives are often the most useful starting points for learning.
Replay and purple teaming can help explain why a detection was missed, why an alert was not escalated or why a response did not achieve its intended outcome. They can also reveal effective controls that deserve to be preserved or extended.
Turn a finding into an action
| Element | A useful question |
|---|---|
| Affected function | Which operational outcome could the issue undermine? |
| Root cause | Is the gap in technology, process, ownership, knowledge or a combination? |
| Action | What specific change will reduce the risk? |
| Owner and timing | Who is accountable, and what dependencies determine the target date? |
| Validation | What evidence will demonstrate that the improvement works? |
| Residual risk | What remains unresolved, and who accepts or escalates it? |
A plan that says only “improve monitoring” leaves important choices open. A more actionable plan identifies the missing visibility, the detection logic or operational step to change, and the team responsible for validating it.
Read diagram text
- Engineering change
- Bounded technical validation
- Operating procedure
- Relevant process or exercise evidence
- Residual exposure
- Explicit owner and review decision
Keep the regulatory timing visible
RTS Articles 12 and 13 cover closure and remediation requirements, including document timing. The red-team and blue-team reports, authority review, test summary and remediation documentation have distinct steps and triggers.
Assign someone to track these obligations and communications. Do not assume that submitting a technical report completes the entity’s responsibilities or that provider availability removes the need for internal ownership.
Read diagram text
- Observation
- What was actually demonstrated
- Condition
- Assistance, version and operating limits
- Decision
- Priority, ownership and accepted uncertainty
Control sensitive evidence
Reports can describe attack paths and security gaps that should not circulate broadly. Agree access, secure transfer, retention and redaction based on the audience and purpose. Management summaries can support decisions without reproducing every technical detail.
Do not put real findings into a public contact form or marketing case study. Any external case study needs a separate confidentiality and permission assessment.
Define what happens after closure
Remediation and any retesting should have explicit ownership and scope. Clarify whether follow-up validation is included in the contract, what evidence the entity will produce and how unresolved issues are escalated.
A completed TLPT is a basis for improvement. It does not guarantee that all weaknesses were found or discharge the entity’s wider DORA responsibilities.
Separate technical findings from resilience lessons
An individual weakness may contribute to a broader path involving identity, detection, escalation and response. Report the technical condition with reproducible evidence, then explain how it relates to the scenario and the defenders' observations. Keep the effect of assistance, timing and operational constraints visible. A technically successful step does not automatically establish every downstream impact, and a detected step does not by itself demonstrate an effective response.
The bank pentest remediation guide provides a practical model for defining observable technical closure. Use that discipline within the wider TLPT reporting and treatment process rather than treating a list of closed vulnerability tickets as the entire outcome.
Design validation around the intended improvement
For each action, identify the control or process expected to change, the accountable owner and the evidence that would demonstrate improvement. A policy update, engineering change and operational rehearsal may need different validation methods. Record dependencies between actions so the programme does not close individual tasks while the combined path remains unresolved. Preserve the agreed prioritisation and the rationale for any accepted residual risk.
Fast-moving platforms also need release context. The fintech report and release retesting guide explains how to connect an observation, a change and a later result without losing version history. At final handover, maintain a clear boundary between completed observations, proposed validation and untested assumptions. That gives management an accountable treatment plan and a sound basis for reviewing whether the intended resilience improvements have actually occurred.
Read diagram text
- Define the improvement
- State the intended control behaviour
- Link dependent actions
- Keep the complete path visible
- Validate and review
- Record results and remaining decisions
Continue your preparation
Primary sources
General information, not legal advice. Confirm the applicable requirements and test arrangements with your relevant authority.
This guide and the related sector publications linked above are published by Atlant Security. Technical examples are planning examples, not claims about completed client tests.
Published by Atlant Security. Sources, editorial policy and corrections.
