TIBER-EU control team and risk management

How does a TIBER-EU control team keep a live red team test safe?

A TIBER-EU red team test runs against live production systems, so the control team is the entity's safety mechanism. It conducts and documents a risk assessment before and during testing, checks that backup and restoration are in place for every in-scope system, sets confidentiality and escalation rules, and holds the power to halt the test. The entity remains ultimately responsible for the red team test and its risks, even though the external threat intelligence provider and red team testers carry out the attacks. That is why the control team, not the provider, owns the decisions that keep the test from becoming an incident.

The risks the control team plans for are specific. Testers may reach confidential data, so the control team must decide what access is acceptable and how it is monitored. Attacks may disrupt critical activities, so the team must know which functions cannot tolerate interruption and when to stop. Systems may not be fully restored after a test, so backup verification is needed before any testing starts. Before testing, the control team should confirm with its test manager that each risk is covered, and it should record the reasoning so an assessor can later see how decisions were made.

The hard part is balance. Awareness of the test must stay with a small, trusted group on a need-to-know basis, yet the blue team must not be given advance knowledge that makes the test meaningless. Escalation procedures have to stop mandatory real-incident actions, such as contacting a CSIRT, an information sharing platform or law enforcement, or contain them, without hiding a genuine incident. Entities should confirm with their test manager exactly which notifications are suppressed, who may trigger a halt, and how the agreed code name is used so that every stakeholder can speak about the test without revealing its target.

Which parties, systems and decisions does the control team cover?

The control team sits at the center of a live-production TIBER-EU test, and its work touches several parties at once. Each card below names one party or decision area, what it means for the control team's risk assessment, and what to check before testing starts.

The entity's own control team

The tested entity owns the red team test and its risks, so the control team must be set up and documented before anything runs. It conducts and records a risk assessment before and during the test, and it consults the test manager before testing begins. Check that the team has named members, a documented mandate and a clear line to the management body.

The blue team kept unaware

The blue team defends the systems under test without knowing a test is underway, so awareness is limited to a small, trusted group on a need-to-know basis. The control team must decide who is told and what is withheld, and it must keep that list current. Check that the list is written down and that detection and response results can be interpreted without exposing the test.

In-scope systems and flags

The control team must know which systems sit behind each critical or important function and each flag. Before testing, it should confirm that backup and restoration capabilities exist for those systems. Risks to watch include disruption of critical activities and incomplete restoration after a test, so each system needs a documented owner and recovery path.

Test manager and TIBER Cyber Team

Each test has a dedicated test manager and at least one alternate from the TIBER Cyber Team. The framework strongly encourages that TIBER Cyber Team members are not involved in the test in a supervisory or oversight capacity. The control team should confirm who the test manager is, how they are consulted, and how they receive risk assessment updates.

Threat intelligence provider and red team testers

The external threat intelligence provider and red team testers handle confidential data and attack live systems. The control team must assess provider access to confidential information and check that escalation procedures cover what testers may trigger. Ask how the same provider and testers are used for the whole test and how any change would be assessed.

Multi-party arrangements

In a multi-party test, each entity's control team conducts its own risk assessment. The lead entity's control team assesses the joint aspects, such as shared providers, shared testers and shared escalation paths. Confirm in writing which risks each control team owns and how the lead entity receives the others' assessments.

How does an assessor test the control team and its risk management?

This table compares each control team duty with how an assessor checks the documents and records behind it, and where tested entities usually fall short. Read it as a pre-test checklist: each row is a record you should be able to produce before a live-production test starts and keep updating while it runs.

