TIBER-EU threat intelligence and red team procurement

How TIBER-EU procurement decides who can touch your live systems

Procurement must be complete before the testing phase starts, and the launch meeting that onboards the providers takes place no later than six months after the authority's written notification. The threat intelligence provider must always be external, and external red team testers are strongly encouraged. Internal testers are allowed only in exceptional circumstances, with the test manager's prior approval, and they must meet the same standards. Testers employed by an ICT intra-group provider count as internal, so an entity cannot treat a group affiliate as a shortcut around the external requirement without that approval. The risk this step controls is simple to state: unqualified or poorly contracted testers would be attacking live production systems, with access to the flags the entity has agreed to protect. A weak supplier can cause outages, expose data or leak results long after the test ends.

Procurement is often the slowest part of preparation because the control team must document its own assessment of each candidate and hand the evidence to the test manager, who then decides whether the provider is compliant. The control team may not contract any provider the test manager assesses as non-compliant. The minimum requirements are set in the TIBER-EU Guidance for Service Provider Procurement, which requires threat intelligence providers to supply at least three references and a team led by a manager with at least five years of threat intelligence experience. Red team providers must supply at least five references and a red team test manager with at least five years of penetration and red team testing experience, plus at least two testers with at least two years each. Confirm these figures against the current guidance before you issue a request for proposal, and check whether your national implementation adds anything.

Which providers and testers fall under the procurement rules

The procurement rules apply to every external party that supplies threat intelligence or red team testing, and to any tester who works on the test without being employed by the tested entity. The cards below separate the threat intelligence provider, the red team provider, the narrow internal tester exception and intra-group providers, because each one changes who approves the choice and what evidence the control team must produce.

The threat intelligence provider

The threat intelligence provider must always be external. It builds the targeted threat intelligence report that drives scenario selection, so the control team cannot fill this role with its own staff. Before contracting, the control team documents its assessment of each candidate's compliance and gives that evidence to the test manager. Check that the provider is outside the tested entity's reporting lines and that its team meets the experience requirements for a manager and at least one further member.

The external red team provider

External red team testers are strongly encouraged, and the framework's default is a provider outside the entity. The provider must supply references and field a red team test manager and testers with the required penetration testing experience. Ask for named individuals and their CVs during procurement, because the test manager assesses people, not only the firm. Any shortfall must be recorded, since a provider that is assessed as non-compliant cannot be contracted.

The internal tester exception

Internal testers may be used only in exceptional circumstances, and only with the test manager's prior approval. Those testers must meet the same standards as external testers, so the control team needs the same evidence on their experience and references. Ask the control team to document why an external provider is not feasible before requesting approval. Treat this route as a request that needs its own file, not a shortcut for cost or convenience.

Testers from ICT intra-group providers

Testers employed by an ICT intra-group provider count as internal, even though they sit in a separate legal entity. An entity that buys testing from its own group company should not assume the group relationship lightens the rules. The same prior approval, standards and evidence apply, and the control team should confirm the group provider's staffing and experience in writing. Check the intra-group arrangement against the exception before the test manager is asked to decide.

How internal testing changes the file

Internal testers shift the work from market selection to approval and proof. The control team must document the exception, obtain the test manager's approval, and gather the same reference and experience evidence it would collect from an external firm. Because the test manager can challenge the case at any point, the file should be complete before testing starts. Ask the control team to list each internal tester's qualifications so the attestation can record how the exception was handled.

How the test manager checks provider compliance

This table sets out each element of the control team's compliance file, what the test manager checks against it, and the evidence to request. Read it as a sequence: a provider that fails one requirement cannot be contracted unless a documented mitigating measure is accepted, and that exception is recorded in the attestation.

