Red Team: complete guide to DORA TLPT, TIBER-EU and MITRE ATT&CK

A Red Team is an exercise in which an offensive team simulates a real adversary against an organization, with a specific objective and agreed rules, to check whether people, processes and technology detect and stop the attack. It does not look for every vulnerability in a system, as a pentest does: it answers how far an attacker would get and what the defense would see along the way.

This guide explains what a Red Team is and is not, how it differs from a pentest and from purple teaming, what DORA requires through TLPT tests (Articles 26 and 27), how it relates to TIBER-EU and TIBER-ES, the phases of an exercise, the role of MITRE ATT&CK, the legal limits and how to measure the result without promising figures. The service is at pentesting and Red Team.

What a Red Team is

The European TIBER-EU framework describes this type of test as a controlled, bespoke, intelligence-led test of an entity's critical or important functions and the systems underpinning them (people, processes and technologies), which mimics the tactics, techniques and procedures of real attackers [5]. It helps assess protection, detection and response capabilities [5].

Three traits:

• It has an objective, not a checklist. In a DORA TLPT the objectives are called "flags": key objectives in the systems supporting critical or important functions that the testers try to achieve [2].
• It is covert. The defenders do not know an exercise is under way. Delegated Regulation 2025/1190 explains why: if security staff knew, they would be more alert than under normal conditions and the outcome would change [2].
• It is not passed or failed. TIBER-EU says so expressly: the result is not "pass" or "fail" but an insight into strengths and weaknesses so the entity can learn and raise its maturity [3].

In the Delegated Regulation, "red team" means the testers (internal or external) of the exercise and "blue team" means those who defend the systems without knowing there is an exercise [2]. In everyday use, "Red Team" also names the type of exercise.

Red Team, pentest, vulnerability scanning and purple team

They are different things and they complement each other. DORA reflects this: its testing programme lists, separately, vulnerability assessments and scans and penetration testing, among others (Article 25), and reserves advanced threat-led testing (TLPT) for Article 26 [1].

On the pentest column, recital 12 of the Delegated Regulation says conventional penetration tests give a detailed and useful assessment of technical and configuration vulnerabilities, often of a single isolated system, but do not assess the full scenario of a targeted attack against a whole entity, with its people, processes and technologies; it therefore asks entities, when choosing providers, to check that they can run intelligence-led red team tests and not only pentests [2].

Vulnerability scanning is another piece: DORA lists it as a test distinct from penetration testing [1]. According to Hodeitek's service, automated scans do not detect exploitable business logic, which a pentest analyzes using methodologies such as OWASP, PTES and MITRE ATT&CK.

Purple teaming deserves a clarification. The Delegated Regulation defines it as a collaborative activity involving both the testers and the blue team [2]. In a TLPT it appears as an exceptional resource during the active phase, if there is no other way to continue (for example "catch-and-release" or "war gaming"), and as a mandatory exercise in the closure phase [2].

When a Red Team makes sense

TIBER-EU is designed for entities with national or European systemic importance and sufficient ICT maturity, although any type or size of entity can use it [5]. The TIBER-ES guide adds that the tests run on production systems with external providers, with an inherent risk and a high cost borne by the entity tested [6].

Our conclusion, not a requirement of any standard: a Red Team pays off more when controls, monitoring and incident response already exist to be tested. If that base is not there yet, a targeted pentest may be more useful.

TLPT in DORA: Articles 26 and 27

DORA, Regulation (EU) 2022/2554, applies from 17 January 2025 [1]. Article 24 requires financial entities (except microenterprises) to have a testing programme and, at least yearly, appropriate tests of the ICT systems and applications supporting critical or important functions [1]. Article 26 adds, for the entities identified by the authorities, advanced threat-led penetration testing, TLPT.

Source of the table: Article 26 of Regulation (EU) 2022/2554 [1]. Significant credit institutions (Article 6(4) of Regulation (EU) No 1024/2013) may only use external testers meeting Article 27(1), points (a) to (e) [1].

Who is required

Article 26 leaves it to the authorities to identify the entities, based on impact, systemic character and ICT risk profile [1]. Delegated Regulation (EU) 2025/1190, which develops that paragraph, sets the criteria in its Article 2 [2]. Paragraph 2 lists the types of entity from which the authorities will require TLPT unless their assessment shows it is not justified: credit institutions identified as G-SIIs or O-SIIs or part of their groups, payment and electronic money institutions above certain volume thresholds, central securities depositories, central counterparties, certain trading venues and insurance and reinsurance undertakings above thresholds for premiums, technical provisions and assets [2]. The authorities may also assess other types of entity using the criteria in paragraph 1 [2]. If you do not know whether your entity is identified, your authority has the answer.

Requirements for testers (Article 27)

Article 27(1) of DORA says entities shall only use testers that [1]:

