Choosing TIBER-EU threat intelligence and red team providers

Choosing TIBER-EU threat intelligence and red team providers starts with the minimums

A notified TIBER-EU or DORA threat-led penetration test cannot move into testing until procurement is complete, so the entity must choose a threat intelligence provider and a red team provider that both meet the ECB's minimum experience and reference rules. The test manager at the authority reviews that choice before the providers are onboarded. Start by checking the minimums against each shortlisted firm's named people, not the firm's general reputation: the threat intelligence team needs a manager with at least five years of threat intelligence experience plus one more member with at least two years, and the red team needs a test manager with at least five years of penetration and red team experience plus at least two testers with two years each. Both providers must also supply current CVs for each team member and proof of professional indemnity insurance covering misconduct and negligence.

The right provider depends on your scope, your systems and whether internal testers are allowed. Under the ECB's guidance the threat intelligence provider must always be external, and internal red team testers are permitted only in exceptional circumstances with the test manager's approval, while significant credit institutions under DORA may not use internal testers at all. Confirm early which of these rules applies to your entity, because that decision changes how many external seats you need to fill and how much the red team contract must cover. Ask each provider how its staff have worked on live production systems in regulated environments, since the framework deliberately sets stringent requirements for that reason.

DeployOpen prepares systems and evidence for a TIBER-EU or DORA test, but it does not select, certify or replace threat intelligence or red team providers, and it does not issue the attestation. Your organization owns the procurement decision and must document its compliance assessment of each provider for the control team, which in turn gives that evidence to the test manager. If a provider falls short of a minimum in exceptional circumstances, the deviation and its mitigating measures are recorded in the test attestation, so decide before the launch meeting whether you are willing to accept that exposure.

What team size, experience and references a provider must show

The TIBER-EU procurement guidance sets minimum staffing, experience and reference levels for both the threat intelligence provider and the red team provider. Each card covers one minimum, what to verify in a proposal, and how the same figures carry into DORA threat-led penetration testing.

Threat intelligence manager experience

The threat intelligence team must be led by a manager with at least five years of threat intelligence experience. Ask for a named person, a current CV and evidence of the years claimed, not a general statement about the firm's history. Check that the manager's experience is hands-on analysis for financial sector clients, since the manager will shape the targeted threat intelligence report that drives scenario selection.

Threat intelligence core member

At least one more threat intelligence member must have at least two years of experience. This person usually does the day-to-day collection and analysis work, so the proposal should name them and show their role. Confirm that the two core members together have taken part in at least three earlier assignments for penetration or red team tests, because that combined count is the minimum, not a per-person figure.

Threat intelligence references

The threat intelligence provider must supply at least three references. Ask for references that describe work similar to a TIBER-EU threat intelligence phase, and confirm that the referee will speak to the people actually proposed. Keep a record of who was contacted, when, and what was confirmed, because the control team must document its compliance assessment and provide the evidence to the test manager.

Red team test manager experience

The red team must be led by a test manager with at least five years of penetration and red team testing experience. The test manager directs the live testing against flags for at least 12 weeks in a TIBER-EU test, so ask for a description of recent live production engagements, not only laboratory or training work. Verify that the years claimed were spent on red team or penetration testing, not general IT security roles.

Red team tester depth

The red team needs at least two testers with at least two years of experience each. Ask which testers will work on the live engagement and whether they are the same people named in the proposal. A provider that substitutes staff during the test should be treated as a change of team, and the control team should check it against the original compliance assessment before the substitute starts.

Red team references and combined assignments

The red team provider must supply at least five references, and its three core members must together have taken part in at least five earlier assignments. Compare these against the named team, not the firm's overall portfolio. Ask each referee about the scope, the level of live testing and how the provider handled a production incident, since those answers test the experience claim more directly than a list of client names.

DORA Article 7 alignment