Review item	What the test manager checks	Evidence to request	Common finding
Threat intelligence references	At least three references from comparable engagements for the threat intelligence provider	Named references the control team has contacted, with the date and summary of each reference check	References listed but never checked, or checks not documented
Threat intelligence team experience	A manager with at least five years of threat intelligence experience and at least one more member with at least two years	CVs or experience summaries showing role, years and relevant work for each named individual	Experience described in general terms without years, or staff named who are not assigned to the test
Red team references	At least five references from comparable red team engagements	Reference list with completed reference checks and notes on scope comparability	Fewer than five references, or references that cover only testing rather than red team work
Red team team experience	A red team test manager with at least five years of penetration and red team experience, and at least two testers with at least two years each	Individual experience records tied to the staff who will deliver the test, plus confirmation of assignment	Senior staff named in the bid while junior testers deliver the work
Contract security and confidentiality	Security and confidentiality standards at least as strict as the entity's, with indemnification, data destruction and breach notification	Signed or draft contract clauses mapped to each requirement	Entity's own standards not matched, or no data destruction or breach notification clause
Contract prohibitions	Clauses that bar unauthorised equipment destruction, disruption of critical functions, testing of out-of-scope systems, unauthorised disclosure and threats or bribery of employees	Contract text showing each prohibition as an explicit term	Prohibitions covered only by general acceptable-use language
Internal testers	Whether any tester is internal, including testers from an ICT intra-group provider, and whether the test manager gave prior approval	Written request for exception, the test manager's prior approval and proof that internal testers meet the same standards	Internal testers used without prior approval or treated as outside the rules because they belong to a group company
Documented mitigating measures	Exceptional use of a provider that misses some requirements, only with documented measures that the test manager accepts	Gap list, mitigating measures, the test manager's written acceptance and the text carried into the attestation	Non-compliant provider used with no mitigating measures recorded, or measures not carried into the attestation

Steps to complete procurement before testing starts

Procurement runs in a fixed sequence: the control team defines the minimum profiles, checks each provider against the TIBER-EU requirements, documents the result and gets the test manager's sign-off before any provider joins the test. The sequence ends at the launch meeting, which must take place no later than six months after the authority's written notification, and procurement must be complete before the testing phase starts.

Define minimum team profiles for each provider
The control team sets out what the threat intelligence provider and the red team provider must field before it approaches the market. For the threat intelligence provider, this means a manager with at least five years of threat intelligence experience and at least one more member with at least two years. For the red team provider, it means a red team test manager with at least five years of penetration and red team testing experience and at least two testers with at least two years each. The step closes when these profiles are written into the procurement file and the control team has agreed them internally.
Request references and team CVs from bidders
Each candidate provider is asked in writing for its references and for CVs of the named team members. The framework requires at least three references from the threat intelligence provider and at least five from the red team provider. The control team checks that the CVs match the profiles defined in the previous step, including the years of relevant experience. The step is complete when the control team holds a complete response file for every bidder, with gaps listed and followed up.
Assess each provider against the requirements
The control team reviews each bidder's references, team composition and experience against the TIBER-EU guidance for service provider procurement. It checks whether the named individuals are actually available for the test, and whether the provider can meet the security and confidentiality expectations that will later appear in the contract. Where a provider misses a requirement, the team records which requirement is missed and whether any mitigating measure is proposed. The step closes with a compliance rating for each provider.
Document the assessment for the test manager
The control team writes up its assessment of each provider's compliance, citing the evidence it reviewed for each requirement. This document, together with the supporting evidence, is what the test manager receives. Providers assessed as non-compliant cannot be contracted. A provider that misses some requirements can be used only in exceptional cases with documented mitigating measures, and those measures are recorded later in the attestation. The step is done when the evidence package is complete and dated.
Agree contract clauses with each provider
The control team negotiates the contract with each selected provider. Clauses should require security and confidentiality standards at least as strict as the entity's own, indemnification, data destruction at the end of the engagement and breach notification. The contract should also prohibit unauthorized destruction of equipment, compromising the continuity of critical functions, testing out-of-scope systems, unauthorized disclosure of results, and threatening or bribing employees. Legal and procurement teams typically review the wording. The step is complete when the signed contract includes all of these terms.
Obtain the test manager's sign-off
The control team presents the documented assessments and the draft contracts to the test manager at the authority. The test manager confirms that each provider is compliant, or accepts a documented mitigating measure where one applies. No provider should be contracted or begin work before this approval is recorded. The step closes with a written sign-off for each provider held in the test file.
Complete internal tester approval if applicable
If the entity proposes internal red team testers, the case must be made in advance. Internal testers are permitted only in exceptional circumstances, with the test manager's prior approval, and they must meet the same standards as external testers. Testers employed by an ICT intra-group provider count as internal. The control team should record the justification and the evidence of the testers' qualifications before the test manager decides. The step is done when the decision is written down, whether approval is given or refused.
Onboard providers at the launch meeting
Once procurement is complete, the providers are onboarded at the launch meeting, which must take place no later than six months after the written notification. Procurement must be finished before the testing phase starts, so any provider not yet contracted at this point delays the test. The meeting confirms each provider's role, the contact points and the handling of the test. The step is complete when the attendance and onboarding confirmations are recorded and the testing phase can begin.