Area	How the assessor tests it	Evidence requested	Common findings
Documented risk assessment	Reviews the assessment dated before testing starts and checks that it was refreshed during testing as conditions changed	Dated risk assessment, risk register entries, change log showing in-test updates and sign-off by the control team	Assessment written once at the start and never updated; risks such as provider access to confidential data left out
Consultation with the test manager	Confirms the control team raised its assessment with the test manager before testing began and recorded the outcome	Meeting minutes, correspondence with the test manager, and a record of agreed changes to the plan	No recorded consultation, or concerns raised after testing had already started
Backup and restoration due diligence	Checks that each in-scope system was reviewed for backup and restore capability before any testing	Backup inventory per in-scope system, restore test results, and verification reports from the backup tooling	Backups assumed to work without a test restore; systems with incomplete restoration paths not identified
Need-to-know awareness	Confirms the group aware of the test is small, named and limited to what each member needs	Access list of the trusted group, awareness acknowledgments and records of any later additions	Awareness spread to teams with no operational role, or the list was never maintained
Escalation procedures	Walks through how a real incident would be handled and checks which mandatory actions are suppressed or contained during the test	Written escalation procedure, mapping of CSIRT, information sharing and law enforcement steps, and containment rules	Procedure copied from the incident plan with no test-specific handling, so reporting obligations are triggered unintentionally
Agreed code name	Checks that all stakeholder documents and communications use the agreed code name instead of the entity name	Code name approval record and a sample of documents, tickets and messages reviewed for naming	Entity name appearing in tickets, provider communications or shared drives
Halt authority	Verifies who may order a temporary or complete halt, the criteria that trigger it, and whether the process was usable in practice	Written halt procedure, named decision holders, contact paths and any halt records or rehearsals	Halt rights unclear or resting on people unreachable during testing windows
Test manager oversight	Confirms the test manager and alternate received the control team's reports and reviewed decisions made during testing	Reporting cadence records, decision logs and the test manager's written feedback	Oversight limited to a single status meeting, with no record of challenges or decisions

What steps set up the control team and its risk assessment before testing starts?

The control team is built, briefed and equipped before any red team activity touches live production, so that the tested entity holds a documented risk position, a tested recovery path and an agreed way to stop the test.

Appoint the control team members
The tested entity names a small control team with the authority to make decisions about live systems, and limits awareness of the test to this trusted group on a need-to-know basis. Each member should be able to speak for the systems, escalation paths and business functions in scope. The output is a named list of control team members with their roles, kept under confidentiality controls and reviewed as the test approaches.
Carry out the pre-test risk assessment
The control team conducts and documents a risk assessment before testing starts. It should cover provider access to confidential data, incident escalation, disruption of critical activities and the possibility that systems are not fully restored. Because the entity remains responsible for the red team test and its risks, this assessment is the entity's own work, not the provider's. The output is a dated risk assessment document that the control team signs off.
Verify backup and restoration for in-scope systems
Before any testing, the entity checks that every in-scope system has backup and restoration capability in place. This means confirming what is backed up, where the copies live, and whether a restore has been exercised rather than assumed. Open-source tools such as Bareos can schedule, verify and restore backup jobs, and restic's check command can confirm that stored data is structurally sound and, with read-data options, that pack files are unmodified. The output is a restore record showing which systems were restored, when and with what result.
Design the escalation procedure
The control team defines how the entity responds to events it may see during the test. Actions that a real incident would trigger, such as contacting a CSIRT, an information sharing platform or law enforcement, must either not fire or be contained so that the test does not create a false incident. The procedure should name who decides, who is told and what is paused. The output is a written escalation procedure that the control team has reviewed against the risk assessment.
Agree the code name and confidentiality rules
The control team agrees a code name that all stakeholders, including the threat intelligence provider and red team testers, use in place of the tested entity's name. It also sets confidentiality rules for test information, including who may hold the scope, the flags and the provider's findings. The output is a short written record of the agreed code name and the confidentiality rules, acknowledged by the parties that receive them.
Consult the test manager before testing starts
The control team consults the dedicated test manager from the TIBER Cyber Team before testing begins. The test manager, who has sector, cyber and project management experience, reviews the risk assessment, backup evidence, escalation procedure and code name arrangements. The control team records the points raised and how each was resolved. The output is a consultation record that the control team holds alongside the risk assessment.
Document the halt procedure and authority
The control team confirms in writing that it may order a temporary or complete halt of the test at any time if it has concerns about damage to a system. The procedure states who can give the instruction, how it reaches the provider and testers, and how testing resumes or closes. The output is a signed halt procedure, distributed to every party with an active role, so that the stop mechanism is known before the first test action.

