Red teaming and adversary simulation
You have bought the tools. Somebody configured them. The dashboard is green. The question nobody in the organization can answer is whether any of it would actually fire — and if it fired, whether anyone would act on it within the window that matters.
The short version: this tests your response, not your vulnerabilities
A penetration test measures how many exploitable weaknesses exist; an adversary simulation measures whether your detection and response notice somebody using one. They are different products with different outputs, and buying the wrong one is the most common mistake in this part of the market.
The deliverable here is not a list of weaknesses. It is a timeline: what was done, at what time, what the environment recorded, what was raised as an alert, who saw it, what they did, and how long each step took. Against that timeline sits an improvement register, and most of the entries are about tuning, ownership and process rather than about buying anything.
When is this the right buy — and when is it not?
If there is no alerting, no log retention and nobody on call, a simulation will confirm what you already suspect, and readiness work or a penetration test buys more for the same money. The honest sequence for most organizations is: fix the configuration, test the build, build the response capability, then test the response capability. An exercise run out of that order produces an expensive document that says you would not have noticed, which you could have established in an afternoon.
The organizations that get the most from this have a security operations function — in-house or outsourced — a plan, and a genuine belief that they would catch an intruder. That belief is the thing being tested. Where it turns out to be true, you have evidence worth showing a board. Where it turns out to be false, you learn it on a Tuesday of your choosing.
If what you need is coverage of exploitable weaknesses, buy penetration testing. If what you need is a plan and a rehearsal, buy incident response readiness.
The three shapes an engagement takes
Objective-based
The engagement is defined by an outcome rather than by a target list: reach the customer database, obtain a specific document, move a payment, gain persistent access to the environment that holds the signing key. The objective is agreed with you in advance and written into the scope, because an objective chosen by the tester measures the tester’s imagination rather than your risk.
Assumed breach
The exercise starts from a position — a standard workstation, a valid account, a foothold in one segment — rather than spending the first two weeks earning it. This is usually the better purchase, because the initial access step is the part most likely to be blocked for reasons that say nothing about the rest of your defences, and because every day spent on it is a day not spent measuring what happens afterwards.
Purple team
The attack is replayed with your defenders watching, step by step, with the telemetry open in front of them. Each action is performed, the room looks for it, and where it is invisible the detection is written and tested on the spot. The improvement is immediate rather than deferred to a report, which is why this is the variant most organizations should end on even if they start elsewhere.
The timeline and the improvement register
Two artifacts carry the value. The first is a detection-and-response timeline, aligned so that every action taken sits beside what the environment saw, what it raised, and what the response was. Gaps are visible as gaps rather than as prose.
The second is an improvement register: one row per gap, with the detection or process change that closes it, the data source it depends on, an owner, and whether it was validated during the replay. Adversary behaviour is described at framework level using publicly documented tactics — MITRE ATT&CK for conventional systems and MITRE ATLAS where machine learning systems are in scope — so your defenders can map the findings onto work they may already be doing. Specific technique identifiers are not published on this site; they belong in the report, with your environment around them.
The written structure follows the same pattern as everything else here; see the sample report.
What is out of scope, and why
No pretext phone calls, no impersonation of named staff and no physical entry of any kind are performed on these engagements. That is a standing boundary on this practice, not a per-engagement negotiation.
The reasons are practical as much as legal. Pretext calls and impersonation of identified individuals put named employees in a position where they are deceived by someone their employer hired, and the fallout outlives the finding. Physical entry work sits squarely in a licensed field. Both can be commissioned elsewhere; neither is offered here, and the scope document says so in writing rather than leaving it to be assumed.
Security awareness training and phishing simulation programme design are in scope for this practice — as design and content, run by you — and they live on incident response readiness.
Authorization and scope, before anything starts
An adversary simulation is testing, and it is bounded the same way. The scope names the objectives, the environments, the dates and hours, the techniques excluded, the stop condition, and the small group who know the exercise is happening. Authorization is signed by whoever owns the systems. Where an engagement would extend into investigation or forensic work, that part is delivered with appropriately licensed partners where the law requires it, and no licence is claimed here that is not held.
Where an exercise touches systems a provider hosts, their published rules apply too and are checked against their current text at scoping.
Where specialists are brought in
Engagements are staffed for the environment in front of them, and vetted specialists are brought in per project where the scope calls for capability this practice does not hold directly. Who is doing what is stated in the scope document before the engagement starts, not discovered from the report.
Where the systems in scope include models and agents, the relevant work is LLM application penetration testing and agentic AI security, and the difference between attacking such a system and evaluating its behaviour is set out in AI red teaming versus safety evaluation.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
Testing and adversary simulation are carried out only with signed authorization, to a scope agreed in writing.
Investigation and forensic work is delivered with appropriately licensed partners where the law requires it.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
How is this different from a penetration test?
A useful test of which one you want: if the answer you need is a list, buy a test. If the answer you need is a time in minutes, buy a simulation.
Do our defenders know it is happening?
That is a decision made at scoping. A small number of people must always know, so the exercise can be stopped and so nobody calls law enforcement, and who else knows changes what the exercise measures. A fully blind exercise measures the response as it really is; a partly informed one measures capability without the surprise. Both are legitimate, and the report states which was bought.
Do you do social engineering?
Phishing content design and awareness material are a different product, delivered as programme design for you to run.
Are we mature enough for this?
Where the answer is no, the scoping reply says so and names the work that would come first — often ransomware readiness and resilience, which covers the controls an intruder has to get through before detection even matters.
Find out whether any of it would fire
Describe what you have deployed, who watches it and what an attacker would want. The reply says which of the three shapes fits, what it would measure and what you would receive — see also all security services.