Cet article est actuellement disponible en anglais. Si vous souhaitez le parcourir avec nous en francais, nous pouvons le faire pendant le cadrage.

TIBER-BE is often described as a red-team exercise. That is true, but it leaves out the part that tends to decide whether the work is valuable: the preparation. A TIBER-style engagement is intelligence-led, controlled, and aimed at critical functions. It involves more governance, white-team coordination, threat intelligence, provider management, and replay work than a normal "let the red team try" exercise.

Formal TIBER-BE has a specific place in Belgium's financial-sector testing landscape. If you are in that scope, the framework and governance matter. If you are not, the label should be used carefully. What is still worth borrowing is the discipline: threat intelligence before action, a capable white team, controlled live testing, clear safety boundaries, and a replay that turns the exercise into decisions.

If an institution treats it like procurement for a technical test, the friction appears quickly. The red-team activity may be the most visible part, but readiness lives in the decisions around it: who can approve actions, what is truly in scope, how risk is controlled, which teams are shielded from information, and how the exercise turns into change afterwards.

Readiness starts before provider selection

The first readiness question is not which red-team provider to choose. It is whether the institution can explain what it wants to learn. Which critical function is the exercise meant to pressure? Which business process, technology dependency, supplier relationship, identity path, or operational habit is being tested? If the answer is vague, the scenario will become vague too.

This matters because TIBER-style work should not be a theatre piece. The threat intelligence should shape a credible path. The red team should test that path under controlled conditions. The replay should help defenders and decision-makers understand what happened. All of that depends on a scope that is meaningful enough to matter and precise enough to govern.

The white team is not an admin detail

A good white team protects the exercise from becoming chaos. It holds the risk picture, manages escalation, keeps the right people informed, protects the confidentiality of the test, and makes judgement calls when activity approaches sensitive systems. That role needs authority, context, and time. It cannot be assembled casually the week before testing starts.

The white team should know how to reach system owners, cloud owners, identity owners, outsourced service contacts, legal stakeholders, crisis leads, and executives if something genuinely sensitive appears. It also needs out-of-band communication paths. If everyone depends on the same monitored channels, the exercise can become awkward for the wrong reasons.

Critical functions need sharper language

"Payments", "customer data", "trading", "operations", or "core banking" may be useful starting words, but they are not yet a testable scope. The team needs to translate them into systems, identities, processes, dependencies, data flows, and operational consequences. What would count as meaningful impact? What would be too risky to touch? Which steps can be simulated rather than executed? Which evidence is needed for the replay?

This is where many readiness discussions become useful. The institution may discover that no single team owns the full path. The business understands the consequence, infrastructure owns part of the stack, security owns monitoring, a supplier owns a key platform, and identity sits somewhere in between. That is exactly the sort of complexity the exercise needs to handle deliberately.

Threat intelligence and red-team delivery are different jobs

In a TIBER-style engagement, threat intelligence is not decoration for the report. It should help choose the scenario, attacker profile, likely objectives, initial-access routes, tooling assumptions, and operational style. The red team then turns that intelligence into safe, controlled activity. Those are connected disciplines, but they are not interchangeable.

When reviewing providers, ask how they handle that handoff. How does threat intelligence become scenario design? How are assumptions documented? How are live-system risks handled? How does the red team avoid drifting into generic techniques that are easy to perform but not relevant to the threat story? Vague answers here usually lead to vague learning later.

Live-system risk needs explicit boundaries

Serious exercises need realism, but realism does not mean recklessness. Before testing starts, the institution should have clear boundaries around fragile systems, production constraints, destructive actions, data handling, supplier touchpoints, safety stops, and evidence collection. The point is not to remove all risk. The point is to understand and govern it.

Some actions may be executed fully. Some may be simulated after proof. Some may require white-team approval at the moment. The important thing is that these decisions are made before pressure rises. If the first serious go/no-go decision happens during active testing with unclear authority, the readiness gap is already showing.

Detection readiness is more than having tools

A TIBER-style exercise should test whether signals become decisions. That requires a basic understanding of logging coverage, alerting paths, retention, escalation, and response ownership before the exercise starts. If critical systems are not logging the right events, the replay may still be useful, but the active phase will mostly confirm a known blind spot.

The institution does not need perfect visibility to begin preparing. It does need honesty. Where are the blind spots? Which systems depend on supplier telemetry? Who can retrieve evidence? How long is it retained? What does the SOC see directly, and what only appears after asking another team?

The replay is where the hidden value lands

The active red-team phase creates evidence. The replay turns it into learning. A strong replay walks through the scenario path, the decisions the attacker made, the signals defenders saw or missed, the assumptions that failed, and the points where a small change would have altered the outcome. It should not become a victory lap for the red team or a blame session for defenders.

This is also where business value becomes visible. Technical teams can improve detection and hardening. Incident leaders can improve escalation. Executives can understand which decisions would matter during a real event. Suppliers can see where evidence or coordination broke down. The exercise earns its cost when those groups leave with work they can actually do.

If you are not formally in scope, the checklist still helps

Not every organisation needs a formal TIBER-BE engagement. The readiness questions are still useful for any serious red-team or adversary-simulation programme. If you cannot name the objective, form a capable white team, define boundaries, handle live-system risk, collect evidence, and run a replay, the exercise may still produce a story. It just may not produce much improvement.

Good simulations do not start with surprise. They start with disciplined preparation so that the surprise, when it comes, teaches something real.

If you are preparing for a TIBER-style exercise and want the scoping conversation to be practical instead of ceremonial, contact us. The earlier the white-team and scope questions are handled properly, the more value the exercise tends to produce.