Which evidence shows the control team and risk management work?

A TIBER-EU test runs on live production systems, so the control team has to prove it managed the risk at each stage. The six artifacts below form one record: they show what was decided before testing, what happened during it, and how the entity could stop it. Because the framework treats intervals of three years between tests as the norm, each record needs a process for refreshing it before the next test starts.

Dated pre-test risk assessment

This is the control team's written assessment of risks before testing starts, produced before the test manager is consulted. It should cover provider access to confidential data, incident escalation, disruption of critical activities and incomplete restoration of systems, with an owner and date for each risk. Check that it names the in-scope systems and the mitigation for each risk, since an assessment that stays generic cannot show the control team understood the test. Review it again whenever the scope or threat intelligence changes.

In-test risk log

The risk log records each risk raised, decided and closed while the red team is active, with timestamps and the decision maker. It proves the control team kept assessing risk during the test rather than only at the start. Keep entries factual, such as which system was affected, what action was taken and whether the test manager was informed. Ask your team to confirm how the log is stored so that it stays accessible after the test ends.

Backup and restoration due diligence records

These records show that backup and restoration capabilities were confirmed for each in-scope system before any testing. They should include the backup job, the most recent successful restore test and the restoration time the team verified. Open-source tools such as Bareos and restic can generate job logs and integrity check output that support these records, but the control team must confirm that restores were actually tested, not just scheduled. Repeat the checks before each test, because backup configurations drift over a three-year interval.

Awareness list and need-to-know rationale

This list names each person who knows the test is running, their role and the reason they need to know. It shows that awareness was limited to a small, trusted group, which keeps the red team's activity realistic for the blue team without exposing the test to unnecessary staff. Record who was removed from the list when they left the project. Review it before each test, since staff turnover and new vendors change who should be included.

Escalation procedure and containment rules

This document sets out which real-incident actions are contained during the test, such as contacting a CSIRT, an information sharing platform or law enforcement, and who authorizes each containment. Evidence includes the agreed escalation paths, the code name used for the tested entity and any tabletop or dry-run results. Confirm that the procedure was reviewed with the people who would handle a real incident, because a containment rule that only exists on paper can trigger a real external notification. Update it after every incident response change.

Halt decision record

This record documents any temporary or complete halt the control team ordered, including the concern raised, the system affected, who decided and when testing resumed or ended. Even if no halt happened, the record should state that the power was available and who held it. An assessor will look for a clear chain from concern to decision. Keep the halt procedure and contact list current between tests, and confirm that the people with halt authority are still in post.

Who does what: the entity, an implementation partner and the authority's test manager?

The tested entity is ultimately responsible for the red team test and its risks. Its control team conducts and documents the risk assessment before and during testing, and it is the only party that can order a temporary or complete halt. The entity also decides who knows about the test, keeps awareness to a small, trusted group on a need-to-know basis, and defines the escalation procedures that stop real-incident actions from firing during the exercise.

Risk ownership: The board-level accountability for the test sits with the entity, even when a partner drafts the risk register.
Halt authority: The control team holds the power to stop the test if a system is at risk, and this decision cannot be delegated to a supplier.
Escalation design: The control team decides how CSIRT contacts, information sharing platforms and law enforcement contacts are contained during the test.
Confidentiality: The entity controls who receives the agreed code name and who sees test traffic and findings.
Backup due diligence: The entity confirms that in-scope systems can be backed up and restored before any testing starts.

Confirm with your authority which staff must sit on the control team, and whether your national document adds requirements for who holds the halt decision.