Commission Delegated Regulation (EU) 2025/1190 sets the same experience and reference minimums for threat intelligence providers and external testers under Article 7. A provider that meets the TIBER-EU guidance therefore also meets those DORA minimums, but the entity should still record each figure in its file for a DORA threat-led test. Confirm with your authority which evidence format it expects.

How to read certifications, CVs and professional indemnity insurance

Certifications confirm that a tester has been trained and examined, but they do not prove that the tester can run a threat-led test on a live production system. The ECB's TIBER-EU Guidance for Service Provider Procurement requires both the threat intelligence provider and the red team provider to supply copies of certifications appropriate to recognised market standards, together with up-to-date CVs for every team member, and to hold professional indemnity insurance covering misconduct and negligence. The guidance names no certification list, because availability varies by market. That leaves the buyer to judge each credential, and the framework expects experience and references to carry the weight alongside it.

When you review a certificate, check four things before you accept it. Confirm the prerequisites, such as prior experience or training that the certifying body requires before an exam can be taken. Check the reputation of the certifying body with your own market contacts and, where possible, with the authority's test manager. Find out whether the exam is practical, where the candidate must exploit or report on real systems, or multiple choice and sat remotely without proctoring, since the two tell you very different things. Finally, note the renewal rule and the date of the most recent renewal. An expired or unrenewed credential is a gap to resolve in writing, not a detail to overlook.

Read the CVs against the minimums rather than against the provider's marketing. The threat intelligence manager needs at least five years of threat intelligence experience, and the red team test manager needs at least five years of penetration and red team testing experience, so ask for dated roles that show those years and the named assignments behind them. Cross-check the CVs with the reference letters and the participation counts in the provider's proposal. Ask the provider to confirm in writing which team members hold professional indemnity cover, the insurer, the limit and the policy period, and whether the policy covers the named testers and the provider entity. Your legal team should review those terms before signature.

Which conflicts of interest and staff separations rule a provider out

The executive does not run the checks, but accepts the risk of the decision. TIBER-EU rules out any provider that has a current or previous service for the entity creating a conflict of interest, so the question is not only whether the provider is skilled but whether it already holds a position that could bias the test. Executives should ask for a written statement that covers the provider's group, subcontractors and recent engagements, not only the direct contract.

No current conflicting services: The provider must not be delivering any service to the entity that creates a conflict with the test.
No recent conflicting services: Earlier engagements that create a conflict also count, so ask for a look back, not just a snapshot.
Separation of staff: Threat intelligence staff may not do blue team work, and the two teams of one provider must be kept apart for the same test.
Accountability: Ask who at the entity signs the conflict declaration and who can reject a provider.

Before approving the choice, confirm that the control team lead has documented each conflict check and that no exception has been granted without written mitigating measures.

When internal red team testers are allowed and who must approve them

The threat intelligence provider must always be external to the entity. Internal staff can be considered for the red team only in exceptional circumstances, and only with the approval of the test manager. Before an entity plans around internal testers, it should treat the exception as the exception: the default path is an external threat intelligence provider and external red team testers, and any internal option needs a documented reason and a decision from the test manager before procurement is closed.

Internal testers, when approved, must meet the same minimum standards as external testers: the same experience thresholds for the test manager and testers, the same reference and certification evidence, and the same conflict and separation rules. Internal staff who have been involved in building, operating or defending the systems in scope are the hardest to clear on independence, so the entity should record how it has kept them separate from the blue team and the control team. Significant credit institutions under DORA may not use internal testers at all, so for those entities the question is closed before it starts.

Because the rules differ between authorities and DORA obligations, the entity must confirm the rule with its own authority before it relies on any internal option. Ask the TIBER Cyber Team or supervisor in writing whether internal testers are permitted for the entity's category, what approval form the test manager expects, and what mitigating measures will be required if a minimum is missed. Any deviation is recorded in the test attestation, so the answer should be on file before the red team is named.

What the provider contract must cover before signing

This sequence turns the procurement checklists into a signed agreement that protects the entity's data, systems and legal position before any red team member touches a live production system. Each step ends with a document or check that the buyer's legal team and the control team can confirm.

