Recommended resources
The freely available resources this lesson will direct you to.
Hello. The previous lesson gave you an OPSEC risk register for the hypothetical finance-workflow exercise. It identified what could go wrong with the supplied test credential, exercise infrastructure, approvals, and evidence. A register becomes useful during an operation only when its risks are connected to decisions: what must be verified before work begins, who can pause it, and what happens when conditions change.
This lesson turns the authorized objective—use the supplied test account to reach and observe a seeded marker—into a phased operation plan. You will place decision gates around the work, define how the control team distinguishes exercise activity from a real incident, and prepare contingencies that do not silently expand scope. This completes the planning-and-governance module; later modules will put these decisions into operator workflows.
Think in phases, but manage at gates
A phase describes what kind of work is underway. A gate asks whether the conditions for the next kind of work have actually been met. “Begin testing on Tuesday” is a schedule; “begin only after the control contact acknowledges the approved plan, infrastructure identifiers, and stop procedure” is an operational decision.
The TIBER-EU framework offers a useful model without being a template you must adopt wholesale. Its three official phases are preparation, testing, and closure. Within testing, threat intelligence and red-team planning precede active work; active work can be described as in, through, and out. The image expands that lifecycle into six practical decision points.
Our small, hypothetical exercise is not a TIBER-EU test. In particular, its short example schedule should not be mistaken for compliance with TIBER-EU’s minimum active-testing duration. Borrow the structure and governance logic, not an unearned claim of framework compliance.
Watch the brief planning distinction in HackerSploit’s Planning Red Team Operations | Scope, ROE & Reporting.
Planning Red Team Operations | Scope, ROE & Reporting
HackerSploit distinguishes levels of planning, which helps locate the operation plan between the engagement's rules and an operator's task-by-task instructions.
Watch planning layers, where the presenter separates engagement, operations, mission, and remediation plans. Focus on why an operation plan needs more than an objective and a calendar.
For the governance behind those layers, read the relevant passages of the European Central Bank’s TIBER-EU Framework. The assigned sections are short; you need the phase structure, plan approval, and authority to halt—not the surrounding regulatory process.
TIBER-EU Framework - European Central Bank
Read the European Central Bank's framework to see how an approved test plan and a control team keep a live exercise governable.
In Section 5.1, “High level process overview” (p. 23), read the phase definition and look at Figure 3 immediately below it. In Section 8.3, “Red Team Test Plan creation” (pp. 44–45), read plan creation. Start where the section explains how scenarios become a test plan; stop after the sentence specifying approval of the plan and subsequent changes. Notice the requirements for milestones, escalation contacts, risk controls, and approval. In Section 4.1.5, “Confidentiality and escalation procedures” (pp. 21–22), read escalation authority. Start with limiting awareness to a trusted group and stop after the explanation of trusted incident-escalation contacts. Pay particular attention to who can halt the test.
The distinction between planning a route and authorizing progress matters here. A credible route to the marker is not permission to keep trying every possible method until one works. The approved plan must say which route is permitted and when changed circumstances require a new decision.
Give each gate an owner, evidence, and a no-go outcome
A usable gate has four parts: a proposed next activity, evidence that its prerequisites hold, a named decision-maker, and an explicit outcome if they do not. “Check scope” is too vague. “The red-team lead compares the next system and action with the approved scope; if either differs, no action occurs until the control contact resolves it” can be followed under pressure.
The TIBER-EU Red Team Test Plan Guidance makes this more concrete. Read its selected requirements before examining the example plan.
TIBER-EU RED Team Test Plan Guidance
Read the European Central Bank's test-plan guidance for the information a phased plan must carry: communications, risk controls, fallback assistance, and a schedule tied to objectives.
In Section 2, “Required content of the RTTP” (p. 4), read required content. Begin with the communication-channels item and end with the final resources item. Notice that prerequisites and possible control-team assistance belong in the plan. In Sections 3.3.2, “Communication channels,” and 3.4, “Risk management” (pp. 6–7), read communications and controls. Begin with stakeholder updates and stop after the sensitive-artifact handling paragraph. Focus on retained approvals, urgent contact, and advance sharing of exercise identifiers for deconfliction. In Section 3.5, “Leg-up process” (pp. 7–8), read assistance rules. Begin with the reasons a team might be unable to progress and stop at the end of the subsection. Notice that assistance is agreed and prepared in advance, not invented by an operator at the roadblock. In Section 3.6, “Attack phase planning” (pp. 8–9), read phase scheduling. Begin with the need for a clear plan and stop after the example of conflicting internal activity. Focus on milestones, dependencies, and why dates may change.
TIBER-EU calls an authorized assist past a roadblock a leg-up. It can let a team test a later part of a scenario when an earlier part was blocked. A leg-up is not evidence that the earlier defense failed, and it is not something the red team grants itself. For this exercise, an example would be a control-team-approved way to resume the same finance-workflow test after the supplied account is blocked. Creating a different account or accessing real records would still be outside the stated permission.
A phased plan for the finance-workflow exercise
Treat the following as a draft for authorization, not as an approval already obtained. The control contact represents the small group authorized to manage and deconflict the exercise; the red-team lead manages operators. Each gate requires a recorded outcome. The “in, through, out” labels describe activity within this bounded scenario, not a requirement to perform lateral movement or real data extraction.
| Segment | Planned work and decision gate | If the gate fails |
|---|---|---|
| Preparation | Confirm written scope, supplied test account, marker definition, allowed window, prohibited actions, named control contact and backup, secure channels, and stop authority. Verify RI-01 through RI-04 safeguards from the OPSEC register rather than assuming they work. Gate: control contact records a go decision for planning and readiness. | Do not schedule active work. Assign owners and dates to unresolved safeguards. |
| Threat scenario | Match the selected adversary behaviors to the approved finance workflow. Remove any behavior that would require account changes, real-record collection, or security-control impairment. Gate: control contact agrees that the scenario still tests the authorized objective. | Revise the scenario; do not treat threat-profile realism as permission to widen scope. |
| Test plan and readiness | Record permitted actions, expected observations, operator assignments, infrastructure identifiers, activity-log location, checkpoints, and the proposed response to likely roadblocks. Check that the approved window has not changed. Gate: authorized approvers accept the plan and acknowledge how to pause and deconflict it. | No active testing. Record the missing approval or readiness evidence. |
| Active: in | At the approved time, use only the supplied test account and permitted entry path. Log operator, time, account assignment, and observed result. Gate: before continuing, verify that the observed access is on the approved system and attributable to the exercise. | Pause if the account, system, or activity cannot be reconciled. Escalate unexpected access. |
| Active: through | Follow only the approved finance workflow toward the seeded marker. Review scope at each change of system, action, or data visible to the operator. Gate: confirm that the next action remains permitted and that the control contact has not issued a hold. | Preserve the blocked or unexpected result. Request an approved alternative or leg-up if one was planned; do not improvise a new account or route. |
| Active: out | Observe the seeded marker, capture only the minimum agreed evidence, and end exercise activity on the approved path. “Out” here means a controlled end to the test interaction, not extraction of real finance data. Gate: reconcile actions and evidence with the objective and check for unintended material. | Stop further collection; protect what was already captured and escalate its disposition. |
| Closure | Reconcile operator and control-team timelines; document achieved and blocked objectives separately. Coordinate evidence retention and any necessary restoration with the authorized owners. Gate: control contact confirms active work has ended and open incidents or artifacts have owners. | Keep the matter open with a named owner; do not declare closure merely because operators have stopped. |
This table is deliberately condition-based rather than promising that every segment will occur on a particular date. Attach the authorized window and checkpoint times in the restricted working plan. A missed milestone prompts a decision; it does not extend authorization automatically.
The risk register supplies specific readiness evidence. RI-01 calls for an attributable test-account assignment; RI-02 for verified restrictions on exercise administration; RI-03 for tested primary and fallback approval channels; and RI-04 for a marker-only evidence process. A safeguard marked pending verification remains a reason for a no-go decision on the activity that depends on it.
Deconfliction is controlled comparison, not an instruction to ignore alerts
A blue-team alert during an authorized exercise can be valuable evidence. It can also resemble an unrelated attack. Deconfliction is the controlled process of determining which is which without disabling normal security response or prematurely exposing the exercise.
Before active work, the red-team lead gives the control contact the agreed exercise identifiers through the secure channel: approved infrastructure identifiers where applicable, assigned operators, test account, scope, time window, and a way to locate activity records. Keep the detailed list restricted and update it when the plan changes. The control contact acknowledges receipt; sending a message without confirmation is not a completed gate.
During an alert, the control contact can compare the reported time, asset, account, and observed behavior against the approved plan and operator log. The red team supplies a factual account of its activity, including uncertainty. If the event does not match, or if the evidence is inconclusive, treat it as a possible genuine incident under the agreed incident process. Do not label it “the exercise” merely because a test is underway.
Pre-agree these communications rules:
- Primary and fallback: name an authenticated secure channel and a separately tested fallback. Specify who can issue a hold or approve resumption.
- Acknowledgment: urgent instructions require acknowledgment. If authority or delivery cannot be confirmed, pause the affected activity.
- Decision record: retain the request, relevant observation, approver, decision, time, conditions, and plan version. A verbal discussion can be useful, but its resulting authorization needs a durable record.
- Blue-team independence: share enough with the control contact to manage risk; do not casually suppress alerts or direct defenders to stand down. The control contact manages any necessary disclosure under the engagement’s rules.
In a TIBER-EU test, the framework assigns particular approval and halt roles to its control team and test managers. In this hypothetical exercise, the actual written authorization determines the corresponding people. The transferable principle is that operators may pause for safety, but they may not authorize themselves to resume after a hold or enlarge scope.
Decide in advance what changes the plan
A contingency is a conditional decision, not a second unrestricted attack path. It should specify a trigger, an immediate safe action, an escalation owner, and what evidence is required to resume or close. These examples connect directly to the previous lesson’s risks:
| Trigger | Immediate action | Decision required |
|---|---|---|
| Supplied account is blocked or the approved path fails | Stop repeated attempts; log the block and preserve it as a defensive observation. | Control contact decides whether to end that path, adjust timing, or approve a documented leg-up within scope. Record that later results depended on assistance. |
| Defender reports suspected exercise activity | Pause only if the rules or control contact require it; provide the activity facts for comparison. | Control contact determines whether the event matches the test, whether defenders continue their normal process, and whether testing may proceed. Detection alone is not proof of failure or automatic permission to change tactics. |
| Real finance records appear instead of the seeded marker | Stop viewing and collecting; restrict access to any material already captured. | Control contact and evidence owner decide handling, incident escalation, and whether any marker-only activity can safely resume. |
| Approval channel fails or instructions conflict | Do not advance to the next action; use the authenticated fallback. | Authorized approver resolves the conflict and records a fresh go or no-go decision. |
| Exercise infrastructure shows unexpected access, or an asset lies outside scope | Stop using the affected path and preserve relevant records without probing the new asset. | Control contact coordinates incident handling or scope clarification. Resume only after the affected risk and authorization have been reassessed. |
For every change, update the plan version and the affected risk-register entry. A useful decision entry would record: checkpoint, observation, affected scope, current risk, options considered, decision-maker, decision and conditions, time, and evidence reference. That is enough for another operator to understand why the team continued, paused, or ended a path.
A final distinction prevents distorted reporting: if the original route was blocked and a leg-up enabled observation of the marker, report both facts. The exercise learned something about the earlier defense and about later workflow visibility. Calling the whole route an unassisted success would discard the first finding.
Conclusion
A phased operation plan ties an approved objective to controlled progress. Preparation establishes authority and safeguards; scenario and plan gates keep threat realism within scope; active in, through, and out checkpoints test the permitted path; closure reconciles activity and evidence. At every transition, record who decided, on what evidence, and what happens if the gate fails.
Deconfliction protects both the exercise and genuine incident response. Contingencies preserve learning when a path is blocked or conditions change, but they require explicit authority rather than operator improvisation. In the next module, you will begin building the scripting skills that can help maintain consistent operational records and automate bounded work in an authorized lab.