How can self-hosted open-source backup tools support pre-test restoration checks?

Before a live-production TIBER-EU test starts, the control team needs proof that every in-scope system can be restored, not an assumption that backups exist. The framework expects the entity to carry out due diligence on in-scope systems before any testing so that backup and restoration capabilities are in place. In practice, the control team should record which systems are in scope, where their backups live, when each backup last completed, and whether a test restore has succeeded on a recent copy. A red team that degrades or corrupts a system is only survivable if the entity can bring it back, so this evidence belongs in the pre-test risk assessment, and the test manager should see it before testing begins.

Self-hosted backup software can produce much of that evidence inside the entity's own infrastructure. Bareos is a client-server backup system whose Director schedules and supervises backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files, so the control team can query what exists and restore files from the current backup or from one taken before a given date and time. Restic takes a different approach: restic check verifies the structural consistency of snapshots, trees and pack files, and adding --read-data or --read-data-subset makes it read pack files back to confirm the stored data is unmodified. Bareos is licensed under AGPL-3.0-only and restic under BSD-2-Clause, so the entity should have its legal team confirm that each license fits how it deploys and modifies the software. Whichever tools are chosen, the control team should confirm that recovery point and recovery time targets for each in-scope system can be met with them, using a timed test restore in a non-production environment.

The control team may also want a register for the risk assessment and the restoration evidence. *CISO Assistant* is an open-source option (AGPL-3.0-only) that ships more than 200 frameworks, including DORA, and can run audits and compliance assessments with automatic mapping between frameworks. It can hold the documented risk assessment, the backup check results and the escalation decisions in one place, which helps when the test manager or an auditor asks for them. It is optional, and a spreadsheet or ticketing system can serve the same purpose. Whichever register is used, the control team should confirm that it can be access-restricted to the trusted group that knows about the test, since the test's existence is itself sensitive.

What does meeting the control team requirement cost in money and effort?

This table lists each cost component of running the control team and risk management work for a TIBER-EU test, who is paid for it, whether it is one-time or recurring, and what moves it up or down. No price or duration is given because none has been supplied for this topic, so use the table to build your own quote request. The main takeaway is that the largest recurring effort sits with your own control team during each test, while tooling costs depend mostly on what you already run.

Cost component	One-time or recurring	What drives it up or down	What to request in a written quote
Control team time (setup)	One-time	Size of the trusted group, number of in-scope systems, and how many staff already hold the needed roles	Named roles, time allocation per role, and who signs off the control team composition
Control team time (during each test)	Recurring per test	Length of active red team testing, frequency of control team check-ins, and the number of flags under test	Estimated hours per week during active testing, and how escalation drills are counted
Risk assessment and documentation	Recurring per test (before and during)	Number of in-scope systems, how many risks are assessed during testing, and the quality of existing risk registers	Document list the provider expects, review cycle, and who writes versus approves each document
Backup due diligence and restoration testing	One-time setup, recurring per test	Age and complexity of backup estate, whether restores have been tested recently, and the number of in-scope systems	Scope of restore tests, evidence format, and whether the provider or your team runs the checks
Tooling and licenses	Recurring (licenses) or one-time (deployment)	Whether backup and compliance tools are already licensed. Self-hosted open-source options such as Bareos (AGPL-3.0-only), restic (BSD-2-Clause) and CISO Assistant (AGPL-3.0-only) remove license fees, but AGPL terms and support contracts still need legal review	Itemized licenses or subscriptions, support tier, and any fees tied to hosting or upgrades
External facilitation or review by an implementation partner	One-time or recurring, depending on engagement	Whether your team needs help preparing systems, evidence and documents, and how many review cycles are planned	Fixed-scope deliverables, written milestones, and what is excluded from scope
Authority involvement	Recurring per test	Number of meetings with the test manager, and the consultation required before testing starts	Confirm with your authority in writing which meetings and reviews are included at no separate charge
Threat intelligence and red team provider involvement	Recurring per test	Provider's team size, the time needed for control team reviews, and how often the provider must access confidential data	Provider's role in risk discussions, data handling terms, and any fees for escalation support