Start from the ECB agreement checklists
The control team takes the agreement checklists in the ECB's TIBER-EU Guidance for Service Provider Procurement (January 2025) and turns them into a clause-by-clause draft list for each provider type. The threat intelligence provider and the red team provider need separate lists, because their work, data access and risks differ. The output is one checklist per provider, reviewed by the test manager before any negotiation starts so that gaps are visible early.
Set confidentiality at least as strict as internal rules
The framework expects confidentiality terms at least as strict as the entity's own information security policies. The control team compares the draft confidentiality clause with the entity's classification rules for test data, flags, scenarios and findings, and asks the provider to confirm who can access that material and for how long. The step closes when the legal team signs off that the clause matches or exceeds the internal standard.
Define indemnification and liability terms
Live testing can cause outages, data exposure or damage to third parties, so the contract must state who bears those losses. The buyer's legal team reviews indemnification, liability caps and the provider's professional indemnity cover, which the guidance requires to address misconduct and negligence. The provider should supply the insurance certificate, and the step is complete when the cover amounts and exclusions have been checked against the scope and the entity's own risk appetite.
Agree data destruction and return terms
Test artifacts can include credentials, customer records, network maps and exploit code. The contract should require the provider to return or destroy all such material at the end of the engagement, and to confirm destruction in writing with a named responsible person. The control team checks that the destruction obligation covers subcontractors and backups, and the step closes when the wording and the timing of the confirmation are agreed.
Set breach notification duties and timelines
The contract must oblige the provider to report any security incident affecting the entity's data or the test infrastructure, and to do so within a defined period that the legal and security teams agree. Ask the provider to name its incident contacts and escalation path. The step is complete when the notification clause, the contacts and the escalation route are listed in the agreement and in the test's communication plan.
Write prohibited activities and scope limits
The contract lists what the provider must never do, such as testing outside the agreed flags, using denial-of-service techniques that were not approved, moving data out of agreed locations, or passing findings to third parties. The control team links each prohibition to the scope specification and the rules of engagement. The step closes when the list has been reviewed against the scope document and the provider has acknowledged it in writing.
Complete the legal review before signature
The buyer's legal team reviews the full agreement against the completed checklists, the conflict-of-interest declarations and the certification and CV evidence. The guidance makes the test manager responsible for assessing compliance but gives no commercial advice, so legal review is the entity's own duty. The output is a signed legal memo confirming that each checklist item is either met or recorded as an approved deviation for the attestation.
File the signed contract as procurement evidence
Once signed, the control team stores the agreements, checklists, declarations and legal memo together as the procurement evidence package. This package supports the compliance assessment that the test manager reviews, and it must be ready before the testing phase begins. The step is done when the package is indexed, access-restricted and confirmed as complete by the test manager.

How the test manager reviews the provider choice

The control team owns the provider decision, but it must document its compliance assessment of each threat intelligence provider and red team tester and hand that evidence to the test manager at the authority. The test manager reviews whether each provider meets the minimum requirements in the ECB's procurement guidance, which covers team experience, references, certifications, CVs and professional indemnity insurance. The test manager does not recommend a provider or give commercial advice on which firm to hire, so the control team should not expect the authority to shortlist vendors or negotiate on its behalf. Before the file goes to review, ask whether the evidence pack maps each minimum to a named team member and a dated document.

The control team must not contract any provider that the test manager assesses as non-compliant. This is the decision point that most often causes delay, because a failed review sends the control team back to procurement and the six-month window from written notification to launch meeting keeps running. Build the review into the procurement timetable rather than treating it as a formality at the end. Confirm early with the test manager which evidence format they expect, whether that is copies of certificates with validity dates, signed CVs or reference letters, so the first submission is not rejected for form alone.