• are of the highest suitability and reputability;
• have technical and organizational capabilities and demonstrate specific expertise in threat intelligence, penetration testing and red team testing;
• are certified by an accreditation body in a Member State or adhere to formal codes of conduct or ethical frameworks;
• provide an independent assurance or audit report on the sound management of the risks associated with carrying out TLPT, including due protection of the entity's confidential information and redress for its business risks;
• are duly covered by professional indemnity insurance, including against misconduct and negligence.

The Delegated Regulation specifies how to check this (Article 7) [2]:

In exceptional circumstances, an entity may contract providers that do not meet one or more of the documentation, insurance, references and team composition requirements, provided it adopts and records measures that mitigate that risk (Article 7(2)) [2].

With internal testers, Article 27(2) also requires approval by the competent authority, sufficient dedicated resources, no conflicts of interest and an external threat intelligence provider [1]; Article 15 of the Delegated Regulation requires a team with a test lead and at least two other members, employed by the entity or by an intra-group provider for the preceding 12 months [2].

TIBER-EU and TIBER-ES

TIBER-EU is the European framework for threat intelligence-based ethical red teaming. It was developed jointly by the ECB and the EU national central banks and published in May 2018 [3]. It seeks to harmonize these tests in Europe and to facilitate their mutual recognition [5]. The ECB updated the framework to align it with the DORA RTS on TLPT (note of 11 February 2025): the process follows the RTS deliverables and timelines, purple teaming is mandatory and the "White Team" was renamed "Control Team" [4].

Its relationship with DORA has two sides:

• Delegated Regulation 2025/1190 was drafted in accordance with TIBER-EU and mirrors its methodology, process and structure. Entities may refer to and apply TIBER-EU or one of its national implementations insofar as it is consistent with Articles 26 and 27 of DORA and with the Delegated Regulation itself [2].
• According to the framework itself, an entity completing a test under a national or European implementation of TIBER-EU will be DORA TLPT-compliant, provided it fulfils the formal requirements set by the competent authorities [5]. This is a statement by the ECB about its framework, not a decision by your authority.

TIBER-ES is the Spanish adoption. In December 2020 the Executive Commission of the Banco de España approved the adoption of the TIBER-EU framework, assisted by the CNMV and the DGSFP for entities in their remit [6]. The Banco de España implementation guide dates from January 2022 and, according to its text, participation in those tests was then voluntary [6]. It predates the application of DORA: for the mandatory TLPT of a specific entity, ask its authority and check the current documentation; this guide does not determine which authority is competent.

Phases of an exercise

TIBER-EU defines a process with three mandatory phases: preparation, testing and closure [5]. Delegated Regulation 2025/1190 sets deadlines for the DORA TLPT [2]:

The phases and deliverables are those of Articles 9 to 14 of the Delegated Regulation [2]. The remediation plan must include, for each finding, a description of the shortcomings, the proposed measures with their prioritization and expected completion, the root cause analysis, the staff responsible and the risks of not implementing them (Article 13) [2]. These deadlines are those of the DORA TLPT; a voluntary exercise may have others.

Rules of engagement and exercise safety

A Red Team touches real systems, and the rules of engagement agreed beforehand are one of the ways to control the risk. In a DORA TLPT they take shape as follows [2]:

• Risk assessment before starting. The control team assesses the risks of testing production systems of critical or important functions, including interrupting activities or corrupting data, the testers' access to sensitive information and incomplete restoration of systems (Article 5).
• Secrecy. Access is limited to those who need to know and, where possible, a code name is used (Article 4).
• Approved test plan. The testers draw up a plan that includes communication and the use of "leg-ups"; later changes to the timeline, scope, target systems or flags are approved by the control team lead and the test managers (Article 11).
• "Leg-ups". These are help or information the control team gives the testers when they cannot advance on their own and there is no other reasonable alternative, for example for lack of time or resources (Article 1). They are approved by the control team and the test managers (Article 11) and, according to TIBER-EU, they are logged [5].
• Detection during the test. If someone detects the activity, the control team proposes measures to keep the secrecy, which the test managers validate (Article 11).
• Suspension. In exceptional circumstances, with risk of impact on data, damage to assets or disruption of critical functions, the control team lead may suspend the exercise or, as a last resort and with the authority's validation, continue with limited purple teaming (Article 11).
• Clean closure. The testers restore what they touched and may not destroy equipment without authorization, modify information or assets in an uncontrolled way, intentionally compromise the continuity of critical or important functions, include out-of-scope systems without authorization or disclose results without authorization (Article 7).

An exercise outside DORA is not bound by these articles, but they are a good reference for what to agree: scope, exclusions, windows, emergency channel and stop criteria (our judgment). In Hodeitek's service, the first step is scoping and rules of engagement: scope, objectives, constraints and communication channels are defined, and non-disclosure agreements and legal authorizations are signed.

Legal limits in Spain