Where do control teams usually fall short, and how do they close the gap?

Most control team weaknesses are not technical. They come from risk paperwork that stops moving, backups that were assumed rather than tested, and informal habits that leak awareness or trigger real incident processes. Each card names one gap and the action that closes it before the red team starts.

Risk assessment written once

The control team often documents its risk assessment during preparation and then leaves it untouched. TIBER-EU expects the assessment to be conducted and documented before and during testing, so new findings, changed systems and provider access questions must be added as the test runs. Close the gap by setting a named owner and a review step at each phase change, and by checking that the file records what was decided and when. Ask to see the dated revision history during the test.

Backups claimed but never restored

Teams often confirm that backup jobs run, but never prove that in-scope systems can be restored. The framework asks entities to carry out due diligence on in-scope systems before testing so that backup and restoration capabilities are in place. Close the gap with a restore test on each in-scope system, recorded with the time taken and the data verified. Tools such as Bareos can restore files from a chosen date, and restic's check command with read-data options can confirm stored data is unmodified.

Awareness spreading beyond need-to-know

Test awareness often grows as colleagues are asked to help with access, infrastructure or approvals. Each extra person who knows about the test weakens the realism of the exercise and increases the chance of leaked scenarios. Keep awareness limited to a small, trusted group on a need-to-know basis, and record who holds each piece of information. Review the list at each phase change and remove anyone whose role has ended.

Escalation rules that trigger real responses

Escalation procedures are sometimes written without checking what they set off. A test that causes a real CSIRT callout, an information sharing alert or a law enforcement notice wastes responder time and creates external records. The control team should map each mandatory incident action to a containment step, such as a pre-agreed hold or a restricted contact list. Confirm the mapping with the incident response lead before testing begins.

Unclear halt authority

When no one is sure who can stop the test, a concern about damage to a system can sit unresolved while the red team keeps working. The control team must be able to order a temporary or complete halt at any time. Close the gap by writing the halt criteria, naming the people who can call a halt, and rehearsing how the order reaches the red team and the test manager. Record the time each halt was requested and lifted.

Inconsistent code name discipline

Stakeholders sometimes slip and use the real organization name in emails, tickets or chat channels, which exposes the test and can leak to outside parties. All stakeholders must refer to the tested entity by the agreed code name. Close the gap by briefing every participant, including providers, and by applying the code name to shared folders, ticket titles and distribution lists. Spot-check these locations during the test and correct any slips in writing.

What do buyers ask about TIBER-EU control teams before hiring help?

How much effort does a TIBER-EU control team need?

The effort depends on the number of flags, the systems behind each flag, and how many parties are in the test. The control team must run its own documented risk assessment before and during testing, consult the test manager before testing starts, and keep escalation, backup and confidentiality arrangements working for as long as the red team is active. The framework does not give a headcount or a number of days, so ask any provider to show you a bottom-up estimate tied to your scope specification document, including how many weeks of active testing the control team must stay on call for. Testing runs for at least 12 weeks, so the effort is continuous, not a single event.

Can we run the TIBER-EU control team in-house?

Yes, the framework assigns the control team to the tested entity, so it can staff the team with its own people. The real question is whether your staff can keep the test invisible to most of the organization while still making live decisions about production systems. Awareness is limited to a small, trusted group on a need-to-know basis, which means the people on the team are often the same people who run the systems under test. Ask yourself whether you can staff that team without disrupting day-to-day operations for several months, and whether your incident response staff can separate a test from a real attack.

What skills does the control team need from senior staff?

Senior staff need authority to make decisions about live production systems, plus enough technical depth to judge the risk of each red team action. The team must cover provider access to confidential data, incident escalation, disruption of critical activities and incomplete restoration of systems. Someone senior should own the risk assessment, and someone should be able to order a temporary or complete halt without waiting for approval. Ask a provider to confirm which of these roles it expects your people to fill, and which it can support through training or advisory work.