In exceptional circumstances a provider may miss some minimum requirements. In that case the entity must adopt and evidence mitigating measures, such as additional supervision, narrower scope for the affected tester or extra senior oversight, and the deviation is recorded in the test attestation. Treat a deviation as a formal risk decision: name who approves it, document why no compliant alternative was available, and keep the mitigating measures in the file so an assessor can verify them. Confirm with the authority whether it accepts deviations for the threat intelligence provider, the red team, or both, because the framework's stringency on live production testing means a weak mitigation plan is likely to be challenged.

When procurement must finish to keep the test on schedule

Procurement is the step that most often sets the start date of a TIBER-EU test, so the sequence below shows how notification, initiation, scoping and provider selection fit together before the testing phase begins. Working backward from the launch meeting shows the entity when its provider search has to start.

Receive the authority's written notification
The test formally starts when the TIBER Cyber Team or the test manager at the authority sends written notification to the entity. This letter starts the clock for the preparation phase, and the entity should record its date and treat it as the reference point for every later milestone. The step is complete when the notification is filed and the internal sponsor has confirmed who will receive it and who owns the response.
Hold the initiation meeting and agree roles
The entity, the authority and the test manager meet to confirm the parties, the control team and the expected cadence of the test. The entity names its control team lead and the blue team contacts, and agrees who will handle provider questions. The output is an initiation document that records these roles, so that the procurement work has a clear owner from the start.
Set the scope and critical functions
The control team identifies the critical or important functions, the systems that support them and the flags that red team testers will try to reach. The scope specification document records these decisions and is shared with the test manager for review. Procurement cannot be specified well until this document is agreed, because the size and skills of both provider teams depend on the systems in scope.
Prepare procurement against the minimum requirements
The control team translates the ECB procurement guidance into a request for each provider, covering team experience, references, certifications, insurance, conflict declarations and contract terms. Each bidder must supply CVs and certification copies so the control team can document its compliance assessment. The step is complete when the request and checklists are ready and the test manager has confirmed the requirements apply to this test.
Assess bids and sign provider contracts
The control team evaluates each bid against the minimum requirements and documents the result, including any deviations and the mitigating measures for them. It then contracts only providers that the test manager has not assessed as non-compliant. The step closes when both the threat intelligence provider and the red team are contracted, and the evidence file is with the test manager.
Onboard providers at the launch meeting
Procurement must be complete before the testing phase begins, and the providers must be onboarded at a launch meeting no later than six months after the written notification. The launch meeting brings the entity, the authority, the threat intelligence provider and the red team together to confirm the test plan, the ground rules and the communication channels. The step is done when all parties have attended and the testing phase can formally begin.
Start procurement as early as possible
The framework advises beginning procurement early, because a slow provider search is the most common reason a test cannot launch on time. The entity should ask its control team to start the bid work during scoping rather than after it, and to confirm internally how long its own approvals take. Ask potential providers early about their current availability, since qualified testers are in demand and the test window depends on them.

Where provider selection usually goes wrong

Most delays in a TIBER-EU provider choice come from a small set of predictable mistakes, from starting procurement too late to signing contracts without the protections the framework expects. Each card below names one failure, why it hurts the test, and the check that prevents it.

Starting procurement too late

Procurement must be finished before the testing phase begins, and the providers must be onboarded at a launch meeting no later than six months after the written notification. Teams that wait for the authority's notification to open a sourcing exercise often find the market slow, the best testers booked and the launch date fixed. Start the market scan early, build the shortlist against the minimum requirements, and agree a calendar with the test manager before the notification arrives.

Weak reference checks

The guidance requires at least three references from the threat intelligence provider and at least five from the red team provider. Reviewers often accept the list at face value. Call each referee, confirm the assignment was a live production test of similar scope, and ask whether the named core members actually did the work. A reference that cannot describe the team's role is not evidence of the experience you are buying.

Certifications treated as proof of experience

The TIBER-EU guidance gives no list of recommended red team certifications and advises against relying on certifications alone. A certificate does not show years of live testing against a regulated production environment. Check prerequisites, whether the exam is practical or multiple choice and proctored, the certifying body's reputation and renewal rules, then verify the experience minimums separately using CVs and references.

