Safe, repeatable execution of real attacker techniques against your live environment, establishing, technique by technique, whether each one is prevented, detected, merely logged, or missed entirely.

Run a simulation What it produces

Safe by construction

Techniques simulated, not weaponised

No live malware detonated

No production data touched or moved

Agreed scope, agreed windows

Reversible, with a clean-up step

A penetration test tells you what an attacker could exploit. Simulation tells you what your defences would do about it, which is a different question, and the one your security spend is supposed to answer.

The result

Every technique lands in one of four buckets

This is the entire value of the exercise. Not a risk rating or an opinion, a factual outcome per technique, repeatable next month to see whether it changed.

Prevented

The control blocked the technique outright. Nothing further was required.

Detected

It was not blocked, but an alert fired and reached somebody. Response time is measurable from here.

Logged only

Evidence exists in the logs, but nothing raised it. This is the largest category in almost every first run.

Missed

No prevention, no alert, no usable record. The technique would have proceeded unobserved.

The gap between logged only and detected is where most SOC improvement work comes from. The evidence was always there; nothing was watching for it.

Coverage

The full chain, not just the front door

Techniques mapped to MITRE ATT&CK and drawn from what is currently being used against your sector, executed across every stage an intrusion passes through.

01

Initial access

Phishing payload delivery, exploitation of exposed services, malicious attachments and credential use, executed against your real controls rather than described.

02

Execution & persistence

Script and command execution, scheduled tasks, service creation and registry persistence, the techniques a real intrusion uses to stay after it arrives.

03

Privilege escalation

Local and domain escalation attempts, token manipulation and credential dumping behaviour, tested against your endpoint and identity controls.

04

Defence evasion

Obfuscation, tooling that resembles legitimate administration, and tampering with logging and security agents.

05

Lateral movement

Remote execution, share enumeration and movement between segments, exercising internal monitoring and segmentation rather than assuming them.

06

Collection & exfiltration

Data staged and moved out over common channels, testing whether egress controls and leakage prevention actually fire on your traffic.

How it differs

Four assurance activities, four different questions

Simulation does not replace testing. It fills the eleven months between tests with continuous evidence about your controls.

Activity

What it answers

Cadence

Output

Vulnerability scan

What is unpatched or misconfigured

Continuous or scheduled

A list of weaknesses

Penetration test

What a skilled human could exploit

Once or twice a year

Exploitable findings with proof

Breach & attack simulation

Whether your controls stop or see known techniques

Continuously, safely, automated

A prevented / detected / missed score per technique

Red team

Whether your people would notice a patient adversary

Annually, covert, objective-led

Detection and response measured under real conditions

Why run it

Six things it settles

01

Prove the stack works

You have bought endpoint, network, email and identity controls. Simulation establishes which of them actually stop what they were purchased to stop.

02

Find the gaps between tools

Most misses sit in the seams: a technique the endpoint agent ignores because it assumes the network layer covers it, and vice versa.

03

Validate detection content

Every simulated technique that produces no alert is a detection rule your SOC does not have and did not know was missing.

04

Measure change over time

Run monthly, the score becomes the one security metric that improves visibly when you tune something.

05

Safe in production

Techniques are simulated, not weaponised. No malicious payload detonates and no production data is touched.

06

Evidence for the board

A percentage of known techniques prevented, trending upward, is a far better answer than a list of products owned.

The loop

Simulate, tune, re-simulate

A single run is a snapshot and a mildly uncomfortable meeting. The loop is what actually moves the number.

Step 1

Baseline

The first run, against the estate as it stands. Expect the prevented figure to be lower than the tooling inventory suggests.

Step 2

Analyse

Each missed and logged-only technique traced to a cause: coverage gap, policy in audit mode, missing detection content, or a tool doing less than assumed.

Step 3

Tune

Policies enforced, detection rules written, coverage extended. Changes made through your change process, not around it.

Step 4

Re-simulate

The same techniques run again to confirm the fix worked. This is the step that separates a report from an improvement.

Step 5

Expand

New techniques added as adversary behaviour changes, so the score reflects the current threat rather than last year’s.

Engagement model

Point-in-time assessment

A defined simulation across the attack chain, with a scored result per technique, root cause per gap and a prioritised tuning plan for your team to work through.

Talk to an engineer →

Engagement model

Continuous programme

Run on a monthly cadence with the technique set kept current, findings triaged, detection content built and the trend reported, either alongside your SOC or as part of ours.

Managed SOC →

Related

Get your first score.

One simulation across a defined segment tells you what percentage of known techniques your current stack prevents. Most clients are surprised twice.

Run a simulation Talk to an engineer

You own the controls. Nobody has confirmed they fire.