Minimum team and reference requirements by provider type

The threat intelligence provider produces the targeted threat intelligence report that shapes the scenarios used in the test, so its experience must be demonstrable. Under the TIBER-EU Guidance for Service Provider Procurement (January 2025), the provider must give at least three references. Its team must include a manager with at least five years of threat intelligence experience and at least one further member with at least two years of the same experience. The provider must always be external, so these requirements apply to a third party, not to the entity's own analysts.

References: At least three references, ideally from comparable financial or critical entities, with contact details the control team can actually use.
Team manager: A named manager with at least five years of threat intelligence experience, documented in a CV or role history.
Additional member: At least one further team member with at least two years of threat intelligence experience.
Independence: Confirmation that the provider is external and has no conflict with the entity or its other suppliers.
Certificates and training: Any certifications the provider claims should be checked against the issuing body's public records rather than accepted as stated.

The control team should confirm each reference by calling the referee, checking the years of experience against employment records or signed statements, and documenting the results in the evidence pack given to the test manager.

Evidence the control team gives the test manager

Before testing starts, the control team assembles one evidence file for each provider and hands it to the test manager. The cards below cover what goes into that file, how it stays current, and what the test manager checks before approving the providers.

Documented compliance assessment per provider

The control team writes its own assessment of each threat intelligence provider and each red team provider against the TIBER-EU minimum requirements. The assessment should map each requirement to the evidence that supports it and record who reviewed it and when. A provider the test manager assesses as non-compliant cannot be contracted, so this document is the starting point for every later decision. Ask whether the assessment names the specific requirement met or missed, not only an overall pass.

References and verification notes

Each threat intelligence provider must supply at least three references, and each red team provider at least five. The control team should contact referees directly, confirm the engagement was of comparable scope, and record the date and outcome of each call. Notes should state what was verified and what could not be checked, such as references bound by confidentiality. Vague notes that only copy the provider's own claims weaken the file.

Staff experience records

The file should show, for each named team member, the role, years of relevant experience and the basis for that figure. The threat intelligence team needs a manager with at least five years of threat intelligence experience and one more member with at least two years. The red team needs a test manager with at least five years of penetration and red team testing, and at least two testers with at least two years each. Confirm that the named people are the ones who will actually work on the test, since substitution after contracting is a common gap.

Signed contracts with required clauses

The file holds the signed contract for each provider, checked against the clause list in the TIBER-EU procurement guidance. Security and confidentiality terms must be at least as strict as the entity's own, and the contract must cover indemnification, data destruction and breach notification. It must also prohibit actions such as testing out-of-scope systems, unauthorized disclosure of results, and threatening or bribing employees. The control team should record which clause covers each item so the test manager can find it quickly.

Documented mitigating measures

If a provider misses some requirements, the framework allows its use only in exceptional cases with documented mitigating measures. Each measure should name the gap, the control that offsets it, the person accountable for it and how it will be monitored during testing. These measures are recorded in the attestation, so they must be specific and dated. Treat an undocumented exception as a procurement failure rather than a judgment call made later.

Currency and test manager review