Conflicts missed in the market scan

Providers must have no current or previous services for the entity that create a conflict of interest. Threat intelligence and red team staff of the same provider must also be separated for the same test, and threat intelligence staff may not do blue team work. Map every existing supplier relationship, including advisory and managed services, against each shortlisted firm before any bid is accepted. Ask each provider to declare its separation of teams in writing.

Internal testers used without approval

The threat intelligence provider must always be external. Internal red team testers are permitted only in exceptional circumstances, with the test manager's approval, and they must meet the same standards as external testers. Significant credit institutions under DORA may not use internal testers at all. Teams that quietly staff part of the red team in-house without a written approval risk an invalid test and a finding raised at closure. Confirm the approval route before any internal name appears in a plan.

Contracts missing data destruction or breach notification

The framework expects provider contracts to cover confidentiality at least as strict as the entity's own, indemnification, data destruction, breach notification and prohibited activities. Test data from a live production system includes sensitive material, so an agreement that does not specify how that data is destroyed, or how quickly a breach is reported, leaves the entity exposed. Work through the agreement checklist in the procurement guidance line by line, and have counsel confirm the indemnity and professional indemnity insurance terms before signature.

Common questions about choosing TIBER-EU providers

Who pays for TIBER-EU threat intelligence and red team providers?

The tested entity pays its own providers directly, under contracts it signs, and the authority's test manager does not set or receive those fees. The threat intelligence provider and the red team testers are separate contracts, so the entity pays for each team's time, reporting and any travel or tooling built into the agreed scope. Cost is driven by the number of target systems and flags, the length of active red team testing, how many teams and jurisdictions are involved, and how much of the work is fixed price versus time and materials. Ask each bidder for a fee split by phase, the assumed number of days, the reporting deliverables covered and what is excluded, such as retesting or remediation support. Some authorities charge their own fees, so confirm that separately with them. For a cost breakdown, see the TIBER-EU cost guide.

How long does TIBER-EU provider procurement take?

Procurement must be finished before the testing phase begins, and providers must be onboarded at a launch meeting no later than six months after the written notification. Because that deadline covers the whole preparation phase, procurement is usually the longest step to start early. Plan the work backwards from the launch meeting: scope and risk management, a request for proposal, reference and certification checks, the test manager's review, contract negotiation and onboarding. The ECB's procurement guidance advises starting as early as possible, and the time each step takes depends on your internal approvals, legal review and how many bidders you assess. Ask your authority whether it expects any intermediate deliverables before the launch meeting.

Can our organization run TIBER-EU provider procurement ourselves?

Yes, the entity runs its own procurement, and it owns the decision, but it must follow the minimum requirements in the ECB's service provider procurement guidance. The entity's control team documents its compliance assessment of each bidder and gives the evidence to the test manager. The test manager reviews that evidence but does not advise on which provider to choose, and the control team must not contract any provider the test manager assesses as non-compliant. Internal staff can run the process if they have procurement, legal and security skills, though many entities bring in an outside control team lead or project support to keep the evidence complete. Keep in mind that the threat intelligence provider must always be external.

Can DeployOpen be one of the TIBER-EU providers or our implementation partner?

DeployOpen offers security testing, including red teaming, and it can support compliance readiness, but its role has to be checked against the independence and conflict rules before any engagement. DeployOpen does not issue attestations or reports, and only the independent authority and the test manager's process produce the TIBER-EU outputs. Whether DeployOpen may act as a red team provider for a given test depends on the minimum experience and reference requirements, on the absence of conflicting prior work for the entity, and on the authority's rules. Where DeployOpen works as an implementation partner, it can help prepare systems, controls and evidence for the control team, provided it does not take on roles that the rules keep separate. Ask DeployOpen to confirm its eligibility in writing against your authority's rules before shortlisting it, and get a fixed-scope written proposal for any role.

