Is Execute an automation engine?

It is the initiation layer for control actions. Actions begin because a defined condition was met, under the approval pattern agreed for them, and the decision and the action are recorded together through Anchor.

What happens if a trigger misbehaves?

An explicit supervisory layer can pause, redirect or stop an action when human judgement needs to take over, and each action is constrained to the systems and operations the policy permits.

Does Execute act without approval?

Sensitive actions require the right approval before execution, not after the fact. Nothing destructive, privileged or boundary-altering happens without a named approver and a recorded decision.

Can Execute be paused entirely?

The supervisory override can pause, redirect or stop actions. Where appropriate, actions also have a defined undo path.

FV-04 ExecuteControl module · Control the path

The decision is made in advance. The action runs when it is needed.

Execute carries out control actions you have agreed beforehand: on an approved request, a schedule or a security alert. It sends the command out of band to Firebreak® hardware, so the action does not depend on the network that may be in trouble.

Book a Control demo See it in action

ExecuteControl the path

Module: FV-04 Execute
Family: Control the path
The question it answers: What runs, on whose trigger?
Acts through: Firebreak® at Layer 1
Command path: Out of band

What happens when

The alert arrives at 02:00. Nobody is sure who can act.

Detection tools are good at raising the alarm. What happens next often depends on who answers the phone.

02:00An alert fires.
Your SIEM sees unusual traffic heading for a critical system.
02:20Calls begin.
The on-call engineer needs approval to change anything and starts phoning managers.
03:10A rule is written.
An emergency change goes in an hour later, on a device that may itself be reachable.

An alert tells you something is wrong. Execute makes sure the agreed action happens.

See it in action

Three triggers. Switch between an ad hoc response and Execute.

The same operator request, schedule and alert, handled two ways.

Ad hoc responseWith Execute

Each trigger turns into calls and a manual change. Timing depends on who is awake.

Each trigger runs an action agreed in advance, sent out of band and recorded.

Step by step

Step 1Agree the actions
Decide which actions exist, on which paths, and what triggers each one.
Step 2Agree the approvals
Name who may approve each action and when approval is needed.
Step 3Trigger
An operator, schedule or alert starts the agreed action.
Step 4Record
The request, approval, command and result are recorded.

What Execute is

The module that acts, within rules you set.

Execute does not decide what is dangerous. It carries out the actions you agreed, through a path that stays independent.

Agreed actions
Every action is defined in advance, with its path and its effect.
Several triggers
Operator request, schedule or an approved security alert.
Out-of-band command
Commands travel separately from the network being controlled.

What it changes

A response that does not depend on who answers the phone.

Execute does not make an incident smaller on its own. It means the response you planned is the response that happens.

Execute record

Trigger · SIEM alertApproved by on-call leadRun
Schedule · Vendor path closePlanned window endedRun
Request · OperatorAwaiting second approvalPending
Review · Action listMonthly, signed offLogged

Planned actions. Recorded outcomes.

Agreed actions run on agreed triggers
Approvals are part of the action, not a phone call
Commands do not rely on the affected network
Every action has a full record

Where it fits

Fracture, Isolate and Execute answer different questions.

Fracture and Isolate decide whether connections exist. Execute does a different job, and most Plans use more than one module.

Module	Fracture	Isolate	Execute
The question it answers	Must this connection be physically disconnected now?	Which zones should never share a path?	What should run, on which trigger, and who approved it?
Normal state	Connected, with a crossing ready to be disconnected	Zones held apart, crossings closed by default	Ready, with actions and approvals agreed
When it acts	When a connection becomes dangerous	By design, before anything goes wrong	On an approved request, schedule or alert
What it ends	An incident travelling along a live path	Trust that exists only because systems share a network	Responses that depend on phone calls and emergency changes
Typical Plans	CP-01, CP-02	CP-04, CP-05, CP-14	CP-01, CP-02, CP-14

Control Plans and Blueprints

Where Execute does the work.

Execute is the module that turns a Plan into action. Plans marked Proposed are awaiting technical approval.

Control PlansTwenty Plans, each solving one problem.All Control Plans
Control BlueprintsIndustry solutions that combine Plans.All Control Blueprints
FracturePhysically disconnect a connection.See Fracture
IsolateHold zones apart by design.See Isolate

Questions

What network and security teams ask.

Want to see it on real hardware? We will show you.

Book a Control demo

Does Execute act on its own?

Only within the actions and triggers you agree. Whether an alert can trigger an action directly, or needs approval first, is your decision for each path.

How is Execute different from Fracture?

Fracture is the disconnection of a connection. Execute is how that, and other agreed actions, are triggered and commanded.

Which tools can trigger an action?

Integration with your SIEM or other tools is agreed during scoping. Nothing is assumed to be automatic.

How quickly does an action run?

It depends on command delivery, authorisation and the hardware. Timings are measured for each deployment, not promised in advance.

Your next step

See an agreed action run in front of you.

We will take one of your incident scenarios and show the action, the approval and the record.

Book a Control demo