The control team should date every document, record each change, and update the file before any provider joins the launch meeting, which must take place no later than six months after the written notification. The test manager reviews the complete file, questions any weak assessment, and confirms in writing that procurement is complete before testing begins. Ask whether your file has a named owner who refreshes references and staff records if a provider's team changes during the contract.

Which contract clauses TIBER-EU expects in provider agreements

The TIBER-EU Guidance for Service Provider Procurement sets out the clauses a tested entity should put into its agreements with the threat intelligence provider and the red team testers. The first requirement is security and confidentiality standards at least as strict as the entity's own. Your contract should bind each provider to handling of test data, credentials, flags and results to the level your organization applies to its own most sensitive material, not to a generic supplier baseline. Alongside that, expect clauses on indemnification, on data destruction at the end of the engagement, and on breach notification with a defined timeline. Confirm the exact notification window and destruction method with your counsel and the test manager, because the guidance describes what the contract should cover rather than fixed wording.

The guidance also lists activities the contract should prohibit. These are unauthorized destruction of equipment, actions that compromise the continuity of critical functions, testing of systems outside the approved scope, unauthorized disclosure of results, and threatening or bribing employees. Each prohibition should map to something the control team can verify during the test. For example, the scope specification document defines which systems and flags are in bounds, so an out-of-scope clause only works if the provider's contract refers to that approved document and the control team can show the test manager where the boundary sat. Treat the prohibitions as the minimum list and review them against your own risk assessment.

Counsel should draft and review all wording, including how indemnification interacts with your existing supplier terms, liability caps and the governing law of each provider. Ask counsel to confirm that the agreement reflects the mandatory requirements of your jurisdiction's TIBER-EU implementation document, since national authorities may add rules. Before signature, check that each clause is reflected in the provider's written evidence to the control team, so that the contract, the compliance assessment and the attestation tell the same story.

What procurement costs in money and internal effort

This table separates the money paid to outside parties from the internal effort the control team and test manager spend on procurement. Read the one-time and recurring columns to see which items recur across a test cycle, and use the drivers column to see which choices move cost up. No fees or durations are stated here because none are supplied for this topic, so the last column lists what to request in a written quote.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up and what to request in a quote
Threat intelligence provider fees	External threat intelligence provider, which must be external under TIBER-EU	One-time per test	Team composition and reference checks. Request a fee breakdown by team member role, the minimum team stated in the guidance, and what is included in the targeted threat intelligence report.
Red team provider fees	External red team provider, strongly encouraged over internal testers	One-time per test	Size of the red team and the length of active testing. Request a quote tied to the written scope, including the test manager role, testers and any reporting or replay work.
Control team assessment time	Internal control team of the tested entity	One-time per test	Number of providers and depth of evidence review. Ask the provider to supply compliance evidence in a standard format so the team does not rebuild it for each candidate.
Reference checks	Internal control team, sometimes with the test manager	One-time per test	Number of references checked. The guidance requires at least three references from the threat intelligence provider and at least five from the red team provider, so each extra check adds effort.
Legal review of contract clauses	Internal legal and procurement staff, and outside counsel if used	One-time per contract	Number of exceptions to the standard clauses on security, confidentiality, indemnification, data destruction and breach notification. Ask providers to state in advance which clauses they will not accept.
Test manager review time	Test manager at the authority, reviewing the control team's evidence	One-time per provider	Number of providers assessed as compliant with documented mitigating measures. Each exception needs review and must be recorded in the attestation, so confirm the test manager's review process before procurement starts.
Mitigating measures for partial compliance	Internal control team and provider	One-time per exception	Count of exceptional cases. Each must be documented, so ask providers for a written plan that lists each missed requirement and the measure that offsets it.
Internal tester costs (exceptional use only)	Internal staff used as red team testers	Recurring within the test	Only allowed with the test manager's prior approval. Internal testers must meet the same standards, and intra-group provider staff count as internal, so confirm approval and skills before using them.
Replacement procurement if a provider is rejected	Internal control team and the candidate provider	One-time, repeated if needed	Rejection of a provider the test manager assesses as non-compliant means restarting part of procurement. Verify requirements against the guidance before shortlisting to avoid repeat cycles.