The Spanish Criminal Code punishes, in Article 197 bis.1, anyone who, "without being duly authorised", accesses, or gives another access to, an information system, or part of it, breaching security measures, or stays in it against the will of whoever has the right to exclude them, and, in 197 bis.2, the unauthorized interception of non-public transmissions of computer data [11]. Article 264.1 punishes deleting, damaging, altering or making inaccessible third-party computer data or programs, "without authorisation" and in a serious manner, when the result is serious [11].

What is usually needed in practice (our judgment, not legal advice):

• Prior written authorization from whoever can give it, with specific systems, addresses and windows. Whatever is outside the agreed scope is not authorized.
• Agreement with affected third parties. If the exercise may touch a provider's infrastructure (cloud, hosting, an ICT provider), your authorization is not enough. DORA provides for this for ICT providers included in a TLPT: the entity must ensure their participation (Article 26) [1].
• Authorization also for social engineering and physical access, with specific people and sites.

This section is general information: before an exercise, the contract and the authorizations should be reviewed by those with legal responsibility. The BOE consolidated text is cited (last update published: 9 April 2026). The quoted fragments are our English rendering of the Spanish text.

MITRE ATT&CK

MITRE ATT&CK is a globally accessible knowledge base of adversary tactics and techniques based on real-world observations. MITRE states that it serves as a foundation for threat models and methodologies in the private sector, government and the cybersecurity community, and that it is free to use for any person or organization [7]. At the time of consultation, the current version was ATT&CK v20.1, of 13 October 2026 [9].

The Enterprise matrix organizes techniques by tactics. In the version consulted, the columns were Reconnaissance, Resource Development, Initial Access, Execution, Persistence, Privilege Escalation, Stealth, Defense Impairment, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration and Impact [8]. That list changes between versions: check the current one.

Common uses in a Red Team (our judgment): a shared language to describe what the attacker did and what the defense saw, checking which techniques were tested and which were not, and linking each offensive action to its detection or its absence.

One clarification: neither TIBER-EU nor Delegated Regulation 2025/1190 requires the use of ATT&CK. The Regulation asks for the tactics, techniques and procedures (TTPs) used successfully and unsuccessfully to be documented [2], and the vocabulary used is agreed by the parties. In Hodeitek's service, the declared methodologies are OWASP, PTES and MITRE ATT&CK.

How to measure results without promising figures

TIBER-EU does not grade with pass or fail [3], and no source in this guide sets a numeric success threshold. The annexes of the Delegated Regulation do define what the reports of a TLPT contain, a good list of what to measure [2]:

Two useful readings (our judgment): how many leg-ups were needed shows where the attacker stopped without help, and the match between actions and detections shows what the defense sees and does not see. Neither is a result that can be promised before the exercise: it depends on the scope, the scenarios and the organization.

The Red Team at Hodeitek

Hodeitek describes its pentesting and Red Team service as follows: simulation of real attacks on infrastructure, applications and people, with OWASP, PTES and MITRE ATT&CK methodologies. The full Red Team is an advanced adversary simulation with defined objectives, combining digital, social and physical techniques over weeks of covert operation. The process includes scoping and rules of engagement, reconnaissance, exploitation, post-exploitation and pivoting, and a two-level report (executive summary and technical report with evidence) with vulnerabilities classified by criticality (CVSS) and a prioritized remediation plan. The later retest is optional and quoted separately.

For the DORA TLPT, the service itself warns that it helps cover the testing programme but does not by itself satisfy the requirements Article 27 of DORA sets for testers. That check is done case by case with the authority and with the provider.

Where HodeiShield fits. Between exercises, HodeiShield offers an exposure radar that cross-references the critical and high CVEs of your assets with the providers that own them, with periodic synchronization of its sources, in addition to vendor scoring and scheduled scans with periodic follow-up. It does not replace a Red Team: it does not simulate an adversary, does not measure detection and response and does not replace a TLPT.

If your doubt is which exercise to choose, the comparison is in Red Team vs pentest. To see how a result is documented, there is an example pentest report with fictitious data.

Relationship with DORA and NIS2

A Red Team is not a certification and does not satisfy a framework on its own, but it can provide evidence:

This guide does not analyze the ENS or ISO/IEC 27001: see the ENS guide and the ISO 27001 guide. If you need to organize compliance before choosing tests, there is GRC and compliance consulting.

Checklist before commissioning an exercise

Common mistakes

• Expecting a pass or fail. TIBER-EU rules it out: the aim is to learn [3].
• Telling the whole security team. If the defending staff know, they will be more alert and the result changes [2].
• Starting without rules, authorization or agreement with affected third parties. Without them, the exercise may fall outside what is allowed (see the legal section).
• Choosing the provider on price alone. In a TLPT, DORA and the Delegated Regulation set suitability, reference and insurance requirements [1] [2].
• Skipping the closure. The replay with the blue team and purple teaming are part of the process, not an extra [2].
• Believing a Red Team replaces the other tests. DORA also requires a programme of periodic tests [1], and a scan or a pentest answer other questions.

This guide is informational and does not replace the text of the regulations, the decision of the competent authority or legal advice. Updated on 13 November 2026.