How long does control team setup take within the preparation phase?

The framework allows up to six months for the whole preparation phase, starting from the authority's written notification. That phase also covers scoping and procurement of the threat intelligence and red team providers, so control team setup has to fit inside the same window. The initiation meeting is due within three months of notification, and the scope specification document within six months. Ask your provider to show a timeline that places control team appointment, the documented risk assessment and backup due diligence ahead of the testing phase, and to confirm the dates against your authority's own requirements.

Can an outside provider run the TIBER-EU control team for us?

An outside provider can support the control team with preparation, risk assessment drafting, backup checks, escalation design and reporting, but the control team itself belongs to the tested entity. The entity remains ultimately responsible for the red team test and its risks, so accountability for decisions cannot be handed to a third party. Define in writing which tasks the provider performs, which tasks your staff perform, and who signs off each risk decision. Confirm that the provider does not also act as your red team tester or threat intelligence provider, since the framework requires separate roles.

Who has the power to halt a TIBER-EU test?

The control team holds the power to halt the test. It can order a temporary or complete halt at any time if it has concerns about damage to a system. Because the team is inside your organization, you should decide in advance who on the team can give that order, how fast it must be acted on, and how the red team is told. Put the halt procedure in writing before testing starts. An outside provider can advise on the decision but should not be the party that holds the halt authority.

What does the test manager do and what does it not do?

The test manager is assigned by the TIBER Cyber Team at the authority, supported by at least one alternate, and oversees the test on the authority's behalf. The test manager must be consulted before testing begins and provides sector, cyber and project management oversight. The framework strongly encourages that TIBER Cyber Team members are not involved in the test in a supervisory or oversight capacity, which reflects the distinction between regulator and tested party. The test manager does not run your control team, make your risk decisions or prepare your systems. Ask a provider to confirm which of these tasks sit with your team and which with the authority.

What should we ask a provider to confirm before signing a control team engagement?

Ask for a written scope that lists each control team task, the deliverables you will receive, and the people who will do the work. Confirm how the provider documents the risk assessment, how it verifies backup and restoration of in-scope systems before testing, and how it designs escalation procedures so that mandatory incident actions, such as contacting a CSIRT or law enforcement, are not triggered or are contained. Ask who will be on call during active testing and how the engagement ends. DeployOpen plans, implements and documents systems and evidence for this work, and its engagements are fixed-scope and agreed in writing before work starts. It does not issue attestations, and the authority and the attestation process remain separate.

How DeployOpen works on this

DeployOpen plans, implements and documents the self-hosted open-source platforms that a control team relies on during a live-production test, including backup, restore and evidence systems. The control team still owns the risk assessment, escalation procedures and the decision to halt, and DeployOpen prepares the systems and records that support those decisions.

How we scope

Written scope agreed before work starts, listing the in-scope systems the control team must protect during testing
Fixed-scope engagements that name the backup, restore and logging components covered by the work
Clear boundaries stating which control team tasks remain with the tested entity and which DeployOpen will prepare

How we build

Backup jobs and restore points configured for in-scope systems, with the scheduling and catalog settings documented
Restore tests run against the in-scope systems so the control team can confirm recovery before testing begins
Monitoring and alerting set up so the control team can see activity on in-scope systems and act on concerns quickly

How we hand over

Runbooks for backup verification, restoration, escalation contacts and the procedure for ordering a temporary or complete halt
Evidence packs with backup job records, verification output and configuration baselines the control team can file
Handover session where the control team walks through each runbook and records who is authorized to act

How we support

Ongoing support available as a retainer for updates to runbooks, backup configuration and evidence after the test
Changes to in-scope systems tracked so the control team's risk assessment reflects the current environment
Independent assessment remains with the test manager and authority, and DeployOpen does not issue attestations or reports