Where procurement usually stalls and how to close each gap

Procurement sits between notification and the start of testing, so delays and weak paperwork here push the whole test back. The gaps below recur across tests, and each one has a concrete fix that the control team can document before the launch meeting.

Starting procurement too late

Procurement must be complete before the testing phase starts, and the launch meeting that onboards the providers must take place no later than six months after the written notification. Teams that wait for scoping to finish before opening provider discussions often run out of room. Build a dated procurement plan at initiation that works backward from the launch meeting, and assign an owner to each provider milestone, including contract signature and the compliance file handover to the test manager.

Accepting unverified references

The threat intelligence provider must give at least three references, and the red team provider at least five. A reference list is only a claim until someone checks it. Ask each reference for a written confirmation of scope and client type, and verify that the work was delivered by the people proposed for this test. Record the check in the control team's compliance assessment so the test manager can see what was confirmed and how.

Undocumented internal tester approvals

Internal testers may be used only in exceptional circumstances, and only with the test manager's prior approval. Approval given by email after testing has begun, or verbal agreement with a team lead, will not satisfy an assessor. Record the justification, the test manager's written approval date, and proof that the internal testers meet the same experience standards as external testers before any testing activity starts.

Intra-group testers treated as external

Testers employed by an ICT intra-group provider count as internal. A group company that sells testing services to a sister entity can therefore look external on paper but fall under the internal approval rules. Check the employing entity for every tester on the proposed team, not only the company named on the invoice, and route any intra-group staff through the same prior approval and documentation as internal testers.

Weak contract clauses

Contracts should require security and confidentiality standards at least as strict as the entity's own, along with indemnification, data destruction and breach notification. They should also prohibit unauthorized destruction of equipment, compromising critical functions, testing out-of-scope systems, unauthorized disclosure of results, and threatening or bribing employees. Have legal counsel map each prohibited activity to a specific clause, and confirm that data destruction terms cover test artifacts held by subcontractors.

Providers that fail the compliance assessment

The control team must not contract a provider the test manager assesses as non-compliant. Where a provider misses some requirements, an exceptional use is possible only with documented mitigating measures, and those measures are recorded in the attestation. Start the assessment early enough that a failed provider can be replaced without moving the launch meeting, and treat any mitigating measure as a visible item for the test manager to accept in writing.

Who does what: your team, a partner, and the authority

Your control team and legal function own the procurement decision. The control team assesses each threat intelligence provider and red team candidate against the TIBER-EU requirements, documents that assessment, and gives the evidence to the test manager. Legal and procurement negotiate the contracts and sign them, because the entity carries the liability for what the providers do in its live production environment.

Assessment record: The control team documents its compliance review of each provider and keeps the evidence on file for the test manager.
Go or no-go decisions: The control team must not contract any provider the test manager assesses as non-compliant.
Contract clauses: Legal ensures security and confidentiality standards are at least as strict as the entity's own, with indemnification, data destruction and breach notification terms.
Prohibited activities: Contracts should bar unauthorised destruction of equipment, testing of out-of-scope systems, unauthorised disclosure of results, and threatening or bribing employees.
Internal testers: Any internal tester use needs the test manager's prior approval and must meet the same standards as external testers.

Confirm internally who holds signing authority and how long your procurement cycle takes, so the completed procurement lands before the testing phase begins.

Questions buyers ask about TIBER-EU provider procurement

Can we use our own staff as red team testers under TIBER-EU?

Only in exceptional circumstances. The threat intelligence provider must always be external, and external red team testers are strongly encouraged. Internal testers need the test manager's prior approval, and they must meet the same standards as external testers. Testers employed by an ICT intra-group provider count as internal, so a group affiliate's staff do not avoid this rule. Confirm early with the test manager whether your team qualifies, because the approval must be in place before you rely on it. Your own staff also cannot provide the threat intelligence, so that work still goes to an external firm.

How many references must a red team provider give?

