Red Team Engagement Plan Template (TIBER-EU, DORA TLPT)

Red Team Engagement Plan: [Engagement code name]

Plan for a threat-led red team engagement against live production systems: purpose, scope of critical or important functions, roles of the control team (often called the white team), threat intelligence and scenarios, rules of engagement, risk management, provider selection, timeline, communication, closure with replay and purple teaming, remediation and attestation. Structure follows the process of the TIBER-EU framework (European Central Bank, edition of January 2025) and, for EU financial entities, the threat-led penetration testing (TLPT) rules in Regulation (EU) 2022/2554 (DORA), Articles 26 and 27, and Commission Delegated Regulation (EU) 2025/1190. It works for voluntary engagements too. Replace every [bracketed] value and every row marked Example. Worked examples use Varnholt Bank, a fictional EU retail bank, and the code name OPAL HARBOUR. This is a documentation format, not legal advice: check the current official texts and your TLPT authority's national guidance, and involve qualified legal counsel.

Document control

Approvals

Revision history

Contents

1. Purpose and engagement type
2. Regulatory and framework basis
3. Teams, roles and responsibilities
4. Secrecy and need-to-know
5. Scope and flags
6. Threat intelligence and scenarios
7. Rules of engagement
8. Risk management
9. Provider and tester selection
10. Timeline and phases
11. Communication, escalation and stop conditions
12. Closure: reports, replay and purple teaming
13. Remediation plan and attestation
14. Evidence, logging and data handling
15. Traceability matrix
16. Glossary and references
17. Standard and licence note

1. Purpose and engagement type

Purpose (Example): find out whether Varnholt Bank can prevent, detect and respond to attacks by the threat actors most likely to target its retail payments, online banking and customer data functions, using the tactics those actors use today, and turn the results into funded improvements to protection, detection and response.

How this engagement differs from neighbouring activities:

2. Regulatory and framework basis

Outside regulated finance there is usually no legal obligation to run a threat-led red team. The process here still works: replace the TLPT authority with an internal assurance function (for example internal audit) that plays the independent oversight role, and keep every other element. Wherever this plan quotes a deadline from the Delegated Regulation, a voluntary engagement may set its own, but should record why.

3. Teams, roles and responsibilities

3.1 Teams

3.2 RACI

R = responsible, A = accountable, C = consulted, I = informed.

4. Secrecy and need-to-know

Secrecy rules:

1. Use the code name in every message, ticket, calendar entry and file name. Never use the words "red team" or the provider's name in shared systems.
2. Store engagement material in a restricted repository with access logging, readable only by the people listed above.
3. Use the secure communication channels agreed in section 11, not corporate chat that the security operations centre can read.
4. If a blue team member detects the test and escalates, the control team contains the escalation (see section 11.3) without revealing the engagement more widely than needed.
5. Record any suspected leak, assess its effect on test validity with the test manager and decide whether to continue, adapt or restart.

5. Scope and flags

5.1 Critical or important functions in scope

5.2 Flags

5.3 Out of scope

6. Threat intelligence and scenarios

6.1 Intelligence inputs

6.2 Scenario shortlist and selection

Selection rationale (Example): SCN-01 to SCN-03 cover all three functions, three distinct actors and three entry routes (people, customer-facing identity, supplier). The control team lead selected them on 2027-07-05 after the scenario selection meeting, taking into account the TIP recommendation, test manager input, tester feasibility and the bank's risk profile.

6.3 Technique mapping

Map each selected scenario to MITRE ATT&CK techniques (use the ATT&CK version current at test time and record it). The red team test plan holds the detailed attack path; this table keeps the summary visible to the control team.

7. Rules of engagement

7.1 Authorisation

• Written authorisation letter signed by [@sponsor] and [@legal-counsel], naming the provider, the testers, the code name, the scope and the active testing window. Testers carry it (digitally and, for physical tests, on paper) and show it only if challenged by law enforcement or after a stop instruction.
• Third-party authorisation from each ICT service provider in scope, signed before any activity touches its systems.
• Insurance: confirm professional indemnity cover of each provider, including misconduct and negligence (see section 9).

7.2 Allowed and not-allowed techniques

7.3 Leg-ups

A leg-up is help the control team gives testers so the engagement can continue when a step would take a real attacker longer than the test allows (for example, providing a foothold equivalent to a successful phish). Every leg-up is planned or requested, approved by the control team and, for regulated tests, the test manager, and recorded.

8. Risk management

Risk scale: likelihood and impact use the organisation's risk methodology (compliance/risk-methodology). Accepted residual risks are signed by the sponsor.

9. Provider and tester selection

9.1 External provider checks

Check these figures against Article 7 of the current consolidated text before contracting; national TIBER guidance may add requirements, such as accreditation schemes.

9.2 Internal testers (if used)

10. Timeline and phases

11. Communication, escalation and stop conditions

11.1 Channels and rhythm

11.2 Stop conditions

Testing pauses immediately when any of the following happens; it resumes only on the CTL's instruction, after consulting the test manager for regulated tests:

1. Unplanned impact on availability or integrity of a critical or important function.
2. Testers access real customer personal data beyond the minimum needed to prove a flag.
3. Evidence of a real attacker in the environment.
4. A blue team escalation that would trigger external notification, law enforcement involvement or customer communication.
5. Safety concern for any person, including during physical or social engineering activity.
6. Loss of contact between the CTL and the red team lead for more than [4] hours during an active operation.

11.3 Handling detection by the blue team

If the red team confirms the activity, the control team decides with the test manager whether to let the blue team continue its response (valuable learning), to provide a cover story, or to adapt the scenario. If the red team denies it, treat the event as a real incident immediately (11.4).

11.4 Real incident during the engagement

Pause testing, hand over to the incident response plan (compliance/incident-response-plan), share relevant tester logs with responders under need-to-know, and assess with the test manager whether the engagement can resume or must be restarted later. Major incidents still follow their own reporting duties, for example compliance/dora-major-incident-report.

12. Closure: reports, replay and purple teaming

12.1 Closure deliverables

12.2 Replay and purple teaming plan

12.3 Findings register

13. Remediation plan and attestation

Attestation: for TLPT, the authority issues an attestation that the test met the requirements, which supports mutual recognition by other authorities. Record its reference and date here: [Attestation reference], YYYY-MM-DD. Track remediation in the organisation's risk treatment plan (compliance/risk-treatment-plan) and report status in the security metrics report (security/security-metrics-report).

14. Evidence, logging and data handling

15. Traceability matrix

16. Glossary and references

16.1 Glossary

16.2 References

Standard and licence note

Based on Regulation (EU) 2022/2554 (DORA), Articles 26 and 27, Commission Delegated Regulation (EU) 2025/1190 (public EU law) and the TIBER-EU framework of the European Central Bank (January 2025 edition; ECB copyright, freely available on the ECB website). The phase structure, role names, deadlines and deliverable lists are summarised and paraphrased in original words; no text is reproduced from the framework or its guidance documents. CBEST is cited by name only. Deadlines, provider requirements and authority roles can change through amendments, national implementations and new framework editions: check the current consolidated text on EUR-Lex, the ECB TIBER-EU pages and your authority's guidance before each engagement. This template is not legal advice; consult qualified counsel on authorisation, employment and privacy limits of social engineering and physical testing in each jurisdiction. Template licence: MIT.