What must we confirm with our national authority before choosing providers?

Confirm with your national authority which implementation document applies, how it reads the mandatory requirements, and any national rules that add to the European framework. Ask whether the authority requires specific notice, approval or a launch meeting format, and whether it charges fees. Also confirm the timing of the six-month onboarding limit from written notification, what the test manager expects to review, and how the authority wants the deviation process handled if a provider misses a minimum. Finally, ask whether your authority applies the same rules to DORA threat-led penetration tests, and whether it accepts external control team support. Record each answer in writing, because the authority's position decides which evidence the attestation will rely on.

What do TIBER-EU provider requirements look like for an engineer to check?

Engineers should check each bidder's named core team against the minimum experience and reference rules, then verify the evidence. The threat intelligence team needs a manager with at least five years of threat intelligence experience and at least one more member with at least two years, plus at least three references. The red team needs a test manager with at least five years of penetration and red team experience, at least two testers with at least two years each, and at least five references. Ask for current CVs, copies of certifications, and professional indemnity insurance covering misconduct and negligence. Request the reference contacts and confirm that the three core members of the red team have at least five earlier assignments between them. Do not rely on certifications alone; check the certifying body's reputation, whether exams are practical, and the renewal requirements.

What belongs in a TIBER-EU provider contract checklist?

The contract should cover confidentiality at least as strict as your own, indemnification, data destruction, breach notification and prohibited activities, as the framework expects. Add clear scope and rules of engagement for live production systems, named staff with the right experience, and the deliverables each phase requires. Include conflict of interest declarations, a commitment that threat intelligence staff will not perform blue team work, and separation between the threat intelligence and red team teams of the same provider. Agree how evidence is handed to the control team and how the provider supports the test manager's review. The ECB procurement guidance includes question lists and agreement checklists for both provider types, so use them as the baseline and have counsel review the final text.

Can we use internal testers instead of an external red team?

Internal red team testers are allowed only in exceptional circumstances, with the test manager's approval, and they must meet the same experience and reference standards as external testers. The threat intelligence provider must always be external. Significant credit institutions under DORA may not use internal testers at all, so check your classification before planning around them. If an external provider misses a minimum in exceptional circumstances, the entity must adopt and evidence mitigating measures, and the deviation is recorded in the test attestation. Ask your authority early whether an exception would be considered, because a late request can delay the launch meeting.

How DeployOpen works on this

DeployOpen works on the readiness and evidence side of choosing TIBER-EU threat intelligence and red team providers. We help the entity prepare the systems, controls and records that the control team and test manager need to review provider selection, while the entity keeps ownership of every procurement decision and DeployOpen does not issue any attestation.

How we scope

Engagements are fixed-scope, with the provider-selection support, deliverables and timelines agreed in writing before work starts.
We confirm which procurement evidence the control team must hand to the test manager, such as certifications, CVs and insurance copies.
We agree which provider minimum requirements the entity must document, including any deviation and the mitigating measures it would need to evidence.

How we build

We build a provider evaluation file that records experience, reference, certification and insurance checks against the stated minimums.
We prepare a conflict of interest and staff separation register so the control team can show that threat intelligence and red team staff are kept apart.
We set up a contract checklist covering confidentiality, indemnification, data destruction, breach notification and prohibited activities for review by the entity's legal team.

How we hand over

We deliver the provider evaluation file, conflict register and contract checklist in a format the control team can give directly to the test manager.
We document the reasoning behind each selection so the entity can explain its choices to the test manager and, later, to the independent attestation process.
We hand over working procedures and templates so internal staff can maintain the procurement records for future test cycles.

How we support

Ongoing support, upgrades and continuous testing are available as retainers for entities that need help between test cycles.
We can review updated provider evidence, such as renewed certifications or new CVs, when a test is delayed or a provider changes.
We confirm with the entity and its test manager which questions the procurement guidance expects, so the file answers them directly.