Under the TIBER-EU Guidance for Service Provider Procurement (January 2025), a red team provider gives at least five references. Its red team test manager needs at least five years of penetration and red team testing experience, and the provider must field at least two testers with at least two years each. A threat intelligence provider gives at least three references, with a team manager who has at least five years of threat intelligence experience and at least one more member with at least two years. Ask each provider for references that match financial sector, live production and TIBER-EU or DORA work, and check that the named individuals are the people who will actually run the test.

What happens if a provider does not meet every requirement?

The control team must not contract a provider that the test manager assesses as non-compliant. The control team documents its assessment of each provider and gives the evidence to the test manager. In exceptional cases, a provider that misses some requirements can be used, but only with documented mitigating measures. Those measures are recorded in the attestation, so the authority and any later reviewer will see them. Plan for this before the shortlist is final, because a gap found late can delay the start of testing.

What is the deadline for completing procurement?

Procurement must be completed before the testing phase starts. The launch meeting that onboards the providers must take place no later than six months after the authority's written notification. Those six months cover the whole preparation phase, including initiation, scoping and the control team's risk management, so procurement competes for time with those steps. Work backward from the launch meeting date and agree the provider timetable with your test manager early. Contract signature, evidence review and any mitigating measures all need to fit inside that window.

How much time will procurement take from our team?

The main load falls on the control team, which assesses each provider, documents that assessment and passes the evidence to the test manager. Staff time also goes into reviewing provider references, agreeing contract terms with legal and procurement, and checking the security and confidentiality standards of each firm against your own. The framework does not set a number of days or hours for this work, so ask your test manager and prospective providers for their own timetables. Your effort will grow if references are weak, if providers need to remediate gaps, or if the contract needs several rounds of legal review.

Can we run provider procurement ourselves, or do we need a partner?

You can run procurement yourselves. The control team owns the assessment and the decision, and the contract is between your organization and each provider. A partner can help prepare the evidence file, check provider claims against the requirements, and draft contract clauses for legal review, but it cannot select providers on your behalf or certify their compliance. DeployOpen prepares systems, controls and evidence for assessments and does not issue reports or attestations. Work out which steps your team can absorb, and scope any outside help in writing before work starts, since most engagements are fixed-scope.

What should we ask a red team firm for in a quote?

Ask for a quote built from a written scope that lists the red team test manager, the named testers, their years of experience and the references you can check. Request a breakdown of what each person does, which phases are included, how the provider handles reporting and the red team test plan, and what is excluded. Confirm that the contract includes security and confidentiality standards at least as strict as yours, indemnification, data destruction, breach notification, and prohibitions on destroying equipment, compromising critical functions, testing out-of-scope systems, disclosing results without authorization, and threatening or bribing employees. Ask how the quote changes if the test runs longer or the scope grows.

How DeployOpen supports TIBER-EU provider procurement

DeployOpen helps regulated entities prepare the procurement file the control team needs before the test manager can approve threat intelligence and red team providers. We work under a written, fixed scope and prepare documentation and evidence, while the authority, the control team and the providers keep their own roles, and only independent parties issue reports or attestations.

How we scope

The written scope fixes which provider evidence, control team documents and contract clauses we prepare.
We agree the list of documents against the Guidance for Service Provider Procurement before work starts.
Scope also records who decides: the control team owns the assessment, and the test manager keeps the approval.

How we build

We help the control team set up a provider assessment record for each threat intelligence and red team bidder.
We map reference requirements and team experience thresholds to a checklist the control team can evidence.
We draft contract clause checklists covering confidentiality, indemnification, data destruction, breach notification and prohibited activities for your counsel to review.

How we hand over

Handover includes a procurement evidence pack the test manager can review before the testing phase starts.
Internal tester files, where an exception is requested, are documented against the same standards and approval record.
Each document is delivered as an editable file the control team owns after handover.

How we support

Ongoing support after handover is available as a retainer, scoped in writing.
We can help update the evidence pack when providers change, or when the test timeline moves.
Questions about who may serve as provider, including intra-group testers, go to the test manager and your counsel.